Subject: RE: [midcom] Last call reminder

From: "Yutaka Takeda" <[email-masked]>
Date: Tue, 23 Jul 2002 10:57:44 -0700

Regarding the re-try of discovery process, what I proposed to do to 
this issue was still using the same port number that IANA would
assign for STUN server...

For the subsequent discovery process, STUN client can use different
'source' port number of the local device to send a STUN request to 
the same port number (likely to be the default 3478) of the STUN 
server. This way, the NAT device newly creates the binding table 
so that previous process will not affect to the new result.

If the result falls into 'Full-cone' where it should be 'Restricted-cone',
application might decide not to send a packet to prime the NAT at
the actual UDP port to receive incoming packets. Since it is 
actually a Restricted-cone NAT, incoming packet will nerver reach
local device.

Considering the device may re-boot within a short time, it should
be something that implementers have to be aware of... 

Yutaka Takeda

> -----Original Message-----
> From: Panayiotis A. Thermos [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 9:41 AM
> To: Yutaka Takeda
> Cc: [email-masked]
> Subject: RE: [midcom] Last call reminder
> 
> 
> 
> 
> 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
> 
> 
> 
> 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
> 
> 
> 
> 
> 

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

---

From: [email-masked]
Date: Tue, 23 Jul 2002 14:19:06 -0400

Thanks very much to everybody for going through the document
with such care.  Just to clarify, it's my sense that most of
what's been discussed in the past few days is editorial in
nature (can be corrected in the document without going
through WG last call again), rather than something that would
prevent the document from being sent on to the IESG.  Does
anybody feel otherwise?

Melinda

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jul 2002 15:25:03 -0400

I agree that the best resolution is to use a different local socket for 
subsequent retries. I also agree that this is an implementation issue, 
but worth documenting. I added the following text:

Typically, a client will re-do this discovery process periodically to
detect changes, or look for inconsistent results. It is important to
note that when the discovery process is redone, it should not
generally be done from the same local address and port used in the
previous discovery process. If the same local address and port are
reused, bindings from the previous test may still be in existence, and
these will invalidate the results of the test. Using a different local
addres and port for subsequent tests resolves this problem. An
alternative is to wait sufficiently long to be confident that the old
bindings have expired (half an hour should more than suffice).

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com