Cullen Jennings said:
"I was somewhat shocked to see the draft in IETF Last Call. The last time this
draft was discussed at the microphone in Behave, many people were very
concerned that it id not possible to correctly characterize a NAT without using
more than one address behind the NAT. The tests done on on NATs by the
researches at MIT did that, so did the the stuff from Cornell, as did
draft-jennings-behave-test-results. The reason why this was needed is largely
the reason why the IETF invented ICE. Initially folks thought that STUN alone
would be enough to do NAT traversal. This turned out not to be true, STUN
deprecated those parts and ICE was started. This draft fails to describe the
types of test that have actually been found to work and just reinstates the
stuff that was deployed and failed and then deprecated out of STUN.
Now this draft pays some lip service to the fact that it basically won't work.
You can read section 1
and get the full idea. The first and 2'nd par basically say this won't work.
Then para 3 proposes this is experiment to find out something we already know
the answer to. When this work was chartered, it was about making a way to
characterize NATs and describe them in a controlled lab like environment. It
was not about resurrecting exactly the part of STUN that had been tried, failed
, and deprecated."
There are several distinct issues here:
a. Whether the draft faithfully represents the reliability of the mechanism
described and the state of IETF standardization efforts in this area.
b. Whether the draft prescribes use of the mechanism in ways that are
appropriate (and different from RFC 3489).
c. Whether the document is appropriate for publication as an Experimental RFC.
d. Whether the draft fulfills the work item specified in the BEHAVE WG charter.
With respect to a, here is what Section 1 says:
" This experimental STUN usage does not allow an application behind a
NAT to make an absolute determination of the NAT's characteristics.
NAT devices do not behave consistently enough to predict future
behaviour with any guarantee. This STUN usage provides information
about observable transient behavior; it only truly determines a NAT's
behavior with regard to the STUN server used and the particular ports
used at the instant the test is run. Applications requiring reliable
reach between two particular endpoints must establish a communication
channel through a NAT using another technique. IETF has proposed
standards including ICE [I-D.ietf-mmusic-ice] and OUTBOUND
[I-D.ietf-sip-outbound] for establishing communication channels when
a publicly accessible rendezvous service is available.
This usage provides techniques which are powerful diagnostic tools in
the hands of a network administrator or system programmer trying to
determine the causes of network failure; particularly when behavior
varies by load, destination, or other factors that may be related to
NAT behavior.
"
Given this statement, it seems to me that the document isn't claiming that the
usage enables the reliable determination of NAT characteristics, and that it
recommends ICE for that purpose. So I'd say that the document is accurate in
this respect.
With respect to b, the document does describe experimental use in P2P
applications:
This draft also proposes experimental applications of NAT Behavior
Discovery STUN for real-time selection of parameters for protocols in
situations where a publicly accessible rendezvous service is not
available. One such application is role selection in P2P networks
based on statistical experience with establishing connections and
diagnosing NAT behavior with a variety of peers. The experimental
question is whether such a test is useful. If a node trying to join
an overlay as a full peer when its NAT prevents sufficient
connectivity and then withdrawing is expensive or leads to unreliable
or poorly performing operation, then even if the behavior discovery
check is only "correct" 75% of the time, its relative cheapness may
make it very useful for optimizing the behavior of the overlay
network. Section 2.2 describes this experimental application in more
detail and discusses how to evaluate its success or failure.
This particular usage seems to overlap with the ones envisaged in RFC 3489, and
so it seems to me that Cullen does have a point about whether such an
"experiment" would really yield new knowledge, or whether the outcome is
already well understood (e.g. lots of situations in which it is already known
that the "experiment" will fail).
Another described use is diagnosis. However, in this use the diagnoser would
presumably want as much information as possible about the behavior of the NAT
in question in order to figure out why their application or service isn't
working with it. Given that, do we believe that the diagnostic mechanisms
described in the document are the best that the IETF can produce, given the
state of existing knowledge? The evidence seems to indicate that we can do
better.
With respect to c, given the amount of experimentation that has already
ocurred, and the slim chances that this publication would lead to a future
standardization effort (aside from ICE or RFC 3489bis which are independent),
I'd say that justification for publication as an Experimental RFC is somewhat
shaky.
With respect to d, the work item corresponding to this document appears to be
the following:
"Submit experimental document that describes how an application can determine
the type of NAT it is behind"
Given the issues raised below, it would not appear to me that this document in
its current state satisfies the charter work item.
In terms of what should happen next, my take is that this document should go
back to the WG for further baking.
Cullen Jenning also said:
Specific problems with the draft....
2.2 - this just won't work. The test described in this draft will not find out
if the node is behind an endpoint independent nat. I have specific nats where
it won't work. I have explained to the authors why it won't work. The answer I
get back is "it might work some of the time". It true it might work some of the
time but we all agree there are many NATs for which it will not work. Other
section that don't work are 3.1, 3.2, 3.3, 3.4, 3.5, 3.5 - uh all of them
actually. I'm glad to provide details on why they don't work but I have in the
past and we not really debating if they work or not. The authors believe there
is sufficient text at the beginning of the draft in section 1 that it is OK
that these fail in many cases and don't need to be mentioned again. We not
debating these work some of the but not all the time - everyone agrees on that.
Section 4.1 - The results in here will be just wrong for ports different than
the one the test was run on. The response to this was to add "use same port
when possible". That's not going to exactly cause applications to work. Section
4.2 - Can't really separate the topic from if UDP is blocked from if the STUN
server is down. Section 4.4 - this fails if the port was recently used for
similar tests from same stun server. There no way to know this as an
application. This type of test can work in lab condition where all traffic on
NAT is controlled but it operational networks it will fail. It is possible to
do timing testing using just the change ip flag. The REPSONSE-TARGET stuff is
not needed and open up the possibility to have a STUN server send packets to
places that it should not which causes IDS system to black list all traffic
from the STUN server thus making it unusable for other clients. The ability to
tell the STUN server to send packets to arbitrary locations would be fine for a
system in a lab used to characterize a NAT but is not a good idea for internet
deployed STUN servers. The bulk of these issues were sent Aug 28 to behave list
during the 2nd WGLC. I requested agenda time during IETF 74 to discuss these
issues but it was denied. In summary -The approaches described in this draft
are known to fail with many NATs. I don't see any evidence of the WG actually
having read this draft much less have consensus on the approach in it. I think
the WG should spend meeting time to discuss the topic and decide what to do.
The key topic in my mind is we are defining a document that allows us to
characterize a NAT in a lab or if we are trying to make something that works in
field and can be used to aid NAT traversal in applications. Cullen <in my roll
as individual contributor and ex chair of behave>
On Mar 10, 2009, at 8:44 AM, The IESG wrote:
The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'NAT Behavior Discovery Using STUN '
<draft-ietf-behave-nat-behavior-discovery-06.txt> as an Experimental
RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the ietf at
ietf.org mailing lists by 2009-03-31. Exceptionally,
comments may be sent to iesg at ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-06.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15728&rfc_flag=0
The following IPR Declarations may be related to this I-D:
https://datatracker.ietf.org/ipr/919/
https://datatracker.ietf.org/ipr/945/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf