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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Please see inline for few responses.

-----Original Message-----
From: Ben Campbell <[e-mail]>
Date: Wednesday, 2 December 2015 at 12:10 AM
To: Alissa Cooper <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]" <[e-mail]>,
"[e-mail]" <[e-mail]>
Subject: Re: Alissa Cooper's Discuss on
draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

>(Commenting on discuss items 1 and 2. See separate email for comments on
>3).
>
>I think items 1 and 2 come down to having a clear scope and purpose.
>This version actually made progress in that direction (see section 1.2),
>but clearly didn't reach the goal.
>
>Normally, I I would favor making this informational, and removing the
>normative language. But on reflection, I see that the straw charter
>calls for describing normative requirements to make certain features
>work. In this case, the "certain feature" is e2e dtls-srtp.
>
>Alissa: Would it help if we clarified the scope along the following
>lines:
>
>- This draft defines certain behaviors that a b2bua needs to engage (or
>not engage) in in order to allow the "feature" of e2e dtls-srtp.
>
>- Define what we mean by e2e. I _think_ we are talking about end-user
>devices, and that we don't want to leave room for semantic games along
>the line of calling a b2bua an "end". (This would change the arguments
>around certain requirements, e.g."don't terminate srtp".)

Ok. We can add text like what Ben is suggesting to the draft if its going
to make it clearer.


>
>- Recognize that there are b2buas that intentionally do not allow e2e
>protection. We cannot stop those, and we don't need to get wrapped
>around reasons why or whether that's good or bad.

Agree. OTOH there are B2BUAs that do allow DTLS-SRTP end-to-end. See below
for some points on this.


>
>We would also need to be more consistent with the use of 2119 keywords.
>
>Authors/Shepherd/Chairs: Please indicate your thoughts. It would be
>really nice to have an idea of the way forward by Thursday's telechat.
>
>Thanks!
>
>Ben.
>
>
>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.


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