[e2e] overlay over TCP

[Joe Touch]

Randall Stewart wrote:
....
>>> As to "doing SCTP" NAT's don't do TCP.. they know about
>>> it.. where the ports are, what the c-sum is etc.
>>
>> And where the data is, which for TCP and DCCP isn't as tricky ;-)
> 
> There was no trick to it... one does not have to
> know where the data is since the header is
> just like TCP, just like UDP, just like DCCP.
> 
> And all data (data and control) start after the
> header.. no different than TCP.. except for one
> minor rinkle.. I don't have to do the bit with
> psuedo headers...

Yeah, but you do have to deal with the SCTP muxing headers. Don't 
forget, you have to scan certain protocols to translate IP addresses and 
port numbers in the data too. That means parsing the data inside the 
muxing chunks. (see below)

>>> Same for UDP and of course the same thing is needed
>>> for SCTP. You have to understand a "SYN" or an "INIT"
>>> but it is not as complex as you make out.. no more
>>> complex than having a NAT do TCP...
>>
>> NATs translate data _inside_ the packets too; that's where 'knowing 
>> SCTP' is substantially more complex.
> 
> FTP, last I checked, does not run over SCTP.. and even
> if it did it would not be that tough to find the addresses
> etc... no different than knowing the data format of
> any other protocol... including TCP..

Does HTTP? Will either FTP or HTTP? Any other protocols?

Doing "NAT" _means_ translating inner addresses used in the data. If 
you're ignoring that, sure, it's certainly easy. But that's not what 
makes NATs hard or complex.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050120/2170db2b/signature.bin