[e2e] Re: NATting SCTP

[Dan Wing]

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:
>> On Jan 27, 2005, at 4:00 PM, Randall Stewart wrote:
>>> Dan Wing wrote:
>>>
>>>> (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
>>>
>>>
>>> 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
>>>>>
>>>>>>> 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)
>>>>>
>>>
>>>
>>> -- 
>>> Randall Stewart
>>> 803-345-0369 <or> 815-342-5222(cell)
>>>
>
>
> -- 
> Randall Stewart
> 803-345-0369 <or> 815-342-5222(cell)
>