Subject: [Ietf-behave] NATting SCTP

From: Dan Wing <[email-masked]>
Date: Wed, 26 Jan 2005 13:48:20 -0800 (PST)

(CC'ing ietf-behave, and setting reply-to to ietf-behave)

On Jan 26, 2005, at 12:20 PM, Randall Stewart wrote:

I admit to only reading that I-D once, but NATting SCTP is certainly 
more complex than NATting TCP or UDP, especially with multihoming.
I'm unclear how two SCTP devices, behind their own NATs, can 
communicate with each other.  The communication problem seems akin to 
two UDP or TCP devices, behind their own NATs, communicating with 
each other ---- the NAT will have to preserve the port numbers which 
means only one SCTP device is permitted behind a NAT, or else the NAT 
will have to multiplex using something other than the SCTP port 
number, or else you need an SCTP port discovery protocol (akin to 
STUN for UDP).
No why do you say that? If you follow the recomendation of the
drafts you get
--From IP-A'(port:2222)-INIT(**)-To:IP-Z:port-80---->

** No addresses listed aka we are singly homed.

Nat gets it and makes it

----->From IP-A(port:9999)-INIT(**)---To:IPZ:port-80-------->

Nat at IPZ gets it and does whatever static mapping.. i.e. you
have the same problem you have with a apache server behind a NAT .. you
must have the NAT direct the port 80 connection somewhere.. this is
the same for TCP..
----From IP-A(port:9999)---INIT(**)----To:IPZ':port-8080---->

And the reverse mappings take place the opposite ways...

I don't see how this does not work..
I agree it works, but only if:

  1.  you know the SCTP servers behind the NAT, and
  2.  reconfigure your NAT to do port forwarding, and
  3.  inform the remote SCTP client of your public SCTP port (which,
      if there is only one SCTP device behind the NAT, might well be
      the same as your application's default SCTP port).
However, the barista at the local coffeeshop won't reconfigure their 
NAT to support your SCTP server while you're using wireless at the 
coffeeshop.  And my proverbial father wouldn't know how to reconfigure 
his NAT, either, and my SCTP application won't know the public SCTP 
port he chose to use when I visit his house with my wireless device.

As to your statement that this is how TCP works, there are active 
efforts to make TCP servers behind NATs 'just work', without requiring 
the NAT to be configured for port forwarding.  See for example
http://nutss.gforge.cis.cornell.edu/stunt.php, which would require only 
(3) from my list above -- which is necessary anyway if the same 
application exists on multiple hosts behind a common NAT.

-d

R

and yes Cisco has had at least one
customer ask for it... Have they had lots .. no. The
reason being where Cisco currently makes money from
SCTP is inside the network. Most folks don't run their
SS7 over IP network where they want to have a NAT
to Global address cross over.
[...]
I expect SCTP will find more applications than just SS7-over-SCTP, 
and that will help drive the need for NATs that understand SCTP.
-d

--
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Dan Wing <[email-masked]>
Date: Sun, 30 Jan 2005 23:20:15 -0800 (PST)

On Jan 27, 2005, at 4:00 PM, Randall Stewart wrote:

Dan Wing wrote:

I admit to only reading that I-D once, but NATting SCTP is 
certainly more complex than NATting TCP or UDP, especially with 
multihoming.
I'm unclear how two SCTP devices, behind their own NATs, can 
communicate with each other.  The communication problem seems akin 
to two UDP or TCP devices, behind their own NATs, communicating 
with each other ---- the NAT will have to preserve the port numbers 
which means only one SCTP device is permitted behind a NAT, or else 
the NAT will have to multiplex using something other than the SCTP 
port number, or else you need an SCTP port discovery protocol (akin 
to STUN for UDP).
No why do you say that? If you follow the recomendation of the
drafts you get
--From IP-A'(port:2222)-INIT(**)-To:IP-Z:port-80---->

Nat gets it and makes it

Nat at IPZ gets it and does whatever static mapping.. i.e. you
have the same problem you have with a apache server behind a NAT .. 
you
must have the NAT direct the port 80 connection somewhere.. this is
the same for TCP..

I don't see how this does not work..
I agree it works, but only if:
  1.  you know the SCTP servers behind the NAT, and
And does this differ with the way we do TCP servers behind a NAT?

  2.  reconfigure your NAT to do port forwarding, and
And again, does this differ with the way we do TCP servers behind a 
NAT?
  3.  inform the remote SCTP client of your public SCTP port (which,
      if there is only one SCTP device behind the NAT, might well be
      the same as your application's default SCTP port).
Again.. All of these cavets you list are the SAME exact ones that
you do when you put a TCP server behind a NAT.. you:
1) Place the TCP server behind the NAT
and
2) configure your nat to port forward <80> (for example) to 8080 at
   10.1.1.1
and
3) Tell the client about the public port.
Nothing here is any differnet then the way current nats work with
TCP...
As I said, I agree it works.  I agree that's what happens to use TCP 
servers today.  If you're comfortable that SCTP servers will always 
need manual configuration of NATs, that's great.   TCP hasn't worked 
out that way, though -- for example, Windows fileshares and "p2p" 
filesharing both want to connect to TCP servers behind NATs.

