Subject: [rtcweb] Trickle ICE in practice

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Jan 2012 11:24:33 -0800

Hi Justin,

i’ve been thinking about how ICE works in JSEP and ISTM that the API
may not be emitting enough information to work here. As I understand
it, the following is a reasonable order of operations:

Alice->Bob: Offer
Alice->Bob: ICE candidates
Bob->Alice: ICE candidates
// ICE happens
// Bob answers
Bob->Alice: Answer

Unless I’m missing something, though, Alice and Bob can’t start doing
ICE until they have exchanged the ice-ufrag and ice-pwd
properties. Alice sends these in her offer, so this is no problem, but
they would ordinarily be in Bob’s answer, but that gets delayed, and
they’re not in Bob’s ICE candidates, so I don’t think they can start
ICE until Bob’s answer arrives. I suspect that what we need here is
something more like an XEP-0176 <transport/> element, which would
contain the pwd and ufrag. This also has the potential to solve the
problem you raise at the end of how to associate each candidate with
the relevant media stream, since we can stuff a pointer in that
structure. [Note: I am not an SDP expert, so I don’t have an opinion
on the best form of that pointer. As you know, in ordinary ICE-SDP,
this info is just assocaited with the m-line by counting.]

While we’re on the topic of stuffing stuff here, it would be pretty
nice to know in advance if you are going to bundle, so you’re not
thinking you’re going to do ICE on channels which you don’t want. As
you pointed out in another message, it’s also natural to put the DTLS
info here, so that we can get DTLS started early. In general, I think
if we’re going to separate transport and media signaling, we should
probably be thinking about if there is anything else that really needs
to be delivered prior to Bob’s decision to answer the phone.

Finally, as you point out in Appendix A, we don’t currently know when
you have all your candidates, which makes it hard to implement SIP
compatibility from this API. I’m not 100% sure what the best API is
here: do we want to know when all candidates are found or just all for
a given flow?

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Jan 2012 13:55:34 -0700

> here: do we want to know when all candidates are found or just all for

In the past, I have considered adding an CANDIDATES message to ROAP to allow extra candidates to be augmented to an existing offer or answer but it never been clear if the optimization guided by this was worth the complexity. Definitely worth thinking about.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Jan 2012 15:16:46 -0500

> to be delivered prior to Bob’s decision to answer the phone.

Yes; I think if the IceCallback provides the application with ice-ufrag,
ice-pwd, BUNDLE info, and cert fingerprint (in addition to candidates),
this would solve this problem (by effectively making IceCallback a
transport-info generator).

> here: do we want to know when all candidates are found or just all for

I think you need to know when all candidates needed for the offer are
obtained. Simplest way to do this in the proposed API is to add a
|morePending| flag to the IceCallback.

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jan 2012 15:37:16 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eric Rescorla
> Sent: Thursday, January 26, 2012 11:25 AM
> To: [email-masked]
> Subject: [rtcweb] Trickle ICE in practice
> 
> Hi Justin,
> 
> i've been thinking about how ICE works in JSEP and ISTM that the API
> Unless I'm missing something, though, Alice and Bob can't start doing
> they would ordinarily be in Bob's answer, but that gets delayed, and
> they're not in Bob's ICE candidates, so I don't think they can start
> ICE until Bob's answer arrives.

Alice can respond to Bob's incoming connectivity checks before receiving 
Bob's answer.  However, Alice cannot validate the incoming connectivity
checks really came from Bob until she receives Bob's ice-ufrag and
ice-pwd.  That isn't a problem; she can validate them later.

-d

> I suspect that what we need here is
> structure. [Note: I am not an SDP expert, so I don't have an opinion
> While we're on the topic of stuffing stuff here, it would be pretty
> nice to know in advance if you are going to bundle, so you're not
> thinking you're going to do ICE on channels which you don't want. As
> you pointed out in another message, it's also natural to put the DTLS
> if we're going to separate transport and media signaling, we should
> to be delivered prior to Bob's decision to answer the phone.
> 
> Finally, as you point out in Appendix A, we don't currently know when
> compatibility from this API. I'm not 100% sure what the best API is

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Jan 2012 16:07:48 -0800

> ice-pwd.  That isn't a problem; she can validate them later.

If both are behind address-restricted NATs, don't Bob's connectivity checks
just get dropped?

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jan 2012 17:31:02 -0800

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Monday, January 30, 2012 4:08 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [rtcweb] Trickle ICE in practice
> 
> If both are behind address-restricted NATs, don't Bob's connectivity
> checks just get dropped?

Bob is sending the packets to Alice, so his NAT's filtering does not
come into play.

You are correct that if Alice has an address-filtering NAT, Bob's
connectivity checks will be dropped by Alice's NAT.  They will be
dropped until Alice receives Bob's Answer and Alice sends a 
connectivity check to Bob's IP address.  At that point, Bob's
connectivity checks will be allowed by Alice's NAT.  ICE has
Bob send that connectivity check immediately upon receiving 
a check from Alice, for just this reason.

How often a typical "Alice" might be behind an address-filtering
NAT is something that can be measured in the wild.  I have not 
seen reliable numbers of such testing in the wild, but 25% has 
been mentioned.  There are known geographies (e.g., Switzerland) 
where the number is higher because the major ISP provided
address-filtering NAT to their subscribers.

The same problem described above also exists for IPv6, because 
IPv6 residential-class CPE ship with filtering enabled by default.
I expect small/medium businesses and enterprises will also do
IPv6 filtering for all the (good) reasons the do IPv4 filtering
today.

Said another way - it ain't just NAT's fault that life is like
this.

If Alice's client application (and/or OS) and NAT (or firewall) 
implement a mapping protocol (e.g., NAT-PMP, UPnP IGD, or PCP), 
then Bob's connectivity checks will not suffer any delay.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Jan 2012 06:02:44 -0800

> ice-pwd.  That isn't a problem; she can validate them later.

Dan,

I think you are wrong here. In the context of ICE the following applies
to responding to any Binding Request, per section 7.2 of RFC 5245:

The agent MUST use a short-term credential to authenticate the
   request and perform a message integrity check.

So, unless alice has received the ufrag and the password you are dead in
the water.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Jan 2012 13:56:27 -0800

> Behalf Of Magnus Westerlund
> Sent: Tuesday, January 31, 2012 6:03 AM
> To: [email-masked]
> So, unless alice has received the ufrag and the password you are dead
> in the water.

You neglected to read that entire paragraph.  The important part
begins with the sentence "It is possible" and continues to 
the end of the paragraph.  It is from 
http://tools.ietf.org/html/rfc5245#section-7.2, and copied here:

   The agent MUST use a short-term credential to authenticate the
   request and perform a message integrity check.  The agent MUST
   consider the username to be valid if it consists of two values
   separated by a colon, where the first value is equal to the username
   fragment generated by the agent in an offer or answer for a session
   in-progress.  It is possible (and in fact very likely) that an
   offerer will receive a Binding request prior to receiving the answer
   from its peer.  If this happens, the agent MUST immediately generate
   a response (including computation of the mapped address as described
   in Section 7.2.1.2).  The agent has sufficient information at this
   point to generate the response; the password from the peer is not
   required.  Once the answer is received, it MUST proceed with the
   remaining steps required, namely, 7.2.1.3, 7.2.1.4, and 7.2.1.5 for
   full implementations.  In cases where multiple STUN requests are
   received before the answer, this may cause several pairs to be queued
   up in the triggered check queue.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Jan 2012 16:50:50 -0800

>    up in the triggered check queue.

Hmmm, there is something strange here.

First, this seems to reduce the incoming verfication to that the request
has has a username that contains the agents local ufrag.

Secondly, the outgoing response can't be signed by the agent, as it
needs the requestors password and ufrag to do that.

So how does this achieve the security goals of ensuring that only
entities that has the secret responds correctly?

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Jan 2012 16:56:20 -0800

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, January 31, 2012 4:51 PM
> To: Dan Wing
> Cc: [email-masked]
> First, this seems to reduce the incoming verfication

Yes.  The verification is done later, when the Answer arrives.  If
verification succeeds, all is well.  If verification fails, Alice
(who was the Offerer) throws away the information received because
it was bogus.

> to that the
> request has has a username that contains the agents local ufrag.
> 

It doesn't - the password from the peer isn't required; only the
Offerer's password is needed, which the Offerer already knows (because
the Offerer sent it in SDP).

> entities that has the secret responds correctly?

It does meet that goal.

Let's talk in person about it.

-d