Subject: [Ietf-behave] NAT behave for SCTP (Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt)

From: Qiaobing Xie <[email-masked]>
Date: Wed, 10 Nov 2004 18:16:16 -0800 (PST)

Hi, all,

I'd like to get your feedback on this I-D. Our intention is to put together some guidelines 
and information for people who 1) want to run SCTP across NATs, and 2) want to make future 
NATs more SCTP friendly. This has been presented at tsvwg session today.

regards,
-Qiaobing
> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
>
>
>         Title           : SCTP NAT Transverse Considerations
>         Author(s)       : Q. Xie, et al.
>         Filename        : draft-xie-tsvwg-sctp-nat-00.txt
>         Pages           : 8
>         Date            : 2004-7-14
>
> This document provides guidelines and solutions for dealing with SCTP
>    association transversing NAT and similar middleboxes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at ietf.org with the word unsubscribe in the body of the 
message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-xie-tsvwg-sctp-nat-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         mailserv at ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> <ftp://ftp.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt>
> _______________________________________________

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 17 Nov 2004 09:43:52 -0800 (PST)

Thanks for making us aware of your draft.

In section 3.2 you appear to be describing a true NAT, not a NAPT
(Network Address and Port Translator).  Is my understanding accurate?
Does your entire document talk about true NATs, or NAPTs?

In section 4.1, "Simple NAT enhancement to support singly-homed SCTP
associations", you write:

   ... In such cases, the enhancement needed for a NAT to
   support SCTP is relatively simple: 1) recognize the protocol number
   for SCTP, and 2) locate and change the transport ports (if needed).
   The location of the transport port numbers are the same as both TCP
   and UDP so these should be minor changes for NAT software.

But there isn't a mention that the signaling to set up SCTP needs
to learn, or communicate to the peer, the change to the SCTP transport
port.

(I noticed section 4.2 has a fuller description of what a NAT needs
to do when it NATs an SCTP packet; you might want to use more
parallel language in 4.1 and 4.2).

Do applications that run over SCTP have symmetry, like RTP?  See
draft-wing-mmusic-symmetric-rtprtcp-01.txt, which will be folded
into BEHAVE's "application" document.  We can extend this to describe
UDP applications (specifically RTP and RTCP) and SCTP.  TCP already
has symmetry as defined by draft-wing-mmusic-symmetric-rtprtcp-01.txt.

In addition, I caution against the "(if needed)" clause in your
document because allowing an implementation to leave the transport
port the same means only one SCTP-capable host can be behind a NAT
which is quite restrictive.

Section 4.2 says, "This approach is transparent to the endpoints
and can support multi-homing", but I'm curious how the other SCTP
endpoint knows the mapping in a back-to-back NAT case (such as
your second figure in section 3.1).

I have some other comments, but these are the significant issues
I wanted mention immediately.

Thanks again,
-d

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Qiaobing
> Xie
> Sent: Wednesday, November 10, 2004 6:18 PM
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: [Ietf-behave] NAT behave for SCTP (Re:
> I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt)
>
>
> Hi, all,
>
>  > A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>  >
>  >
>  > i-d-announce-request at ietf.org with the word unsubscribe in
> the body of the message.
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Nov 2004 10:13:20 -0800 (PST)

On Wednesday, November 17, 2004, at 12:43 PM, Dan Wing wrote:
But there isn't a mention that the signaling to set up SCTP needs
to learn, or communicate to the peer, the change to the SCTP transport
port.
It doesn't, actually.  That information is transmitted in-band,
and SCTP is a transport-layer protocol like TCP, not a session-
layer protocol like RTP.  In other words, SCTP streams can't be
assumed to be signaled by another protocol - it's switched off
the IP protocol number.
Melinda

---

From: Dan Wing <[email-masked]>
Date: Wed, 17 Nov 2004 11:10:47 -0800 (PST)

On Nov 17, 2004, at 10:12 AM, Melinda Shore wrote:

On Wednesday, November 17, 2004, at 12:43 PM, Dan Wing wrote:
But there isn't a mention that the signaling to set up SCTP needs
to learn, or communicate to the peer, the change to the SCTP transport
port.
It doesn't, actually.  That information is transmitted in-band,
and SCTP is a transport-layer protocol like TCP, not a session-
layer protocol like RTP.  In other words, SCTP streams can't be
assumed to be signaled by another protocol - it's switched off
the IP protocol number.
If the multiplexing is done by IP protocol number, I guess two
SCTP devices can't be behind a NAPT?
-d

---

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Nov 2004 11:21:24 -0800 (PST)

On Wednesday, November 17, 2004, at 02:09 PM, Dan Wing wrote:
If the multiplexing is done by IP protocol number, I guess two
SCTP devices can't be behind a NAPT?
Sure, but the NAT would need to be able to recognize SCTP and 
demultiplex
SCTP traffic on port number.  Getting NAT vendors to add basic SCTP
support to their devices is one problem, but it's more-or-less the same
problem as supporting TCP and UDP.  The real problems are around
stream endpoint address mutability and multihoming, which are unique to
SCTP.

Melinda

---

From: Dan Wing <[email-masked]>
Date: Wed, 17 Nov 2004 12:31:36 -0800 (PST)

On Nov 17, 2004, at 11:17 AM, Melinda Shore wrote:

On Wednesday, November 17, 2004, at 02:09 PM, Dan Wing wrote:
If the multiplexing is done by IP protocol number, I guess two
SCTP devices can't be behind a NAPT?
Sure, but the NAT would need to be able to recognize SCTP and 
demultiplex
SCTP traffic on port number.
Is the desire of draft-xie-tsvwg-sctp-nat-00 to _not_ work in such a
scenario?  The document didn't declare that out of scope, but the
introduction does define a NAT as a device that also does port
translation.

Getting NAT vendors to add basic SCTP
support to their devices is one problem, but it's more-or-less the same
problem as supporting TCP and UDP.  The real problems are around
stream endpoint address mutability and multihoming, which are unique to
SCTP.
This is discussed a bit in the draft (3.2), but I'd like to see more
discussion in the I-D about what NAT vendors could do to support
such multhoming -- I expect the requirements to support SCTP's 
multihoming
are nearly identical to support multihoming a device that uses TCP or
UDP, no?

-d

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Nov 2004 12:39:13 -0800 (PST)

On Wednesday, November 17, 2004, at 03:31 PM, Dan Wing wrote:
Is the desire of draft-xie-tsvwg-sctp-nat-00 to _not_ work in such a
scenario?  The document didn't declare that out of scope, but the
introduction does define a NAT as a device that also does port
translation.
Yes, the scoping should probably be clearer.

This is discussed a bit in the draft (3.2), but I'd like to see more
discussion in the I-D about what NAT vendors could do to support
such multhoming -- I expect the requirements to support SCTP's 
multihoming
are nearly identical to support multihoming a device that uses TCP or
UDP, no?
No, this is quite different.  In the SCTP case the endpoint address
may change over the lifetime of a stream and it may be the case that
individual frames are sent to different addresses.  For example, you
could stripe one stream across multiple interfaces.
Melinda

---

From: Dan Wing <[email-masked]>
Date: Wed, 17 Nov 2004 12:49:48 -0800 (PST)

On Nov 17, 2004, at 12:38 PM, Melinda Shore wrote:

Thanks.
-d

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 17 Nov 2004 14:15:39 -0800 (PST)

Melinda Shore wrote:

If the multiplexing is done by IP protocol number, I guess two
SCTP devices can't be behind a NAPT?
Sure, but the NAT would need to be able to recognize SCTP and demultiplex
SCTP traffic on port number.  Getting NAT vendors to add basic SCTP
support to their devices is one problem, but it's more-or-less the same
problem as supporting TCP and UDP.  
Yes, indeed. The work to support singly-homed SCTP is very much the same as for TCP or UDP. 
The intention of the draft is to cover both NAT and NAPT cases.

The real problems are around
stream endpoint address mutability and multihoming, which are unique to
SCTP.
Yes. That's the more interesting part :-)

regards,
-Qiaobing
Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 17 Nov 2004 14:21:43 -0800 (PST)

I don't see why this has to be out of scope. Please clarify.

Getting NAT vendors to add basic SCTP
support to their devices is one problem, but it's more-or-less the same
problem as supporting TCP and UDP.  The real problems are around
stream endpoint address mutability and multihoming, which are unique to
SCTP.
This is discussed a bit in the draft (3.2), but I'd like to see more
discussion in the I-D about what NAT vendors could do to support
such multhoming -- I expect the requirements to support SCTP's multihoming
are nearly identical to support multihoming a device that uses TCP or
UDP, no?
No, section 3.2 is about "multi-point traverse". Multi-homing support recommendation is 
discussed in section 4.1.

regards,
-Qiaobing
-d

Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 17 Nov 2004 14:26:51 -0800 (PST)

Hi, Dan,

Thanks for the review and comments. Please see my comments in-line.

Dan Wing wrote:

In section 3.2 you appear to be describing a true NAT, not a NAPT
(Network Address and Port Translator).  Is my understanding accurate?
Does your entire document talk about true NATs, or NAPTs?
Actually both. The text applies to both NAT and NAPT. An SCTP association can have multiple 
addresses but only one port number at either end.

This case is very much the same as TCP/UDP. As pointed out by Melinda.

ok.

As Melinda has pointed out, SCTP is a transport protocol like TCP. It is unlike RTP.

Section 4.2 says, "This approach is transparent to the endpoints
and can support multi-homing", but I'm curious how the other SCTP
endpoint knows the mapping in a back-to-back NAT case (such as
your second figure in section 3.1).
The other SCTP endpoint will not be aware of the NATs in the path. It will only see the 
translated address list from the last NAT (and possibly the translated port number if NAPT 
is involved).

Thanks,
-Qiaobing
Thanks again,
-d

-----Original Message-----

I'd like to get your feedback on this I-D. Our intention is to
put together some guidelines
and information for people who 1) want to run SCTP across NATs,
and 2) want to make future
NATs more SCTP friendly. This has been presented at tsvwg session today.
regards,
-Qiaobing
the body of the message.

---

From: Dan Wing <[email-masked]>
Date: Wed, 17 Nov 2004 15:25:17 -0800 (PST)

On Nov 17, 2004, at 2:18 PM, Qiaobing Xie wrote:

If the multiplexing is done by IP protocol number, I guess two
SCTP devices can't be behind a NAPT?
Sure, but the NAT would need to be able to recognize SCTP and 
demultiplex
SCTP traffic on port number.
Is the desire of draft-xie-tsvwg-sctp-nat-00 to _not_ work in such a
scenario?  The document didn't declare that out of scope, but the
introduction does define a NAT as a device that also does port
translation.
I don't see why this has to be out of scope. Please clarify.
If the NAPT translates port numbers, the other SCTP peer needs to know
the translated port number.
For example, if you have two SCTP endpoints behind a single NAPT and
both of them are listening on SCTP port 1234, and the NAPT receives
a SCTP packet for port 1234, what's the NAPT supposed to do?  Currently
you only discuss the NAPT intercepting and modifying SCTP packets
for the multi-homing scenario (section 4.2); I believe you want
similar behavior for the case of two SCTP devices behind a single
NAT.

Getting NAT vendors to add basic SCTP
support to their devices is one problem, but it's more-or-less the 
same
problem as supporting TCP and UDP.  The real problems are around
stream endpoint address mutability and multihoming, which are unique 
to
SCTP.
This is discussed a bit in the draft (3.2), but I'd like to see more
discussion in the I-D about what NAT vendors could do to support
such multhoming -- I expect the requirements to support SCTP's 
multihoming
are nearly identical to support multihoming a device that uses TCP or
UDP, no?
No, section 3.2 is about "multi-point traverse". Multi-homing support 
recommendation is discussed in section 4.1.
Thanks.
-d

regards,
-Qiaobing
-d
Melinda

---

From: Dan Wing <[email-masked]>
Date: Wed, 17 Nov 2004 15:31:39 -0800 (PST)

On Nov 17, 2004, at 2:29 PM, Qiaobing Xie wrote:

Hi, Dan,

Dan Wing wrote:

Thanks for making us aware of your draft.
In section 3.2 you appear to be describing a true NAT, not a NAPT
(Network Address and Port Translator).  Is my understanding accurate?
Does your entire document talk about true NATs, or NAPTs?
Actually both. The text applies to both NAT and NAPT. An SCTP 
association can have multiple addresses but only one port number at 
either end.

In section 4.1, "Simple NAT enhancement to support singly-homed SCTP
associations", you write:
   ... In such cases, the enhancement needed for a NAT to
   support SCTP is relatively simple: 1) recognize the protocol number
   for SCTP, and 2) locate and change the transport ports (if needed).
   The location of the transport port numbers are the same as both TCP
   and UDP so these should be minor changes for NAT software.
But there isn't a mention that the signaling to set up SCTP needs
to learn, or communicate to the peer, the change to the SCTP transport
port.
This case is very much the same as TCP/UDP. As pointed out by Melinda.
TCP doesn't have a mechanism to learn the ephemeral NAT'd port (that 
is, the
source port), but also doesn't need to -- TCP connections are symmetric
in that a 5-tuple describes the connection in both directions.  UDP, and
especially RTP, don't behave that way.

Maybe SCTP does; I'm not familiar with it (which is undoubtedly obvious
by now!).

Do applications that run over SCTP have symmetry, like RTP?  See
draft-wing-mmusic-symmetric-rtprtcp-01.txt, which will be folded
into BEHAVE's "application" document.  We can extend this to describe
UDP applications (specifically RTP and RTCP) and SCTP.  TCP already
has symmetry as defined by draft-wing-mmusic-symmetric-rtprtcp-01.txt.
In addition, I caution against the "(if needed)" clause in your
document because allowing an implementation to leave the transport
port the same means only one SCTP-capable host can be behind a NAT
which is quite restrictive.
As Melinda has pointed out, SCTP is a transport protocol like TCP. It 
is unlike RTP.
I realize SCTP is its own protocol.  However, I don't know if it has 
symmetry
in its use of ports.  For example, if an SCTP application sends a packet
with a source port of 1234, will responses from the remote SCTP stack 
come
back to that same port?  UDP, which is its own protocol, doesn't 
guarantee
this; TCP, which is also its own protocol, does guarantee this.  I'm 
curious
about SCTP's behavior in this regard.

Section 4.2 says, "This approach is transparent to the endpoints
and can support multi-homing", but I'm curious how the other SCTP
endpoint knows the mapping in a back-to-back NAT case (such as
your second figure in section 3.1).
The other SCTP endpoint will not be aware of the NATs in the path. It 
will only see the translated address list from the last NAT (and 
possibly the translated port number if NAPT is involved).

-d

-----Original Message-----

NATs more SCTP friendly. This has been presented at tsvwg session 
today.

regards,
-Qiaobing
the body of the message.
> You can also visit 
https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 17 Nov 2004 18:01:37 -0800 (PST)

....
If the NAPT translates port numbers, the other SCTP peer needs to know
the translated port number.
For example, if you have two SCTP endpoints behind a single NAPT and
both of them are listening on SCTP port 1234, and the NAPT receives
a SCTP packet for port 1234, what's the NAPT supposed to do?  Currently
But the two SCTP endpoints behind the NAPT will always have a different local IP 
address(es). I still do not seem to see the problem.

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 17 Nov 2004 18:06:44 -0800 (PST)

...
TCP doesn't have a mechanism to learn the ephemeral NAT'd port (that is, the
source port), but also doesn't need to -- TCP connections are symmetric
in that a 5-tuple describes the connection in both directions.  UDP, and
especially RTP, don't behave that way.
Maybe SCTP does; I'm not familiar with it (which is undoubtedly obvious
by now!).
Yes, SCTP does, just like TCP. The only difference with SCTP is that the src and dest 
address in TCP now become possibly a list of src and dest addresses.

...
I realize SCTP is its own protocol.  However, I don't know if it has symmetry
in its use of ports.  For example, if an SCTP application sends a packet
with a source port of 1234, will responses from the remote SCTP stack come
back to that same port?  UDP, which is its own protocol, doesn't guarantee
this; TCP, which is also its own protocol, does guarantee this.  I'm 
curious about SCTP's behavior in this regard.
Yes, SCTP has the same symmetry as TCP in port use.

regards,
-Qiaobing