[BEHAVE] Re: SCTP over NAT and hole-punching?

[Bryan Ford <[e-mail]>]

Ah - OK, that all sounds great; I wasn't aware of the INIT collision  
extension (i.e., didn't do my homework well enough I guess :) ).

Thanks!
Bryan

On Dec 10, 2007, at 12:16 PM, Michael Tuexen wrote:
> Hi Bryan,
>
> see my comments in-line.
>
> Best regards
> Michael
>
> On Dec 10, 2007, at 4:06 PM, Bryan Ford wrote:
>
>> Another, perhaps more substantial issue that occurred to me with  
>> draft-stewart-behave-sctpnat-03.txt is whether it's possible to  
>> provide any kind of peer-to-peer NAT traversal functionality -  
>> i.e., something analogous to UDP or TCP hole punching - with this  
>> approach, or will NATted SCTP always be strictly limited to client/ 
>> server communication?
> Yes, this will be possible. Both sides will send an INIT to the peer  
> (getting a hole in the NAT) and
> the simultaneous setup works. I'm not sure if we have already enough  
> description in the ID, but
> the next rev will have it.
>>
>>
>> The thing is, you seem to be effectively adding SCTP's VTAG to the  
>> "endpoint address tuple" used by SCTP to distinguish different  
>> streams - i.e., now it's "kinda, sorta" (IP, port, vtag) instead of  
>> just (IP, port).  At least for the possible multiple SCTP  
>> associations that might emerge from a NAT's single public IP  
>> address and the same internal port, and outbound to the same server  
>> address and port, the VTAG provides the only way to distinguish  
>> those streams.  But what if the server wants to be a rendezvous  
>> server of some kind and help clients establish a direct SCTP  
>> association somehow?  Will there need to be a way for one client to  
>> open an outbound SCTP connection to another client's public IP  
>> address and port, specifying explicitly the VTAG the other client  
>> is using to talk to the rendezvous server?  (Even without the "VTAG  
>> addressing" issue this would presumably need to be an extension to  
>> SCTP, since as far as I know SCTP has no simultanous open  
>> functionality like TCP does.)
> Yes, using this kind of rendezvous is possible. We have been asked  
> for it a couple of times
> after the presentation. It is possible, we just did not present it...
>
> And SCTP does support of the 'simultaneous open functionality', it  
> is called INIT collision in RFC 4960.
>>
>>
>> Which I guess brings up the higher-level issue, not yet addressed  
>> in "SCTP NAT Traversal Considerations" (draft-xie-behave-sctp-nat- 
>> cons-03), of whether a "NAT for SCTP" project should include peer- 
>> to-peer connectivity in its scope or stay strictly limited to  
>> client/server?
> No, it will be in the scope. And we will combine the two documents  
> in one.
> To be clear: It will be possible to setup a peer to peer association  
> if both ends know the
> addresses and ports used by the other. Both will start an  
> association and the INIT collision
> handling of SCTP we make sure the only one association is established.
>>
>>
>> Cheers,
>> Bryan
>>
>>
>



_______________________________________________
Behave mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/behave