Subject: [MMUSIC] ICE-12, SBCs and hotel ALGs

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2006 17:39:59 -0400

A big topic of discussion on the list and in our calls has been what ICE 
should do in the presence of SBCs and hotel-ALG and similar beasts which 
try and 'help' but get in the way.

I had proposed a solution on the list here:
http://www1.ietf.org/mail-archive/web/mmusic/current/msg04696.html

THe essential idea was that ICE would look for the m/c-line to not match 
any existing candidates, and if not, treat it as a high priority 
candidate. If it works, use it, if not, fall back.

This sounds great in theory, but when I got down to writing it up, some 
issues arose.

Firstly, the proposal was based on the theory that an SBC would pass 
STUN packets on the RTP ports. I spoke to several vendors of SBCs and it 
turns out this is often not the case. Indeed, in their role as "security 
boxes", many of them will rate limit the RTP, or prevent early media, or 
check for the right payload types, etc., all of which will cause the 
STUN checks to fail even though the RTP will work. Furthermore, some 
SBCs will in fact terminate a call if they see no media traffic, so 
bypassing them will not help. THus, my proposed approach would make 
calls fail when they would otherwise work if we didn't try and make ICE 
work in the presence of SBCs.

Secondly, the proposal flat out doesn't work for TCP, since the 
candidate line for TCP includes some crucial information (active/passive 
roles or SO), which is missing for the m/c-line. One of the things I 
accomplished with this set of revisions is a unification of the UDP and 
TCP mecahnisms. I think its a mistake to break that.

Finally, it was going to make it harder to specify this "passive-only" 
mode, also known as ICE-for-gateways. In the current -12 a gateway 
doesn't even maintain a candidate list for its peer; with this proposal 
it would need to do some of it.

So, ICE-12 does not contain the proposal in the mail above. Rather, it 
specifies that if an offer shows up, and the m/c-line doesn't match any 
candidate, you abort ICE processing (just like -11 and -10 said). It 
also adds that, when a re-invite comes to confirm the pairs selected by 
ICE, if the m/c-line doesn't match what is selected by ICE, use the 
pairs selected by ICE.

My main rationale on the first piece of this (if m/c-line doesnt match a 
candidate, abort) is that we dont know what SBCs will or won't do. Their 
behaviors are not specified, and they are highly variable. If the 
purpose of ICE is to make voip *reliable*, then the most reliable thing 
is to abort ICE processing and go with the relays. In a real sense, the 
b2bua is a UA on the path; we abort ICE when an ICE-capable UA calls an 
ICE-unaware UA - thats the only safe thing to do. Same here.

This does mean that if you have a non-ICE SBC in a network with ICE 
endpoints, you get an extra relay hop in the call path. Extra latency - 
but reliable. If however you make the SBC ice-aware, that problem goes 
away, and there are many ways to do that which we don't need to specify. 
I might argue that, within your own network, if you deploy ICE to 
endpoints and have non-ICE SBC, you should be happy it works at all let 
alone that it works with just an extra media hop.

Consequently, ICE will only proceed in -12 if the m/c-line MATCHES a 
candidate. There is only one case I found where you still have some kind 
of non-ICE media intermediary on the path, and ICE would proceed - an 
ALG which leaves the m/c-line alone with its on the public side of the 
NAT. In that case, ICE checks can proceed and will most often validate 
that address anyway. In the case where both endpoints are behind the 
same NAT/ALG, ICE would find that the direct path works, and re-invite 
to it. NOW, the helpful ALG might rewrite the SDP to the public value. 
With ICE-12, media would still flow direct.

There is also a case where the m/c-line don't match what ICE selected, 
even though there isn't an intermediary. That case is when severe packet 
loss causes each side to disagree on the selected candidates. In that 
case I think an agent should use what it thinks works, and that is why 
ICE-12 specifies to ignore the m/c-line in this case.

Generally I don't like sending media to somewhere else than the 
m/c-lines. However, the important point is that in ICE-12, that ISNT 
going to happen except for these two cases, and the former case you 
reallly want to fix with TLS. That reduces the mismatch to one of a bad 
failure case, and if that is our only mismatch use case I am not so 
worried about it.

Backing up one step further, this idea of 'getting around SBCs and ALGs' 
was never a real requirement for ICE, and I am worried that it is 
something that is fraught with problems. I don't want to try and dump 
lots more complexity into ICE to try and guess our way around SBC and 
ALG implementations. TLS is the surefire way to deal with ALGs. Let us 
design ICE for how it ought to work without SBCs and ALGs, make sure it 
has a backwards compatibility mode when they are present, and then 
declare victory. Right now, I think the market needs a light-as-possible 
and FINISHED ICE spec more than anything else.

Thanks,
Jonathan R.

-- 
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

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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Oct 2006 19:42:21 -0500

I agree with your conclusion.

Your last paragraph is exaclty what I've been saying before.

Thanks. 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 2:40 PM
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE-12, SBCs and hotel ALGs
> 
> A big topic of discussion on the list and in our calls has 
> been what ICE should do in the presence of SBCs and hotel-ALG 
> and similar beasts which try and 'help' but get in the way.
> 
> THe essential idea was that ICE would look for the m/c-line 
> to not match any existing candidates, and if not, treat it as 
> a high priority candidate. If it works, use it, if not, fall back.
> 
> This sounds great in theory, but when I got down to writing 
> it up, some issues arose.
> 
> Firstly, the proposal was based on the theory that an SBC 
> would pass STUN packets on the RTP ports. I spoke to several 
> vendors of SBCs and it turns out this is often not the case. 
> Indeed, in their role as "security boxes", many of them will 
> rate limit the RTP, or prevent early media, or check for the 
> right payload types, etc., all of which will cause the STUN 
> checks to fail even though the RTP will work. Furthermore, 
> some SBCs will in fact terminate a call if they see no media 
> traffic, so bypassing them will not help. THus, my proposed 
> approach would make calls fail when they would otherwise work 
> if we didn't try and make ICE work in the presence of SBCs.
> 
> Secondly, the proposal flat out doesn't work for TCP, since 
> the candidate line for TCP includes some crucial information 
> (active/passive roles or SO), which is missing for the 
> m/c-line. One of the things I accomplished with this set of 
> revisions is a unification of the UDP and TCP mecahnisms. I 
> think its a mistake to break that.
> 
> mode, also known as ICE-for-gateways. In the current -12 a 
> gateway doesn't even maintain a candidate list for its peer; 
> with this proposal it would need to do some of it.
> 
> So, ICE-12 does not contain the proposal in the mail above. 
> Rather, it specifies that if an offer shows up, and the 
> m/c-line doesn't match any candidate, you abort ICE 
> processing (just like -11 and -10 said). It also adds that, 
> when a re-invite comes to confirm the pairs selected by ICE, 
> if the m/c-line doesn't match what is selected by ICE, use 
> the pairs selected by ICE.
> 
> My main rationale on the first piece of this (if m/c-line 
> doesnt match a candidate, abort) is that we dont know what 
> SBCs will or won't do. Their behaviors are not specified, and 
> they are highly variable. If the purpose of ICE is to make 
> voip *reliable*, then the most reliable thing is to abort ICE 
> processing and go with the relays. In a real sense, the b2bua 
> is a UA on the path; we abort ICE when an ICE-capable UA 
> calls an ICE-unaware UA - thats the only safe thing to do. Same here.
> 
> This does mean that if you have a non-ICE SBC in a network 
> with ICE endpoints, you get an extra relay hop in the call 
> path. Extra latency - but reliable. If however you make the 
> SBC ice-aware, that problem goes away, and there are many 
> ways to do that which we don't need to specify. 
> I might argue that, within your own network, if you deploy 
> ICE to endpoints and have non-ICE SBC, you should be happy it 
> works at all let alone that it works with just an extra media hop.
> 
> Consequently, ICE will only proceed in -12 if the m/c-line 
> MATCHES a candidate. There is only one case I found where you 
> still have some kind of non-ICE media intermediary on the 
> path, and ICE would proceed - an ALG which leaves the 
> m/c-line alone with its on the public side of the NAT. In 
> that case, ICE checks can proceed and will most often 
> validate that address anyway. In the case where both 
> endpoints are behind the same NAT/ALG, ICE would find that 
> the direct path works, and re-invite to it. NOW, the helpful 
> ALG might rewrite the SDP to the public value. 
> There is also a case where the m/c-line don't match what ICE 
> selected, even though there isn't an intermediary. That case 
> is when severe packet loss causes each side to disagree on 
> the selected candidates. In that case I think an agent should 
> use what it thinks works, and that is why
> Generally I don't like sending media to somewhere else than 
> the m/c-lines. However, the important point is that in 
> ICE-12, that ISNT going to happen except for these two cases, 
> and the former case you reallly want to fix with TLS. That 
> reduces the mismatch to one of a bad failure case, and if 
> that is our only mismatch use case I am not so worried about it.
> 
> 
> was never a real requirement for ICE, and I am worried that 
> it is something that is fraught with problems. I don't want 
> to try and dump lots more complexity into ICE to try and 
> guess our way around SBC and ALG implementations. TLS is the 
> surefire way to deal with ALGs. Let us design ICE for how it 
> ought to work without SBCs and ALGs, make sure it has a 
> backwards compatibility mode when they are present, and then 
> declare victory. Right now, I think the market needs a 
> light-as-possible and FINISHED ICE spec more than anything else.
> 
> Thanks,
> Jonathan R.
> 
> 
> --