Cullen, I will respond to your comment on a high level. I think the applicability statement on this document is correct and clear that this will not work all the time. You seem to want to press the point that there is no meaning for a mechanism unless it is always correct. I don't agree with that view, and because of that I found is suitable to last call. The uncertainty in its usefulness is why it is labeled experimental. I do like to see input from more individuals before determining consensus if this document should be moving forward or be blocked. I would also like to see the authors comment on the individual points. It seems likely that document changes are needed if we are progressing this to IESG review. Best Regards Magnus Cullen Jennings skrev: > > 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. > > 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@xxxxxxxx mailing lists by 2009-03-31. Exceptionally, >> comments may be sent to iesg@xxxxxxxx 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/ >> >> >> _______________________________________________ >> Behave mailing list >> Behave@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/behave > > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@xxxxxxxxxxxx ---------------------------------------------------------------------- _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf