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

 From a functional perspective, I believe the tests as defined would 
work, given the assumptions they make about NAT behavior, regardless of 
whther the STUN tests are each done from the same socket or different 
ones. The two times that test I is run, though, those both have to be 
from the same socket.

As such, if you are getting different results from the tests depending 
on the source IP/port, it is symptomatic of the fact that RFC 3489 does 
not properly model modern NAT behavior, and this is precisely why these 
tests were removed in the draft revision.

Thanks,
Jonathan R.

Christopher A. Martin wrote:

> 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
> 
> 
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom
> 

-- 
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