Subject: RE: [MMUSIC] ICE-TCP: Why isn't passive enough for ICE lite

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 7 Nov 2007 18:51:05 +0100

Any comments on this?
 
Regards,
 
Christer

________________________________

	From: Christer Holmberg [mailto:[email-masked]] 
	Sent: 26. lokakuuta 2007 13:48
	To: [email-masked]
	Subject: [MMUSIC] ICE-TCP: Why isn't passive enough for ICE lite

	Hi, 

	The ICE-TCP draft says that all entities supporting ICE for TCP
must be full ICE compliant. 

	My question is: why can't an ICE lite entity (ie an entity which
knows it's not located behind a NAT) simply send a single TCP passive
candidate, and tell the other party (possibly located behind a NAT) to
establish that TCP connection. That should work with all NATs, shouldn't
it?

	Regards, 

	Christer 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Nov 2007 21:10:37 -0500

Sorry for the delay. I've been pondering this question in fact.

The biggest issue really is that things get really troubling when two 
lite implementations call each other. Both would insist that they be 
passive and you'd end up with neither side initiating the tcp 
connection. This is probably fixable; the spec would need to say that if 
this happens one of the sides initiates the connection. We'd need to 
make sure we can negotiate that, and that would be a different 
negotiation than the way ICE negotiates other directionalities.

So, there would be added complexity to do this. Is there a real need? 
Frankly ICE-lite is meant as a stepping stone. Do we really need it for 
ice-tcp?

-Jonathan R.

Christer Holmberg wrote:
> 
> Hi,
> 
> The ICE-TCP draft says that all entities supporting ICE for TCP must be 
> full ICE compliant.
> 
> My question is: why can't an ICE lite entity (ie an entity which knows 
> it's not located behind a NAT) simply send a single TCP passive 
> establish that TCP connection. That should work with all NATs, shouldn't it?
> 
> Regards,
> 
> Christer
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 13 Nov 2007 10:03:13 +0100

Hi Jonathan,

>The biggest issue really is that things get really troubling 
>when two lite implementations call each other. Both would 
>insist that they be passive and you'd end up with neither 
>side initiating the tcp connection. This is probably fixable; 
>the spec would need to say that if this happens one of the 
>sides initiates the connection. We'd need to make sure we can 
>negotiate that, and that would be a different negotiation 
>than the way ICE negotiates other directionalities.
> 
>Frankly ICE-lite is meant as a stepping stone. Do we really 
>need it for ice-tcp?

The background is the work in 3GPP, and the discussions on how to deal
with ICE when there are B2BUAs in the path. Doing "full TCP-ICE" (as
defined by the draft) is quite "heavy", so a couple of ideas have been
presented how things could be made easier in cases where there are
B2BUAs in the path.

One of the ideas is that the B2BUA only sends "passive" towards the
clients, indicating that they shall establish TCP connections towards
the B2BUA. The clients themselves would still insert candidates etc
according to the draft (in case there is no B2BUA in the path and the
clients will communicate directly with each other).

The second idea is that the B2BUA doesn't include any candidates for TCP
streams towards the clients, and forces a "fallback" to RFC 4145. The
B2BUA would use the appropriate RFC 4145 attribute values to tell the
clients to initiate TCP connections towards the B2BUA. Now, in this case
the TCP streams would in many cases pass through a STUN relay, even if
it may not be needed, but due to less TCP connections, no connectivity
checks etc it would be an even "lighter" solution for TCP.

This was discussed in 3GPP, and it was agreed to bring the issue to
IETF, so I think there IS a need.

Regards,

Christer

> Christer Holmberg wrote:
> > 
> > Hi,
> > 
> > The ICE-TCP draft says that all entities supporting ICE for 
> TCP must 
> > be full ICE compliant.
> >

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 13 Nov 2007 11:34:19 +0200

> clients will communicate directly with each other).

You have the exact problem that JR was referring to.

Say there are two "B2BUAs" on the path, both setting the "passive" flag on 
both side. You end up with a complete dead lock whereby both B2BUA waits for 
the other to establish the connection.

-- 
Rémi Denis-Courmont

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 13 Nov 2007 10:55:20 +0100

>Say there are two "B2BUAs" on the path, both setting the 
>"passive" flag on both side. You end up with a complete dead 
>lock whereby both B2BUA waits for the other to establish the 
>connection.

In this case the second B2BUA would establish the TCP connection towards the first B2BUA, since it only receives "passive".

So, one must of course be prepared to establish a TCP connection if only "passive" is received. The point is that it should be "allowed" to only send "passive" in the first place.

Regards,

Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 13 Nov 2007 23:48:50 -0500

There are many ways that a B2BUA can deal with ICE when it is ICE aware. 
Frankly the easiest is that it leaves things alone, doesn't modify the 
SDP at all, and lets ICE negotiation take place through it. I'm guessing 
3gpp wanted to have the b2bua also act as a media intermediary? Easiest 
way for that is for it to also be the TURN server...

-Jonathan R.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 Nov 2007 09:45:50 +0100

Hi, 

>There are many ways that a B2BUA can deal with ICE when it is ICE
aware. 

Yes.

But, this could be used also by an MGCF, or other entities which know
they are not located behind NATs (entities which for UDP would perform
ICE lite procedures)

>Frankly the easiest is that it leaves things alone, doesn't 
>modify the SDP at all, and lets ICE negotiation take place 
>through it.
>
>I'm guessing 3gpp wanted to have the b2bua also act as a media
intermediary?

Yes. In no-media cases there should not be any problem.

>Easiest way for that is for it to also be the TURN server...

I don't think that is always possible, because the B2BUA doing this can
be in another domain. And, there may by multiple B2BUAs in the path.

I am happy to discuss the different alternatives that were presented in
3GPP with you off-line.

But, the focus on THIS discussion is TCP, and whether it would be
allowed to only send "passive". I have found no techncial issues to do
so.

(The other alternative, which I also mentioned earlier, is to remove all
candiates for TCP, but that would require that ICE is still performed
for UDP streams which do contain candidates.)

Regards,

Christer

> >> connection. This is probably fixable; the spec would need 
> to say that 
> >> if this happens one of the sides initiates the connection. 
> We'd need 
> >> to make sure we can negotiate that, and that would be a different 
> >> Frankly ICE-lite is meant as a stepping stone. Do we 
> really need it 
> >> for ice-tcp?
> > 
> > The second idea is that the B2BUA doesn't include any 
> candidates for 
> > TCP streams towards the clients, and forces a "fallback" to 
> RFC 4145. 
> > The B2BUA would use the appropriate RFC 4145 attribute 
> values to tell 
> > the clients to initiate TCP connections towards the B2BUA. Now, in 
> > this case the TCP streams would in many cases pass through a STUN 
> > relay, even if it may not be needed, but due to less TCP 
> connections, 
> > no connectivity checks etc it would be an even "lighter" 
> solution for TCP.
> > 
> ---------------------------------------------------------------------
> >> -
> >>> --
> >>>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 Nov 2007 09:36:22 -0800

>they are not located behind NATs (entities which for UDP would perform

As I've said on other lists, knowing you are not behind a NAT is
already tricky and going to get trickier as we get more and more
pressure on v4 address space.  As 3gpp has moved to accept new
address network types, I wonder how long it will be true for its
networks.

<snip>
>be in another domain. And, there may by multiple B2BUAs in the path.

Are you assuming that each of the B2BUAs in the path will be participating
in ICE?

>allowed to only send "passive". I have found no techncial issues to do

Maybe I missed your reply to this, but how are you avoiding the
problem when both send "passive"?

>for UDP streams which do contain candidates.)

This seems like a potentially bad idea, as it may remove the candidates
which would be best according to the other side's network conditions/limitations.

In the original message you, argued that ICE TCP was heavyweight for
B2BUA's (for those that want to be media intermediaries in particular
it seems).  Since there are clearly other alternatives, like letting the
ICE negotiation take place through it, why select the heavyweight alternative?
Can you describe the problem in more detail for the currently proposed
case (is it buffer exhaustion,  state overhead, something else)?

To put this another way, can you describe the problem in ways that justify
a design change to something in the RFC Editor's queue?  Because this
out the door seems to be a pretty high priority.  Clawing it back at this
point for this change when there seems to be no broken protocol behavior
seems hard to justify.

Sorry if that seems harsh; I just don't think I get the problem you're describing
yet.
			thanks,
				Ted

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2007 14:24:48 -0500

Ted,

To clarify one point, Christer's comments are against ice-tcp which is 
NOT in rfc-ed queue. That document has not even had WGLC, so it 
certainly is possible to make a change if we like.

