Subject: [MMUSIC] draft-uberti-mmusic-nombis and (D)TLS

From: Ari Keränen <[email-masked]>
Date: Sat, 21 Mar 2015 19:38:50 -0500

Hi,

When we discussed this idea in the previous meetings, it was noted that 
there could be issues with (D)TLS being normally bound to a single 5-tuple.

I didn't see anything on this mentioned in the draft. Should that be 
addressed here too?

Cheers,
Ari

---

From: Justin Uberti <[email-masked]>
Date: Sun, 22 Mar 2015 01:12:04 +0000

I think this is a bigger issue than just this document. It's been discussed
a bunch in rtcweb - I need to look at what the conclusion was, but the plan
iirc was to discuss this *somewhere* this week.
On Sat, Mar 21, 2015 at 5:39 PM Ari Keränen <[email-masked]>

---

From: Ari Keränen <[email-masked]>
Date: Sun, 22 Mar 2015 00:56:32 -0500

OK. If you can report back on the result of that discussion (e.g., on 
the Friday MMUSIC session), that would be great.

Thanks,
Ari

On 21/03/15 20:12, Justin Uberti wrote:
> I think this is a bigger issue than just this document. It's been
> discussed a bunch in rtcweb - I need to look at what the conclusion was,
> but the plan iirc was to discuss this *somewhere* this week.
> On Sat, Mar 21, 2015 at 5:39 PM Ari Keränen <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 22 Mar 2015 03:59:41 -0700

I do not think this document is the natural place to put this information, since it is basic to the operation of WebRTC. 

IMHO, this should be in one of the RTCWEB security documents.

> On Mar 21, 2015, at 17:38, Ari Keränen <[email-masked]> wrote:
> 
> Hi,
> 
> When we discussed this idea in the previous meetings, it was noted that there could be issues with (D)TLS being normally bound to a single 5-tuple.
> 
> I didn't see anything on this mentioned in the draft. Should that be addressed here too?
> 
> 
> Cheers,
> Ari
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Mar 2015 00:08:03 +0000

Hi,

>IMHO, this should be in one of the RTCWEB security documents.

If the scope is wider than WebRTC, then it should not be in a RTCWEB document.

What was discussed in RTCWEB was to, instead of binding a DTLS connection to a 5-tuple, bind it to a "virtual connection". A "virtual connection" would be the set of all candidate pairs associated with a.... something. 

Whether "something" is an m- line, a BUNDLE group, a complete SDP, or something else, hasn't been discussed - as far as I remember (please correct me if I'm wrong).

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sun, 22 Mar 2015 21:10:25 -0400

On Sun, Mar 22, 2015 at 8:08 PM, Christer Holmberg <
[email-masked]> wrote:

>
> What was discussed in RTCWEB was to, instead of binding a DTLS connection
> to a 5-tuple, bind it to a "virtual connection". A "virtual connection"
> would be the set of all candidate pairs associated with a.... something.
>
> Whether "something" is an m- line, a BUNDLE group, a complete SDP, or
> something else, hasn't been discussed - as far as I remember (please
> correct me if I'm wrong).
>
>
I was proposing that "something" is ICE ufrag, i.e. all 5-tuples for which
a ICE/STUN bind request with the particular ufrag is received gets
associated with the same "virtual" connection.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Sun, 22 Mar 2015 20:56:33 -0700

Alas, an ICE ufrag doesn't uniquely identify an ICE virtual connection;
with ICE forking you can have N virtual connections from the same ufrag.

A lfrag:rfrag tuple is closer, but even this does not work, because a) an
ICE restart changes lfrag/rfrag without invalidating the connection, and b)
because a ufrag can be shared across multiple m= lines (and thereby ICE
connections).

The closest thing is m-line, keeping in mind that bundled m-lines use the
virtual connection of the m-line onto which they are bundled.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 23 Mar 2015 04:08:22 +0000

The virtual connection is, I think, a single component of what RFC 5245 and draft-ietf-mmusic-rfc5245bis-04 call a “media stream”.  (This will be clearer, I think, if you think about non-muxed RTP/RTCP.)

Unfortunately, the “ICE media stream" terminology in 5245 conflicts rather badly with the RTP Taxonomy, so we may want to come up with something better.

In SDP, the virtual connection is identified by a BUNDLE group if you’re using BUNDLE, or an m-line if not; and in either case sharing the same component ID, and considering both sides of the offer/answer exchange (to handle forking cases).

On Mar 22, 2015, at 10:56 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

Alas, an ICE ufrag doesn't uniquely identify an ICE virtual connection; with ICE forking you can have N virtual connections from the same ufrag.

A lfrag:rfrag tuple is closer, but even this does not work, because a) an ICE restart changes lfrag/rfrag without invalidating the connection, and b) because a ufrag can be shared across multiple m= lines (and thereby ICE connections).

The closest thing is m-line, keeping in mind that bundled m-lines use the virtual connection of the m-line onto which they are bundled.

On Sun, Mar 22, 2015 at 6:10 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Mar 22, 2015 at 8:08 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

I was proposing that "something" is ICE ufrag, i.e. all 5-tuples for which a ICE/STUN bind request with the particular ufrag is received gets associated with the same "virtual" connection.
_____________
Roman Shpount

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Mar 2015 14:05:49 +0000

Hi,

Even without forking, all candidate pairs associated with the virtual connection have to be handled at the same DTLS stack/physical device.

For example, two m- lines (non-bundled) could be associated with separate physical devices, so you would need separate DTLS connections.

Regards,

Christer

