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

From: Flemming Andreasen <[email-masked]>
Date: Mon, 5 Oct 2020 18:15:22 -0400

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)" <[email-masked]>
> *Date: *Monday, October 5, 2020 at 12:07 PM
> *To: *"Flemming Andreasen (fandreas)" <[email-masked]>, RFC Errata 
> System <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Technical Errata Reported] RFC4568 (6291)
>
> Hi Flemming,
>
> I was just wondering if you heard anything regarding this?
>
> Thanks,
>
> David
>
> *From: *Flemming Andreasen <[email-masked]>
> *Date: *Monday, September 21, 2020 at 12:55 PM
> *To: *"David Nguyen (davidtng)" <[email-masked]>, RFC Errata 
> System <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *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"<[email-masked]>  <mailto:[email-masked]>  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<[email-masked]>  <mailto:[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, 12 Oct 2020 18:17:51 -0400

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:
> Reported by: David Nguyen <[email-masked]>
>
> Section: 7.1.4
>
> Original Text
> -------------
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).

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

>     -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).

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

> 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

> .

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Oct 2020 18:25:27 -0400

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

Best Regards,
_____________
Roman Shpount

On Mon, Oct 12, 2020 at 6:18 PM Flemming Andreasen <fandreas=
[email-masked]> wrote:

> RFC 4568 in detail and hence it would be great if more people could take a
> closer look and chime in as well.
>
> You may review the report below and at:https://www.rfc-editor.org/errata/eid6291
>
> Reported by: David Nguyen <[email-masked]> <[email-masked]>
>
> Section: 7.1.4
>
> Original Text
> -------------
> 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)
> 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
> 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.
>
> 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
> 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).
>
> packets it sends, thereby forcing a new "late binding" event with a ROC=0
> (RFC 4568, Section 6.4.1)
> 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:
> -------------
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 13 Oct 2020 16:23:24 -0400

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=[email-masked] 
> <mailto:[email-masked]>> 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.
>
>     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
>     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.
>
>     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
>     The current text treats each direction independently, and hence
>     the answer is no (which as noted above can lead to problems).
>
>     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).
>
>     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)
>
>     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:
>>     -------------
>     [email-masked] <mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 13 Oct 2020 21:27:11 -0400

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

> *Date: *Tuesday, October 13, 2020 at 1:23 PM
> *To: *Roman Shpount <[email-masked]>
> *Cc: *RFC Errata System <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "Murray S. Kucherawy" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, Bo Burman 
> <[email-masked]>, "David Nguyen (davidtng)" 
> <[email-masked]>, mmusic WG <[email-masked]>
> *Subject: *Re: [MMUSIC] [Technical Errata Reported] RFC4568 (6291)
>
>     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.
>
> 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).
>
>
>         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.
>
>         Note that there is some asymmetry in the way SDP signaling is
>         done in RFC 4568:
>         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
>
>         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
>
>         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).
>
>
>         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)
>
>
>         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.
>
>         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:
>
>             -------------
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 14 Oct 2020 23:01:37 -0400

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) <[email-masked]>
wrote:

> Thanks Flemming.  Who can we reach out to in order to get further input
> regarding your comments?
>
> *Date: *Tuesday, October 13, 2020 at 6:27 PM
> *To: *"David Nguyen (davidtng)" <[email-masked]>, Roman Shpount <
> [email-masked]>
> *Cc: *RFC Errata System <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>,
> "Murray S. Kucherawy" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Bo Burman <[email-masked]>, mmusic WG <
> [email-masked]>, "Patrick Kinane (pkinane)" <[email-masked]>,
> "Venkata Amudalapalli -X (vamudala - INFOSYS LIMITED at Cisco)" <
> [email-masked]>
> 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.
>
> hold/resume to continue using it afterwards? (since they are using the same
> SSRC before and after hold/resume)
>
> 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 <[email-masked]> <[email-masked]>
> *To: *Roman Shpount <[email-masked]> <[email-masked]>
> *Cc: *RFC Errata System <[email-masked]>
> <[email-masked]>, "[email-masked]" <[email-masked]>
> <[email-masked]> <[email-masked]>, "[email-masked]"
> <[email-masked]> <[email-masked]> <[email-masked]>,
> "Murray S. Kucherawy" <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]>
> <[email-masked]> <[email-masked]>, Bo Burman
> <[email-masked]> <[email-masked]>, "David Nguyen
> (davidtng)" <[email-masked]> <[email-masked]>, mmusic WG
> <[email-masked]> <[email-masked]>
> 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.
>

---

From: "Patrick Kinane (pkinane)" <[email-masked]>
Date: Tue, 20 Oct 2020 20:24:47 +0000

Hey Jeff,

I hope all is well. @David<mailto:[email-masked]> 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: [email-masked]<mailto:[email-masked]>
Phone: +1-919-574-6013
Cisco U.S. Contact Numbers: +1-800-553-2447 or +1-408-526-7209
Cisco Worldwide Contact: http://www.cisco.com/c/en/us/support/web/tsd-cisco-worldwide-contacts.html
-------------------------------------------
Team Lead: Bryan Johnson
Phone: +1-919-392-2297
Email: [email-masked]<mailto:[email-masked]>
-------------------------------------------
Direct Manager: Chris Phillips
Phone: +1-919-392-4013
Email: [email-masked]<mailto:[email-masked]>
-------------------------------------------
Looking for an instant update on your case?
Connect with me via TAC Connect Bot!
Teams: mailto:[email-masked] or learn more here.

From: Roman Shpount <[email-masked]>
Sent: Wednesday, October 14, 2020 11:02 PM
To: David Nguyen (davidtng) <[email-masked]>
Cc: Flemming Andreasen (fandreas) <[email-masked]>; RFC Errata System <[email-masked]>; [email-masked]; [email-masked]; Murray S. Kucherawy <[email-masked]>; [email-masked]; Bo Burman <[email-masked]>; mmusic WG <[email-masked]>; Patrick Kinane (pkinane) <[email-masked]>; Venkata Amudalapalli -X (vamudala - INFOSYS LIMITED at Cisco) <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 13, 2020 at 6:27 PM
To: "David Nguyen (davidtng)" <[email-masked]<mailto:[email-masked]>>, Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: RFC Errata System <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Bo Burman <[email-masked]<mailto:[email-masked]>>, mmusic WG <[email-masked]<mailto:[email-masked]>>, "Patrick Kinane (pkinane)" <[email-masked]<mailto:[email-masked]>>, "Venkata Amudalapalli -X (vamudala - INFOSYS LIMITED at Cisco)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC4568 (6291)

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 <[email-masked]><mailto:[email-masked]>
Date: Tuesday, October 13, 2020 at 1:23 PM
To: Roman Shpount <[email-masked]><mailto:[email-masked]>
Cc: RFC Errata System <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "Murray S. Kucherawy" <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Bo Burman <[email-masked]><mailto:[email-masked]>, "David Nguyen (davidtng)" <[email-masked]><mailto:[email-masked]>, mmusic WG <[email-masked]><mailto:[email-masked]>
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC4568 (6291)

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=[email-masked]<mailto:[email-masked]>> 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.

Type: Technical

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

Section: 7.1.4

Original Text

-------------

   encryption, etc.).

Corrected Text

--------------

Notes

-----

(and in so doing, it

    -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

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

   -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).

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)

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:

-------------

Stream              : IETF

Verifying Party     : IESG

.

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic