Subject: [Sipping] The next ICE age

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 22 Mar 2007 11:14:01 -0400

The thing that bothers me about this ICE vs. ANAT discussion/decision is
that it makes the assumption that ICE is or will soon become ubiquitous.
That may well happen, but it is far too premature to assume so.  The IETF
has shown time and time again that it is good at specifying protocols, but
bad at mandating market forces by fiat.  The SIP WG is no exception to that.
The market picks and chooses from the work of the ietf, not the other way
around.

So the concern I have is if we start going down this road of "oh we can
deprecate this now", without any evidence that the ICE is successful in the
market, then we are creating yet another head-in-the-sand scenario that made
the ietf ignore NATs to begin with. 

So if the proposal is to actually _deprecate_ ANAT because ICE can do it a
different way, then I think it's too soon.  If the proposal is just to
ignore ANAT with respect to the ICE draft - i.e., support address family
selection natively in ICE without any ANAT syntax needed, then I'm in favor
of that. 

-hadriel

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 12:36:46 -0400

Hadriel,

If the primary or only argument was, 'we should deprecate anat because 
ICE is deployed', I would agree. It is not ubiquitously deployed by any 
stretch, though there are implementations and deployments today and they 
are not insignificant. Regardless, thats not the argument.

We deprecate a protocol when we define a new protocol whose 
functionality is superior because it fixes problems in a previous one. I 
think the point is being made that ICE provides a superset of 
functionality of ANAT and fixes two issues ANAT has - (1) its selection 
of transport addresses are not dynamic and we've have learned that 
dynamic selection is better, and (2) ANAT doesn't allow for RFC 3484 
address selection.

-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: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 22 Mar 2007 13:32:57 -0400

Howdy,
Inline...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, March 22, 2007 12:37 PM
> To: Hadriel Kaplan
> Cc: 'sipping'; [email-masked]
> Subject: Re: The next ICE age
> 

That would make sense if ICE did so in a similar manner to ANAT, with
similar complexity for similar architectures.  Clearly it does not.  There
is a heavy price to pay, and it remains to be seen if the market will bear
that cost.  For some network architectures there is no problem ICE solves
they cannot already solve a different way.

I would also argue we have not learned dynamic selection is better.  You
have learned that in your environments with your constraints/assumptions it
is better.  For mine I am not sure it will do anything of value.  For
example I am not at all convinced ICE provides better troubleshooting for my
environments - in fact I think it will make things worse, given the current
sorry state of endpoint and gateway compliance to RFCs.

I also do not understand the issue with RFC 3484.  I am no expert on the
subject by any stretch, but from my reading the selection algorithm can be
overridden by the application at will.  So it is not a case of "conflicts
with 3484", but rather a case of potentially causing issues if the
application picks poorly.  Again while I think that is a legitimate concern
that ICE should address, it does not negate the value of a simpler ANAT
method for those deployments that can use it and don't need ICE.

-hadriel

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 22 Mar 2007 13:50:36 -0400

Let me add my two cents. I think ICE is probably the best thing out there
for solving today's NAT issues and we need to increase its adoption. What
you find today are broken implementations or endpoints/gateways implementing
different mechanisms. This group needs to make a strong technical decision
to help create some market confidence so things can move forward at a faster
pace!

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 22 Mar 2007 20:03:51 +0200

On Thursday 22 March 2007 19:32:57 ext Hadriel Kaplan wrote:
> similar complexity for similar architectures.

It is arguable whether ANAT is simpler than ICE. It depends on the SDP 
grouping thingy which is not easy to implement, and then needs to be bound to 
ANAT-specific semantics. And then, you have to handle re-INVITEs in case the 
receiver does not support ANAT (presumably, you will send anat in a Required: 
header).

> Clearly it does not.

And clearly, using ICE+ANAT is way more complicated than either of ICE and 
ANAT.

> There is a heavy price to pay, and it remains to be seen if the market will
> bear that cost.

There is a heavy price to pay in not doing ICE. It's called customer 
dissatisfaction. See, for a single example, the early media problem drafts.

> For some network architectures there is no problem ICE solves 

Yes, in lab setup. Pretty much anything else has firewalls somewhere (on the 
host itself if not on the network). ANAT does not solve hole punching.

> I would also argue we have not learned dynamic selection is better.

The IPv6 IETF folks did. Read the source selection RFC and drafts for 
reference.

> You
> example I am not at all convinced ICE provides better troubleshooting for
> my environments

You are free to use ANAT in your environment.

> - in fact I think it will make things worse, given the
> current sorry state of endpoint and gateway compliance to RFCs.

ICE has this nice property that it is transparent to endpoints and gateways 
that do not implement it. ANAT is not (see above).
> overridden by the application at will.

To restate what JR already said, RFC3848 needs the full list of source and 
destination addresses to run its algorithm. ANAT only gives one IPv4 and one 
IPv6 address, which fails this requirement in 100% of the real IPv6 
deployments: any IPv6 device on an IPv6 network has **at the very least** a 
link-local and a global scope addresses.

> So it is not a case of "conflicts with 3484", but rather a case of
> potentially causing issues if the application picks poorly.

The application will pick poorly given the "input" to RFC3483 will be 
incomplete.

> Again while I think that is a legitimate concern 

Give me a significant deployment where:
1/ there is no NATs and firewalls, no need for hole punching,
2/ IPv4 is provided,
3/ IPv6 is provided,
4/ devices only have a single IPv6 addresses,
(5/ every users trust each other so we do not need to protect against voice 
hammer attack)

-- 
Rémi Denis-Courmont

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 22 Mar 2007 15:14:23 -0400

Inline...

> From: Rémi Denis-Courmont [mailto:[email-masked]]
> Sent: Thursday, March 22, 2007 2:04 PM
> 
> [snip] And then, you have to handle re-INVITEs in case
> the

You need to handle re-Invite's period.  No free lunch there for anyone.  But
no I'm not sure I'd send rfc4092 in a require header.  It's not a problem I
face currently.

> And clearly, using ICE+ANAT is way more complicated than either of ICE and

Well obviously we're getting into subjective analysis, but yes (i + j) > i.
For me i = 99 and j = 1, for you maybe they're similar in size to each
other.
But I'm not suggesting using both together is necessary.  I am in favor of
having ICE fix it itself without needing ANAT whatsoever.  Let the market
decide.

> dissatisfaction. See, for a single example, the early media problem

ICE relies on getting an SDP answer, unless it's changed since the last time
I read it.  So does ANAT.  So do most gateways.  So does SRTP.  So do a lot
of things that go bump in the night.  

> host itself if not on the network). ANAT does not solve hole punching.

There are massive deployments with NAT traversal working every single day
for IPv4.  This is not some new phenomenon only just recently "fixed" by the
ietf with ICE.  This has been going on for years.  I can't speak to what if
any goes on in IPv6 with ANAT, as from my perspective that's still a niche
market - I don't do ANAT currently.

> that do not implement it. ANAT is not (see above).

Yes ANAT is, in theory, as I said in another email.  In theory a receiver
getting an ANAT offer will use the address type it supports.  I also pointed
out that theory may well fail.
But that's not what I meant by sorry state of compliance.  I meant endpoints
implement RFCs in very haphazard ways, and I fear what that means with a
large and complicated document such as ICE.  In my particular market it is
also quite difficult to troubleshoot such things at the endpoint side.

BTW, now that we "have" ICE, we should really get a sipping doc for using a
reason header or some such in a BYE or CANCEL to indicate a failure
condition, and define the header values, so that the far-end or (gasp) proxy
knows why.  Or does this already exist? (there're just too many docs to keep
up with)

> link-local and a global scope addresses.

Right, so here's the part I don't get, not being up to speed on such things:
why can't it use the global one?  Even if it ends up with media going to
another local device, so what?  Are you saying the packets won't get there?

> (5/ every users trust each other so we do not need to protect against

Give me a significant deployment where the converse is true.  Frankly I
don't know of any significant IPv6 deployments.  At least not what I
consider significant.  Well... that's not totally true.  I know of one, but
they don't seem to have a problem, though I don't know if they have NATs or
not.

The voice hammer attack is a red herring in my opinion. (well... at least
for my case - to each his own)

-hadriel

---

From: "Jerry Yin" <[email-masked]>
Date: Thu, 22 Mar 2007 15:59:32 -0400

> market - I don't do ANAT currently.

This is a puzzle to me as well. We tested our SIP phones 7.0 behind the
cooperate firewall and some commercial NAT firewalls (LinkSys, Dlink), and
found no problems for incoming calls, outgoing calls, and both way media. We
don't support ICE yet, but only rport, stun, symetric-udp (for both SIP and
RTP), and keep alive (partial outbound draft). I don't understand what kind
of firewall would really block our media streaming? The server we tested in
the public domains are: Broadsoft, Sylantro, InGate, Iptel.org, MKC, etc.

The only thing the ICE concerned me is that it's very difficult to separate
the media components from the SIP Stack or the transport layer. This maybe a
wrong perception. But just my two cents.

Regards,
Jerry

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 23 Mar 2007 03:00:48 -0600

Beyond the goal of facilitating interoperability of IPv6/IPv4 hosts,
what started this discussion is:
   - the assumption that ANAT is not implemented today, and,
   - there should be some guidance on how ANAT and ICE co-exist or
collide,
   - some recommendations should be made to facilitate implementations
and interoperability.

What seems dominant in the debate for people making positions for one
side or another is:
   - whether or not it is sufficient to just advertise IPv6/IPv4 media
with ANAT without doing actual connectivity checks,
   - whether or not there are enough examples or scenarios for using
ANAT alone, or ICE alone,

There seems to be consensus that ANAT+ICE is the worst option. However
if both options exist, for the implementers of dual-stack hosts that do
not want to make any assumptions about the deployment topologies of
their devices (I think we serve this community in IETF), they will
likely have to implement both to interoperate with a maximum of
implementations. So there is a risk that the worst option becomes
dominant.

This is more or less what I said on the mike today and just my personal
thoughts. 

Jean-Francois.

> Sent: Thursday, March 22, 2007 10:37 AM
> To: Hadriel Kaplan
> Subject: [MMUSIC] Re: The next ICE age
> 
> Hadriel,
> 
> We deprecate a protocol when From [email-masked] Fri Mar 23 05:05:26 2007
Content-class: urn:content-classes:message
Date: Fri, 23 Mar 2007 03:00:48 -0600
From: "Jean-Francois Mule" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>,
	"Hadriel Kaplan" <[email-masked]>
Cc: sipping <[email-masked]>, [email-masked]
Subject: [Sipping] RE: [MMUSIC] Re: The next ICE age

Beyond the goal of facilitating interoperability of IPv6/IPv4 hosts,
what started this discussion is:
   - the assumption that ANAT is not implemented today, and,
   - there should be some guidance on how ANAT and ICE co-exist or
collide,
   - some recommendations should be made to facilitate implementations
and interoperability.

What seems dominant in the debate for people making positions for one
side or another is:
   - whether or not it is sufficient to just advertise IPv6/IPv4 media
with ANAT without doing actual connectivity checks,
   - whether or not there are enough examples or scenarios for using
ANAT alone, or ICE alone,

There seems to be consensus that ANAT+ICE is the worst option. However
if both options exist, for the implementers of dual-stack hosts that do
not want to make any assumptions about the deployment topologies of
their devices (I think we serve this community in IETF), they will
likely have to implement both to interoperate with a maximum of
implementations. So there is a risk that the worst option becomes
dominant.

This is more or less what I said on the mike today and just my personal
thoughts. 

Jean-Francois.

> Sent: Thursday, March 22, 2007 10:37 AM
> To: Hadriel Kaplan
> Subject: [MMUSIC] Re: The next ICE age
> 
> Hadriel,
> 
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 24 Mar 2007 09:53:13 -0500

That is because your NAT complies with RFC 4787. It's a good NAT.

But what ICE will do in that case, is ensure that media is directly
flowing from endpoint to endpoint, avoiding triangulation when routing
as you are seeing today on your corporate NAT, thereby optimizing 
routing and maximiming voip quality by minimizing delay.

> From: Jerry Yin [mailto:[email-masked]] 
> Sent: Thursday, March 22, 2007 13:00
> To: Hadriel Kaplan; 'Rémi Denis-Courmont'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] RE: The next ICE age
> 
> >
> > There are massive deployments with NAT traversal working 
> every single 
> > day for IPv4.  This is not some new phenomenon only just recently 
> > "fixed" by the ietf with ICE.  This has been going on for years.  I 
> > can't speak to what if any goes on in IPv6 with ANAT, as from my 
> > perspective that's still a niche market - I don't do ANAT currently.
> >
> >
> 
> This is a puzzle to me as well. We tested our SIP phones 7.0 
> behind the cooperate firewall and some commercial NAT 
> firewalls (LinkSys, Dlink), and found no problems for 
> incoming calls, outgoing calls, and both way media. We don't 
> support ICE yet, but only rport, stun, symetric-udp (for both 
> SIP and RTP), and keep alive (partial outbound draft). I 
> don't understand what kind of firewall would really block our 
> media streaming? The server we tested in the public domains 
> are: Broadsoft, Sylantro, InGate, Iptel.org, MKC, etc.
> 
> The only thing the ICE concerned me is that it's very 
> difficult to separate the media components from the SIP Stack 
> or the transport layer. This maybe a wrong perception. But 
> just my two cents.
> 
> Regards,
> Jerry
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>