Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

> On Dec 2, 2015, at 8:14 AM, Ram Mohan R (rmohanr) <[e-mail]> wrote:
>> 
>> 
>> On 30 Nov 2015, at 22:58, Alissa Cooper wrote:
>> 
>>> Alissa Cooper has entered the following ballot position for
>>> draft-ietf-straw-b2bua-dtls-srtp-09: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut
>>> this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to 
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> (1)
>>> I have a fairly fundamental concern about this document that I'd like
>>> to
>>> discuss. My impression is that most B2BUAs in the market today that
>>> handle DTLS-SRTP do so with the explicit purpose of accessing the
>>> media.
>>> That is, if I need a box that doesn't access the media I use a SIP
>>> proxy,
>>> and if I need one that does access it I use a B2BUA. I realize that
>>> there
>>> are more flavors of B2BUA defined in RFC 7092, but in terms of how
>>> real
>>> SBCs work, it seems to me that they break DTLS-SRTP intentionally if
>>> they
>>> do so at all.
> 
> I am aware of B2BUAs that pass-through SRTP (in this case DTLS-SRTP) end to
> end as well. In several deployments B2BUAs/SBCs are used for address
> hiding / media latching (as described in
> https://tools.ietf.org/html/rfc7362).
> In these scenarios the B2BUAs will be in media path as well but it just
> changes the UDP/IP headers and relay the UDP payload as is with out
> inspecting/modifying payload.
> 
> 
>>> 
>>> If that's the case, the question then arises about the value of
>>> writing
>>> down normative recommendations that are more than likely to be
>>> ignored.
>>> Perhaps this document would have made more sense as informational,
>>> offering a non-normative explanation of what a B2BUA should do if it
>>> does
>>> not want to break e2e security. Even as an informational document it's
>>> still not obvious to me that there is much at all to say here for
>>> media-aware B2BUAs that isn't entirely reductive -- "don't terminate
>>> DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an
>>> informational document it wouldn't be suggesting normative
>>> requirements
>>> that are out of sync with real deployments.
>>> 
>>> Could you articulate the reasons why someone would build a B2BUA that
>>> follows the recommendations in this draft?
> 
> B2BUAs used in deployments like the above mentioned scenarios can use the
> recommendations in this draft.

Ok. What I am still missing is why this draft needs to be published to make that happen. This is the type of SBC to which the Section 3.1.1 guidance is directed. How does the behavior of existing media-latching SBCs differ from what 3.1.1 tells them to do? And if this type of SBC implementation is the key target audience, doesn’t that make the 3.1.2 guidance essentially no-ops?

Alissa

> 
> 
>>> I note that the draft says
>>> nothing about using a TURN server as a media relay, which seems like
>>> it
>>> would be more common than using a B2BUA for the same purpose.
> 
> Not all endpoints support ICE yet which is one of the reasons
> B2BUAs are used for simple media latching as well (described in RFC7362).
> 
> 
>>> Aren't
>>> B2BUAs typically deployed *because* they are media-aware?
> 
> They can be media-aware or can just switch the media with out being aware
> of media as well.
> 
> Regards,
> Ram
> 
>>> 
>>> (2)
>>> Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 are
>>> problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement
>>> for
>>> inspection B2BUAs without explaining what the exception cases are, and
>>> 3.1.2.2 creates no normative requirements for modification B2BUAs.
>>> It's
>>> not even clear to me why the distinction is being drawn between the
>>> two
>>> kinds of B2BUAs if the bottom line is that in both cases the
>>> recommendation is to not terminate DTLS-SRTP. But this brings us back
>>> to
>>> the above comment. The problem here seems to be that what the WG and
>>> the
>>> IETF would want to say here is that B2BUAs MUST NOT terminate
>>> DTLS-SRTP
>>> to man-in-the-middle the media, but that is what B2BUAs generally do,
>>> so
>>> instead the text waffles and the recommendations are watered down and
>>> unclear.
>>> 
>>> (3)
>>> The characterization of the RFC 4474 mechanism seems to contradict the
>>> way the mechanism is actually specified. The 4474 mechanism was
>>> designed
>>> such that intermediaries would be able to provide signatures on behalf
>>> of
>>> users (e.g., see RFC 4474 Section 3, "This specification allows either
>>> a
>>> user agent or a proxy server to provide identity services and to
>>> verify
>>> identities ... in the initial use of this mechanism, it is likely that
>>> intermediaries will instantiate the authentication service role"). So
>>> the
>>> claim that terminating DTLS-SRTP would cause 4474 identity and
>>> integrity
>>> checks to fail isn't true, because an SBC can decrypt and re-sign the
>>> request itself. A B2BUA that bridges two administrative domains can
>>> check
>>> the validity of the signature in the domain on on side as
>>> authorization
>>> to form a new signature that is valid in the domain in the other side.
>>> 
>>> The fact that user-provided identity assertions are not guaranteed to
>>> persist end-to-end is one key reason for the ongoing work in the STIR
>>> WG.
>>> The work there and elsewhere shows that it's fairly widely
>>> acknowledged
>>> that 4474 has not seen the deployment that was hoped for when it was
>>> specified. Making its use a normative requirement here again seems out
>>> of
>>> sync with deployment reality. I would encourage you to review
>>> draft-ietf-stir-rfc4474bis and reconsider what security mechanism
>>> should
>>> form the basis of the recommendations in this draft.
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Section 3.1.1:
>>> 
>>> Is there anything new being specified here that isn't already
>>> specified
>>> in other SIP documents?
>>> 
>>> Section 3.2:
>>> 
>>> Is this saying anything that RFC 5763 doesn't already say?
>