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

From: [email-masked]
Date: Fri, 27 Oct 2006 15:14:26 -0400 (EDT)

The consensus that we reached on the ICE calls was that a user agent could ignore the m/c line if it couldn't validated by ICE. This is needed to deal with misbehaving ALG devices, which are an existing deployment issue. These devices are often not controlled by the network operator, and can be seen as morally equivalent to a misbehaving NAT from the ice requirements standpoint.

A large part of this debate was around whether SBC type devices needed to be ICE aware, or if ICE should be designed so that it deosn't "work around" existing SBCs. I don't know if we settled that debate; consensus seemd to be that it is easy for an SBC vendor to disable ice. Changing ice so that the m/c line MUST match a candidate assumes that the requirement is that ice not bypass existing SBC devices.  This includes the motivation that existing SBC devices do not allow ice checks to proceed. We need to resolve this SBC/ICE requirments debate if we are ever going to reach consensus on ICE.

It seems to me that a way forward is to have two operating modes for ice; one which is designed to honour existing middle boxes in a deployment, and one which just tries to establish connectivity.

I propose we have another ice breakout session this IETF to try to reach consensus on this long running issue. Given past performance, we should schedule several hours.

-Derek

Jonathan Rosenberg <[email-masked]> said:

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Oct 2006 17:53:22 -0800

[email-masked] writes:

> The consensus that we reached on the ICE calls was that a user agent
> could ignore the m/c line if it couldn't validated by ICE. This is
> needed to deal with misbehaving ALG devices, which are an existing
> deployment issue. These devices are often not controlled by the
> network operator, and can be seen as morally equivalent to a
> misbehaving NAT from the ice requirements standpoint.

I too am uncomfortable with aborting in this case.

> I propose we have another ice breakout session this IETF to try to
> reach consensus on this long running issue. Given past performance,
> we should schedule several hours.

Yeah, this sounds right. Let's schedule it soon, too, cause my
schedule is filling up already.

-Ekr

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Oct 2006 13:40:55 -0500

> misbehaving NAT from the ice requirements standpoint.

The problem I ran into is that this is the "right" thing to do for those 
nasty ALGs, but is exactly the wrong thing to do for an SBC thats on the 
path. THe UA cannot tell which is which. So, when an offer shows up with 
an m/c-line which doesn't match a candidate, and it doesn't validate, is 
the situation that:

1. there is an SBC on the path that is ice-unaware, and it blocks 
non-RTP packets from flowing

2. there is an ALG on the path that is broken and the m/c-line it 
provided doesnt work

You cannot differentiate these two cases with ICE. If you ignore the 
m/c-line assuming its case (2), and in reality its case (1), the call 
will fail.

So, the mechanism that can in fact make things more reliable here is to 
deal with the ALG problem with SIP over TLS, leaving only case 1. Then, 
in case 1, you do what I described in ICE-12 - use the m/c-line and 
abort ICE processing.

> 
> A large part of this debate was around whether SBC type devices
> needed to be ICE aware, or if ICE should be designed so that it
> deosn't "work around" existing SBCs. I don't know if we settled that
> debate; consensus seemd to be that it is easy for an SBC vendor to
> disable ice. Changing ice so that the m/c line MUST match a candidate
> assumes that the requirement is that ice not bypass existing SBC
> devices.  This includes the motivation that existing SBC devices do
> not allow ice checks to proceed. We need to resolve this SBC/ICE
> requirments debate if we are ever going to reach consensus on ICE.

THere are two cases to worry about - ICE aware and ICE-unaware SBCs. For 
ICE-aware, there are lots of things an SBC can do once it knows ICE is 
running. THis was really not the case we were worried about. Its an 
ICE-unaware SBC.

I believe the requirement is that calls do not fail in the presence of 
an ICE-unaware SBC. That is the only requirement I think we should 
strive to meet. Some folks wanted the requirement to get around the 
ICE-unaware SBC if a better path was available. I disagree with that and 
I think it is a path fraught with peril. You simply don't know how the 
SBC is configured or working and you should not guess your way around 
it. An SBC is a UA, and when one is in the way, its like talking to an 
ICE-unaware UA. We should abort ICE.

> 
> It seems to me that a way forward is to have two operating modes for
> ice; one which is designed to honour existing middle boxes in a
> deployment, and one which just tries to establish connectivity.

I really noodled on this for a while. Given the unpredictability of SBC 
and ALG behavior, I do not think you can write an algorithm which will 
work. The problem is that you just don't know what the SBC behavior is 
going to be.

-Jonathan R.