Subject: RE: [midcom] Last call reminder

From: "Yutaka Takeda" <[email-masked]>
Date: Mon, 22 Jul 2002 22:25:27 -0700

Depending on the implementation, STUN client likely re-tries the 
discovery process to make sure the result was correct.  In such
a case, I have observed one problem when it was 'Restricted
cone NAT'.

In the first discovery process, it results in Restricted NAT. And
then, STUN client re-tries the one from the same port. In Test II 
after knowing that it is natted with Test I, STUN client receives
a response and ends up with wrong result of Full-cone NAT. This
happens because STUN client has already sent a packet to the
secondary IP (Ca) in Test I (to Ca) in the first discovery process.

To prevent this, the following workaround can be taken.

- Prepare more than one port for STUN discovery process.
- Perform each process with different port number.

This is an implementation issue, however, it is good to point out
this and conduct implementers to take a workaround
described above in case implementers want to re-try the process.

------------------------------
Yutaka Takeda - Project Leader
Kyushu Matsushita Electric Research Laboratory
of Panasonic Technologies Company
A Division of Matsushita Electric Corporation of America
Tel: 858-485-4692, Fax: 858-485-6647
E-mail: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 5:41 AM
> To: [email-masked]
> Subject: [midcom] Last call reminder
> 
> 
> The STUN draft is in WG last call, which closes on Wednesday
> the 24th.  Speak now or forever hold your peace.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt
> 
> Melinda
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 

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

---

From: "Panayiotis A. Thermos" <[email-masked]>
Date: Tue, 23 Jul 2002 12:40:48 -0400

We experianced the same issue using our implementation
(http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html)

After the initial STUN discover (requests/responses) the NAT device
maintains state of the connection for a predifined period of time.

For example fpr a Linux firewall configured as NAT the UDP connections
are maintained for about 3 minutes. The TCP conections are maintained
for much longer, a little over 10 minutes or so.

Indeed this can be an issue, but I believe that the assumption is that  the
discovery algorithm provides all the steps to identify correctly your NAT
configuration the first time.

If you like to verify the results you can send your STUN requests to a new
STUN server with different IP address _AND_  different port. But since the
port is most likely to be standardized down the road by IANA, sending your
STUN requests to a new STUN server will help resolve this issue.

Peter Thermos

"Yutaka Takeda" <[email-masked]> on 07/23/2002 01:25:27 AM

To:   [email-masked]
cc:    (bcc: Panayiotis A. Thermos/Telcordia)
Subject:  RE: [midcom] Last call reminder