Subject: [Tsvwg] Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt

From: Qiaobing Xie <[email-masked]>
Date: Tue, 20 Jul 2004 12:12:11 -0500

All,

I'd like to get your feedback on this I-D. Our intention is to put together some guidelines 
and information for people 1) who want to run SCTP across NATs, and 2) who want to make 
future NAT/middleboxes more SCTP friendly.

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>
> _______________________________________________

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 20 Jul 2004 14:11:58 -0400

There's a middle case which may bear mention, and that's that in
the case of a multihomed association a NAT may choose to create
one NAT table mapping per endpoint address.  Yes, that's wasteful,
but it's implementable without introducing new data structures (list
of addresses) within the NAT.

I'm not sure I agree with the conclusion in section 3.2 that there
needs to be an inter-NAT protocol.  I would look to see if there's
some way that the verification tag could be used to identify
packets that belong to a particular association, or perhaps it would
be more effective to add an association identifier TLV of some sort.
An inter-NAT protocol is going to be a big project and is going to
introduce a very considerable ugliness into the scenario, which is
the question of how the NATs know about each other.  Worse, it would
mean that every NAT you traversed would need to run that protocol.
It would be better, I think, to use a mechanism that didn't require
support from the NAT itself.

Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 21 Jul 2004 13:55:07 -0500

Melinda,

Thanks for the comments.

> of addresses) within the NAT.

Good point.

> be more effective to add an association identifier TLV of some sort.

We mentioned inter-NAT prot simply because we felt there need to be some sort of 
coordination/communication among the NATs so that they would uniquely identify the packets 
each of them sees actually belong to the same SCTP association. Whether it v-tag or a new 
assoc-id, you still need to sync that up among the NATs, right? ... unless it's some kind of 
globally defined numbering scheme? But that seems to be more difficult to establish.

> mean that every NAT you traversed would need to run that protocol.

We were hoping some existing/work-in-progress inter-middlebox mechanism (e.g., midcom, nsis, 
  ...) could give us a hand :-) I agree to create a new inter-NAT protocol is a big project.

> support from the NAT itself.

That would be ideal.

regards,
-Qiaobing

---

From: Melinda Shore <[email-masked]>
Date: Wed, 21 Jul 2004 15:35:28 -0400

On Wednesday, July 21, 2004, at 02:55 PM, Qiaobing Xie wrote:
> We mentioned inter-NAT prot simply because we felt there need to be 
> some sort of coordination/communication among the NATs so that they 
> would uniquely identify the packets each of them sees actually belong 
> to the same SCTP association. Whether it v-tag or a new assoc-id, you 
> still need to sync that up among the NATs, right? ... unless it's some 
> kind of globally defined numbering scheme? But that seems to be more 
> difficult to establish.

There are several ways of actively dealing with NATs.  My preferred way
is to take it outside, set it on a hard surface, and pound it repeatedly
with a heavy object, but that's not always an option.  Basically it 
comes
down to using a relay, which obviously is not an appropriate general
solution, or being able to talk directly to the NAT and request a NAT 
table
mapping, or to try to make your protocol more NAT-friendly.  
Unfortunately
using an explicit list of addresses to define the association is not 
very
NAT-friendly.

If you're going to talk to the NAT directly, you'll need a protocol to
do that.  Neither midcom nor nsis is complete, although midcom is close.
Talking to the NAT directly means finding the appropriate one.  That's
extremely difficult to do with midcom in a multihomed scenario.  I'll 
spare
you my opinion of nsis.  UPnP is basically midcom in consumer-oriented
devices and it's currently available, but it suffers from the same 
shortcomings
as midcom in topologically complex networks.

I think that in the circumstances you're describing your best bet is to
not touch the NAT at all (beyond adding basic SCTP support in the first
place) and instead use low-probability identifiers combined with
authentication (on the odd chance that you have a collision).  The 
obvious
problem is that this is not how SCTP currently identifies members of an
association, but this could be added as an extra check rather than as a
replacement for the current logic.  It also obviates the extra messaging
and "post-dial delay" that would come with using a protocol that 
communicates
directly with the NAT, as well as the requirement that the NAT 
communication
protocol be supported in every device involved.

So that's my bias for this kind of problem.  Unfortunately there's 
rarely
a low-cost solution for NAT traversal problems.

Melinda