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

[Roman Shpount <[e-mail]>]

David,

You can look at open source projects such as pjsip,  Asterisk, Freeswitch,
linphone.

I am fairly certain they reset the ROC count if either IP address changes,
but you are free to double check.
_____________
Roman Shpount


On Wed, Oct 14, 2020 at 10:21 PM David Nguyen (davidtng) <[e-mail]>
wrote:

> Thanks Flemming.  Who can we reach out to in order to get further input
> regarding your comments?
>
> a) What they have actually implemented
> b) What they believe is the propoer solution here.
>
>
>
> Thanks,
> David
>
> *From: *Flemming Andreasen <[e-mail]>
> *Date: *Tuesday, October 13, 2020 at 6:27 PM
> *To: *"David Nguyen (davidtng)" <[e-mail]>, Roman Shpount <
> [e-mail]>
> *Cc: *RFC Errata System <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>,
> "Murray S. Kucherawy" <[e-mail]>, "[e-mail]" <
> [e-mail]>, Bo Burman <[e-mail]>, mmusic WG <
> [e-mail]>, "Patrick Kinane (pkinane)" <[e-mail]>,
> "Venkata Amudalapalli -X (vamudala - INFOSYS LIMITED at Cisco)" <
> [e-mail]>
> *Subject: *Re: [MMUSIC] [Technical Errata Reported] RFC4568 (6291)
>
>
>
>
>
> On 10/13/20 4:49 PM, David Nguyen (davidtng) wrote:
>
> Thanks Flemming.
>
>
>
> For the flow I posted in the Errata, which is also the reason for the
> Errata, your understanding is correct.  Due to Music on Hold (MOH) handling
> by CUCM, the c= IP address in the INVITE gets changed from IP1ofEXP to
> IP2ofMoH and then back to IP1ofEXP.  (The CUCM is only part of the
> signaling flow and not part of the actual media flow)  The problem is
> Expressway (or an IP phone) does not know about this IP address change and
> thus does not reset the crypto context/ROC for the media stream from SBC to
> EXP.
>
> Should the SBC in this case cache the crypto context from before the
> hold/resume to continue using it afterwards? (since they are using the same
> SSRC before and after hold/resume)
>
> It can do that as a workaround in this particular case, but it's not
> something that's defined in RFC 4568 (which, as noted below, doesn't seem
> to properly cover this call flow scenario).
>
> Thanks
>
> -- Flemming
>
>
>
>
> Thanks,
> David
>
>
>
> *From: *Flemming Andreasen <[e-mail]> <[e-mail]>
> *Date: *Tuesday, October 13, 2020 at 1:23 PM
> *To: *Roman Shpount <[e-mail]> <[e-mail]>
> *Cc: *RFC Errata System <[e-mail]>
> <[e-mail]>, "[e-mail]" <[e-mail]>
> <[e-mail]> <[e-mail]>, "[e-mail]"
> <[e-mail]> <[e-mail]> <[e-mail]>,
> "Murray S. Kucherawy" <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]>
> <[e-mail]> <[e-mail]>, Bo Burman
> <[e-mail]> <[e-mail]>, "David Nguyen
> (davidtng)" <[e-mail]> <[e-mail]>, mmusic WG
> <[e-mail]> <[e-mail]>
> *Subject: *Re: [MMUSIC] [Technical Errata Reported] RFC4568 (6291)
>
>
>
>
>
> On 10/12/20 6:25 PM, Roman Shpount wrote:
>
> Hi Flemming,
>
>
>
> As far as I know, and as far as I understand this text, if either offerer
> or answerer changes the IP address, a new master key should be sent in SDP
> (either offer or answer) and new crypto contexts where the ROC is set to
> zero should be created in BOTH directions.
>
> I agree this is what needs to happen (or alternatively we need another way
> of resetting the ROC), but I don't think the current text says exactly
> that. For example, if only the answerer changes it's IP-address, then by
> definition, the offerer will keep his master key for media he is sending to
> the answerer. What you could do at that point of course is to require
> another offer/answer exchange where the offerer needs to change it's media
> transport address, but that has some side effects that need to be
> considered as well (e.g. NAT traversal).
>
>
>
> The reasoning for this is a decomposed SIP gateway or working with B2BUA.
> In these cases, there is no guarantee that the same two endpoints
> communicate and that that the current ROC counter is known.
>
> Right - that's the problem. It would be good to hear from more people as
> to
> a) What they have actually implemented
> b) What they believe is the propoer solution here.
>
> Thanks
>
> -- Flemming
>
>
>
> Best Regards,
>
> _____________
> Roman Shpount
>
>
>
>
>
> On Mon, Oct 12, 2020 at 6:18 PM Flemming Andreasen <fandreas=
> [e-mail]> wrote:
>
> Sorry for the delay - it's been quite a while since I looked at SRTP and
> RFC 4568 in detail and hence it would be great if more people could take a
> closer look and chime in as well.
>
> In any case, please see below.
>
> On 9/16/20 1:46 PM, RFC Errata System 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]> <[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 ?
>
> Note that there is some asymmetry in the way SDP signaling is done in RFC
> 4568:
> - The transport address information (per normal SDP) refers to where media
> will be *received* (although in practice, symmetric RTP will lead to it
> being both the send and receive address)
> - The SRTP crypto parameters provided apply to media being *sent* by the
> endpoint that generated the SDP
>
> Furthermore, both the sender and receiver of SRTP media need to agree on
> the SRTP cryptographic context for a given SSRC.
>
> Having said that, the above text applies to media being generated (sent)
> by the offerer. The change in IP-address indicates that the offerer may not
> have access to the old cryptographic context parameters, and hence we must
> create a new one (on both the sending and receiving side).
>
>
>
>
> (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?
>
> If the offer transport address stays the same, then the cryptographic
> context also stays the same (unless any of the parameters were changed in
> the offer). In other words, the offerer does not change the SRTP crypto
> context for media sent to the answerer.
>
> Conversely, if the answerer sends back a new transport address, then a new
> crypto context will be created for media sent from the answerer to the
> offerer.
>
> Now, there seems to be a potential problem here, since if only the
> answerer changed his IP-address, then the answer endpoint may have changed,
> and chances are he does not have the crypto context parameters for media
> sent to him. The current text does not seem to adequately handle this
> scenario.
>
>
>
> 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?
>
> The current text treats each direction independently, and hence the answer
> is no (which as noted above can lead to problems).
>
> Note also that the above sentence is misleading when taken out of context:
> It is not the change in master key that causes the ROC to be reset to zero
> - it's the change in transport address as called out earlier in the
> paragraph for that sentence (if my re-read of SRTP [RFC 3711] is correct).
>
>
>
> 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?
>
> The document does not seem to adequately address this scenario. A couple
> of options come to mind:
> 1) If the offerer sees a change in transport address information (but it
> kept the old crypto context itself), it can change the SSRC for media
> packets it sends, thereby forcing a new "late binding" event with a ROC=0
> (RFC 4568, Section 6.4.1)
> 2) Update RFC 4568 to clarify how the above situation should be handled.
> It's not immediately obvious to me how we can do that without either
> a) introducing some additional form of signaling where we include the
> current ROC value from the offerer
> b) require another O/A exchange with a new transport address from the
> offerer (and hence a new crypto context)
>
>
>
> What is expected for IP address of 0.0.0.0 for hold, should this reset crypto context as well?
>
> The text does not treat 0.0.0.0 as a special IP-address, so yes.
>
>
>
> 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?
>
> It's a bit difficult to follow given the lack of call flow detail above,
> but since there was an IP-address change from IP2ofMoH to IP1ofEXP, RFC
> 4568 Section 7.1.4 would want a new crypto context for media *from* the
> EXP.
>
> In terms of media *to* the EXP, the SBC sees a change in IP-address
> information (from IP2ofMoH to IP1ofEXP), so it should create a new crypto
> context. However, from EXP's point of view, it may or may not have seen a
> change in IP-address when the change to IP2ofMoH was made. If it did, then
> things should be ok. If it did not, then we are in a situation that is not
> properly covered by RFC 4568 (as far as I can tell) and one the above
> suggestions will have to be considered.
>
> Thanks
>
> -- Flemming
>
>
>
> 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
>
> .
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
>
>