Subject: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

From: Simon Perreault <[email-masked]>
Date: Wed, 04 Mar 2015 13:12:18 -0500

This is a follow-up to this thread on discuss-webrtc:
https://groups.google.com/forum/#!topic/discuss-webrtc/i67xq-FWtoM

I see two distinct problems:

1. It must be possible for a DTLS connection to jump from one ICE 
candidate to another. That is, a DTLS connection must not be bound to a 
single 5-tuple. This can be deduced from a good understanding of ICE, 
but it could certainly be stated more clearly.

2. SRTP keying material extracted from a DTLS connection must also not 
be bound to a single 5-tuple, in case media jumps from one ICE candidate 
to another. That's more problematic because RFC 5764 states very clearly 
that keying material is to be bound to the DTLS 5-tuple, modulo forking.

If I'm not mistaken, the right thing to do would be to bind keying 
material to all local ICE candidates (multiple 3-tuples), and treat any 
incoming media flow as indicated in RFC 5764 page 15, with one mapping 
table per 3-tuple. For outgoing flows, I guess it would make most sense 
to bind keying material to the 5-tuples for which the sender has 
obtained consent.

Is this correct? If so, would it be useful to add text explaining this 
in detail?

Simon

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Mar 2015 13:54:16 -0500

On Wed, Mar 4, 2015 at 1:12 PM, Simon Perreault <[email-masked]> wrote:

> table per 3-tuple. For outgoing flows, I guess it would make most sense to
> bind keying material to the 5-tuples for which the sender has obtained
> consent.
>
> Is this correct? If so, would it be useful to add text explaining this in
> detail?
>
>
This is not correct. End point can have multiple flows with different
keying material or different DTLS sessions on the same local ICE 3-tuple
due to forking. More correct implementation would be to associate multiple
5-tuples with the same logical transport stream based on ICE connectivity
checks using ICE ufrag to identify which logical stream to associate with
each 5-tuple.

There is also another interesting consequence of this -- end point should
not re-use the same ICE candidate IP/port with a different ufrag during
session update offer/answer exchange. Otherwise you might end up with
ambiguous association between the logical streams and keying material or
DTLS session.

All of this probably needs to be defined somewhere and I am not aware which
RFC or draft defines this at this time.
_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Wed, 04 Mar 2015 14:02:10 -0500

Le 2015-03-04 13:54, Roman Shpount a écrit :
> due to forking. More correct implementation would be to associate
> multiple 5-tuples with the same logical transport stream based on ICE
> connectivity checks using ICE ufrag to identify which logical stream to
> associate with each 5-tuple.

Agreed.

> There is also another interesting consequence of this -- end point
> should not re-use the same ICE candidate IP/port with a different ufrag
> during session update offer/answer exchange. Otherwise you might end up
> with ambiguous association between the logical streams and keying
> material or DTLS session.

Right. And wait MSL seconds before reusing a candidate to let the pipes 
drain.

> All of this probably needs to be defined somewhere and I am not aware
> which RFC or draft defines this at this time.

I guess for DTLS/DTLS-SRTP the obvious target would be -security...

Simon

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Mar 2015 19:54:04 +0000

Hi,

Didn't we last week agree that, if the underlying transport changes, the DTLS connection MUST be re-established?

Jumping from one candidate to another is a transport change, isn't it?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Simon Perreault<mailto:[email-masked]>
Sent: ‎04/‎03/‎2015 21:02
To: Roman Shpount<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

Agreed.

Simon

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Mar 2015 14:59:42 -0500

On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmberg <
[email-masked]> wrote:

>   Didn't we last week agree that, if the underlying transport changes,
> the DTLS connection MUST be re-established?
>
In cases where ICE is used jump from on candidate to another should not
constitute a transport change. A change in ICE ufrag should constitute the
transport change. All ICE candidates are a single virtual transport
channel. Without this a lot of ICE setup scenarios, such as rapid
nomination, break down. Even changes in the c= line address, m=line port
port, or list of candidates is not a transport change if ufrag stays the
same.

In cases where ICE is not used, changes of address in c= line or port in m=
line are a transport change.
_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Wed, 04 Mar 2015 15:01:47 -0500

Le 2015-03-04 14:59, Roman Shpount a écrit :
> On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> constitute a transport change. A change in ICE ufrag should constitute
> the transport change. All ICE candidates are a single virtual transport
> In cases where ICE is not used, changes of address in c= line or port in
> m= line are a transport change.

I'm in full agreement.

Simon

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Mar 2015 20:04:50 +0000

Hi,

What if you jump from an UDP candidate to a TCP candidate? At the same time you would be jumping from DTLS to TLS (even for SRTP, where DTLS is only used for key management).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎04/‎03/‎2015 21:59
To: Christer Holmberg<mailto:[email-masked]>
Cc: Simon Perreault<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Didn't we last week agree that, if the underlying transport changes, the DTLS connection MUST be re-established?

In cases where ICE is used jump from on candidate to another should not constitute a transport change. A change in ICE ufrag should constitute the transport change. All ICE candidates are a single virtual transport channel. Without this a lot of ICE setup scenarios, such as rapid nomination, break down. Even changes in the c= line address, m=line port port, or list of candidates is not a transport change if ufrag stays the same.

In cases where ICE is not used, changes of address in c= line or port in m= line are a transport change.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Mar 2015 20:06:46 +0000

Correction. You are not jumping to TLS, if you use framing for DTLS when TCP is used.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Christer Holmberg<mailto:[email-masked]>
Sent: ‎04/‎03/‎2015 22:05
To: Roman Shpount<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

Hi,

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Mar 2015 12:07:22 -0800

On Wed, Mar 4, 2015 at 12:04 PM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
> What if you jump from an UDP candidate to a TCP candidate? At the same
> time you would be jumping from DTLS to TLS (even for SRTP, where DTLS is
> only used for key management).
>

No. You do DTLS even with TCP.

-Ekr

>  ------------------------------
> From: Roman Shpount <[email-masked]>
> To: Christer Holmberg <[email-masked]>
> Cc: Simon Perreault <[email-masked]>; [email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Mar 2015 15:51:31 -0500

> No. You do DTLS even with TCP.

And this is still continues to be the same logical channel, i.e. this does
not constitute a transport change.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Mar 2015 22:05:47 +0000

Hi,

I am not objecting to the idea, but as far as I know this "logical channel" concept is not defined anywhere, so before we can start referring to it it needs to be anchored somewhere on DTLS level.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎04/‎03/‎2015 22:51
To: Eric Rescorla<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

On Wed, Mar 4, 2015 at 3:07 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 4, 2015 at 12:04 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
What if you jump from an UDP candidate to a TCP candidate? At the same time you would be jumping from DTLS to TLS (even for SRTP, where DTLS is only used for key management).

And this is still continues to be the same logical channel, i.e. this does not constitute a transport change.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Mar 2015 01:44:01 +0100

2015-03-04 23:05 GMT+01:00 Christer Holmberg <[email-masked]>:
> I am not objecting to the idea, but as far as I know this "logical channel"
> concept is not defined anywhere, so before we can start referring to it it
> needs to be anchored somewhere on DTLS level.

Take into account that when aggressive ICE nomination is being done, a
peer sends multiple STUN requests with USE-CANDIDATE at the same time
and DTLS ClientHello after each of them. At the end this means that
the receiver must be ready to receive DTLS packets via different
5-tuples at the same time, all of them belonging to the same DTLS
association/connection.

So stating that "if the underlying transport changes the DTLS
connection MUST be re-established" seems a unfortunate simplification
to me.

Said that, I fully agree with you. This kind of "virtual transport"
created by ICE must be defined somewhere because existing specs (for
example DTLS-SRTP RFC) do not mention ICE at all.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Mar 2015 06:58:26 +0000

Hi,

As far as I understand, sending of multiple ClientHellos, on different 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), and who knows how long such work would take. Do we really want to add such dependency to our deliveries at this point?

In addition, do we expect existing DTLS implementations to support this?

If one doesn't want to re-establish DTLS when jumping between candidates, doesn't it work by creating separate DTLS connections for each candidate?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Iñaki Baz Castillo<mailto:[email-masked]>
Sent: ‎05/‎03/‎2015 02:44
To: Christer Holmberg<mailto:[email-masked]>
Cc: Roman Shpount<mailto:[email-masked]>; Eric Rescorla<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Mar 2015 10:52:44 +0100

2015-03-05 7:58 GMT+01:00 Christer Holmberg <[email-masked]>:
> As far as I understand, sending of multiple ClientHellos, on different
> 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), and who
> knows how long such work would take. Do we really want to add such
> dependency to our deliveries at this point?

Sorry, I think I didn't explain well.

It is not about multiple DTLS connections, but about the fact that
DTLS packets belonging to the *same* DTLS connection/association can
be carried over different 5-tuples. This may happen during agressive
ICE nomination in which media (so the DTLS ClientHello) follows the
USE-CANDIDATE Binding request without even waiting for a response.

> In addition, do we expect existing DTLS implementations to support this?

There is nothing new to implement in DTLS libraries. It is just the
the DTLS user must not assume a single and fixed 5-tuple

> If one doesn't want to re-establish DTLS when jumping between candidates,
> doesn't it work by creating separate DTLS connections for each candidate?

This subject has been heavily discussed time ago:

http://www.ietf.org/mail-archive/web/mmusic/current/msg13637.html

No, there MUST NOT be separate DTLS connection for each candidate-pair.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Mar 2015 05:10:17 -0500

> 5-tuples at the same time, all of them belonging to the same DTLS

I am not sure this is entirely correct.  My assumption was that during
aggressive ICE nomination, an end point will send DTLS ClientHello over the
first candidate pair where ICE connectivity check succeeds. The end point
should be ready to receive DTLS messages over any ICE candidate pair. If
end point does not receive response to DTLS ClientHello it should
re-transmit ClientHello over the highest priority ICE candidate pair at the
time of the re-transmission. I do not think there is any need to send
multiple DTLS ClientHello messages at the same time over multiple candidate
pairs. In other words, an end point should treat ICE as a single virtual
channel, where data is transmitted over the highest priority ICE candidate
pair for which the connectivity check succeeded and process data received
from any non-pruned ICE candidate pair. There is no need to trombone the
data over all the candidate pairs when it is being sent out. This should
fit nicely with existing DTLS implementations.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Mar 2015 05:14:39 -0500

> USE-CANDIDATE Binding request without even waiting for a response.

When was it agreed that DTLS ClientHello can be sent before the
connectivity check succeeded? I understand that this will increase the
connection setup time, but I though that no data should be sent before the
connectivity check response (consent) from the remote party.

> No, there MUST NOT be separate DTLS connection for each candidate-pair.

Agreed
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Mar 2015 10:25:06 +0000

Hi,

>> 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), 
>> and who knows how long such work would take. Do we really want to add 
>> such dependency to our deliveries at this point?
>
> It is not about multiple DTLS connections, but about the fact that DTLS packets 
> belonging to the *same* DTLS connection/association can be carried over different 5-tuples.

Correct, and that's what I meant too :)

I.e. you would be sending multiple ClientHello, using different 5-tuples, associated with the *same* DTLS connection.

I assume the server would also return the same cookie for each ClientHello, or?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Mar 2015 10:30:31 +0000

Hi,

>When was it agreed that DTLS ClientHello can be sent before the connectivity check succeeded? I understand >that this will increase the connection setup time, but I though that no data should be sent before the >connectivity check response (consent) from the remote party.

And, if the ClientHello reaches the server BEFORE the connectivity check STUN, how does the server know that it is associated with a given “virtual connection”?

Regards,

Christer

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 5 Mar 2015 11:44:25 +0100

On Thu, 5 Mar 2015 10:30:31 +0000
Christer Holmberg <[email-masked]> wrote:

> >connectivity check succeeded? I understand >that this will increase
> >the connection setup time, but I though that no data should be sent
> >before the >connectivity check response (consent) from the remote
> >party.
> 
> And, if the ClientHello reaches the server BEFORE the connectivity
> check STUN, how does the server know that it is associated with a
> given “virtual connection”?
> 
> Regards,
> 
> Christer
> 

I guess sending a ClientHello before the ICE process has been completed
would be pointless, as you wouldn't be sure where to send the message,
and even if it reached the right destination it might be discarded. The
"virtual connection" is only available when you have at least a working
pair on both sides.

Lorenzo

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Mar 2015 11:46:30 +0100

2015-03-05 11:14 GMT+01:00 Roman Shpount <[email-masked]>:
> When was it agreed that DTLS ClientHello can be sent before the connectivity
> check succeeded? I understand that this will increase the connection setup
> time, but I though that no data should be sent before the connectivity check
> response (consent) from the remote party.

I don't remember at 100%, but AFAIR that happens (may be I'm wrong
sorry, I checked it in deep long time ago but cannot remember right
now).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Mar 2015 11:53:02 +0100

2015-03-05 11:30 GMT+01:00 Christer Holmberg <[email-masked]>:
>> connectivity check succeeded? I understand >that this will increase the
> And, if the ClientHello reaches the server BEFORE the connectivity check
> STUN, how does the server know that it is associated with a given “virtual
> connection”?

It just ignores it. Client retransmissions will fix that.

Anyhow, I'm sorry but I no longer remember whether DTLS (which is just
media from the ICE point of view) can be sent before receiving the
STUN response or not. From the point of view of the peer performing
aggressive ICE nomination, it is sending USE-CANDIDATE Binding
requests so I can understand that it assumes a "valid-pair" (even if
it's not replied/confirmed yet by the remote) so media can begin (and
DTLS is just media).

I have to re-check.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Mar 2015 13:01:51 +0000

> it's not replied/confirmed yet by the remote) so media can begin (and

<Raju>
Aggressive nomination is to avoid 2nd round of checks with USE-CANDIDATE, but not to send media before the nomination is complete. Per [1], nomination is complete only when checks on all valid pairs are complete. A pair becomes "valid" only when you get response. That means, you can't send media (DTLS ClientHello) before you get STUN response.

[1] http://tools.ietf.org/html/rfc5245#section-8.1.1.2

8.1.1.2.  Aggressive Nomination

   With aggressive nomination, the controlling agent includes the USE-
   CANDIDATE attribute in every check it sends.  Once the first check
   for a component succeeds, it will be added to the valid list and have
   its nominated flag set.  When all components have a nominated pair in
   the valid list, media can begin to flow using the highest priority
   nominated pair.  However, because the agent included the USE-
   CANDIDATE attribute in all of its checks, another check may yet
   complete, causing another valid pair to have its nominated flag set.
   ICE always selects the highest-priority nominated candidate pair from
   the valid list as the one used for media.  Consequently, the selected
   pair may actually change briefly as ICE checks complete, resulting in
   a set of transient selections until it stabilizes.

</Raju>

BR
raju

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Mar 2015 14:06:29 +0100

> Aggressive nomination is to avoid 2nd round of checks with USE-CANDIDATE, but not to send media before the nomination is complete. Per [1], nomination is complete only when checks on all valid pair…

Thanks. I remember now what it may happens:

- A sends USE-CANDIDATE requests in parallel.
- A receives the ok response from one of them.
- A sends DTLS ClientHello.
- A receives the ok response with higher priority from another pair.
- A then continues sending media (maybe remaining DTLS stuff or RTP)
for that pair.

At the end DTLS packets can be sent over any valid and confirmed
candidate-pair. That's why we need to think about it as a "virtual
transport" and forget the 5-tuple when it comes to ICE.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Mar 2015 13:26:41 +0000

> > Aggressive nomination is to avoid 2nd round of checks with USE-CANDIDATE,
> but not to send media before the nomination is complete. Per [1], nomination
> is complete only when checks on all valid pairs are complete. A pair becomes
> "valid" only when you get response. That means, you can't send media (DTLS
> ClientHello) before you get STUN response.
> 

<Raju>
This is not allowed by http://tools.ietf.org/html/rfc5245#section-8.1.1.2 , unless webrtc overrides it.
A can only send DTLS once final nomination, which happens after all valid pairs are found, is done.
</Raju>

> candidate-pair. 

<Raju> As mentioned above, http://tools.ietf.org/html/rfc5245#section-8.1.1.2 does not allow sending media (DTLS) on any valid pairs until final nomination is complete.
</Raju>

BR
Raju

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Mar 2015 14:44:18 +0100

> A can only send DTLS once final nomination, which happens after all valid pairs are found, is done.

   However, because the agent included the USE-CANDIDATE
   attribute in all of its checks, another check may yet
   complete, causing another valid pair to have its nominated flag set.
   ICE always selects the highest-priority nominated candidate pair from
   the valid list as the one used for media.  Consequently, the selected
   pair may actually change briefly as ICE checks complete, resulting in
   a set of transient selections until it stabilizes.

Also consider the case in which the ICE-CONTROLLING agent is not the
DTLS client. This is:

- A sends USE-CANDIDATE requests in parallel.
- B replies OK to the first one.
- B decides that it is the selected-pair (common in ICE-Lite servers).
- B sends DTLS ClientHello.
- A replies DTLS ServerHello etc.
- A continues sending USE-CANDIDATE requests.
- After a while another pair may be selected but "media" already started.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Mar 2015 13:44:46 +0000

Hi,

>- A then continues sending media (maybe remaining DTLS stuff or RTP) for that pair.

Just to clarify: when you say "continues sending", you are NOT saying that A "starts over" by sending a new initial ClientHello on the new pair - instead A only switches to the other pair and continues with normal DTLS setup procedures?

...which means that both the client and server may receive DTLS messages, associated with the same DTLS connection setup, on different 5-tuples?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Mar 2015 08:58:09 -0500

> pairs are found, is done.

I think you are misreading
http://tools.ietf.org/html/rfc5245#section-8.1.1.2: An end point can start
sending media once a valid pair is discovered for each component (which is
actually one component in case of bundle, one component per m= line in case
of no bundle and rtcp-mux, and two components per m= line in case of
neither). New valid pairs can still be found when media is being sent and
media should be switched to the valid pair with the highest priority. When
all the pairs are checked the final nomination request is sent, but the
media will start flowing way before that. Alternative would be almost
unusable since pair of two private IPs for two end-point each behind NAT
will never get nominated and it will take a long time to time out,
preventing media from flowing long after call is connected.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Mar 2015 09:03:41 -0500

On Thu, Mar 5, 2015 at 8:44 AM, Christer Holmberg <
[email-masked]> wrote:

> Just to clarify: when you say "continues sending", you are NOT saying that
> A "starts over" by sending a new initial ClientHello on the new pair -
> instead A only switches to the other pair and continues with normal DTLS
> setup procedures?
>
> ...which means that both the client and server may receive DTLS messages,
> associated with the same DTLS connection setup, on different 5-tuples?
>

End point should not "start over". End point should continue the normal
DTLS setup over a new pair. This does mean that the same DTLS association
can go over different 5-tuples over time. With some of the new proposals,
such as continuous nomination, DTLS association can be switching the
underlying 5-tuple at any time while the connection is active, not just
during the initial setup. As far as DTLS is concerned, all 5-tuples setup
with the same ICE ufrag pair are the same transport and all the packets
received over any of those 5-tuples should be processed by the same DTLS
association.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Mar 2015 15:32:54 +0100

> ...which means that both the client and server may receive DTLS messages, associated with the same DTLS connection setup, on different 5-tuples?

yep, and that happens.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Mar 2015 15:33:54 +0100

> preventing media from flowing long after call is connected.

Exactly. And that is also stated in the RFC somewhere.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 5 Mar 2015 15:22:33 +0000

On Mar 5, 2015, at 5:14 AM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 5, 2015 at 4:52 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:

When was it agreed that DTLS ClientHello can be sent before the connectivity check succeeded? I understand that this will increase the connection setup time, but I though that no data should be sent before the connectivity check response (consent) from the remote party.

As I understand the current rough consensus, the endpoint has to have received a successful response to a connectivity check on the 5-tuple, proving consent, but it doesn’t have to have received (or sent) a check with a USE-CANDIDATE attribute in it yet.

This was the outcome of our discussion “merging" regular and aggressive ICE nomination.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 5 Mar 2015 16:15:19 +0000

On Thu, Mar 5, 2015 at 8:26 AM, Makaraju, Maridi Raju (Raju) <[email-masked]<mailto:[email-masked]>> wrote:
This is not allowed by http://tools.ietf.org/html/rfc5245#section-8.1.1.2 , unless webrtc overrides it.
A can only send DTLS once final nomination, which happens after all valid pairs are found, is done.

I think you are misreading http://tools.ietf.org/html/rfc5245#section-8.1.1.2: An end point can start sending media once a valid pair is discovered for each component (which is actually one component in case of bundle, one component per m= line in case of no bundle and rtcp-mux, and two components per m= line in case of neither). New valid pairs can still be found when media is being sent and media should be switched to the valid pair with the highest priority. When all the pairs are checked the final nomination request is sent, but the media will start flowing way before that. Alternative would be almost unusable since pair of two private IPs for two end-point each behind NAT will never get nominated and it will take a long time to time out, preventing media from flowing long after call is connected.
<Raju>
You are right and I completely agree with you [1]. Sorry, I overlooked this.

[1] http://tools.ietf.org/html/rfc5245#section-11.1.3
11.1.3<http://tools.ietf.org/html/rfc5245#section-11.1.3>.  Procedures for All Implementations

   ICE has interactions with jitter buffer adaptation mechanisms.  An
   RTP stream can begin using one candidate, and switch to another one,
   though this happens rarely with ICE.  The newer candidate may result
   in RTP packets taking a different path through the network -- one
   with different delay characteristics.

</Raju>

BR
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 08 Mar 2015 18:57:00 -0400

> ...which means that both the client and server may receive DTLS messages, associated with the same DTLS connection setup, on different 5-tuples?

To get back to a point that Christer made some time ago on this thread:

This stuff is *not* "rtcweb" stuff - it has much broader import. It 
needs to be specified more generally.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 8 Mar 2015 19:28:08 -0400

On Mar 8, 2015, at 6:57 PM, Paul Kyzivat <[email-masked]> wrote:
> This stuff is *not* "rtcweb" stuff - it has much broader import. It needs to be specified more generally.

[BA] It is appropriate for discussion in RTCWEB since WebRTC implementations are implementing this and need to know how things work. However I agree that there should be a document (probably in MMUSIC) that describes how it works. This was discussed in MMUSIC at the last IETF.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Mar 2015 05:18:20 +0000

Hi,

In MMUSIC we define how it's negotiated using SDP.

But, shouldn't the "virtual connection" concept, i.e. usage of multiple 5-tuples for a DTLS, be defined in a security WG?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Bernard Aboba<mailto:[email-masked]>
Sent: ‎09/‎03/‎2015 01:28
To: Paul Kyzivat<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Mar 2015 08:47:11 -0400

Le 2015-03-09 01:18, Christer Holmberg a écrit :
> But, shouldn't the "virtual connection" concept, i.e. usage of multiple
> 5-tuples for a DTLS, be defined in a security WG?

Not at all. The "virtual connection" concept applies to any protocol 
being transported over ICE. DTLS is just one such protocol. Another 
obvious one is... RTP! :)

Maybe ICE-bis should explain all of this?

Simon

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 9 Mar 2015 13:51:00 +0100

2015-03-09 13:47 GMT+01:00 Simon Perreault <[email-masked]>:
> Not at all. The "virtual connection" concept applies to any protocol being
> transported over ICE. DTLS is just one such protocol. Another obvious one
> is... RTP! :)
>

Yes. ICE-bis should define what a "virtual transport" is, and should
explain that from the point of view of the application is must be used
as a single 5-tuple transport.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Mar 2015 12:54:00 +0000

Hi,

DTLS itself knows nothing about ICE.

So, IF DTLS assumes (implicitly or explicitly) that a single 5-tuple is used, the appropriate WG at least need to be consulted about whether usage of multiple 5-tuples will cause any issues - technical or security. 

Regards,

Christer

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: 9. maaliskuuta 2015 14:47
To: Christer Holmberg; Bernard Aboba; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

Le 2015-03-09 01:18, Christer Holmberg a écrit :
> But, shouldn't the "virtual connection" concept, i.e. usage of 
> multiple 5-tuples for a DTLS, be defined in a security WG?

Not at all. The "virtual connection" concept applies to any protocol being transported over ICE. DTLS is just one such protocol. Another obvious one is... RTP! :)

Simon

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 9 Mar 2015 13:56:48 +0100

> So, IF DTLS assumes (implicitly or explicitly) that a single 5-tuple is used, the appropriate WG at least need to be consulted about whether usage of multiple 5-tuples will cause any issues - techn…

DTLS wrongly assumes a single 5-tuple. It should assume a single
transport, and such a transport may be a classic 5-tuple or a ICE
transport. It is a task of ICE to define what such a transport is.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Mar 2015 13:00:26 +0000

> DTLS wrongly assumes a single 5-tuple. It should assume a single transport, and such a transport may be a classic 5-tuple or a ICE transport. It is a task of ICE to define what such a transport is.

Yes, I agree that ICE can define such virtual transport.

But, before we do that, the DTLS folks need to agree that assuming a single 5-tuple IS wrong  :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 9 Mar 2015 14:03:43 +0100

> But, before we do that, the DTLS folks need to agree that assuming a single 5-tuple IS wrong  :)

It is as wrong as assuming that using a single **UDP** 5-tuple is safe :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Mar 2015 09:17:04 -0400

> So, IF DTLS assumes (implicitly or explicitly) that a single 5-tuple is used, the appropriate WG at least need to be consulted about whether usage of multiple 5-tuples will cause any issues - techn…

Definitely.

Simon

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Mar 2015 10:16:03 -0400

>> So, IF DTLS assumes (implicitly or explicitly) that a single 5-tuple is used, the appropriate WG at least need to be consulted about whether usage of multiple 5-tuples will cause any issues - tech…

ISTM that this subject is closely related to multipath transports - TCP, 
RTP, UDP, SCTP. ICE provides a way to negotiate the multiple paths.

Looking around, work on multipath transports is spread around. For TCP 
and SCTP it was done in transport. There is a draft for multipath RTP in 
avtcore. I see a little email discussion of multipath UDP in transport, 
but (based on my one minute spent googling) not any real action.

To date ICE hasn't considered this to be a general multipath transport 
problem - just a way to negotiate a single path transport. But the 
discussion here is showing flaws in that approach. But 
draft-wing-mmusic-ice-mobility was closer to really dealing with multipath.

This may need a tactical solution to keep rtcweb going in a timely way 
and a more strategic approach to get this all properly cleaned up.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 9 Mar 2015 16:51:35 +0100

2015-03-09 15:16 GMT+01:00 Paul Kyzivat <[email-masked]>:
> discussion here is showing flaws in that approach.

I don't think there are flaws. The fact is that in certain ICE usages
(aggressive nomination) it may perfectly happen that media (say RTP or
DTLS) can be sent over different 5-tuples at the ~same time. IMHO
that's not a flaw to fix, but something that we must assume as it is.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Mar 2015 12:22:26 -0400

> that's not a flaw to fix, but something that we must assume as it is.

I didn't mean that it is a flaw to be discussing this in the context of 
RTCWEB.

What I meant is that it is a flaw that the more general nature of this 
as an aspect of multipath transports hasn't been noticed. (Or maybe it 
has, and I'm just not well informed. I don't follow the transport area.)

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 Mar 2015 09:28:23 -0600

> On Mar 5, 2015, at 8:22 AM, Jonathan Lennox <[email-masked]> wrote:
> 
> 
> On Mar 5, 2015, at 5:14 AM, Roman Shpount <[email-masked]> wrote:
> 

That matches my understanding of how things work.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 9 Mar 2015 16:41:34 -0700

On Mon, Mar 9, 2015 at 8:28 AM, Cullen Jennings <[email-masked]> wrote:

> and who
> > As I understand the current rough consensus, the endpoint has to have
> received a successful response to a connectivity check on the 5-tuple,
> proving consent, but it doesn’t have to have received (or sent) a check
> with a USE-CANDIDATE attribute in it yet.
> >
That discussion is now codified in a new draft,
https://tools.ietf.org/html/draft-uberti-mmusic-nombis-00.

To handle the issue raised by the OP, I think we should either
1) Fix the DTLS draft (and any others) to not be bound to a 5-tuple when
ICE is used
2) Update ICE-bis to say that any language about 5-tuples is invalidated by
ICE, and should be treated as a virtual transport.

#2 seems like the simplest path at this point, given that ICE-bis work is
underway.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Mar 2015 17:49:08 -0700

On Mon, Mar 9, 2015 at 4:41 PM, Justin Uberti <[email-masked]> wrote:

> 2) Update ICE-bis to say that any language about 5-tuples is invalidated
> by ICE, and should be treated as a virtual transport.
>

#2 seems like the right answer to me.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 10 Mar 2015 16:26:31 +0100

> #2 seems like the right answer to me.

+1. Other specs should then update to consider the virtual transport
when ICE is in use.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Mar 2015 12:49:03 +0000

Hi,

>1) Fix the DTLS draft (and any others) to not be bound to a 5-tuple when ICE is used
>2) Update ICE-bis to say that any language about 5-tuples is invalidated by ICE, and should be treated as a >virtual transport.

When you say “any language”, do you refer specifically to DTLS, or to whatever protocol is used together with ICE?

Regards,

Christer

#2 seems like the simplest path at this point, given that ICE-bis work is underway.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 11 Mar 2015 14:42:45 +0100

2015-03-11 13:49 GMT+01:00 Christer Holmberg <[email-masked]>:
>> ICE, and should be treated as a >virtual transport.
>
>
>
> When you say “any language”, do you refer specifically to DTLS, or to
> whatever protocol is used together with ICE?

Clearly he means "whatever protocol is used together with ICE".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Mar 2015 13:55:56 +0000

Hi,

>>>2) Update ICE-bis to say that any language about 5-tuples is 
>>>invalidated by  ICE, and should be treated as a >virtual transport.
>>
>>

So, we assume that whatever protocol, existing and future, will work with a "virtual connection"?

E.g. in case of TCP, you WILL have separate connections for each TCP candidate - each using a single 5-tuple. We can't say that, with ICE, a single TCP connection can suddenly span multiple 5-tuples (one for each candidate pair), can we?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 11 Mar 2015 10:10:15 -0400

On Wed, Mar 11, 2015 at 9:55 AM, Christer Holmberg <
[email-masked]> wrote:

> E.g. in case of TCP, you WILL have separate connections for each TCP
> candidate - each using a single 5-tuple. We can't say that, with ICE, a
> single TCP connection can suddenly span multiple 5-tuples (one for each
> candidate pair), can we?
>
>
I think there is some confusion between the underlying link protocol used
by candidates and the protocol running on top of ICE. I do not think TCP is
defined as a protocol that can operate on top of ICE. It is defined in RFC
6544 using framing from RFC 4571, as a protocol for underlying links.
Whatever protocol is defined on top of ICE should support operation on top
of packetized communication protocol provided by ICE and should define how
its packets can be demuxed from STUN packets used for ICE connectivity
checks. So far things like RTP, DTLS, and SCTP fit such requirements. New
things can be defined in the future. When they do, they should treat ICE a
virtual communication channel that provides unreliable packet transport
with no order guarantees which can span multiple 5-tuples.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 11 Mar 2015 15:14:28 +0100

2015-03-11 15:10 GMT+01:00 Roman Shpount <[email-masked]>:
> I think there is some confusion between the underlying link protocol used by
> candidates and the protocol running on top of ICE. I do not think TCP is
> virtual communication channel that provides unreliable packet transport with
> no order guarantees which can span multiple 5-tuples.

Exactly. Please Christer, don't go to layer 4 protocols. Neither IPv6
can run over an ICE initiated "virtual transport" ;)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Mar 2015 14:19:34 +0000

Hi,

>> I think there is some confusion between the underlying link protocol 
>> used by candidates and the protocol running on top of ICE. I do not 
>> think TCP is defined as a protocol that can operate on top of ICE. It 
>> is defined in RFC
>> Whatever protocol is defined on top of ICE should support operation on 
>> top of packetized communication protocol provided by ICE and should 
>> define how its packets can be demuxed from STUN packets used for ICE 
>> connectivity checks. So far things like RTP, DTLS, and SCTP fit such 
>> requirements. New things can be defined in the future. When they do, 
>> they should treat ICE a virtual communication channel that provides 
>> unreliable packet transport with no order guarantees which can span multiple 5-tuples.
>
> Exactly. Please Christer, don't go to layer 4 protocols. Neither IPv6 can run over an ICE initiated "virtual transport" ;)

I am not the one saying "whatever protocol" :)  

My point is that we need to be more clear about the scope - we can't just say "Take whatever protocol and do a "5-tuple"/"virtual connection" search-replace." :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 11 Mar 2015 15:20:37 +0100

> My point is that we need to be more clear about the scope - we can't just say "Take whatever protocol and do a "5-tuple"/"virtual connection" search-replace." :)

"Whatever protocol suitable to run over a ICE initiated path"

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Mar 2015 14:24:25 +0000

Hi,

>>E.g. in case of TCP, you WILL have separate connections for each TCP candidate - each using a single 5-tuple. We can't say >>that, with ICE, a single TCP connection can suddenly span multiple 5-tuples (one for each candidate pair), can we?
>
> I think there is some confusion between the underlying link protocol used by candidates and the protocol running on top > of ICE. I do not think TCP is defined as a protocol that can operate on top of ICE. It is defined in RFC 6544 using framing 
> from RFC 4571, as a protocol for underlying links. Whatever protocol is defined on top of ICE should support operation on > top of packetized communication protocol provided by ICE and should define how its packets can be demuxed from STUN > packets used for ICE connectivity checks. So far things like RTP, DTLS, and SCTP fit such requirements.

I assume you mean SCTP-over-DTLS? Usage of "plain" SCTP with ICE is not defined, as far as I know.

> New things can be defined in the future. When they do, they should treat ICE a virtual communication channel that 
> provides unreliable packet transport with no order guarantees which can span multiple 5-tuples.

Then the scope of what we discuss now should not be "whatever protocol" - it should be the specific protocols we are discussing.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Mar 2015 14:28:40 +0000

Hi,

>> My point is that we need to be more clear about the scope - we can't just say "Take 
>> whatever protocol and do a "5-tuple"/"virtual connection" search-replace." :)
>

Then we need to define "suitable".

Something like: "It MUST be possible to associate the protocol with multiple 5-tuples, and messages can be sent on any 5-tuple at any given time.".

If a protocol does not fulfil that, it must not be used with ICE.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 11 Mar 2015 10:32:02 -0400

> defined, as far as I know.

You are correct.

> Then the scope of what we discuss now should not be "whatever protocol" -
> it should be the specific protocols we are discussing.
>
>
I think ICE-bis should define protocol requirements for the protocols that
can run on top of ICE, which includes:
1. Ability to run over unreliable packet based transport with no order
guarantees
2. Ability to demux with STUN packets
3. Not t make any assumption about IP addresses, ports, or other transport
level protocols attributes such as TOS.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 11 Mar 2015 08:33:47 -0700

On Wed, Mar 11, 2015 at 7:32 AM, Roman Shpount <[email-masked]> wrote:

>> > New things can be defined in the future. When they do, they should
>> treat ICE a virtual communication channel that
I think these are good criteria. Note that TCP would meet these criteria,
and I see no problem running TCP atop ICE (we used to do this in an old
version of our data channel code).

HTTP, on the other hand, would not meet criterion #1.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Mar 2015 06:53:37 +0000

On 03/11/2015 03:33 PM, Justin Uberti wrote:
>
>
> On Wed, Mar 11, 2015 at 7:32 AM, Roman Shpount <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Wed, Mar 11, 2015 at 10:24 AM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         > New things can be defined in the future. When they do, they
>         should treat ICE a virtual communication channel that
>         > provides unreliable packet transport with no order
>         guarantees which can span multiple 5-tuples.
>
>         Then the scope of what we discuss now should not be "whatever
>         protocol" - it should be the specific protocols we are discussing.
>
>
>     I think ICE-bis should define protocol requirements for the
>     protocols that can run on top of ICE, which includes:
>     1. Ability to run over unreliable packet based transport with no
>     order guarantees
>     3. Not t make any assumption about IP addresses, ports, or other
>     transport level protocols attributes such as TOS. 
>
>
> I think these are good criteria. Note that TCP would meet these
> criteria, and I see no problem running TCP atop ICE (we used to do
> this in an old version of our data channel code).
>

I seem to remember a draft I wrote once upon a time (Feb 2011).... I
called it a "datagram service".

draft-alvestrand-dispatch-rtcweb-datagram-01

The ability to demux with STUN packets was expressed here as:

   The datagram service is not completely transparent; in particular, it
   is not possible to carry a datagram where the two highest bits of the
   first octet are zero and octet 5 to 8 contain the value 0x2112A442,
   since these datagrams are reserved for use of the STUN protocol (RFC
   5389 section 6).

It didn't seem to warrant a special doc at the time, given responses, so
I dropped it.

Note that straight-up TCP on top of this model would require special
work, since the TCP header checksum covers the address fields. A
TCP-like protocol with different checksums would be trivial to define.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Mar 2015 10:12:57 +0000

Hi,

>> I think ICE-bis should define protocol requirements for the protocols that can run on top of ICE, which includes:
>> 1. Ability to run over unreliable packet based transport with no order guarantees
>> 3. Not make any assumption about IP addresses, ports, or other transport level protocols attributes such as TOS. 
>
> I think these are good criteria. Note that TCP would meet these criteria, and I see no problem running TCP atop ICE (we used to do this in an old version of our data channel code).

I don't think a TCP connection can span over multiple 5-tuples - each TCP connection will be bound to one 5-tuple.

Perhaps the protocol running on top of TCP can switch between different TCP connections, though. For example, would it be possible to span a TLS connection over multiple TCP connections?

> HTTP, on the other hand, would not meet criterion #1.

Agree.

Regards,

Christer

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 12 Mar 2015 12:58:32 +0000

> I don't think a TCP connection can span over multiple 5-tuples - each TCP connection will be bound to one 5-tuple.

MPTCP can (http://tools.ietf.org/wg/mptcp/) in my understanding (see e.g. http://tools.ietf.org/html/rfc6897#section-4.1).

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 12. März 2015 11:13
To: Justin Uberti; Roman Shpount
Cc: Cullen Jennings; Jonathan Lennox; [email-masked]
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

Hi,

>>>> treat ICE a virtual communication channel that provides unreliable packet transport with no order guarantees which can span multiple 5-tuples.
>>>
>> order guarantees 2. Ability to demux with STUN packets 3. Not make 
>> any assumption about IP addresses, ports, or other transport level protocols attributes such as TOS.
>

Agree.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Mar 2015 10:48:30 -0400

On Wed, Mar 11, 2015 at 11:33 AM, Justin Uberti <[email-masked]> wrote:

>>> Then the scope of what we discuss now should not be "whatever protocol"
>>> - it should be the specific protocols we are discussing.
>>>
>>>
>> I think ICE-bis should define protocol requirements for the protocols
>> that can run on top of ICE, which includes:
> I think for TCP to meet this criteria, usage of TCP over ICE would still
need to be defined somewhere. In particular the use of address, port, and
checksum in such use case would need to be specified somewhere. Until this
is done, TCP-over-ICE would be under-defined and not quite usable.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Mar 2015 10:53:06 -0400

> connection will be bound to one 5-tuple.

The TCP use case over ICE should be defined in order to be usable. Doing so
is fairly straight forward but was not needed this far.

Perhaps the protocol running on top of TCP can switch between different TCP
> connections, though. For example, would it be possible to span a TLS
> connection over multiple TCP connections?
>
>
TLS (vs DTLS) cannot run on top of ICE since it is not a protocol which can
run on top of unreliable packet based transport with no order guarantees.
It would require a stream based transport to run below it in order to
operate. If someone defines TCP over ICE, that would make a good underlying
stream protocol to run below TLS. Once again, no one needed this so far.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Thu, 12 Mar 2015 09:00:45 -0700

On Thu, Mar 12, 2015 at 3:12 AM, Christer Holmberg <
[email-masked]> wrote:

> >> 3. Not make any assumption about IP addresses, ports, or other
> criteria, and I see no problem running TCP atop ICE (we used to do this in
> an old version of our data channel code).
>

I don't agree. SCTP can be tunneled over UDP, as we know, so why not TCP?
The ports in such a tunnel scenario are just as unnecessary as in SCTP over
UDP.

>
> Perhaps the protocol running on top of TCP can switch between different
> TCP connections, though. For example, would it be possible to span a TLS

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Mar 2015 10:55:16 +0000

It's the checksum.

Den 12. mars 2015 16.00.45 WET, skrev Justin Uberti <[email-masked]>:
>should
>> >>>> provides unreliable packet transport with no order guarantees
>which
>> can span multiple 5-tuples.
>> >>>
>protocols
>order
>this in
>> I don't think a TCP connection can span over multiple 5-tuples - each
>TCP
>> connection will be bound to one 5-tuple.
>>
>
>------------------------------------------------------------------------
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Mar 2015 11:02:35 +0000

Hi Justin,

> I don't agree. SCTP can be tunneled over UDP, as we know, so why not TCP? The ports in such a tunnel scenario are just as unnecessary as in SCTP over UDP. 

We need to be clear about what we mean.

When I say "TCP", I mean plain TCP :)

If we talk about TCP-over-UDP, we should say "TCP-over-UDP" :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Mar 2015 11:05:58 +0000

Hi,

> TLS (vs DTLS) cannot run on top of ICE since it is not a protocol which can run on top of unreliable packet based transport with no order guarantees. It would require a stream
> based transport to run below it in order to operate. If someone defines TCP over ICE, that would make a good underlying stream protocol to run below TLS. Once again, no one 
> needed this so far.

Even if we had TCP over ICE, I still don't know whether we would be able to run TLS on top. Because, in addition to reliability, doesn't TLS also rely on the ordering provided by TCP? We would need to make sure the ordering is maintained if endpoints use multiple TCP 5-tuples.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Mar 2015 12:07:06 +0100

Guys, this thread is getting surreal :)
On 13 Mar 2015 12:02, "Christer Holmberg" <[email-masked]>
wrote:

> TCP connection will be bound to one 5-tuple.
> >
> > I don't agree. SCTP can be tunneled over UDP, as we know, so why not
> TCP? The ports in such a tunnel scenario are just as unnecessary as in SCTP
> over UDP.
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Mar 2015 11:09:57 +0000

BTW, is this going to be discussed in Dallas?

Regards,

Christer

From: Iñaki Baz Castillo [mailto:[email-masked]]
Sent: 13. maaliskuuta 2015 13:07
To: Christer Holmberg
Cc: Jonathan Lennox; Cullen Jennings; [email-masked]; Justin Uberti
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

Guys, this thread is getting surreal :)
On 13 Mar 2015 12:02, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

Regards,

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Mar 2015 11:54:43 -0400

> BTW, is this going to be discussed in Dallas?

It should. Maybe during the ICE-bis slot in MMUSIC?

Simon

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Mar 2015 09:12:12 -0700

On Fri, Mar 13, 2015 at 4:05 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> > TLS (vs DTLS) cannot run on top of ICE since it is not a protocol which
> can run on top of unreliable packet based transport with no order
> guarantees. It would require a stream
> > based transport to run below it in order to operate. If someone defines
> TCP over ICE, that would make a good underlying stream protocol to run
> below TLS. Once again, no one
> > needed this so far.
>
> Even if we had TCP over ICE, I still don't know whether we would be able
> to run TLS on top. Because, in addition to reliability, doesn't TLS also
> rely on the ordering provided by TCP? We would need to make sure the
> ordering is maintained if endpoints use multiple TCP 5-tuples.
>
>
A few points:
- Anything we are say "runs over ICE" is going to be tunneled over UDP or
TCP, whichever ICE chooses to use as its underlying datagram transport. So
the notion of running "plain TCP" over ICE is nonsensical.

- Assuming we do run TCP over ICE, we can certainly run TLS on top. Since
TCP is just treating the underlying ICE transport as a datagram transport,
TCP retains all of its reliability and in-order properties. So TLS just
sees that it is running over TCP, and doesn't care that it is ICE at the
lowest layer. Note that this stacking of TLS/TCP/ICE is different from the
case of running TLS over ICE-TCP, since ICE-TCP does not guarantee
reliability or ordering.

- Harald's point about the TCP checksum is true; if we were truly
standardizing TCP-over-ICE, we would have to define an appropriate way to
compute the TCP checksum given that said checksum makes assumptions about
IP particulars. This would not be hard though.

- Lastly, this is clearly a source of massive confusion, so I agree we
should discuss it in detail in Dallas. I would be happy to help prepare
presentation material if needed.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Mar 2015 16:46:52 +0000

On 03/13/2015 04:12 PM, Justin Uberti wrote:
>
>
> On Fri, Mar 13, 2015 at 4:05 AM, Christer Holmberg
>     > TLS (vs DTLS) cannot run on top of ICE since it is not a
>     protocol which can run on top of unreliable packet based transport
>     with no order guarantees. It would require a stream
>     > based transport to run below it in order to operate. If someone
>     defines TCP over ICE, that would make a good underlying stream
>     protocol to run below TLS. Once again, no one
>     > needed this so far.
>
>     Even if we had TCP over ICE, I still don't know whether we would
>     be able to run TLS on top. Because, in addition to reliability,
>     doesn't TLS also rely on the ordering provided by TCP? We would
>     need to make sure the ordering is maintained if endpoints use
>     multiple TCP 5-tuples.
>
>
> A few points:
> - Anything we are say "runs over ICE" is going to be tunneled over UDP
> or TCP, whichever ICE chooses to use as its underlying datagram
> transport. So the notion of running "plain TCP" over ICE is nonsensical.
>
> - Assuming we do run TCP over ICE, we can certainly run TLS on top.
> Since TCP is just treating the underlying ICE transport as a datagram
> transport, TCP retains all of its reliability and in-order properties.
> So TLS just sees that it is running over TCP, and doesn't care that it
> is ICE at the lowest layer. Note that this stacking of TLS/TCP/ICE is
> different from the case of running TLS over ICE-TCP, since ICE-TCP
> does not guarantee reliability or ordering.
>
> standardizing TCP-over-ICE, we would have to define an appropriate way
> to compute the TCP checksum given that said checksum makes assumptions
> about IP particulars. This would not be hard though.
>
> should discuss it in detail in Dallas. I would be happy to help
> prepare presentation material if needed.

Can we define an use case for which there is a compelling need for
<whatever it is we're discussing> before spending too much meeting time
on it?

It's clearly very simple to define a protocol that is like TCP except
that the checksum doesn't include the addresses, and where the two
highest bits of the first byte aren't 00. It's not interoperable with
standard TCP, it can't take advantage of TCP accelerator hardware or be
detected by TCP-sensitive middle boxes (unless tweaked). But it's simple
to define.

It's also clearly very simple to run this protocol over ICE.

But why?

And is this scenario relevant for RTCWEB, which is trying to finish its
current set of options?

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Mar 2015 11:50:55 -0700

On Fri, Mar 13, 2015 at 9:46 AM, Harald Alvestrand <[email-masked]>
wrote:

> or TCP, whichever ICE chooses to use as its underlying datagram transport.
> So the notion of running "plain TCP" over ICE is nonsensical.
>
> transport, TCP retains all of its reliability and in-order properties. So
> TLS just sees that it is running over TCP, and doesn't care that it is ICE
> at the lowest layer. Note that this stacking of TLS/TCP/ICE is different
> from the case of running TLS over ICE-TCP, since ICE-TCP does not guarantee
> reliability or ordering.
>
> <whatever it is we're discussing> before spending too much meeting time on
> it?
>
> It's clearly very simple to define a protocol that is like TCP except that
> the checksum doesn't include the addresses, and where the two highest bits
> of the first byte aren't 00. It's not interoperable with standard TCP, it
> can't take advantage of TCP accelerator hardware or be detected by
> TCP-sensitive middle boxes (unless tweaked). But it's simple to define.
>

To be clear, I am not advocating going off and doing work to make TCP run
over ICE. My point was merely that essentially any protocol that runs over
IP or some other datagram transport can be made to run over ICE with zero
or minimal modifications; this is not well understood; and so this should
be explicitly codified in ICE-bis.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Mar 2015 19:58:04 +0000

Hi,

The thing that brought this whole thing up was DTLS.

So, unless people see a need for something else, maybe we should limit the scope to DTLS, and describe how a DTLS connection can span multiple candidate pairs (read: multiple 5-tuples)?

Otherwise we may end up spending lots of time for something which nobody really need…

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 13 March 2015 20:51
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

On Fri, Mar 13, 2015 at 9:46 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
On 03/13/2015 04:12 PM, Justin Uberti wrote:

On Fri, Mar 13, 2015 at 4:05 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

A few points:
- Anything we are say "runs over ICE" is going to be tunneled over UDP or TCP, whichever ICE chooses to use as its underlying datagram transport. So the notion of running "plain TCP" over ICE is nonsensical.

- Assuming we do run TCP over ICE, we can certainly run TLS on top. Since TCP is just treating the underlying ICE transport as a datagram transport, TCP retains all of its reliability and in-order properties. So TLS just sees that it is running over TCP, and doesn't care that it is ICE at the lowest layer. Note that this stacking of TLS/TCP/ICE is different from the case of running TLS over ICE-TCP, since ICE-TCP does not guarantee reliability or ordering.

- Harald's point about the TCP checksum is true; if we were truly standardizing TCP-over-ICE, we would have to define an appropriate way to compute the TCP checksum given that said checksum makes assumptions about IP particulars. This would not be hard though.

- Lastly, this is clearly a source of massive confusion, so I agree we should discuss it in detail in Dallas. I would be happy to help prepare presentation material if needed.

Can we define an use case for which there is a compelling need for <whatever it is we're discussing> before spending too much meeting time on it?

It's clearly very simple to define a protocol that is like TCP except that the checksum doesn't include the addresses, and where the two highest bits of the first byte aren't 00. It's not interoperable with standard TCP, it can't take advantage of TCP accelerator hardware or be detected by TCP-sensitive middle boxes (unless tweaked). But it's simple to define.

But why?

And is this scenario relevant for RTCWEB, which is trying to finish its current set of options?

To be clear, I am not advocating going off and doing work to make TCP run over ICE. My point was merely that essentially any protocol that runs over IP or some other datagram transport can be made to run over ICE with zero or minimal modifications; this is not well understood; and so this should be explicitly codified in ICE-bis.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Mar 2015 16:43:56 -0400

Le 2015-03-13 15:58, Christer Holmberg a écrit :
> So, unless people see a need for something else, maybe we should limit
> the scope to DTLS, and describe how a DTLS connection can span multiple
> candidate pairs (read: multiple 5-tuples)?
> 

+1000

What we need is to explain why text in DTLS-SRTP that specifically talks
about binding to a specific 5-tuple applies differently with ICE.

Simon

---

From: Roman Shpount <[email-masked]>
Date: Fri, 13 Mar 2015 16:56:41 -0400

> about binding to a specific 5-tuple applies differently with ICE.
We need text that explains that RTP/RTCP, SRTP/SRTCP, DTLS and DTLS-SRTP
should not bind to a specific 5-tuple when running on top of ICE. We would
also need to explain the concept of the virtual transport channel created
by ICE. We will need to specify how specific 5-tuples get associated with
the same virtual transport. Anything else is of no immediate value. I
believe, the most appropriate place for this would be ICE-bis. One way of
doing this is to introduce the concept of "ICE compatible transports", list
the requirements, and specify transports currently supported as examples.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Mar 2015 23:25:30 +0100

> Otherwise we may end up spending lots of time for something which nobody

You started the "TCP over ICE" subject... XD

Agreed. ICE is already well defined for RTP and RTCP usages. The only
"remaining" problem is that the DTLS-SRTP RFC talks about 5-tuples
while it is clear that the virtual transport (to be) defined by ICE
also fits DTLS(-SRTP) requirements.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Mar 2015 22:44:06 +0000

>You started the "TCP over ICE" subject... XD

...after you started the "whatever protocol" subject ;)

>Agreed. ICE is already well defined for RTP and RTCP usages. The only "remaining" problem is that the DTLS-SRTP RFC talks >about 5-tuples while it is clear that the virtual transport (to be) defined by ICE also fits DTLS(-SRTP) requirements.

We may need some text in the SCTP-SDP draft also.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 15 Mar 2015 15:26:33 -0400

> I assume you mean SCTP-over-DTLS? Usage of "plain" SCTP with ICE is not defined, as far as I know.

Yes. This means that it is DTLS, not SCTP that is running over ICE, and 
that must be prepared for dealing with multiple 5-tuples. DTLS should 
make this transparent to SCTP.

> Then the scope of what we discuss now should not be "whatever protocol" - it should be the specific protocols we are discussing.

AFAIK RTP and DTLS are the only things that have been considered. 
Possibly there are other things that could successfully run directly 
over ICE.

	Thanks,
	Paul