RE: Results on draft-jennings-midcom-stun-results-01.txt

I would agree with those comments, regarding using the same source port,
since this will also facilitate easier security policy development.

________________________________

Christopher A. Martin
P.O. Box 1264
Cedar Hill, Texas 75106
http://domains.sip1.com Low cost domain name registration & other Internet
services.
 
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Tony Yat-Tung Cheung
Sent: Saturday, September 04, 2004 9:47 PM
To: Christian Huitema
Cc: [email protected]
Subject: Re: [midcom] Results on draft-jennings-midcom-stun-results-01.txt

Hi,

Thanks. I also see that the discovery algorithm has be removed from 
draft-rosenberg-rfc3489bis-00. So I think the discovery algorithm will 
not be standardized in any time soon then.

Still, I am interested in know the original algorithm in RFC 3489. I 
found that the implementation of WinStun uses a certain source port to 
send Test I, but a different source port to send Test II and Test III. 
Other implementation uses the same port to send all STUN requests for 
discovery. They each yield different result for the same NAT I have 
tried them on.

In my opinion, the STUN discovery should follow the application (such 
as RTP) closely.
So I think all STUN requests should be sent from the same source port.

Thank you.

Best Regards,
Tony Yat-Tung Cheung

On 5 Sep 04, at 2:47 AM, Christian Huitema wrote:

>
>> I also have a question on the NAT discovery in RFC 3489. For the NAT
>> discovery procedure, should all STUN requests be sent from the same
>> source port?
>
> The main value of STUN is to unambiguously define the message formats
> used in the protocol, and the server responses to these messages. The
> discovery algorithm is, IMHO, less useful.
>
> The algorithm in RFC 3489 is based on a categorization of NAT that was
> state of the art three years ago. As our knowledge progresses, we may
> expect implementers to try better algorithms. As long as they don't
> change message formats and server behavior, this will not break
> interoperability.
>
> -- Christian Huitema


_______________________________________________
midcom mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/midcom