Subject: Re: [straw] WGLC: draft-ietf-straw-b2bua-dtls-srtp-06

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Sep 2015 23:04:30 +0100

On 21 Aug 2015, at 19:46, Christer Holmberg <[email-masked]> wrote:
> (As co-chair)
>  
> This e-mail is to inform that we have now initiated WGLC for draft-ietf-straw-b2bua-dtls-srtp-06.
>  
> https://tools.ietf.org/html/draft-ietf-straw-b2bua-dtls-srtp-06
>  
> We encourage the community to review the draft and provide comments on the list.
>  
> The WGLC will last for two weeks, and will end on Friday 4th September.

I have read this draft, and have some comments:

Section 1.1 says:

>                                          DTLS-SRTP is defined for point-
>    to-point media sessions, in which there are exactly two participants.
>    Each DTLS-SRTP session (described in Section 3 of [RFC5764]) contains
>    a single DTLS connection, and either two SRTP contexts (if media
>    traffic is flowing in both directions on the same 5-tuple) or one
>    SRTP context (if media traffic is only flowing in one direction).

Is this correct, or is it making assumptions about bundled RTCP that don't
necessarily hold? Section 3.1.1 (on page 5) suggests that non-multiplexed
RTCP requires an additional DTLS connection.

In Section 3.1.1, it might be helpful to clarify, for Figure 1, whether
the B2BUA can intercept the media (e.g., by modifying the signalling).

Section 3.1.2 (and its subsections) talks about a "media-aware relay".
Would a term like "RTP-aware media relay" be more appropriate, since it
only seems aware of the RTP and RTCP headers, not the underlying media?
Whatever term is used, the name needs to include "media relay", as that 
is the term defined in Section 3.1.1 (calling it a "Media-aware media
relay" would be consistent, but doesn't read well). Section 3.1.1
similarly shouldn't talk about "media relay", but rather "media-unaware
media relay" or "RTP-unaware media relay". The remainder of the draft 
will then need to be updated to match (in general, the terminology is
inprecise, and needs to be tightened up).

Sections 3.1.2, 3.1.2.1, and 3.1.2.2 can be read as being contradictory:
"may modify the headers", "does not modify the RTP and RTCP headers", and
"may also modify them". I'm not sure the distinction between media-aware
relays that modify the RTP/RTCP headers, and those that do not, it needed. 
However, if it is, then I suggest the last sentence of the introductory
paragraph of Section 3.1.2 ("A media-aware relay...") be changed to say
"There are two types of media-aware relay, those the merely inspect the
RTP and RTCP headers, and those that modify the RTP and RTCP headers";
and the headings of Section 3.1.2.1 and Section 3.1.2.2 be changed to
"Media-aware relays that inspect RTP and RTCP headers" and "Media-aware
relays that modify RTP and RTCP headers", or similar.

Section 3.1.2 (and its subsections) talks about "RTP and RTCP headers".
I understand what is an RTP header, but what is an RTCP header? RTCP 
doesn't have a distinction between headers and payload in the way RTP
does.

Section 3.1.2.1 says "MUST NOT terminate the DTLS-SRTP connection" and
Section 3.1.2.2 says "MUST NOT terminate the DTLS-SRTP sessions". Is a
connection the same as a session? If so, please use consistent terminology
("connection" is used in most of the rest of the draft).

For Section 3.1.2.1 and Section 3.1.2.2, what happens if the relay does
try to terminate the DTLS-SRTP connection? Perhaps a forward reference
to the Security Considerations section would be appropriate. 

Section 3.1.2.2 "may also modify them" - isn't the point that it can't
modify them? 

Section 3.1.2.2 refers to draft-jones-perc-private-media-reqts. That's
an individual draft that doesn't (yet) have working group consensus. I
suggest either waiting to reference the PERC working group draft, or
adding a "for example" here. 

In Section 5, can you clarify what is meant by "attempting to cover"?

In Section 5, can you expand on "unspecified and discouraged"? Are the
endpoints able to detect and/or prevent such attacks? How?

In Section 5, I was surprised there's no normative guideance on how the
endpoints can prevent a malicious B2BUA (presumably, media relay) from
intercepting the connection.

The document contains instances of lower-case RFC 2119 keywords on the
following lines:

24:   This document describes the behavior such B2BUAs should adhere to
117:   described in [RFC7092], these B2BUAs may modify SIP and SDP
118:   information.  They may also be present on the media path, in which
119:   case they may modify parts of the SDP information (like IP address,
136:   The following sections describe the behavior B2BUAs should follow in
275:   single port then only a single DTLS connection would be required
288:   of INVITE response may happen in parallel; thus, the B2BUA SHOULD be
302:   In the above example, Alice may be authorized by the authorization
316:   received SRTP and SRTCP packets and may modify the headers before
328:   relay may also modify them.  In order to modify headers a B2BUA needs
347:   DTLS-SRTP handshakes and SDP offer/answer exchanges [RFC3264] may
360:   an endpoint (offerer) may reach multiple remote endpoints.  As a
361:   result, multiple DTLS-SRTP connections may be established, one
432:   and media-unaware) should follow when acting on the media plane that
441:   data exchanged over it.  A malicious B2BUA may try to break into the

To ensure clarity around which are intended as normative requirements, it
might be worth revising the draft to either change them to upper case, or
to rephrase to avoid the lower-case RFC 2119 keywords.

Regards,
Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 5 Sep 2015 05:12:44 +0530

Hi Colin,

Thanks for the detailed comments.

Please read inline.

Thanks
Partha

> -----Original Message-----
> From: straw [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, September 03, 2015 3:35 AM
> To: Christer Holmberg
> Cc: [email-masked]; [email-masked]
> Subject: Re: [straw] WGLC: draft-ietf-straw-b2bua-dtls-srtp-06
> 

<Partha> This section is intended to provide the overview of DTLS-SRTP 
and the portion of text from Sec 3 of RFC 5764 is mentioned. There
is no other assumption here. To make it clear, the statement shall be 
added to refer sec 3 of RFC 5764 for more details. </Partha> 

> the B2BUA can intercept the media (e.g., by modifying the signalling).
<Partha> As mentioned in Sec 3.1.1 text, 

"A media relay, as defined in section 3.2.1 of [RFC7092], from an
   application layer point-of-view, forwards all packets it receives on
   a negotiated connection, without inspecting or modifying the packet
   contents."

The interception is not possible as per the above statement. In case it
Modify the signaling, those B2BUA will not fall under this type of B2BUA.
Please clarify whether you wish to have the statement that the media 
Interception in B2BUA is not possible in this type of B2BUA.

</Partha>

> inprecise, and needs to be tightened up).
<Partha> 
As long as "RTP-aware media relay" implies RTP/RTCP media aware Relay, 
I have no issue is in updating with the proposed terminology.
</Partha> 
 
> relays that modify RTP and RTCP headers", or similar.

<Partha> Agreed </Partha>

> doesn't have a distinction between headers and payload in the way RTP

<Partha> Agreed. Hope "RTP Headers and RTCP" will clarify 
the original intention. </Partha> 
 
> to the Security Considerations section would be appropriate.
<Partha> Agreed </Partha>

> Section 3.1.2.2 "may also modify them" - isn't the point that it can't
<Partha> I think that the complete statement shall be removed. The actual
Purpose is explained in line 2. Hope removing 1st statement will clarify.
</Partha>

> adding a "for example" here.
<Partha> I prefer "for example" approach. </Partha>

> to rephrase to avoid the lower-case RFC 2119 keywords.
<Partha> Agreed for avoiding lower-case RFC 2119 keywords in the next 
revision </Partha>

> Regards,
> Colin
> 
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

---

From: Colin Perkins <[email-masked]>
Date: Mon, 7 Sep 2015 13:07:22 +0100

On 5 Sep 2015, at 00:42, Parthasarathi R <[email-masked]> wrote:
>> Is this correct, or is it making assumptions about bundled RTCP that don't necessarily hold? Section 3.1.1 (on page 5) suggests that non-multiplexed RTCP requires an additional DTLS connection.
> 
> <Partha> This section is intended to provide the overview of DTLS-SRTP and the portion of text from Sec 3 of RFC 5764 is mentioned. There is no other assumption here. To make it clear, the statement shall be added to refer sec 3 of RFC 5764 for more details. </Partha> 

Sorry, but I think you misunderstood. Section 1.1 of your draft says there is only a single DTLS connection, but Section 3.1.1 says there can be either one or two DTLS connections, depending on whether RTP and RTCP multiplexing is in use. These two statement contradict each other (it seems the text in section 1.1 is assuming RTP and RTCP multiplexing is used, without saying so). 

>> In Section 3.1.1, it might be helpful to clarify, for Figure 1, whether the B2BUA can intercept the media (e.g., by modifying the signalling).
>> 
> The interception is not possible as per the above statement.

That statement says that it doesn't inspect or modify the packet content, not that it cannot inspect or modify them. If it cannot inspect or modify them, you need to say that explicitly. 

> In case it Modify the signaling, those B2BUA will not fall under this type of B2BUA. Please clarify whether you wish to have the statement that the media Interception in B2BUA is not possible in this type of B2BUA.

If that's the case, you need to say it explicitly.

> </Partha>
> 
>> Section 3.1.2 (and its subsections) talks about a "media-aware relay". Would a term like "RTP-aware media relay" be more appropriate, since it only seems aware of the RTP and RTCP headers, not the underlying media? Whatever term is used, the name needs to include "media relay", as that is the term defined in Section 3.1.1 (calling it a "Media-aware media relay" would be consistent, but doesn't read well). Section 3.1.1 similarly shouldn't talk about "media relay", but rather "media-unaware media relay" or "RTP-unaware media relay". The remainder of the draft will then need to be updated to match (in general, the terminology is inprecise, and needs to be tightened up).
>> 
> <Partha> 
> As long as "RTP-aware media relay" implies RTP/RTCP media aware Relay, I have no issue is in updating with the proposed terminology.
> </Partha> 

You can call it "RTP/RTCP-aware media relay" if you want. The important point is that it's called a "______ media relay", to use consistent terminology.

>> Sections 3.1.2, 3.1.2.1, and 3.1.2.2 can be read as being contradictory: "may modify the headers", "does not modify the RTP and RTCP headers", and "may also modify them". I'm not sure the distinction between media-aware relays that modify the RTP/RTCP headers, and those that do not, it needed. However, if it is, then I suggest the last sentence of the introductory paragraph of Section 3.1.2 ("A media-aware relay...") be changed to say "There are two types of media-aware relay, those the merely inspect the RTP and RTCP headers, and those that modify the RTP and RTCP headers"; and the headings of Section 3.1.2.1 and Section 3.1.2.2 be changed to "Media-aware relays that inspect RTP and RTCP headers" and "Media-aware relays that modify RTP and RTCP headers", or similar.
>> 
> 
>> Section 3.1.2 (and its subsections) talks about "RTP and RTCP headers". I understand what is an RTP header, but what is an RTCP header? RTCP doesn't have a distinction between headers and payload in the way RTP does.
> 
> <Partha> Agreed. Hope "RTP Headers and RTCP" will clarify the original intention. </Partha> 

"RTP Headers and RTCP Packets", perhaps?

>> Section 3.1.2.1 says "MUST NOT terminate the DTLS-SRTP connection" and Section 3.1.2.2 says "MUST NOT terminate the DTLS-SRTP sessions". Is a connection the same as a session? If so, please use consistent terminology ("connection" is used in most of the rest of the draft).
>> 
>> For Section 3.1.2.1 and Section 3.1.2.2, what happens if the relay does try to terminate the DTLS-SRTP connection? Perhaps a forward reference to the Security Considerations section would be appropriate.
>> 
>> Section 3.1.2.2 "may also modify them" - isn't the point that it can't modify them?
>> 
> <Partha> I think that the complete statement shall be removed. The actual Purpose is explained in line 2. Hope removing 1st statement will clarify. </Partha>

Yes.

>> Section 3.1.2.2 refers to draft-jones-perc-private-media-reqts. That's an individual draft that doesn't (yet) have working group consensus. I suggest either waiting to reference the PERC working group draft, or adding a "for example" here.
>> 

Fine.

>> In Section 5, can you expand on "unspecified and discouraged"? Are the endpoints able to detect and/or prevent such attacks? How?
>> 
>> In Section 5, I was surprised there's no normative guideance on how the endpoints can prevent a malicious B2BUA (presumably, media relay) from intercepting the connection.

Any response to these?

>> The document contains instances of lower-case RFC 2119 keywords on the following lines:
>> 
>> To ensure clarity around which are intended as normative requirements, it might be worth revising the draft to either change them to upper case, or to rephrase to avoid the lower-case RFC 2119 keywords.
>> 
> <Partha> Agreed for avoiding lower-case RFC 2119 keywords in the next revision </Partha>

Thanks.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 7 Sep 2015 16:04:59 +0000

Please see inline

-----Original Message-----
From: Colin Perkins <[email-masked]>
Date: Monday, 7 September 2015 5:37 pm
To: Parthasarathi R <[email-masked]>
Cc: Christer Holmberg <[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [straw] WGLC: draft-ietf-straw-b2bua-dtls-srtp-06
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>
Resent-Date: Monday, 7 September 2015 5:37 pm

>>> Is this correct, or is it making assumptions about bundled RTCP that
>>>don't necessarily hold? Section 3.1.1 (on page 5) suggests that
>>>non-multiplexed RTCP requires an additional DTLS connection.
>> 
>>and the portion of text from Sec 3 of RFC 5764 is mentioned. There is no
>>other assumption here. To make it clear, the statement shall be added to
>>refer sec 3 of RFC 5764 for more details. </Partha>
>
>Sorry, but I think you misunderstood. Section 1.1 of your draft says
>there is only a single DTLS connection, but Section 3.1.1 says there can
>be either one or two DTLS connections, depending on whether RTP and RTCP
>multiplexing is in use. These two statement contradict each other (it
>seems the text in section 1.1 is assuming RTP and RTCP multiplexing is
>used, without saying so).

 We will fix the Section 1.1 to indicate that there can be multiple DTLS
connections. I will send the updated text (diff) after updating the draft.

> 
>
>>> In Section 3.1.1, it might be helpful to clarify, for Figure 1,
>>>whether the B2BUA can intercept the media (e.g., by modifying the
>>>signalling).
>>> 
>That statement says that it doesn't inspect or modify the packet content,
>not that it cannot inspect or modify them. If it cannot inspect or modify
>them, you need to say that explicitly.

 Since DTLS-SRTP is end to end the B2BUA will not be able to inspect the
packet contents. Will add a explicit statement.

> 
>
>> In case it Modify the signaling, those B2BUA will not fall under this
>>type of B2BUA. Please clarify whether you wish to have the statement
>>that the media Interception in B2BUA is not possible in this type of
>>B2BUA.
>
>You can call it "RTP/RTCP-aware media relay" if you want. The important
>point is that it's called a "______ media relay", to use consistent
>terminology.

Works for me. We actually borrowed this terminology from the B2BUA
taxonomy RFC (RFC7092) which just says media-aware relay.

>>> Sections 3.1.2, 3.1.2.1, and 3.1.2.2 can be read as being
>>>contradictory: "may modify the headers", "does not modify the RTP and
>>>RTCP headers", and "may also modify them". I'm not sure the distinction
>>>between media-aware relays that modify the RTP/RTCP headers, and those
>>>that do not, it needed. However, if it is, then I suggest the last
>>>sentence of the introductory paragraph of Section 3.1.2 ("A media-aware
>>>relay...") be changed to say "There are two types of media-aware relay,
>>>those the merely inspect the RTP and RTCP headers, and those that
>>>modify the RTP and RTCP headers"; and the headings of Section 3.1.2.1
>>>and Section 3.1.2.2 be changed to "Media-aware relays that inspect RTP
>>>and RTCP headers" and "Media-aware relays that modify RTP and RTCP
>>>headers", or similar.
>>> 
>> 
>>> Section 3.1.2 (and its subsections) talks about "RTP and RTCP
>>>headers". I understand what is an RTP header, but what is an RTCP
>>>header? RTCP doesn't have a distinction between headers and payload in
>>>the way RTP does.
>> 

Sure. Will fix it.

>>>connection the same as a session? If so, please use consistent
>>>terminology ("connection" is used in most of the rest of the draft).
>>> 
>>> For Section 3.1.2.1 and Section 3.1.2.2, what happens if the relay
>>>does try to terminate the DTLS-SRTP connection? Perhaps a forward
>>>reference to the Security Considerations section would be appropriate.
>>> 
>> <Partha> I think that the complete statement shall be removed. The
>>actual Purpose is explained in line 2. Hope removing 1st statement will
>>clarify. </Partha>
>
>Yes.
>

This draft does not talk about the scenario where a B2BUA can terminate
DTLS-SRTP and hence act as DTLS proxy. This is some thing we removed after
discussions with security AD. This text is added to indicate that such a
behaviour (where B2BUA terminating DTLS-SRTP is discouraged)

>>>endpoints able to detect and/or prevent such attacks? How?

Endpoints can use Identity validation to detect the peer. The subsequent
text in Section 5 talks about it
³
A malicious B2BUA may try to break into the DTLS connection, but such an
attack can be prevented using the
   identity validation mechanism discussed in [I-D.ietf-stir-rfc4474bis].²

>>> 
>>> In Section 5, I was surprised there's no normative guideance on how
>>>the endpoints can prevent a malicious B2BUA (presumably, media relay)
>>>from intercepting the connection.

Will make the text in section 5 normative. Section 3.1.2.2 has normative
text that says that B2BUA MUST NOT terminate DTLS connections.

Regards,
Ram

>>> To ensure clarity around which are intended as normative requirements,
>>>it might be worth revising the draft to either change them to upper
>>>case, or to rephrase to avoid the lower-case RFC 2119 keywords.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 7 Sep 2015 16:49:26 -0400

> packet contents. Will add a explicit statement.

This depends on what you think "inspect" means. :-(

Certainly it can view the packet contents. But it can't, with just the 
info in the signaling and media, decode it to understand it.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 8 Sep 2015 03:05:47 +0000

-----Original Message-----
From: straw <[email-masked]> on behalf of Paul Kyzivat
<[email-masked]>
Date: Tuesday, 8 September 2015 2:19 am
To: "[email-masked]" <[email-masked]>
Subject: Re: [straw] WGLC: draft-ietf-straw-b2bua-dtls-srtp-06

>info in the signaling and media, decode it to understand it.

Yes. Agreed. Since SRTP keys are negotiated end to end the B2BUA in this
case would not be able to decode the payload.
I will word the sentence to not include inspect.

Ram

---

From: Colin Perkins <[email-masked]>
Date: Tue, 8 Sep 2015 15:47:23 +0100

Inline.

> On 7 Sep 2015, at 17:04, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 
> Please see inline
> 

Sure, I just don’t follow the grammar of the “attempting to cover” sentence. Can you rephrase it?

>   identity validation mechanism discussed in [I-D.ietf-stir-rfc4474bis].²

I sorry, but I don’t understand how this relates.

Fine.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 8 Sep 2015 17:17:36 +0000

(Removed the agreed ones. I will send the diffs soon)

Inline

-----Original Message-----
From: Colin Perkins <[email-masked]>
Date: Tuesday, 8 September 2015 8:17 pm
To: Cisco Employee <[email-masked]>
Cc: Parthasarathi R <[email-masked]>, Christer Holmberg
<[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [straw] WGLC: draft-ietf-straw-b2bua-dtls-srtp-06

>sentence. Can you rephrase it?

I will rephrase the sentence to:

NEW:

Attempting to cover media-aware relay modifying RTP headers and media
   termination scenarios involving secure sessions (like DTLS-SRTP) will
   inevitably lead to the B2BUA acting as a man-in-the-middle, and hence
   a B2BUA MUST NOT terminate DTLS-SRTP session.

Does this sound better ?

>I sorry, but I don’t understand how this relates.

 Endpoints or authentication service proxies involved in the
call uses the identity validation mechanisms discussed in [RFC4474bis]
to validate the identity of peers and detect malicious B2BUA's that may
attempt to terminate the DTLS connection to decrypt the RTP payload. Among
other things the 
Identity header digest takes in to consideration the a=fingerprint
attribute of SDP. So if a
endpoint computes identity header, a B2BUA on the path will not be able to
insert itself 
as DTLS proxy as changing a=fingerprint would cause identity validation
generated by endpoint to fail.

Ram

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Sep 2015 23:26:41 +0100

> On 8 Sep 2015, at 18:17, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 

Yes, that’s clearer. 

> generated by endpoint to fail.

Sure, but again, it’s not clear how the “unspecified and discouraged” text relates to this. If the rewrite suggested above removes “unspecified and discouraged” then that would address the concern. If not, you somehow need to link them.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 10 Sep 2015 03:11:11 +0000

Inline

-----Original Message-----
From: Colin Perkins <[email-masked]>
Date: Thursday, 10 September 2015 3:56 am
To: Cisco Employee <[email-masked]>
Cc: Parthasarathi R <[email-masked]>, Christer Holmberg

>Sure, but again, it’s not clear how the “unspecified and discouraged”
>text relates to this. If the rewrite suggested above removes “unspecified
>and discouraged” then that would address the concern. If not, you somehow
>need to link them.

In the new proposed text above, I have removed the words “unspecified and
discouraged”. 

Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 10 Sep 2015 10:02:59 +0000

Hi Colin,

Please find the diffs with the comments incorporated. Let me know if this
is fine. Also attached is txt version of draft.

WG, Please review the diffs.

Regards,
Ram

---

From: Colin Perkins <[email-masked]>
Date: Thu, 10 Sep 2015 14:21:23 +0100

Thats’s fine.
Colin

> On 10 Sep 2015, at 11:02, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 
> Hi Colin,
> 
> <Diff_ draft-ietf-straw-b2bua-dtls-srtp-06.txt - draft-ietf-straw-b2bua-dtls-srtp-07.txt.html><draft-ietf-straw-b2bua-dtls-srtp-07.txt>

-- 
Colin Perkins
https://csperkins.org/