However, the barista at the local coffeeshop won't reconfigure their 
NAT to support your SCTP server while you're using wireless at the 
coffeeshop.  And my proverbial father wouldn't know how to 
reconfigure his NAT, either, and my SCTP application won't know the 
public SCTP port he chose to use when I visit his house with my 
wireless device.
And let me guess you think someone at these same places is going
to know how to configure a TCP server behind a NAT too? I think
not..
Today's difficulties in getting TCP servers working behind NATs has 
caused several
workarounds for applications, as you're undoubtedly aware, because TCP 
servers
that are behind unconfigured NATs are inaccessible.

As to your statement that this is how TCP works, there are active 
efforts to make TCP servers behind NATs 'just work', without 
requiring the NAT to be configured for port forwarding.  See for 
example
http://nutss.gforge.cis.cornell.edu/stunt.php, which would require 
only (3) from my list above -- which is necessary anyway if the same 
application exists on multiple hosts behind a common NAT.

Ok.. there are efforts underway ..I will look at your link.. but
whatever you come up with for TCP you can do the same exact thing
for SCTP..
Its the same work.. and note that it is "an effort under way" which
means the folks at the coffee shop are still doing 1 and 2 to
get their TCP server to work behind their NAT :-0
-d

R
-d
R

---

From: Dan Wing <[email-masked]>
Date: Mon, 31 Jan 2005 08:18:46 -0800 (PST)

On Jan 31, 2005, at 5:07 AM, Randall Stewart wrote:

Dan:

So what magic do you expect SCTP to be able to
do that TCP can not?
Let me give an example:

Today it is possible, with the majority of the NATs on the market, to 
set up a bi-directional UDP 'connection' with two hosts that are behind 
their own NATs, _without_ changing the configuration of the NAT.  This 
can be done with STUN (RFC3489), which is done by the application.  
However, with TCP, it currently isn't possible to do the same -- 
rather, at least one of the NATs has to be configured.

Do we design protocols to go through NAT's now?
I'm not suggesting changes to SCTP, the protocol.

Rather, I'm suggesting that the recommendations for NATting SCTP be 
written to allow two SCTP applications behind their own NATs to 
communicate directly with each other, without requiring configuration 
changes to their NATs.  I expect that SCTP can do this.

To answer your question, though, it's my understanding that 
IPsec-over-UDP was created primarily to traverse NATs.  And I know STUN 
(RFC3489) was created expressly to assist UDP applications traverse 
NATs.

I realize that this is a long standing problem... I suppose
one could change the fundamental API of SCTP and move
it to use PPID's in the data chunks INSTEAD of
ports to access apps... but even at that you still
have a problem.. how do you find a port someone is
listening on behind a NAT... that is the bottome line
problem and I don't think I know a solution... do you?
The device behind the NAT has to send a packet (towards the Internet) 
in order to establish the NAT binding.

-d

R

Dan Wing wrote:

I admit to only reading that I-D once, but NATting SCTP is 
certainly more complex than NATting TCP or UDP, especially with 
multihoming.
I'm unclear how two SCTP devices, behind their own NATs, can 
communicate with each other.  The communication problem seems 
akin to two UDP or TCP devices, behind their own NATs, 
communicating with each other ---- the NAT will have to preserve 
the port numbers which means only one SCTP device is permitted 
behind a NAT, or else the NAT will have to multiplex using 
something other than the SCTP port number, or else you need an 
SCTP port discovery protocol (akin to STUN for UDP).

Nat gets it and makes it

Nat at IPZ gets it and does whatever static mapping.. i.e. you
have the same problem you have with a apache server behind a NAT 
.. you
must have the NAT direct the port 80 connection somewhere.. this is
the same for TCP..

However, the barista at the local coffeeshop won't reconfigure 
their NAT to support your SCTP server while you're using wireless 
at the coffeeshop.  And my proverbial father wouldn't know how to 

And let me guess you think someone at these same places is going
to know how to configure a TCP server behind a NAT too? I think
not..
Today's difficulties in getting TCP servers working behind NATs has 
caused several
workarounds for applications, as you're undoubtedly aware, because 
TCP servers
that are behind unconfigured NATs are inaccessible.
As to your statement that this is how TCP works, there are active 
efforts to make TCP servers behind NATs 'just work', without 
requiring the NAT to be configured for port forwarding.  See for 
example
http://nutss.gforge.cis.cornell.edu/stunt.php, which would require 
only (3) from my list above -- which is necessary anyway if the 
same application exists on multiple hosts behind a common NAT.

-d

R

[...]
I expect SCTP will find more applications than just 
SS7-over-SCTP, and that will help drive the need for NATs that 
understand SCTP.
-d