From: Jonathan Lennox [mailto:[email-masked]]
Sent: 23 March 2015 06:08
To: Justin Uberti
Cc: Roman Shpount; Christer Holmberg; Ari Keränen; [email-masked]; mmusic
Subject: Re: [MMUSIC] draft-uberti-mmusic-nombis and (D)TLS

The virtual connection is, I think, a single component of what RFC 5245 and draft-ietf-mmusic-rfc5245bis-04 call a "media stream".  (This will be clearer, I think, if you think about non-muxed RTP/RTCP.)

Unfortunately, the "ICE media stream" terminology in 5245 conflicts rather badly with the RTP Taxonomy, so we may want to come up with something better.

In SDP, the virtual connection is identified by a BUNDLE group if you're using BUNDLE, or an m-line if not; and in either case sharing the same component ID, and considering both sides of the offer/answer exchange (to handle forking cases).

---

From: Simon Perreault <[email-masked]>
Date: Mon, 23 Mar 2015 10:06:15 -0500

Le 2015-03-22 22:56, Justin Uberti a écrit :
> The closest thing is m-line, keeping in mind that bundled m-lines use
> the virtual connection of the m-line onto which they are bundled.

Would that handle forks?

Simon

---

From: Roman Shpount <[email-masked]>
Date: Mon, 23 Mar 2015 11:24:28 -0400

> virtual connection of the m-line onto which they are bundled.
Would ICE restart cause new DTLS handshake? If it does not, what is the
appropriate transport parameter change that will cause the new DTLS
handshake?

When you say m= line, how would the end point associate received packets
with the specific m= line? To handle forks this has to be local m= line and
remote m=line pair, but what does this translate into on the RTP/DTLS
transport layer? Do you propose to associate based on remote ufrag, local
ufrag and the set of local candidates associated with this m= line? Would
it not be simpler to prohibit ufrag reuse?

P.S. If ICE restart would cause the new DTLS connection to be established
this would either mean the same candidates cannot be used after ICE restart
or that an end point can receive packets for several unrelated DTLS
connections over the same 5-tuple. Same old mess all over again.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Mon, 23 Mar 2015 14:54:24 -0700

> appropriate transport parameter change that will cause the new DTLS

No, ICE restart does not rehandshake (it's orthogonal). There is currently
no SDP parameter defined that allows for a rehandshake, except for offering
a new fingerprint; use of the a=connection attribute is explicitly
forbidden by 5763.

> it not be simpler to prohibit ufrag reuse?

For unbundled cases this is non-ambiguous. For bundled cases, there is the
mid header extension.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 23 Mar 2015 18:04:19 -0400

> a new fingerprint; use of the a=connection attribute is explicitly

I think this was changed in the latest data channel draft, where it is
specified that fingerprint must not change unless the underlying transport
changes as well. The problem is that you cannot start a new DTLS session
unless it can be de-muxed from the previous sessions based on the transport
parameters. This means a new "virtual" channel for each new DTLS setup.
Which in turn means that there should be a way to identify which "virtual"
channel each packet belongs to based on the 5-tuple, with information
received during ICE handshake used to associate each 5-tuple with the
specific "virtual" channel. More then one 5-tuple can form a single virtual
channels but each 5-tuple can belong to one "virtual" channel at any given
time.

> For unbundled cases this is non-ambiguous. For bundled cases, there is the
How does the mid header extension helps with DTLS packet de-multiplexing in
cases of DTLS-SRTP handshake or data channel?
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Mon, 23 Mar 2015 17:17:43 -0500

On Mon, Mar 23, 2015 at 5:04 PM, Roman Shpount <[email-masked]> wrote:

>> No, ICE restart does not rehandshake (it's orthogonal). There is
>> currently no SDP parameter defined that allows for a rehandshake, except
>> for offering a new fingerprint; use of the a=connection attribute is
>> explicitly forbidden by 5763.
>>
>
>> For unbundled cases this is non-ambiguous. For bundled cases, there is
>> the mid header extension.
>>
>>>
>>>
> How does the mid header extension helps with DTLS packet de-multiplexing
> in cases of DTLS-SRTP handshake or data channel?
>

This would only be an issue if multiple DTLS connections were multiplexed
over a single ICE transport. I'm not aware of any need for this, compared
to the clear need for muxing multiple RTP streams.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 23 Mar 2015 18:32:32 -0400

> to the clear need for muxing multiple RTP streams.

How would you deal with multiple DTLS handshakes for DTLS-SRTP?

My understanding was that in case of bundled channels, all channels go over
the same "virtual" ICE channel, get decoded by the single DTLS-SRTP
session, and then get demuxed using mid header, payload type, SSRC, or some
other RTP level field. In any case, all these bundled m= lines share the
same "virtual" transport channel. There can be, one data channel which
shares this single "virtual" transport with all those RTP streams. In any
case, mid header extensions, SSRC, and payload are irrelevant to binding
packets to the "virtual" transport, since in case of DTLS-SRTP encoded
media, packets would need to be de-muxed before any of those fields can be
determined.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Mon, 23 Mar 2015 18:06:34 -0500

> How would you deal with multiple DTLS handshakes for DTLS-SRTP?

Unclear; as you have pointed out, it's not clear whether a given DTLS
packet belongs to the old session or the new session.

>
> My understanding was that in case of bundled channels, all channels go
> over the same "virtual" ICE channel, get decoded by the single DTLS-SRTP

This is true. But demux is not an issue; we know which 5-tuples are part of
the ICE channel. I think we are simply searching for a convenient handle
that we can apply for this virtual channel.