[e2e] overlay over TCP

[Randall Stewart]

Dan Wing wrote:
> 
> On Jan 24, 2005, at 4:52 AM, Randall Stewart wrote:
> 
>> Dan Wing wrote:
>>
>>> On Jan 21, 2005, at 12:15 PM, David P. Reed wrote:
>>>
>>>> Dan Wing wrote:
>>>>
>>>>>
>>>>> Yes, combined with little market demand, as yet, for a NAT to 
>>>>> handle SCTP.
>>>>
>>>>
>>>>
>>>> There is this chicken/egg problem.  If SCTP doesn't work over NATs 
>>>> it won't be used for applications where NATs are heavily used.   
>>>> Then there won't be demand (at least no evidence of it).
>>>
>>> This egg was demonstrably cooked with IPsec, which had the same 
>>> problem.  IPsec "passthru" was implemented on nearly all vendor's 
>>> residential NATs at about the same time IPsec-over-UDP was beginning 
>>> to hit the market.  Passthru works by examining SPI's and simple 
>>> mechanisms have drawbacks (only one session through the NAT, or only 
>>> one session to a specific remote IP address, for example), and 
>>> IPsec-over-UDP has even more packet bloat than IPsec itself.
>>> I expect DCCP, SCTP, and other new protocols will suffer the same 
>>> awkward deployment unless we (in the collective sense) improve the 
>>> situation with guidance from people familiar with those new 
>>> protocols.  draft-xie-tsvwg-sctp-nat-00.txt is a move in the right 
>>> direction, although it seems NATting SCTP may well be complex.
>>
>>
>> It's not that complex..
> 
> 
> 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..

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)