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

[Flemming Andreasen <[e-mail]>]

Hi David

I have not heard from anybody else on this. I will try to take a closer 
look this week and get back to you.

Thanks

-- Flemming

On 10/5/20 4:23 PM, David Nguyen (davidtng) wrote:
>
> ++ Venkata
>
> Thanks,
> David
>
> *From: *"David Nguyen (davidtng)" <[e-mail]>
> *Date: *Monday, October 5, 2020 at 12:07 PM
> *To: *"Flemming Andreasen (fandreas)" <[e-mail]>, RFC Errata 
> System <[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [Technical Errata Reported] RFC4568 (6291)
>
> Hi Flemming,
>
> I was just wondering if you heard anything regarding this?
>
> Thanks,
>
> David
>
> *From: *Flemming Andreasen <[e-mail]>
> *Date: *Monday, September 21, 2020 at 12:55 PM
> *To: *"David Nguyen (davidtng)" <[e-mail]>, RFC Errata 
> System <[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [Technical Errata Reported] RFC4568 (6291)
>
> 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]>  <mailto:[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]>  <mailto:[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
>
>       
>
>
>
>