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

[Flemming Andreasen <[e-mail]>]

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" <[e-mail]> wrote:
>
>      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 <[e-mail]>
>
>      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
>