Subject: [MMUSIC] [Technical Errata Reported] RFC4568 (6291)

From: RFC Errata System <[email-masked]>
Date: Wed, 16 Sep 2020 10:46:33 -0700 (PDT)

The following errata report has been submitted for RFC4568,
"Session Description Protocol (SDP) Security Descriptions for Media Streams".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6291

--------------------------------------
Type: Technical
Reported by: David Nguyen <[email-masked]>

Section: 7.1.4

Original Text
-------------
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.

Corrected Text
--------------

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?

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4568 (draft-ietf-mmusic-sdescriptions-12)
--------------------------------------
Title               : Session Description Protocol (SDP) Security Descriptions for Media Streams
Publication Date    : July 2006
Author(s)           : F. Andreasen, M. Baugher, D. Wing
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 21 Sep 2020 15:55:20 -0400

Hi David

It is indeed - we will take a closer look and get back to you.

Thanks

-- Flemming

On 9/21/20 12:45 PM, David Nguyen (davidtng) wrote:
> Hi All,
>
> I was just wondering if this mailing list is still active?
>
> Thanks,
> David
>
> On 9/16/20, 10:46 AM, "RFC Errata System" <[email-masked]> wrote:
>