Re: [nbs] [Int-area] New draft related to name-based sockets

[Joe Touch <[e-mail]>]

Hi, Pete,

On 12/9/2010 2:38 PM, Pete McCann wrote:
...
>> However, this option is useful only in the SYN, IMO - as portnames pointed
>> out. And that's the place where NATs are most problematic (stripping data,
>> etc.).
>
> "this option" is doing a lot more than just putting DNS names in.
> The SYN contains a public key signature and information to bootstrap
> keys for use in authentication tags of subsequent packets.  I hope
> you can find the time to read the draft.

I have, albeit briefly. Some comments:

- it'd be useful to understand the problem this is trying to solve. The 
doc just says "avoiding unwanted traffic", but doesn't define the 
boundaries of that problem

- signing the headers, i.e., to provide secure 'safe packet' tags, is 
insufficient protection against attack; an attacker can still read AND 
modify the data in the packets

- during the TCP-AO discussion, the issue of trying to exchange keying 
info inside TCP connection establishment was considered, and determined 
infeasible (for the reasons already noted; need for too much space, and 
inability to use the data of a SYN as a shim layer)

- overall, you're doing a bunch of things at once, and the rationale is 
not clear

It would be useful to start with a concise description of the problem 
you're trying to solve, the conditions for a solution (backward 
compatible or not, etc.), as well as a comparison of existing solutions 
in this space (IPsec, TCP-AO, SSL), and a discussion of the value this 
solution adds.

However, it seems that this solution won't work unless you have a LOT of 
option space - including in the SYN - and we have no known, 
backward-compatible way of doing that.

If this isn't backward compatible, and you just want to use port numbers 
to get through a NAT, you really need a framing protocol for your data 
inside TCP, or you should consider using UDP as your wrapper instead.

Joe