Subject: RE: [midcom] STUN over TCP?

From: "Cedric Aoun"<[email-masked]>
Date: Sun, 17 Mar 2002 18:33:46 -0000

I thought of this again, since there is a reply to the server, in case the
first fragment of the packet doesn't reach the NAT first; the NAT will drop
all the packet's fragments and the server will not get a reply. The result
will be that the server will retransmit again, and at some point the
fragments will reach the NAT in the right sequence.

The sequencing problem occured because the routing changed in the network,
this doesn't happen all the time.

I know that some NATs work with fragmentation (but I don't know if all of
them do like the 100$ residential NATs)when the fragment id is unique given
the remote address (in this case the STUN server) and the NAT address.

Any way the current document doesn't impose the usage of TCP so I don't find
any issue with it, but we probably want to have couple of lines to mention
the real problem that we have with NATs and fragmentation and that it is not
applicable to all NATs.In case the NAT supports fragmentation the STUN
client is configured to use UDP.

Cedric  

-----Original Message-----
From: Mahadev [mailto:[email-masked]]
Sent: Friday, March 15, 2002 8:03 PM
To: Melinda Shore
Cc: [email-masked]
Subject: Re: [midcom] STUN over TCP?

Yes, this very common irrespective of the device type (low/high end)...

-Mahadev

Melinda Shore wrote:
> 
> At 02:19 AM 3/15/02 -0800, Mahadev wrote:
> >This is not a big problem as such. There are NAT implementations which
> >take care of fragmentation issue by storing state information from the
> >first fragment.
> 
> Is this commonly the case, or is it only done on high-end devices?
> 
> Melinda

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Mar 2002 11:34:38 -0500

Cedric Aoun wrote:
> 
> Any way the current document doesn't impose the usage of TCP so I don't
> find any issue with it, but we probably want to have couple of lines to
> mention the real problem that we have with NATs and fragmentation and
> that it is not applicable to all NATs.In case the NAT supports
> fragmentation the STUN client is configured to use UDP.

I will mention the motivation for TCP. However, the big question is how
the client knows that its nat supports fragmentation?

-Jonathan R.

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

---

From: Mahadev Somasundaram <[email-masked]>
Date: Mon, 18 Mar 2002 12:38:33 -0800

>the client knows that its nat supports fragmentation?
one way to detect could be by sending large size packet (~5000bytes) and 
wait for the server reply. If the  reply from server reaches the client, 
then the NAT supports fragmentation. If there is no reply, the reason may 
not be due to NAT fragmentation support (like packet loss, fragment 
out-of-sequence). So, the client retransmits with the interval time of 1 
second and doubles with every try. After 3 tries, with the elapsed time of 
7 seconds, client gives up and assumes that the NAT does not support 
fragmentation.

this could be done during the NAT discovery phase...

-Mahadev

---

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 18 Mar 2002 14:54:54 -0800

If the STUN server had a flag to send a really big packet, it is likely that
it will be fragmented and you will find out what your NAT does.  I am mostly
joking here - I don't think this is the right path but it is an possible
option. Not to mention this would make a STUN server into an amplifier from
a DDOS point of view.

Cullen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jonathan Rosenberg
Sent: Monday, March 18, 2002 8:35 AM
To: Cedric Aoun
Cc: 'Mahadev'; Melinda Shore; [email-masked]'
Subject: Re: [midcom] STUN over TCP?

-Jonathan R.

---

From: Mahadev Somasundaram <[email-masked]>
Date: Mon, 18 Mar 2002 15:55:02 -0800

At 12:38 PM 3/18/2002 -0800, Mahadev Somasundaram wrote:
>then the NAT supports

should be read "requesting to send" instead of "sending"

thanks,
-Mahadev

>fragmentation. If there is no reply, the reason may not be due to NAT 
>fragmentation support (like packet loss, fragment out-of-sequence). So, 
>the client retransmits with the interval time of 1 second and doubles with 
>every try. After 3 tries, with the elapsed time of 7 seconds, client gives 
>up and assumes that the NAT does not support fragmentation.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Mar 2002 00:17:00 -0500

Mahadev Somasundaram wrote:
> wait for the server reply. 

I guess you are assuming that we would add a feature to STUN to allow
you to send large requests that trigger large responses. 

I really don't like this approach. Its correctness is dependent on a lot
of other variables in the system. As you say, no reply can occur for
MANY reasons. Assuming its because of fragmentation seems risky. What is
so bad with TCP?

-Jonathan R.