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

[Flemming Andreasen <[e-mail]>]

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
>