[e2e] Re: NATting SCTP

[Randall Stewart]

Dan:

So what magic do you expect SCTP to be able to
do that TCP can not?

Do we design protocols to go through NAT's now?


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?

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)