Subject: Re: [MMUSIC] Ice and open internet devices

From: [email-masked]
Date: Tue, 3 Oct 2006 11:53:42 -0400 (EDT)

A device would not determine that it is on the open internet by discovery; it would use configuration which is set at delpoyment time.

If a PSTN gateway is behind a NAT, it would have to implement full ice.  The purpose of 'ice-passive' is to simplify the implementation of devices that are not behind a NAT.

-Derek

Michael Slavitch <[email-masked]> said:

> In many situations that would fail. An assumption that a public IP
> address is not behind some kind of firewall, walled garden or gateway
> is a false assumption.
> 
> Philip is entirely correct about a PSTN gateway supporting ICE
> operating behind a NAT.  Same goes for any SIP registrar.
> 
> 
> On 10/3/06, Philip Matthews <[email-masked]> wrote:
>> Derek:
>>
>> How does a device determine that it is on the open Internet?
>> Does it look at its IP address? This mostly works,
>> but there was a recent case in Italy where this test would have failed.
>>
>> And, BTW, a PSTN gateway does not have to be on the open Internet.
>> With ICE, a PSTN gateway can easily be behind a NAT.
>>
>> - Philip
>>
>> On 2-Oct-06, at 19:51 , Derek MacDonald wrote:
>>
>> > Ice should be simplified for devices that are running on the open
>> > internet
>> > or not behind a NAT from the perspective of other devices.  The
>> > most common
>> > example of this device is a PSTN gateway, although B2BUAs could be
>> > deployed
>> > in the 'same place'.   I do not know of any ice-aware PSTN gateways
>> > that
>> > have been deployed, and I suspect this is due to the implementation
>> > cost of
>> > ice.
>> >
>> > Desired simplifications
>> >
>> > 1. stateless processing, or a much simplified ice state machine
>> > 2. should never be the deciding endpoint in the ice algorithm
>> > 3. limited communication between the signaling component and media
>> > component
>> >
>> >
>> > Proposed Solution
>> >
>> > This type of device, which I will refer to as a GW for convenience,
>> > will
>> > only ever have one candidate.  The candidate will be the global IP
>> > address
>> > of the GW, which will always be the same as the m/c line; so candidate
>> > gathering is eliminated.  The GW will not have a NAT/FW in front of
>> > it, so
>> > it will not have to send STUN requests to open NAT/FW permissions.
>> > Local
>> > permissions would have to be opened based on the remote SDP, but GW
>> > devices
>> > that wish to enforce must already do this for the remote m/c line.
>> > A GW
>> > does not prefer any candidate, as it only has one, so it has no
>> > motivation
>> > to prioritize candidates. This leads us to:
>> >
>> > 1. a GW will only perform triggered checks
>> > 2. for each component the GW will send media to the last successful
>> > triggered check, unless informed otherwise by the remote party
>> > 3. the GW is never the controlling endpoint, and will announce this
>> > in SDP
>> > (see later)
>> >
>> > The triggered check is necessary because the remote (non GW)
>> > endpoint could
>> > be behind a NAT/FW which allows outgoing UDP packets but blocks
>> > incoming UDP
>> > packets.  #2 is the same as we are proposing for normal ice
>> > devices, which
>> > will send to the first validated candidate for a component.  A new SDP
>> > attribute, ice-passive, would be used for #3.  Any GW that advertises
>> > ice-passive must be in the open region of the topology, so it will
>> > not need
>> > ice to communicate with another GW which offers ice-passive.  So,
>> > if both
>> > devices advertise ice-passive, no ice discovery will take place.
>> > Keepalives
>> > should not be necessary, but if they are desired, ice keepalives
>> > will be
>> > used.  If no side indicates ice-passive, the offerer is the
>> > controlling
>> > endpoint, as in ice-10.
>> >
>> > If the controlling endpoint wishes the ice-passive endpoint to
>> > switch to
>> > another candidate, it can accomplish this by sending an ice-check
>> > which will
>> > cause the GW to send a triggered check and change candidates if the
>> > triggered check succeeds.
>> >
>> > This approach will allow a very light implementation of ICE for
>> > this type of
>> > device.  It requires very little state (one table of permissions,
>> > one table
>> > of validated candidates from triggered checks) and very little
>> > communication
>> > between the signaling and media components.  It eliminates candidate
>> > gathering, priority processing and the ice-check state machine.
>> >
>> > -Derek
>> >
>> >
>> >
>> > _______________________________________________
>> > mmusic mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/mmusic
>> >
>>
>>
>> _______________________________________________
>> 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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Oct 2006 12:47:18 -0400

I agree with Derek here. I like this idea a lot and have been thinking 
about similar things.

Firstly, I agree that it should not be discovered. THis would be 
something that is specific to the TYPE of device; i.e., a softphone 
would NEVER do this, whereas a PSTN gateway would have the option 
configured (or indeed required to be on the public internet).

Secondly, instead of a passive/active flag, I have an alternate 
suggestion. The main question is who does the reinvite at the end of 
ICE. Today, it says its the offerer. What if the algorithm is this. If, 
after the ICE checks are done, the agent finds that it alone needs to 
use a different candidate than is in the m/c-line, it sends a re-invite. 
If it looks like both sides are using a new candidate, the offerer sends 
a re-invite.

Because a pstn gateway would never see a check produce a different 
candidate for itself, it would never do a re-invite.

I like this algorithm since it puts the burden of work on the component 
that has the most to gain from the work.

Finally, I don't think triggered checks are needed for gateways. I don't 
understand Derek's use case. In fact, I've been thinking about whether 
gateways can skip the checks entirely, and just respond to checks they 
receive.

-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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 3 Oct 2006 21:37:31 +0200

Hi,

Is this discussion really only related to GWs?

What about if there is a normal SIP phone that "knows" it's not behind a
NAT? If it supports ICE, I think it's a good idea that it still includes
a candidate in the offer, in case the remote party IS behind a NAT, and
also wants to use ICE.

Regards,

Christer

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 3. lokakuuta 2006 19:47
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Ice and open internet devices
> 
> I agree with Derek here. I like this idea a lot and have been 
> thinking about similar things.
> 
> Firstly, I agree that it should not be discovered. THieeds.
> >>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 3 Oct 2006 21:37:31 +0200

Hi,

Regards,

Christer

> Firstly, I agree that it should not be discovered. THis would 
> be something that is specific to the TYPE of device; i.e., a 
> softphone would NEVER do this, whereas a PSTN gateway would 
> have the option configured (or indeed required to be on the 
> public internet).
> 
> Secondly, instead of a passive/active flag, I have an 
> alternate suggestion. The main question is who does the 
> reinvite at the end of ICE. Today, it says its the offerer. 
> What if the algorithm is this. If, after the ICE checks are 
> done, the agent finds that it alone needs to use a different 
> candidate than is in the m/c-line, it sends a re-invite. 
> If it looks like both sides are using a new candidate, the 
> offerer sends a re-invite.
> 
> Because a pstn gateway would never see a check produce a 
> different candidate for itself, it would never do a re-invite.
> 
> I like this algorithm since it puts the burden of work on the 
> component that has the most to gain from the work.
> 
> Finally, I don't think triggered checks are needed for 
> gateways. I don't understand Derek's use case. In fact, I've 
> been thinking about whether gateways can skip the checks 
> entirely, and just respond to checks they receive.
> 
> -Jonathan R.
> 
> 
> > A device would not determine that it is on the open 
> internet by discovery; it would use configuration which is 
> set at delpoyment time.
> > 
> > If a PSTN gateway is behind a NAT, it would have to 
> implement full ice.  The purpose of 'ice-passive' is to 
> simplify the implementation of devices that are not behind a NAT.
> > 
> > -Derek
> > 
> >>>Does it look at its IP address? This mostly works, but there was a 
> >>>recent case in Italy where this test would have failed.
> >>>
> >>>>internet or not behind a NAT from the perspective of 
> other devices.  
> >>>>The most common example of this device is a PSTN gateway, 
> although 
> >>>>B2BUAs could be deployed
> >>>>cost of ice.
> >>>>1. stateless processing, or a much simplified ice state 
> machine 2. 
> >>>>should never be the deciding endpoint in the ice algorithm 3. 
> >>>>limited communication between the signaling component and media 
> >>>>component
> >>>>
> >>>>
> >>>>Proposed Solution
> >>>>
> >>>>will only ever have one candidate.  The candidate will be 
> the global 
> >>>>IP address of the GW, which will always be the same as 
> the m/c line; 
> >>>>so candidate gathering is eliminated.  The GW will not 
> have a NAT/FW 
> >>>>in front of it, so it will not have to send STUN requests to open 
> >>>>NAT/FW permissions.
> >>>>Local
> >>>>devices that wish to enforce must already do this for the 
> remote m/c 
> >>>>line.
> >>>>A GW
> >>>>motivation to prioritize candidates. This les would 
> be something that is specific to the TYPE of device; i.e., a 
> softphone would NEVER do this, whereas a PSTN gateway would 
> have the option configured (or indeed required to be on the 
> public internet).
> 
> Secondly, instead of a passive/active flag, I have an 
> alternate suggestion. The main question is who does the 
> reinvite at the end of ICE. Today, it says its the offerer. 
> What if the algorithm is this. If, after the ICE checks are 
> done, the agent finds that it alone needs to use a different 
> candidate than is in the m/c-line, it sends a re-invite. 
> If it looks like both sides are using a new candidate, the 
> offerer sends a re-invite.
> 
> Because a pstn gateway would never see a check produce a 
> different candidate for itself, it would never do a re-invite.
> 
> I like this algorithm since it puts the burden of work on the 
> component that has the most to gain from the work.
> 
> Finally, I don't think triggered checks are needed for 
> gateways. I don't understand Derek's use case. In fact, I've 
> been thinking about whether gateways can skip the checks 
> entirely, and just respond to checks they receive.
> 
> -Jonathan R.
> 
> 
> > A device would not determine that it is on the open 
> internet by discovery; it would use configuration which is 
> set at delpoyment time.
> > 
> > If a PSTN gateway is behind a NAT, it would have to 
> implement full ice.  The purpose of 'ice-passive' is to 
> simplify the implementation of devices that are not behind a NAT.
> > 
> > -Derek
> > 
> >>>Does it look at its IP address? This mostly works, but there was a 
> >>>recent case in Italy where this test would have failed.
> >>>
> >>>>internet or not behind a NAT from the perspective of 
> other devices.  
> >>>>The most common example of this device is a PSTN gateway, 
> although 
> >>>>B2BUAs could be deployed
> >>>>cost of ice.
> >>>>1. stateless processing, or a much simplified ice state 
> machine 2. 
> >>>>should never be the deciding endpoint in the ice algorithm 3. 
> >>>>limited communication between the signaling component and media 
> >>>>component
> >>>>
> >>>>
> >>>>Proposed Solution
> >>>>
> >>>>will only ever have one candidate.  The candidate will be 
> the global 
> >>>>IP address of the GW, which will always be the same as 
> the m/c line; 
> >>>>so candidate gathering is eliminated.  The GW will not 
> have a NAT/FW 
> >>>>in front of it, so it will not have to send STUN requests to open 
> >>>>NAT/FW permissions.
> >>>>Local
> >>>>devices that wish to enforce must already do this for the 
> remote m/c 
> >>>>line.
> >>>>A GW
> >>>>motivation to prioritize candidates. This leads us to:
> >>>>
> >>>>1. a GW will only perform triggered checks 2. for each 
> component the 
> >>>>GW will send media to the last successful triggered check, unless 
> >>>>informed otherwise by the remote party 3. the GW is never the 
> >>>>controlling endpoint, and will announce this in SDP (see later)
> >>>>
> >>>>endpoint could be behind a NAT/FW which allows outgoing 
> UDP packets 
> >>>>but blocks incoming UDP packets.  #2 is the same as we 
> are proposing 
> >>>>for normal ice devices, which will send to the first validated 
> >>>>candidate for a component.  A new SDP attribute, 
> ice-passive, would 
> >>>>be used for #3.  Any GW that advertises ice-passive must 
> be in the 
> >>>>open region of the topology, so it will not need ice to 
> communicate 
> >>>>with another GW which offers ice-passive.  So, if both devices 
> >>>>advertise ice-passive, no ice discovery will take place.
> >>>>Keepalives
> >>>>will be used.  If no side indicates ice-passive, the 
> offerer is the 
> >>>>controlling endpoint, as in ice-10.
> >>>>
> >>>>switch to another candidate, it can accomplish this by sending an 
> >>>>ice-check which will cause the GW to send a triggered check and 
> >>>>change candidates if the triggered check succeeds.
> >>>>
> >>>>This approach will allow a very light implementation of 
> ICE for this 
> >>>>type of device.  It requires very little state (one table of 
> >>>>permissions, one table of validated candidates from triggered 
> >>>>checks) and very little communication between the signaling and 
> >>>>media components.  It eliminates candidate gathering, priority 
> >>>>processing and the ice-check state machine.
> >>>>
> >>>>-Derek
> >>>>
> >>>>
> >>>>

ads us to:
> >>>>
> >>>>1. a GW will only perform triggered checks 2. for each 
> component the 
> >>>>GW will send media to the last successful triggered check, unless 
> >>>>informed otherwise by the remote party 3. the GW is never the 
> >>>>controlling endpoint, and will announce this in SDP (see later)
> >>>>
> >>>>endpoint could be behind a NAT/FW which allows outgoing 
> UDP packets 
> >>>>but blocks incoming UDP packets.  #2 is the same as we 
> are proposing 
> >>>>for normal ice devices, which will send to the first validated 
> >>>>candidate for a component.  A new SDP attribute, 
> ice-passive, would 
> >>>>be used for #3.  Any GW that advertises ice-passive must 
> be in the 
> >>>>open region of the topology, so it will not need ice to 
> communicate 
> >>>>with another GW which offers ice-passive.  So, if both devices 
> >>>>advertise ice-passive, no ice discovery will take place.
> >>>>Keepalives
> >>>>will be used.  If no side indicates ice-passive, the 
> offerer is the 
> >>>>controlling endpoint, as in ice-10.
> >>>>
> >>>>switch to another candidate, it can accomplish this by sending an 
> >>>>ice-check which will cause the GW to send a triggered check and 
> >>>>change candidates if the triggered check succeeds.
> >>>>
> >>>>This approach will allow a very light implementation of 
> ICE for this 
> >>>>type of device.  It requires very little state (one table of 
> >>>>permissions, one table of validated candidates from triggered 
> >>>>checks) and very little communication between the signaling and 
> >>>>media components.  It eliminates candidate gathering, priority 
> >>>>processing and the ice-check state machine.
> >>>>
> >>>>-Derek
> >>>>
> >>>>
> >>>>

---

From: "Derek MacDonald" <[email-masked]>
Date: Tue, 3 Oct 2006 17:19:10 -0700

I think Jonathan's proposal that we do away with the passive/active flag
works.  This is how I interpret this:

If a device only has one candidate, which is the same as its m/c line, it
may behave in the passive mode as detailed below in my original post. If two
such devices communicate ice would not occur as neither side will originate
checks.  I don't keepalives will be sent in this case as ice won't have been
activated.

Basically, the m/c line being the same as the only provided candidate is the
same as the passive flag, if that endpoint does not send ice checks.  If a
full ice implementation happens to have one candidate it can be
distinguished from a passive ice implementation by the fact that it sends
checks.

If two full ice implementations have one candidate the offerer would be the
controlling endpoint.

-Derek
> > A device would not determine that it is on the open internet by
> discovery; it would use configuration which is set at delpoyment time.
> >
> > If a PSTN gateway is behind a NAT, it would have to implement full ice.
> The purpose of 'ice-passive' is to simplify the implementation of devices
> that are not behind a NAT.
> >
> > -Derek
> >

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Oct 2006 21:49:25 -0700

I thought about that awhile and I can't see any problems with it.  
Sounds like a good thing.