Re: [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote:
>This is a great piece of work. Thanks to Cullen for putting this together.
>
>One conclusion I draw from this is that, as STUN itself predicts, the NAT classification algorithm is brittle because it makes assumptions about the types of NATs and there behaviors. We are now seeing NATs that have this dual behavior, depending on whether the internal port is allocated or not, and STUN's detection algorithm does not take this into account. Indeed, I would be inclined to work on reivising STUN, and in such a revision, remove the detection algorithm and explain why that was done. What do people think of that?

I think there is still some value in the NAT-type tests even with 
use of ICE. Positive assertions about traversable NATs may be brittle, 
I agree. Negative assertions about hard-to-traverse NATs are quite 
safe and can eliminiate unnecessary tries. Particularly, if you know 
you are behind a symmetric NAT you can safely eliminate STUN address 
from your offer. 


>To me, this also further strengthens the arguments behind something like ICE (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt), which uses STUN, but does *not* use the detection algorithm. Rather, it relies on dynamic connectivity checks to figure out whether an address works or not. The argument there is that, ultimately, the only way to know whether you can receive media sent from address A to interface X is if you can receive a packet from address A sent to interface X. Any other way of verifying this conclusion is based on assumptions that can be wrong.

Whereas I am quite comfortable with ICE and enjoy its e2e robustness, 
I think there is still some other, parallel, undone work. The left option 
of using a media relay indicates to me that there is an architectural 
imperfection and I see it in silly NATs (silly is an aggregate word standing 
for undeterministic or symmetric or bad or whatsoever). It seems very
desirable to me to abandon such devices and I think it is a quite realistic
goal. Cullen's draft actually strengthens my hope that it is happening.

A way the IETF can help is to collect recommendations for NATs. There was 
such an effort long time ago 
(http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt),
I maintain a very similar list as well (don't be silly, keep NAT bindings for
a while, allow  hairpinning, try to preserve port numbers, try to use stateless 
binding allocation algorithms). 

-jiri