RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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?

Report New Errata