|
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 solicitsfinal comments on this action. Please send substantive comments to theietf 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf