Subject: RE: VS: [MMUSIC] ICE: Client supports, but network doesn't

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 4 Jul 2006 15:43:17 +0200

Hi,

>My colleague Eric Cooper and I thought a bit about this and came up 
>with the following.
>
>Why is the box in the middle  changing the m/c lines?
>In our opinion, either:
>1a)  It is trying to help with NAT traversal, OR
>1b)  It is trying to force the packets to flow through it.

[CHH] It could also be 1a AND 1b.

>Also, the box is either:
>2a) not ICE aware, OR
>2b) is ICE aware.
>
>Consider first the combination of (1a) and (2a) -- for example,
>a box trying to help with NAT traversal that is not ICE aware.
>In this case, the modified m/c line provides an alternative transport 
>address.
>This address may work, or it may not, depending on the network 
>situation.
>So it seems best if ICE consider this another candidate  and try to 
>validate it.

[CHH] "This another candidate" is the c/m line, right?

>To do this, each endpoint could, for example, include "default" 
>candidate ids and passwords in the offer or  answer that would be used by the remote end if the m/
>c line gets changed.
>
>Now consider the  combination (1a) and (2b) -- a box trying to help with
>NAT traversal that is ICE aware. Here the solution of the previous 
>paragraph still works, and Eric and I could not think of anything better that an ICE-
>aware box could do.
>
>Next, consider the combination (1b) and (2b) - an ICE-aware box that 
>is trying to force the media to flow through it.  In this case, the box can simply 
>delete all the ICE-related lines from the SDP, and the remote end will fall back to non-ICE 
>behavior, which will cause all traffic to flow through the box.
>
>Finally, consider the combination (1b) and (2a) - a non-ICE aware box 
>that is trying to force media to flow through it. In this case ... well ... the 
>endpoints, not realizing that the box wants to be in the media path, will try other paths. If one 
>of these succeeds, then the box will be bypassed. Otherwise, if only the modified m/c 
>transport address works, then the media will flow through the box.  If this is not the desired 
>behavior, well, just upgrade the box to an ICE-aware version!

[CHH] Depending on the functionlaity provided by the "box", e.g. if it provides BOTH 1a and 1b, an ICE aware box may of course also modify the candidate attributes.

Regards,

Christer

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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 5 Jul 2006 13:14:52 -0400

Just adding a bit more to Eric's comments.
See inline.

- Philip

> [CHH] It could also be 1a AND 1b.

We view (1a + 1b) to be the same as 1b.  In other words, 1a means the  
traffic
does not necessarily have to flow through the box, while 1b means the  
box
wants to be in the middle.

> [CHH] "This another candidate" is the c/m line, right?

As Eric said, "yes".

> [CHH] Depending on the functionlaity provided by the "box", e.g. if  
> it provides BOTH 1a and 1b, an ICE aware box may of course also  
> modify the candidate attributes.
>

Sure.

One more point. After thinking a bit more about this, having a box  
simply delete all the ICE-related
lines in order to force the media through it might not be the best  
way to achieve 1b. ICE provides certain security
properties, and we might want to preserve this. So an ICE-aware box  
that wants to remain in the
middle should probably modify the ICE-related lines in some way.  
Perhaps it should delete all
the a-candidate lines for other candidates, but leave in the  
"default" candidate info (see above).

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 16:13:20 -0400

A few comments here.

Firstly, I stronly oppose the idea that, if an m/c-line is not listed 
amongst the candidates, we should use default stun usernames and 
passwords and try and do the checks.

My main reason for this is that I believe it will be a tremendous 
barrier to ICE deployment. I like ICE. I want it to get deployed. An 
unfortunate reality of voip today is that there are these session border 
controllers all over the place, and they do rewrite the m/c-line, and 
very possibly may leave the other attributes alone. In such a case, I 
don't want the introduction of ICE into these endpoints to start causing 
surprise behaviors in the network (namely, bypassing the ICE-unaware 
SBC). Thats just a recipe for making the provider install an ICE-aware 
SBC that simply blocks ICE entirely. I don't think it is ICE's role to 
be a trojan horse that forces media to work directly even when there are 
SBCs in the loop that say otherwise. This is why I want ICE to be 
fail-safe. If it looks like an SBC was in the way, things should work as 
if ICE wasn't there. I think this can only help ICE deployment, not hurt it.

Secondly, its extremely likely that connectivity checks sent through the 
SBC, when its not ice-aware, will fail. The reason is that the SBC is 
going to be looking for RTP packets. SBCs do all kinds of RTP packet 
processing. The ICE packets will get discarded immediately. Thus, the 
checks fail, the m/c-line isn't used, and the SBC is either bypassed or 
the call fails. Both are bad IMHO.

Thanks,
Jonathan R.

Philip Matthews wrote:

> does not necessarily have to flow through the box, while 1b means the  box
> lines in order to force the media through it might not be the best  way 
> to achieve 1b. ICE provides certain security
> the a-candidate lines for other candidates, but leave in the  "default" 
> candidate info (see above).
> 
> - Philip
> 

-- 
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: Philip Matthews <[email-masked]>
Date: Sat, 8 Jul 2006 10:01:26 -0400

On 7-Jul-06, at 16:13 , Jonathan Rosenberg wrote:

> A few comments here.
>
> Firstly, I stronly oppose the idea that, if an m/c-line is not  
> listed amongst the candidates, we should use default stun usernames  
> and passwords and try and do the checks.
>
> barrier to ICE deployment. I like ICE. I want it to get deployed.  
> An unfortunate reality of voip today is that there are these  
> session border controllers all over the place, and they do rewrite  
> the m/c-line, and very possibly may leave the other attributes  
> alone. In such a case, I don't want the introduction of ICE into  
> these endpoints to start causing surprise behaviors in the network  
> (namely, bypassing the ICE-unaware SBC). Thats just a recipe for  
> making the provider install an ICE-aware SBC that simply blocks ICE  
> entirely. I don't think it is ICE's role to be a trojan horse that  
> forces media to work directly even when there are SBCs in the loop  
> that say otherwise. This is why I want ICE to be fail-safe. If it  
> looks like an SBC was in the way, things should work as if ICE  
> wasn't there. I think this can only help ICE deployment, not hurt it.

I think this depends very much on WHY a provider has deployed an SBC.
If the point of the SBC is just to aid in NAT traversal, then by- 
passing it is not a problem.
It would be nice to get some service providers involved in this  
discussion.

>
> Secondly, its extremely likely that connectivity checks sent  
> through the SBC, when its not ice-aware, will fail. The reason is  
> that the SBC is going to be looking for RTP packets. SBCs do all  
> kinds of RTP packet processing. The ICE packets will get discarded  
> immediately. Thus, the checks fail, the m/c-line isn't used, and  
> the SBC is either bypassed or the call fails. Both are bad IMHO.

Good point about the SBC dropping the STUN packets.
If the SBC does deep packet inspection, then this would be a problem.

- Philip