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

From: [email-masked]
Date: Mon, 30 Oct 2006 16:45:32 -0500 (EST)

See inline.

Jonathan Rosenberg <[email-masked]> said:
> 
> 
> [email-masked] wrote:
> 
>> 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.
> 
> 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.

Consider a network where the SBC is not important for anything except NAT traversal.  It is desirable to get rid of the SBC in this network(esp. when building a new network) and use a pure TURN/ICE approach. The TURN/ICE approach should result in less realed traffic and will also allow easy deployment of SIP-identity and other technololgies that require that the message body remain intact. 

If ICE doesn't deal with problem ALG devices TLS is required. If TLS isn't used an SBC will be required to deal with the hotel ALG scenario, and this SBC will have to be ICE aware for TURN to be used at the same time. If this network requires TLS or SBCs it will have a higher cost(initial and recurring) than the TURN/ICE approach. Also, an ICE-aware SBC will be required for TURN to deployed. 

Another consideration is the work in P2P-SIP. P2P-SIP will most likely use ICE with some nodes acting as relay devices.  So, to get around misbehaving ALG devices P2P-sip would also require an encrypted channel or SBC like functionality at the relay node.
> 
>>
>> 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.

Consider an existing network where the SBC is providing NAT traversal when necessary. This is usually inefficient and a lot of traffic is relayed unecessarily. If this network is a blood-simple SIP network built on the internet it will probably:

1. Signal SIP over UDP
2. Use SBCs for NAT traversal, which are not ICE-aware.
3. Have PSTN-SIP gateways that are not ICE-aware.
4. Does not have control over all network elements, so will suffer from hotel ALGs.

To optimize traffic, the network has be upgraded to:

1. Have PSTN-SIP gateways that are ICE-aware.
2. Have SBCs that are ICE-aware.
3. Deploy endpoints that are ICE-aware.

I agree that deploying ICE in the network before the upgrade could be harmful if the network will tear down calls that do not support the media path.  However, a network that does not have this property will benefit from 3. There are no issues with ice when a network has 2 and 3.

I still think the core issue is whether:
1) ICE should not 'work around' devices that change the m/c line so it can be deployed in noetworks that rely on traffic following a certain path without a device being ICE-aware.
2) Networks should disable ICE if it can cause problems.

I'm strongly in favour of 2.  ICE seems useless in type 1 networks, as ICE processing will not occur unless the network has detected that two ICE-aware endpoints have reach to each other before the offer reaches the ICE-unaware SBC, or if the devices are not NATd.  Of course, ICE is accomplishing little if the devices were not behind a NAT.

I think another reason for 2 is that it is likely that even if ICE continues to require that the m/c line match a candidate, some ice implementations will *not* follow this mandate as they may have been tweaked for the TURN/ICE deployment described above.

Deploying an ICE endpoint which always attempts ICE in a network which is not prepared for ICE will at worst result in dropped calls for that endpoint.  This should be a self-correcting problem, as the user will either disable ICE, or change the ICE behaviour if we go with the dual operating mode approach.
> 
> 
>>
>> 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.

I don't think we should write an algorithm, and as you say it would be extremely difficult if not impossible. This would have to be a configuration parameter on the endpoint.  
> 
> -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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Oct 2006 13:01:49 -0500

inline.

[email-masked] wrote:

>>> 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.
>> 
>> 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:
>> 
>> 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.
> 
> 
> Consider a network where the SBC is not important for anything except
> NAT traversal.  It is desirable to get rid of the SBC in this
> network(esp. when building a new network) and use a pure TURN/ICE
> approach. The TURN/ICE approach should result in less realed traffic
> and will also allow easy deployment of SIP-identity and other
> technololgies that require that the message body remain intact.

Sure. In this use case, don't deploy an SBC. Or if you have a mix of ICE 
and non-ICE endpoints, have the SBC simply back off for ICE calls. It 
sounds like you want to support a case where the operator wants to keep 
their existing SBC, and by adding ICE endpoints, reduce load on the SBC 
by having traffic cease flowing through it when a direct path is 
detected by ICE.

I can see why you would want to do that. However my point remains that 
and endpoint CANNOT TELL whether disregarding the m/c-line will result 
in media working or failing.

> 
> If ICE doesn't deal with problem ALG devices TLS is required. If TLS
> isn't used an SBC will be required to deal with the hotel ALG
> scenario, and this SBC will have to be ICE aware for TURN to be used
> at the same time. If this network requires TLS or SBCs it will have a
> higher cost(initial and recurring) than the TURN/ICE approach. Also,
> an ICE-aware SBC will be required for TURN to deployed.

I realize that TLS is higher cost than no TLS. But its the reliability 
bit that gets me. Any other solution is simply not going to work reliably.

> 
> Another consideration is the work in P2P-SIP. P2P-SIP will most
> likely use ICE with some nodes acting as relay devices.  So, to get
> around misbehaving ALG devices P2P-sip would also require an
> encrypted channel or SBC like functionality at the relay node.

TLS works fine here too.

>>> 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.
> 
> 
> Consider an existing network where the SBC is providing NAT traversal
> when necessary. This is usually inefficient and a lot of traffic is
> relayed unecessarily. If this network is a blood-simple SIP network
> built on the internet it will probably:
> 
> 1. Signal SIP over UDP 2. Use SBCs for NAT traversal, which are not
> ICE-aware. 3. Have PSTN-SIP gateways that are not ICE-aware. 4. Does
> not have control over all network elements, so will suffer from hotel
> ALGs.
> 
> 1. Have PSTN-SIP gateways that are ICE-aware. 2. Have SBCs that are
> ICE-aware. 3. Deploy endpoints that are ICE-aware.
> 
> I agree that deploying ICE in the network before the upgrade could be
> harmful if the network will tear down calls that do not support the
> media path.  However, a network that does not have this property will
> benefit from 3. There are no issues with ice when a network has 2 and
> 3.

But how does the endpoint know???

> 
> I still think the core issue is whether: 1) ICE should not 'work
> around' devices that change the m/c line so it can be deployed in
> noetworks that rely on traffic following a certain path without a
> device being ICE-aware. 2) Networks should disable ICE if it can
> cause problems.
> 
> I'm strongly in favour of 2.  ICE seems useless in type 1 networks,
> as ICE processing will not occur unless the network has detected that
> two ICE-aware endpoints have reach to each other before the offer
> reaches the ICE-unaware SBC, or if the devices are not NATd.  Of
> course, ICE is accomplishing little if the devices were not behind a
> NAT.

I'm lost here on what a 'type 1 network' is.

> 
> I think another reason for 2 is that it is likely that even if ICE
> continues to require that the m/c line match a candidate, some ice
> implementations will *not* follow this mandate as they may have been
> tweaked for the TURN/ICE deployment described above.

I cannot stop people from breaking the spec. We are trying to figure out 
what is right and codify it.

> 
> Deploying an ICE endpoint which always attempts ICE in a network
> which is not prepared for ICE will at worst result in dropped calls
> for that endpoint.  This should be a self-correcting problem, as the
> user will either disable ICE, or change the ICE behaviour if we go
> with the dual operating mode approach.

ICE will be invisible. Users will not know what it is or know how to 
disable it. The whole idea with ICE is that it makes voip work more 
reliably without configuration or assumptions. You are proposing to make 
a bunch of assumptions and add configuration to the endpoint for voip to 
work.

> 
>> 
>>> 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.
> 
> 
> I don't think we should write an algorithm, and as you say it would
> be extremely difficult if not impossible. This would have to be a
> configuration parameter on the endpoint.

See above. I think there is no hope of user configuration for this 
parameter.

-Jonathan R.