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

On Feb 13, 2004, at 10:46 AM, Jonathan Rosenberg wrote:
> Jiri Kuthan wrote:
>
>> 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.
>
> I disgaree.
>
> Cullen's results show that we are seeing hybrid NATs whose type  
> depends on whether the random port selected by the client is allocated  
> already or not. In such a case, if the client picks an  
> already-allocated port during the detection phase, it may detect the  
> nat as symmetric, when it fact it might be port restricted in other  
> cases.
>
> With ICE, if you happen to be unlucky during a stun allocation, turn  
> would get used. If you're lucky, and you get a port-restricted port,  
> then the relay would not be used.

I find this situation sufficiently unlikely that I would prefer to  
"just use TURN" when i detect a symmetric NAT for code-path simplicity  
and lower call setup delay.

thx,
-rohan

>>> 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).
>
> Yes, it would be nice to obliterate such devices. With ICE, once  
> obliterated, the relay would simply cease seeing any traffic, and you  
> know at that time that you can disconnect it safely. As such, ICE  
> provides a nice way to transition from here to there.
>
>
>  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).
>
> I agree work needs to be done here.
>
> -Jonathan R.
>
>
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email protected]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom