RFC Errata
Found 2 records.
Status: Reported (2)
RFC 4568, "Session Description Protocol (SDP) Security Descriptions for Media Streams", July 2006
Source of RFC: mmusic (rai)
Errata ID: 6291
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Nguyen
Date Reported: 2020-09-16
Section 7.1.4 says:
If the offerer includes an IP address and/or port that differs from that used previously for a media stream (or FEC stream), the offerer MUST include a new master key with the offer (and in so doing, it will be creating a new crypto context where the ROC is set to zero). Similarly, if the answerer includes an IP address and/or port that differs from that used previously for a media stream (or FEC stream), the answerer MUST include a new master key with the answer (and hence create a new crypto context with the ROC set to zero). The reason for this is that when the answerer receives an offer or the offerer receives an answer with an updated IP address and/or port, it is not possible to determine if the other side has access to the old crypto context parameters (and in particular the ROC). For example, if one side is a decomposed media gateway, or if a SIP back-to-back user agent is involved, it is possible that the media endpoint changed and no longer has access to the old crypto context. By always requiring a new master key in this case, the answerer/offerer will know that the ROC is zero for this offer/answer, and any key lifetime constraints will trivially be satisfied too. Another consideration here applies to media relays; if the relay changes the media endpoint on one side transparently to the other side, the relay cannot operate as a simple packet reflector but will have to actively engage in SRTP packet processing and transformation (i.e., decryption and re- encryption, etc.). Finally, note that if the new offer is rejected, the old crypto parameters remain in place.
Notes:
(and in so doing, it
will be creating a new crypto context where the ROC is set to zero).
-Which crypto context for which direction? Logically this would be the crypto context for media towards the new IP address ?
(and hence
create a new crypto context with the ROC set to zero).
-What if the offerer stays the same and only the answerer changes the IP address?
New crypto context in direction towards new IP address?
By always requiring
a new master key in this case, the answerer/offerer will know that
the ROC is zero for this offer/answer,
-Is this resetting crypto context for both directions of media flow?
Is this section based on having offer and answerer both change the IP address.
What if the offerer did not change the IP address but the answerer does change it.
What is the expected behavior for media/crypto context/ROC for both sides?
What is expected for IP address of 0.0.0.0 for hold, should this reset crypto context as well?
How should all of this be handled for the case of switching to MoH server and then back to original call?
SBC ------------- CUCM ------------ EXP (signaling)
SBC --------------------------------- EXP (media stream 1)
SBC --------------------------------- MOH (media stream 2)
SBC ------------- CUCM ------------ EXP
<--------------------SDP with IP1ofEXP part of early offer from SBC
Crypto context for media towards EXP
<--------------------SDP with IP2ofMoH part of delayed offer from CUCM and additional early offer CUCM. CUCM initiates MoH signaling towards SBC.
Crypto context for media towards MoH (only SBC and MoH know about this)
<--------------------SDP with IP1ofEXP part of delayed offer from CUCM
Crypto context for media towards EXP. Should this be the same as the original if SSRC did not change for media from SBC towards Expressway?
Errata ID: 6808
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fritz
Date Reported: 2022-01-05
Section 9.2 says:
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" / "AES_CM_128_HMAC_SHA1_80" / srtp-crypto-suite-ext
It should say:
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_80" / "AES_CM_128_HMAC_SHA1_80" / srtp-crypto-suite-ext
Notes:
Section 6.2.3 uses 80 bit for F8 (IANA registration)