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

Pete McCann <mccap@petoni.org> Thu, 09 December 2010 22:36 UTC

Return-Path: <mccap@petoni.org>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41D928C118; Thu, 9 Dec 2010 14:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtQ7ElQHSEGg; Thu, 9 Dec 2010 14:36:57 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 55FFF28C102; Thu, 9 Dec 2010 14:36:57 -0800 (PST)
Received: by wyf23 with SMTP id 23so2836495wyf.31 for <multiple recipients>; Thu, 09 Dec 2010 14:38:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.135.201 with SMTP id o9mr11371610wbt.121.1291934305939; Thu, 09 Dec 2010 14:38:25 -0800 (PST)
Received: by 10.227.13.136 with HTTP; Thu, 9 Dec 2010 14:38:25 -0800 (PST)
X-Originating-IP: [64.53.131.166]
In-Reply-To: <4D0129B3.4050906@isi.edu>
References: <AANLkTin4-uiFXoS9DaDWtTQartUb6DKEee+B8717odm5@mail.gmail.com> <4CFFFD8D.2000601@isi.edu> <AANLkTi=KG_CL5hQ0k4JQAy6oB=3RV3UWGQxTbYzGmsR3@mail.gmail.com> <72504C2E-CE17-4AE0-ACBC-E6BB4F002267@isi.edu> <AANLkTimmQ-HKJBpoqQCc9t1P=GFPFa8VojPTFh-D8Nay@mail.gmail.com> <4D011EF3.8080407@isi.edu> <AANLkTi=+PQKxMj4C83A90-DK3V-89ydBR02rR5zvA68L@mail.gmail.com> <4D0129B3.4050906@isi.edu>
Date: Thu, 9 Dec 2010 16:38:25 -0600
Message-ID: <AANLkTi=j1NdofgpJUDjFPcGSTT_96GByLaNTRxx7yuCy@mail.gmail.com>
From: Pete McCann <mccap@petoni.org>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "int-area@ietf.org" <int-area@ietf.org>, "nbs@ietf.org" <nbs@ietf.org>
Subject: Re: [nbs] [Int-area] New draft related to name-based sockets
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2010 22:36:59 -0000

Hi, Joe,

On Thu, Dec 9, 2010 at 1:10 PM, Joe Touch <touch@isi.edu> 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