Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior Discovery Using STUN) to Experimental RFC

[Cullen Jennings <fluffy at cisco.com>]

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 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/
>
>
> _______________________________________________
> Behave mailing list
> Behave at ietf.org
> https://www.ietf.org/mailman/listinfo/behave