Subject: [BEHAVE] SCTP NAT questions and concerns

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 20 Nov 2008 14:59:53 -0600

Toward the end of the Wednesday meeting there was a question raised
about the SCTP NAT draft essentially asking whether it had support for
endpoint-independent mapping or other support for inbound connections.
 I was unclear on the answer at the time and spoke with the authors
afterward.

My understanding of the current situation is that ports in sctp never
change (essentially port overloading is always used), but connections
are identified by vtag.  That means that an unsolicited connection can
never be delivered inbound, however it also means that simultaneous
open essentially always works through exchange of vtags through an
ice-like mechanism.

In order to make this work, the NAT does need to make sure that it
uses the same Public Address (using current terminology) for all
connections from the same Private Address.  In fact, the draft
currently seems to assume that a NAT only has one Public Address.
That assumption can't be made, and it seems like the draft needs to
reflect that it needs to mandate endpoint independent mapping like
4787.

The requirements on the NAT implementer are not as clearly worded as
they are in 4787, for example.  Having an explicit list of
requirements, including the mapping requirement and that simultaneous
open must be supported seems desirable to me.

I missed the discussion of the issue in Section 6, "Handling of
internal port number collisions" during the presentation.  My reading
of this section is that it requires every host on the internet
implementing sctp to implement this new NAT_SUPPORTED tag, otherwise
two hosts behind the same NAT cannot exchange data with them.  Is SCTP
at a point where this global change is considered feasible?

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

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Nov 2008 15:18:54 -0600

> reflect that it needs to mandate endpoint independent mapping like

You're talking about the address pooling behavior, which can be either  
"paired" or "arbitrary" according to the terminology in RFC 4787.  My  
poorly informed, but not entirely uneducated, guess is that paired  
address pooling behavior is required for NAT traversal of SCTP.  I  
don't view this as a problem, really, since the translation state is  
entirely tied to the 3-tuple of source address, destination address  
and verification tag, which are mapped one to one with host-to-host  
associations.  Even NAT implementations that do arbitrary address  
pooling behavior for transports that require port floating should have  
no real trouble maintaining the paired pooling behavior required by  
SCTP.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 20 Nov 2008 16:04:06 -0600

On Thu, Nov 20, 2008 at 3:18 PM, james woodyatt <[email-masked]> wrote:
> "paired" or "arbitrary" according to the terminology in RFC 4787.  My poorly
> informed, but not entirely uneducated, guess is that paired address pooling
> behavior is required for NAT traversal of SCTP.  I don't view this as a
> problem, really, since the translation state is entirely tied to the 3-tuple
> of source address, destination address and verification tag, which are
> mapped one to one with host-to-host associations.  Even NAT implementations
> that do arbitrary address pooling behavior for transports that require port
> floating should have no real trouble maintaining the paired pooling behavior
> required by SCTP.
>

Exactly.  I don't envision it should be a problem for a NAT, just
thought that the draft should point out the requirement.  I had
forgotten about the separate term for IP address selection.

Bruce

---

From: Randall Stewart <[email-masked]>
Date: Thu, 20 Nov 2008 21:59:38 -0500

Bruce:

Comments below...

> open essentially always works through exchange of vtags through an

Its not an ICE like mechanism.. its is the basic protocol. The protocol
is designed to handle all the collision cases of simultaneous open and
that is what we do here.. .it is in the draft I believe.. feedback
would be appreciated...

> reflect that it needs to mandate endpoint independent mapping like

Yes, it assumes a simple one IP address in the nat model. The draft
needs some wording added to state the above.. i.e. you must
lock the IP address to a mapping.

> open must be supported seems desirable to me.

Yes.. wording suggestions are always welcome :-)
> at a point where this global change is considered feasible?

The NAT supported tag is only needed when:

1) Two hosts behind a nat decide to talk to  the same server
2) Both hosts of course are talking to the same IP address and port
3) Both hosts pick the same source port
4) Both hosts pick the same vtag...

It is unlikely but it can happen.. and this is where the NAT_SUPPORTED  
tag
comes in.. it basically disables the restart feature of an association.

As to is it feasible to have all SCTP stacks add this.. I think you will
get most, not all. For example the SUN/BSD and Linux stacks will  
probably
implement this (I have just about finished the BSD stack as I type this
email :-D).. but there will be some implementations, specific to telco
private networks that probably never implement it.. but that is probably
ok.. since they are not really talking on the public internet... of  
course
if one of these stacks decide to do this.. then they would naturally  
extend
there implementation to include this.. it is not a lot of work, I have  
done
all of the nat draft in the last day and 1/2 or so for bsd.. I have one
small function left to code.. some more wording that needs to be
added to the draft :-)

R

> Bruce

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 21 Nov 2008 10:51:46 -0500

> that is what we do here.. .it is in the draft I believe.. feedback

I believe the point Bruce was making is that for simultaneous-open to work
(when both endpoints are behind NATs), each party's vtag needs to be
communicated via the rendezvous server, just as its port and external IP
address is.

> tag comes in.. it basically disables the restart feature of an association.

For this to work, is it required that the remote server also implements
NAT_SUPPORTED?

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

---

From: james woodyatt <[email-masked]>
Date: Fri, 21 Nov 2008 10:18:51 -0600

On Nov 20, 2008, at 20:59, Randall Stewart wrote:
>
> It is unlikely but it can happen.. and this is where the  
> NAT_SUPPORTED tag

Thinking forward to a future that may never actually arrive, I suspect  
it would be a good idea to find another name for this tag that doesn't  
include the evil three-letter acronym.  I suggest DISABLE_RESTART.

---

From: <[email-masked]>
Date: Fri, 21 Nov 2008 17:31:16 +0100

Hi,

This not only about disabling restart.
This means that the server must differentiate peer endpoints not
only based on ip address and port. Now the server must also look at the
vtag
and multiple vtags may be valid at the same time.
Ultimately this means that the vtag no longer can be used
to distinguish stale packets from valid packets ! - and that, taken to
the extreme,
has impacts vis-a-vis timewait.

NAT is a term used in other protocols (IPSec, IKE).
Better use this term or use a term that more directly target
the vtag issue - something like
ENPOINT_VTAG_DIFFERENTIATION 

BR Karen

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of james woodyatt
> Sent: Friday, November 21, 2008 5:19 PM
> To: Behave WG
> Subject: Re: [BEHAVE] SCTP NAT questions and concerns
>

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 21 Nov 2008 11:33:31 -0600

> Yes.. wording suggestions are always welcome :-)

I just have a general suggestion that looking at the naming and
wording techniques from 4787 and 5382 and having similar construction
would probably be most useful to implementers.

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 21 Nov 2008 11:26:58 -0600

> communicated via the rendezvous server, just as its port and external IP

Yes, my understanding of the proposal is that a protocol external to
SCTP is required to rendezvous and exchange this information.  ICE is
one such protocol.  Or is the rendezvous actually built into SCTP?

> For this to work, is it required that the remote server also implements

My reading of the existing Section 6 is that current SCTP
implementations fail under condition 4, and that it is only with this
new extension that this would work.

This collision seems like it would be a common case.

The other reason I mentioned it is that I was surprised to see a
change in SCTP in a BEHAVE draft.  I would expect that change to be
done in another wg, and this draft to depend on that work since it
appears to me to require this change to make the whole port
preservation idea.

Bruce

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 21 Nov 2008 13:06:11 -0600

> communicated via the rendezvous server, just as its port and  
No. Both sides need to know the port number and external address
used by the peer. The port numbers do not change, so it is mostly
the IP-address which needs to be learned. See section 12.5 of
http://www.ietf.org/internet-drafts/draft-ietf-behave-sctpnat-00.txt
for the message flow.
>> NAT_SUPPORTED

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 21 Nov 2008 13:06:57 -0600

On Nov 21, 2008, at 10:18 AM, james woodyatt wrote:

> Thinking forward to a future that may never actually arrive, I  
> suspect it would be a good idea to find another name for this tag  
> that doesn't include the evil three-letter acronym.  I suggest  
> DISABLE_RESTART.
That is actually a good idea!

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 21 Nov 2008 13:09:06 -0600

On Nov 21, 2008, at 10:31 AM, <[email-masked]> <[email-masked] 
 > wrote:

> ENPOINT_VTAG_DIFFERENTIATION
Well, let me think about this for a while... At least the client
does something special in case he is multihomed.

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 21 Nov 2008 13:13:46 -0600

> would probably be most useful to implementers.
This ID does not just list requirements, it gives details how
to implement this. If you have suggestions about terminology,
please state them as explicitly as James did...

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 21 Nov 2008 13:23:03 -0600

On Nov 21, 2008, at 11:26 AM, Bruce Lowekamp wrote:

> On Fri, Nov 21, 2008 at 9:51 AM, Jonathan Lennox <[email-masked] 
> > wrote:
No.

But I'm not sure if something like ICE is needed. Think about a
IRC type client server communication where you register with
a server in the global Internet and then to clients figure out
that they want to setup an association peer to peer. Since the
server already knows the global addresses, they can be transferred
by the application protocol...
> new extension that this would work.
If both clients use the same port number, the second association would
be considered a restart of first association.
> appears to me to require this change to make the whole port
I think having it in one document is fine. Since it is mostly NAT
related I think BEHAVE is appropriate, the SCTP experts from TSVWG
will know what is in this document, I'm sure...

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 21 Nov 2008 13:42:39 -0600

> by the application protocol...

Oh, I'm not trying to imply that ICE is required.  I was just using it
as an example of one protocol that could be used to achieve that.

> will know what is in this document, I'm sure...

I'm confident the right people are aware of the extension.

After some further thought, I am concerned about the implications of
the extension, though.  In the world we are quickly hurtling toward,
there will be no way to tell if you are going through a NAT.  Between
NAT444, NAT46, and NAT64, you can have a public IP address
communicating with another public IP address that goes through a NAT.
If you want that to work with SCTP, I think the implication is that
this flag needs to always be set, which eliminates restart from the
SCTP feature set.

Bruce

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 21 Nov 2008 14:45:02 -0500

> http://www.ietf.org/internet-drafts/draft-ietf-behave-sctpnat-00.txt

I'm confused about the step in that flow described as:

                VTag != Int-VTag, but Ext-VTag == 0, find entry.

What happens if there are multiple entries matching the local port and
remote address and port, from different internal hosts?

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 21 Nov 2008 13:52:52 -0600

On Nov 21, 2008, at 1:45 PM, Jonathan Lennox wrote:

> On Friday, November 21 2008, "Michael Tüxen" wrote to "Jonathan  
> Lennox, Randall Stewart, Behave WG" saying:
>
This would mean that the are multiple clients behind the left NAT
choosing the same random port number that want to communicate with
the same peer behind the right NAT at the same time! I consider this
pretty unlikely, but we can restrict these entry to one. The left NAT
box can send an ABORT back...

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 21 Nov 2008 16:12:47 -0500

> box can send an ABORT back...

Consider the scenario where an endpoint is attempting to set up an SCTP
connection using SIP (i.e. with an SDP m= line), and the SIP INVITE request
has forked to two devices behind the same NAT.  Both devices will
(presumably) attempt to connect to the originator's advertised port number,
and in 1/2^16 cases, they'll choose the same random local port.

---

From: <[email-masked]>
Date: Sat, 22 Nov 2008 19:01:46 +0100

> > only based on ip address and port. Now the server must also 
> look at  
> > the
> > vtag

Some input for you to ignore or take into account in your thinking, if you like :-)

My understanding of the protocol is that it's the 4-tuple (disregarding SCTP protocol identification)
(dest Ip address, dest Port, src Ip address, src port) which is used to match
incoming traffic to an association in the multihomed situation and that such a flow may
belong to one and only one association even in the multi-homed situation. 
The vtag matching is used for "security screening and freshness"  but not for endpoint identification.
At least this is how we have implemented SCTP multi-homing. 

We also use our implementation in a load balancing scenario where we do indeed use the vtag for
"NAT" multiplexing much as it is described in your draft but with the exception that due to special restrictions
in this scenario, two clients behind the LB NAT may never choose the same local port. By virtue of this particularity,
the risk of vtag overlap is not changed compared to the standard, I.e., vtag overlap
 may be avoided by appropriate actions taken in individual SCTP end-points, as well as one never risk 4-tuple overlap
between different associations).

Accepting 4-tuple overlaps and thus vtag differentiating may be the right way to go, though I do not particularly like
this situation due to the security problems. An alternative solution could be to enforce split on ports. E.g., extend the 
NAT initiated ABORT message to prompt not only choice of new vtag but also choice of new local port. The latter though, 
has much more severe implications at the socket api level.

BR, Karen