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

["Patrick Kinane (pkinane)" <[e-mail]>]

Hey Jeff,

I hope all is well. @David<mailto:[e-mail]> wanted to know your input from the phone side for this:

“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. 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."

Respectfully,

Patrick Kinane - CCIE Collaboration #58284
Technical Consulting Engineer
Global CX Centers - Collaboration Support Services
Standard business hours: 8am – 5pm ET or 12pm – 9pm UTC
Email: [e-mail]<mailto:[e-mail]>
Phone: [phone]
Cisco U.S. Contact Numbers: [phone] or [phone]
Cisco Worldwide Contact: http://www.cisco.com/c/en/us/support/web/tsd-cisco-worldwide-contacts.html
-------------------------------------------
Team Lead: Bryan Johnson
Phone: [phone]
Email: [e-mail]<mailto:[e-mail]>
-------------------------------------------
Direct Manager: Chris Phillips
Phone: [phone]
Email: [e-mail]<mailto:[e-mail]>
-------------------------------------------
Looking for an instant update on your case?
Connect with me via TAC Connect Bot!
Teams: mailto:[e-mail] or learn more here.

From: Roman Shpount <[e-mail]>
Sent: Wednesday, October 14, 2020 11:02 PM
To: David Nguyen (davidtng) <[e-mail]>
Cc: Flemming Andreasen (fandreas) <[e-mail]>; RFC Errata System <[e-mail]>; [e-mail]; [e-mail]; Murray S. Kucherawy <[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)

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]<mailto:[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]<mailto:[e-mail]>>
Date: Tuesday, October 13, 2020 at 6:27 PM
To: "David Nguyen (davidtng)" <[e-mail]<mailto:[e-mail]>>, Roman Shpount <[e-mail]<mailto:[e-mail]>>
Cc: RFC Errata System <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Murray S. Kucherawy" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Bo Burman <[e-mail]<mailto:[e-mail]>>, mmusic WG <[e-mail]<mailto:[e-mail]>>, "Patrick Kinane (pkinane)" <[e-mail]<mailto:[e-mail]>>, "Venkata Amudalapalli -X (vamudala - INFOSYS LIMITED at Cisco)" <[e-mail]<mailto:[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]><mailto:[e-mail]>
Date: Tuesday, October 13, 2020 at 1:23 PM
To: Roman Shpount <[e-mail]><mailto:[e-mail]>
Cc: RFC Errata System <[e-mail]><mailto:[e-mail]>, "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, "Murray S. Kucherawy" <[e-mail]><mailto:[e-mail]>, "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, Bo Burman <[e-mail]><mailto:[e-mail]>, "David Nguyen (davidtng)" <[e-mail]><mailto:[e-mail]>, mmusic WG <[e-mail]><mailto:[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]<mailto:[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]><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 ?
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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic