There are in fact deployments of ICE, more than one, based on previous
versions of the draft.
Most folks I talk to are waiting to IETF to finish this thing, so they
can go upgrade their code and move to the final version. Delaying it,
making it experiental, informational, or any other variation will serve
no other purpose than to convince everyone that this work is not done,
and so folks should continue to wait. If you want an industry's worth of
feedback and data, lets go and finish this thing. That means PS.
All of that said, ICE has, probably more than most other specs that have
ever come out of RAI, have had the benefit of:
a. extensive technical review, comments and feedbacks, including
commentary from implementors (including one in my own company, and
several others from outside of it) and deployers (Tim Moore from Microsoft)
b. design based on years of experience with NATs and NAT traversal
c. design based on real collected data on NAT behaviors and on
techniques used in other applications
d. consideration on incremental deployability and applicability
across the entire range of SIP, from p2p to enterprise to large provider
to closed application provider and so on
e. multiple open source implementations (two have been pointed out
already)
f. an active design team including security experts that helped in
the massive redesign in -10 to simplify things
And as such, it would seem to me that, not only is there not a single
shred of evidence that suggests this draft deserves anything less than
PS, there is evidence only to demonstrate that it has quality far
greater than most IETF protocols with that moniker.
Other parts of this thread have been folks suggesting alternative
techniques that are simpler or work better. Well, I look forward to
their drafts. So far, no one has suggested a single thing which was not
considered and/or incorporated into ICE in some way over the last four
years.
ICE was built for reliability - to cover lots of cases and achieve not
just 90% effectiveness (not nearly good enough), but as effective as is
possible within the limitations of hurting the Internet or violating
security policies and other things we won't touch. Without a doubt you
can design a custom protocol for any one single deployment scenario with
some set of assumptions that works simpler with fewer messages. However,
our objective was to design a NAT traversal solution for SIP that
applied as broadly as SIP did. ICE has the benefit of resulting in
simple flows in simple topologies, but the same logic produces more
complex flows in more complex situations, but still works. That was a
design decision we made years ago and it remains a sound one.
Comments have also been made that, "well, you thought STUN would work
and you were wrong". This too is bogus. The limitations of STUN were
known at the time of its publication. It was our hope that enough of a
market would find it acceptable to be useful. Quoting from RFC 3489:
STUN introduces brittleness into the system in several ways:
o The discovery process assumes a certain classification of devices
based on their treatment of UDP. There could be other types of
NATs that are deployed that would not fit into one of these molds.
Therefore, future NATs may not be properly detected by STUN. STUN
clients (but not servers) would need to change to accommodate
that.
o The binding acquisition usage of STUN does not work for all NAT
types. It will work for any application for full cone NATs only.
For restricted cone and port restricted cone NAT, it will work for
some applications depending on the application. Application
specific processing will generally be needed. For symmetric NATs,
the binding acquisition will not yield a usable address. The
tight dependency on the specific type of NAT makes the protocol
brittle.
o STUN assumes that the server exists on the public Internet. If
the server is located in another private address realm, the user
may or may not be able to use its discovered address to
communicate with other users. There is no way to detect such a
condition.
o The bindings allocated from the NAT need to be continuously
refreshed. Since the timeouts for these bindings is very
implementation specific, the refresh interval cannot easily be
determined. When the binding is not being actively used to
receive traffic, but to wait for an incoming message, the binding
refresh will needlessly consume network bandwidth.
o The use of the STUN server as an additional network element
introduces another point of potential security attack. These
attacks are largely prevented by the security measures provided by
STUN, but not entirely.
Rosenberg, et al. Standards Track [Page 40]
RFC 3489 STUN March 2003
o The use of the STUN server as an additional network element
introduces another point of failure. If the client cannot locate
a STUN server, or if the server should be unavailable due to
failure, the application cannot function.
o The use of STUN to discover address bindings will result in an
increase in latency for applications. For example, a Voice over
IP application will see an increase of call setup delays equal to
at least one RTT to the STUN server.
o The discovery of binding lifetimes is prone to error. It assumes
that the same lifetime will exist for all bindings. This may not
be true if the NAT uses dynamic binding lifetimes to handle
overload, or if the NAT itself reboots during the discovery
process.
o STUN imposes some restrictions on the network topologies for
proper operation. If client A obtains an address from STUN server
X, and sends it to client B, B may not be able to send to A using
that IP address. The address will not work if any of the
following is true:
- The STUN server is not in an address realm that is a common
ancestor (topologically) of both clients A and B. For example,
consider client A and B, both of which have residential NAT
devices. Both devices connect them to their cable operators,
but both clients have different providers. Each provider has a
NAT in front of their entire network, connecting it to the
public Internet. If the STUN server used by A is in A's cable
operator's network, an address obtained by it will not be
usable by B. The STUN server must be in the network which is a
common ancestor to both - in this case, the public Internet.
- The STUN server is in an address realm that is a common
ancestor to both clients, but both clients are behind the same
NAT connecting to that address realm. For example, if the two
clients in the previous example had the same cable operator,
that cable operator had a single NAT connecting their network
to the public Internet, and the STUN server was on the public
Internet, the address obtained by A would not be usable by B.
That is because some NATs will not accept an internal packet
sent to a public IP address which is mapped back to an internal
address. To deal with this, additional protocol mechanisms or
configuration parameters need to be introduced which detect
this case.
Rosenberg, et al. Standards Track [Page 41]
RFC 3489 STUN March 2003
o Most significantly, STUN introduces potential security threats
which cannot be eliminated. This specification describes
heuristics that can be used to mitigate the problem, but it is
provably unsolvable given what STUN is trying to accomplish.
These security problems are described fully in Section 12.
Well, the market didn't find it useful enough. And so we worked to
improve. Nearly every one of these limitations has been eliminated by
ICE. Go read the IAB considerations section, which discusses this.
Binding lifetime discovery is pretty much the only remaining one;
fortunately that is a minor one and ICE is just aggressive in that area
to compensate. The STUN-control work Dan has been promoting is meant to
add ontop of ICE to finally close that issue.
So, in case its not abundantly clear, I think there is no merit to the
calls for changing ICE to informational or experimental, and that these
last minute claims of better solutions or simpler solutions are also
without merit. ICE is as deserving, and indeed more so, of a PS moniker
than most other documents that achieve that label.
-Jonathan R.
David Barrett wrote:
Hi Cullen, I think you bring up lot of really great and detailed questions.
However, speaking for myself at least, answering those questions doesn't
really address my concern. All I want to know is:
Does ICE work, and how well?
What "works" means is entirely open to debate. I've tossed out "high peer
connectivity" and "low connection setup time" as the most important
criteria, and I've put hard data behind those numbers as a stake in the
ground for comparison, but I'm open to other metrics as well.
But regardless of the metrics, I want somebody who uses it and loves it and
bases their business upon its success to stand up and explain why it's
great. And I want this person to provide real-world data, sampled on a wide
scale, proving that ICE "works" -- by any definition.
Basically, I want ICE firmly grounded in wide-scale testing and real-world
data, and answering the questions below doesn't bring us any closer to that.
Whether it's level 10 or level 12 doesn't produce new data. How its
algorithms differ from competing ones doesn't show that they're any better
or worse. Detailed proposals for change don't shed any light on whether
those changes improve or worsen it, because its current state is completely
unmeasured.
The most powerful thing the IETF can do to standardize the world upon ICE is
prove that it works better than any alternative. Because until that's
proven, we just need to take it as a matter of faith.
-david
-----Original Message-----
From: Cullen Jennings [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 7:56 PM
To: SIP; Behave WG; [EMAIL PROTECTED]
Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC
First I apologize for the cross post - this is a mmusic draft, I
would appreciate replies on the mmusic list only.
Few things I am looking for here ....
1) specific reasons why this work is less appropriate for standards
track than other work that IETF puts on the standards track. Keep in
mind the first step of standards track is Proposed Standards which
requires basically no interoperability, then it could move to Draft
Standard where interoperability is shown and finally Full Standard if
it turns out to be a good idea. If you are going to post a reply to
this point, make sure you have read RFC 2026.
2) I am interested in the specifics of problems that ICE fails to
solve that the WG has not previous considered. There are lots of
people that have implemented versions of it and think it is a good
idea - if people are having some problems with it, I'd love to hear
about details of things that are wrong. That it has a lot of messages
in some use cases has been known for a long time. It used to have far
more messages - engineering was done to consider what was a
reasonable amount for call set up times and a new design was done to
bring the message to a level most people invovled with the design
felt was reasonable. If there are specific other than these that are
wrong and not considered in the design, now would be a good time to
get them on the table.
3) If people think that Skype for example has a simpler solution that
works better than ICE. Feel free to describe exactly what it is.
Several people invovled with the ICE design have looked in extreme
detail at Skype and others and so far none of them have come back
with what we should do different than ICE.
4) ICE can be used in a mode where it only provided the reflexive
candidate. People were pretty clear that this was far inferior to the
modes where there are other candidates. If someone would like to
provide exactly how hole punching works better than this very limited
ICE technique, I'd be glad to hear the details. This has certainly
been an topic that any could have brought up over the last several
years. If someone has specifics, I suggest they get out a full
proposal really soon. I am very doubtful that hole punching solution
is fundamentally different than the type of hole punching ICE does.
5) Some people have suggested that if all NATs were behave complaint,
then we would not need ICE. I strongly disagree. I think the only
part of ICE we would not need is the TURN relays which are more or
less an optional part. Again, specifics on what can be removed are
welcome.
ICE is far more complicated that anyone wants - the problem is, no
one has come up with a proposal that looks like it comes anywhere
close to meeting the requirements and if simpler. The design space
has been extensively explored by many people. The raw data to
understand what will work on what NATs have been painfully tested and
documented in publications such as:
http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf
http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt
https://www.guha.cc/saikat/stunt-results.php?
(Ford used to have a page too but it seems to be gone)
I have a very open mind to considering better ways to do ICE - but I
need specific suggestions or it is impossible for me to really think
about if the suggestions represent a better path or not.
I would love to see more open source ICE code (there is lots already)
- I feel that this is an area where ICE is likely just table stakes
and owning an proprietary ICE stack will not turn out to be a
competitive advantage. Having open source implementations where the
development cost was shared and everyone could get working products
to market faster would be an advantage to companies. Clearly I expect
the bulk of ICE implementations to not be open source but I still
would be keen on doing what I can to contribute to an open source
version as personally I feel that is in the interest of end users, my
employer, and the IETF as a SDO.
Cullen <with my individual hat on>
On Jul 18, 2007, at 9:12 AM, Dean Willis wrote:
On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote:
Henry Sinnreich skrev:
Following some discussions and soul searching, the best approach for
ICE-17 for LC would be to _go ahead and make it an experimental
RFC_.
This would support the development of interoperable
implementations, the
collection of deployment data and also hopefully open source code.
Though I have full faith in ICE, following the practices that
made the
IETF successful take precedent here, I believe.
This is a change from the attached that I wrote on 7/16/2007.
Note: We can only hope the proliferation of SBC in VoIP service
provider
networks will not make these concerns and ICE for SIP a moot
issue, but
this is another topic.
Henry,
I don't quite understand why you are requesting a status change of
ICE? To me it appears that ICE is almost finished spec. It has
been implemented, used and feedback has been influencing the
protocol. It is definitly one of the better examples of current
IETF work that actually has running code. Sure, the
implementations may not be fully updated yet to the latest draft
version. But I think it is safe to say that ICE works in the
intended core cases. If there are some corner cases where it
fails, that may be. But that is not information we will have until
really large scale deployement or someone makes very extensive tests.
Henry has, I believe, been very consistent in urging the IETF to
have more "running code" experience on every specification (not
just ICE) than our process requires. He has, IIRC, also advocated
changing the process to require running code before publishing an
RFC. He's even suggested at times that one should have running code
before submitting a protocol draft.
Another point to consider -- I've known Henry to bark at a tree
with no squirrel in it occasionally, but most of the time he's
pretty reliable, more so than most technology predictors. If he's
worried about ICE, it's probably because he's been talking to
people who are trying to implement it and they're telling him it is
difficult or that they're having performance or reliability issues.
I imagine that there are plenty of internal development teams in
various companies that are working on this and not necessarily
bringing their results back to the IETF. After all, if everybody
sees the emperor as fully clothed, they'd be embarrassed to
proclaim otherwise. Of course, I wish all of these developers were
tied into the IETF, but then I'm sure I don't want to see every ice-
implementor's question on the SIP list. That is why we have a sip-
implementors mailing list, right?
Personally, I think ICE is the best solution we have. We KNOW of
cases where hole-punching doesn't work, and I think ICE will
produce usable results in most of those cases. But that's just my
personal opinion from reading the specs. I haven't implemented ICE,
and I haven't used anybody else's implementation. Sure, it's
complex, but that's because the underlying problem is complex --
there are just too many different behaviors out there in "NAT and
firewall land". Of course, I could be wrong, too. It's happened
before, once or twice ;-). Just how sure are we that we're right
about this?
Are we designing a "spruce goose" or a practical system? Only
experience will tell us. But some good flight reports from the
prototypes could go a long way towards reassuring us of the
design's utility.
So far we've had a couple of people report hearsay evidence -- that
somebody else has an ICE implementation and it works. Any of you
folks have personal experience you can share? Have there been
prototypes exercised at the interop events?
--
Dean
_______________________________________________
Behave mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/behave
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