I have thought about this a bit, and do think its possible to avoid the 
deadlock case. WHat would happen is that an ice-lite-tcp endpoint would 
include a passive tcp candidate only, and also utilize the rfc4145 
directional attributes (a=active, passive, actpass). When two ice-lite 
endpoints meet each other, they basically ditch ICE and utilize the 4145 
attributes to determine directionality. All ice-lite endpoints would 
need to support the ability to actively open a tcp connection (I.e,. to 
be able to support a=active) despite the fact that it had a passive only 
ICE candidate.

When an ice-lite endpoint meets a regular ICE endpoint the rfc4145 
attributes are ignored and ICE is used to determine connection 
directionality. In that case the lite endpoint will always be passive.

So, I think its not too hard to add this to the spec. I would still like 
to understand the same things Ted has asked, about whether it is really 
impossible to support full ICE. As Ted says, the "not natted" (and also 
keep in mind, not firewalled) determination is becoming harder and more 
complex over time. ice-lite was meant as a stepping stone and as we 
know, short term solutions often aren't, so I want to be careful about 
watering down ice-tcp with a lite version. We should tread there carefully.

THanks,
Jonathan R.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 Nov 2007 13:07:32 -0800

At 2:24 PM -0500 11/14/07, Jonathan Rosenberg wrote:
>Ted,
>
>To clarify one point, Christer's comments are against ice-tcp which is NOT in rfc-ed queue. That document has not even had WGLC, so it certainly is possible to make a change if we like.

Sorry, and thanks for that correction.

>I have thought about this a bit, and do think its possible to avoid the deadlock case. WHat would happen is that an ice-lite-tcp endpoint would include a passive tcp candidate only, and also utilize the rfc4145 directional attributes (a=active, passive, actpass). When two ice-lite endpoints meet each other, they basically ditch ICE and utilize the 4145 attributes to determine directionality. All ice-lite endpoints would need to support the ability to actively open a tcp connection (I.e,. to be able to support a=active) despite the fact that it had a passive only ICE candidate.

This really goes back to understanding what the heavyweight aspects are.  If they
have to support this, even if they had passive-only ICE candidates, what is
the resource that is saved?
			regards,
				Ted

>When an ice-lite endpoint meets a regular ICE endpoint the rfc4145 attributes are ignored and ICE is used to determine connection directionality. In that case the lite endpoint will always be passive.
>
>So, I think its not too hard to add this to the spec. I would still like to understand the same things Ted has asked, about whether it is really impossible to support full ICE. As Ted says, the "not natted" (and also keep in mind, not firewalled) determination is becoming harder and more complex over time. ice-lite was meant as a stepping stone and as we know, short term solutions often aren't, so I want to be careful about watering down ice-tcp with a lite version. We should tread there carefully.
>
>THanks,
>Jonathan R.
>
>
>Ted Hardie wrote:

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 Nov 2007 23:30:20 +0100

Hi,

>be able to support a=active) despite the fact that it had a passive only
 
I was thinking that the ice-lite entity which receives only a passive candidate would open the tcp connection and send an active candidate back. But, I guess your "fallback-to-4145" proposal makes it even simpler, becuase there would be no connectivity checks etc between the two ice-lite entities.

>directionality. In that case the lite endpoint will always be passive.
 
Correct. The behavior of regular ICE endpoints would not change - except for the fact that they would have to be prepared to recieve only a passive candidate.

>impossible to support full ICE.
>
> As Ted says, the "not natted" (and also
 
I agree that we should make it very clear that ice-lite procedures are to be used only when one really knows that the entity is not located behind a NAT.
 
But, there are cases when it IS known that entities are not located behind NATs, so it would be really beneficial to be able to have these ice-lite procedures. I think it would also speed up the deployment of ICE.
 
Regards,
 
Christer

 
>>>>> http://www.jdrosen.net <http://www.jdrosen.net/>                          PHONE:
>>> (973) 952-5000
>>>>> http://www.cisco.com <http://www.cisco.com/> 
>>>>>
>>> --
>>> http://www.jdrosen.net <http://www.jdrosen.net/>                          PHONE: (973) 952-5000
>>> http://www.cisco.com <http://www.cisco.com/> 
>>>
>>

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net <http://www.jdrosen.net/>                          PHONE: (973) 952-5000
http://www.cisco.com <http://www.cisco.com/>