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

[Pete McCann <[e-mail]>]

Hi, Joe,

On Thu, Dec 9, 2010 at 1:10 PM, Joe Touch <[e-mail]> wrote:
>
> On 12/9/2010 11:06 AM, Pete McCann wrote:
>>
>> You might say that this is equivalent to defining a new transport,
>> but I think it's important to keep the protocol number 6 because
>> that is what today's middleboxes will pass.
>
> But they won't. The read more than you think, including options. ;-(

I'm trying to stay away from options for just that reason.
But, if middleboxes mess with the segment data in any
way (including coalescing or splitting segments) it would
indeed break the encoding I'm proposing.  But, that would
seem to break any transport-layer authentication option.

> Protocol 6 is an entire protocol, not just the default. If you want
> something inside that, you need to include framing.

I guess the whole semantics of the protocol are now hard-coded
into the network.  It would really be nice if we could draw a line
somewhere and say, "ok, beyond this point, the e2e principle
applies and ye shall make no more modifications."

> 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.

> On a separate point, _pickle.host.example.com presumes that _pickle is a
> transport, which it really isn't. Take a look at the SRV record specs, and
> the pending docs on that issue; I don't know what others feel about that,
> but that might a sticking point as well.

It might be a controversial choice but it is quite similar to the _domainkey
label that was defined in RFC4871.

-Pete