Subject: [BEHAVE] SCTP over NAT and (re-)fragmentation

From: Bryan Ford <[email-masked]>
Date: Mon, 10 Dec 2007 00:09:34 -0500

Hi Randall and Michael,

I liked the general approach you take toward NAT support for SCTP  
described in draft-stewart-behave-sctpnat-03.txt, as presented at IETF  
70.  While (like many) I'm skeptical that any substantial percentage  
of NATs are ever going to support anything but UDP and TCP, I do  
support standardizing NAT for SCTP if there are even a few NAT  
implementors who actually want to support it.

While studying RFC 4960, I realized a minor point that isn't (yet)  
mentioned in your SCTP-NAT draft.  An SCTP sender can't re-fragment  
data chunks that have already been fragmented and transmitted once  
(RFC 4960 section 6.9), so if the MTU of a path decreases dynamically  
due to a route change for example, the SCTP sender MUST rely on IP- 
level fragmentation in re-transmitting any already-fragmented chunks  
that are now too large for the new PMTU.  And as we know many NATs  
currently don't handle IP fragmentation well.  This simply means that  
a NAT that wants to support SCTP also needs to support IP-layer  
fragmentation and reassembly properly for SCTP packets.  Shouldn't be  
too much to ask, since RFC 4787 already requires this functionality  
for UDP.  But it's probably worth stating explicitly, since with a  
transport like SCTP that does its own fragmentation in the normal  
case, it may be easy for this issue to be overlooked in a NAT  
implementation for SCTP, leading to NAT bugs that might cause an SCTP  
association to get "stuck" in rare cases of dynamic path MTU reduction.

Cheers,
Bryan

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 10 Dec 2007 15:31:43 +0100

Hi Bryan,

see my comments in-line.

Best regards
Michael

On Dec 10, 2007, at 6:09 AM, Bryan Ford wrote:

> described in draft-stewart-behave-sctpnat-03.txt, as presented at  
> IETF 70.  While (like many) I'm skeptical that any substantial  
> percentage of NATs are ever going to support anything but UDP and  
> TCP, I do support standardizing NAT for SCTP if there are even a few  
> NAT implementors who actually want to support it.
>
> (RFC 4960 section 6.9), so if the MTU of a path decreases  
> dynamically due to a route change for example, the SCTP sender MUST  
> rely on IP-level fragmentation in re-transmitting any already- 
> fragmented chunks that are now too large for the new PMTU.  And as  
> we know many NATs currently don't handle IP fragmentation well.   
> This simply means that a NAT that  wants to support SCTP also needs  
> to support IP-layer fragmentation and reassembly properly for SCTP  
> packets.
True.
> Shouldn't be too much to ask, since RFC 4787 already requires this  
> functionality for UDP.  But it's probably worth stating explicitly,  
> since with a transport like SCTP that does its own fragmentation in  
> the normal case, it may be easy for this issue to be overlooked in a  
> NAT implementation for SCTP, leading to NAT bugs that might cause an  
> SCTP association to get "stuck" in rare cases of dynamic path MTU  
> reduction.
Good point! I'll add text in the next revision.
Thank you very much for pointing this out.

---

From: Bryan Ford <[email-masked]>
Date: Mon, 10 Dec 2007 10:06:33 -0500

Another, perhaps more substantial issue that occurred to me with draft- 
stewart-behave-sctpnat-03.txt is whether it's possible to provide any  
kind of peer-to-peer NAT traversal functionality - i.e., something  
analogous to UDP or TCP hole punching - with this approach, or will  
NATted SCTP always be strictly limited to client/server communication?

The thing is, you seem to be effectively adding SCTP's VTAG to the  
"endpoint address tuple" used by SCTP to distinguish different streams  
- i.e., now it's "kinda, sorta" (IP, port, vtag) instead of just (IP,  
port).  At least for the possible multiple SCTP associations that  
might emerge from a NAT's single public IP address and the same  
internal port, and outbound to the same server address and port, the  
VTAG provides the only way to distinguish those streams.  But what if  
the server wants to be a rendezvous server of some kind and help  
clients establish a direct SCTP association somehow?  Will there need  
to be a way for one client to open an outbound SCTP connection to  
another client's public IP address and port, specifying explicitly the  
VTAG the other client is using to talk to the rendezvous server?   
(Even without the "VTAG addressing" issue this would presumably need  
to be an extension to SCTP, since as far as I know SCTP has no  
simultanous open functionality like TCP does.)

Which I guess brings up the higher-level issue, not yet addressed in  
"SCTP NAT Traversal Considerations" (draft-xie-behave-sctp-nat- 
cons-03), of whether a "NAT for SCTP" project should include peer-to- 
peer connectivity in its scope or stay strictly limited to client/ 
server?

Cheers,
Bryan

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 10 Dec 2007 18:16:14 +0100

Hi Bryan,

see my comments in-line.

Best regards
Michael

On Dec 10, 2007, at 4:06 PM, Bryan Ford wrote:

> Another, perhaps more substantial issue that occurred to me with  
> draft-stewart-behave-sctpnat-03.txt is whether it's possible to  
> provide any kind of peer-to-peer NAT traversal functionality - i.e.,  
> something analogous to UDP or TCP hole punching - with this  
> approach, or will NATted SCTP always be strictly limited to client/ 
> server communication?
Yes, this will be possible. Both sides will send an INIT to the peer  
(getting a hole in the NAT) and
the simultaneous setup works. I'm not sure if we have already enough  
description in the ID, but
the next rev will have it.
> "endpoint address tuple" used by SCTP to distinguish different  
> streams - i.e., now it's "kinda, sorta" (IP, port, vtag) instead of  
> just (IP, port).  At least for the possible multiple SCTP  
> associations that might emerge from a NAT's single public IP address  
> and the same internal port, and outbound to the same server address  
> and port, the VTAG provides the only way to distinguish those  
> streams.  But what if the server wants to be a rendezvous server of  
> some kind and help clients establish a direct SCTP association  
> somehow?  Will there need to be a way for one client to open an  
> outbound SCTP connection to another client's public IP address and  
> port, specifying explicitly the VTAG the other client is using to  
> talk to the rendezvous server?  (Even without the "VTAG addressing"  
> issue this would presumably need to be an extension to SCTP, since  
> as far as I know SCTP has no simultanous open functionality like TCP  
> does.)
Yes, using this kind of rendezvous is possible. We have been asked for  
it a couple of times
after the presentation. It is possible, we just did not present it...

And SCTP does support of the 'simultaneous open functionality', it is  
called INIT collision in RFC 4960.
> peer connectivity in its scope or stay strictly limited to client/ 
No, it will be in the scope. And we will combine the two documents in  
one.
To be clear: It will be possible to setup a peer to peer association  
if both ends know the
addresses and ports used by the other. Both will start an association  
and the INIT collision
handling of SCTP we make sure the only one association is established.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 10 Dec 2007 14:08:47 -0800

> if both ends know the addresses and ports used by the other. 

Won't you need to also communicate the VTAG?  With UDP and TCP,
where NAPT is often performed, the NAPT device ensures there
is no port collision (by remapping port numbers).  With your
approach with SCTP, you don't want the NAT to change port 
numbers and only rely on the uniqueness of randomly-chosen
port numbers to prevent a collision.  It seems that when port
numbers do collide, you'll want to provide the NAT with the
VTAG so it can differentiate the various hosts behind the NAT
that happened to choose the same port number.

-d

---

From: Bryan Ford <[email-masked]>
Date: Mon, 10 Dec 2007 19:19:16 -0500

Ah - OK, that all sounds great; I wasn't aware of the INIT collision  
extension (i.e., didn't do my homework well enough I guess :) ).

Thanks!
Bryan

On Dec 10, 2007, at 12:16 PM, Michael Tuexen wrote:
>> provide any kind of peer-to-peer NAT traversal functionality -  
>> i.e., something analogous to UDP or TCP hole punching - with this  
>> associations that might emerge from a NAT's single public IP  
>> address and the same internal port, and outbound to the same server  
>> address and port, the VTAG provides the only way to distinguish  
>> those streams.  But what if the server wants to be a rendezvous  
>> server of some kind and help clients establish a direct SCTP  
>> association somehow?  Will there need to be a way for one client to  
>> open an outbound SCTP connection to another client's public IP  
>> address and port, specifying explicitly the VTAG the other client  
>> is using to talk to the rendezvous server?  (Even without the "VTAG  
>> addressing" issue this would presumably need to be an extension to  
>> SCTP, since as far as I know SCTP has no simultanous open  
>> functionality like TCP does.)
> Yes, using this kind of rendezvous is possible. We have been asked  
> for it a couple of times
> And SCTP does support of the 'simultaneous open functionality', it  
> is called INIT collision in RFC 4960.
>>
>>
>> Which I guess brings up the higher-level issue, not yet addressed  
>> in "SCTP NAT Traversal Considerations" (draft-xie-behave-sctp-nat- 
>> cons-03), of whether a "NAT for SCTP" project should include peer- 
>> to-peer connectivity in its scope or stay strictly limited to  
>> client/server?
> No, it will be in the scope. And we will combine the two documents  
> in one.
> addresses and ports used by the other. Both will start an  
> association and the INIT collision

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 11 Dec 2007 21:37:39 +0100

Hi Dan,

negotiating the Vtag is not possible... It is randomly selected when  
sending
the INIT or INIT-ACK.

I would just make an entry (src IP, dst, IP, src port, dst port, 0)
in the table and would match the INIT-ACK.

This will not work, if two hosts between one NAT chose the same port
number and want to talk to the same peer...

So the case to consider is that you have N users behind a NAT wanting
to talk to M users behind another NAT using the peer to peer setup.
What would you expect for N and M? There is a probability that the
port is already taken, but for small N or M it is small. I would just
accept this. But it depends on N and M....

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Dec 2007 13:18:23 -0800

> -----Original Message-----
> From: Michael Tuexen [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2007 12:38 PM
> To: Dan Wing
> Cc: 'IETF BEHAVE WG'; 'Bryan Ford'
> Subject: Re: [BEHAVE] Re: SCTP over NAT and hole-punching?
> 
> Hi Dan,
> 

So -- the question is how successful and widely-deployed will SCTP 
become where both endpoints are behind NATs?

How successful do you want that scenario to become?

-d

---

From: Randall Stewart <[email-masked]>
Date: Tue, 11 Dec 2007 19:47:31 -0500

> extension (i.e., didn't do my homework well enough I guess :) ).

Its not an extension.. check out chapter 5 (if I remember right)
of RFC4960..

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 12 Dec 2007 08:33:01 +0100

Hi Dan,

what I forgot:

After the peer to peer association has been established, the Vtags
are known and the entry with the 0-Vtag is removed. So it it no problem
to handle port number collisions. One is limited only during the period
of time where the INIT is sent and the association is not set up.

Let me think about what can be done if
- multiple end-points which have chosen the same port number
- want to talk to the same peer
- and setup all association at about the same time

Maybe the NAT can just delay the processing of the INITs which
is not the first one...

Best regards
Michael