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

Joe Touch <touch@isi.edu> Thu, 09 December 2010 02:47 UTC

Return-Path: <touch@isi.edu>
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 F0D2728C0CF; Wed, 8 Dec 2010 18:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level:
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 t16LhW1p9R0w; Wed, 8 Dec 2010 18:47:56 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 0515D3A6816; Wed, 8 Dec 2010 18:47:55 -0800 (PST)
Received: from [10.64.50.213] (mobile-166-137-009-172.mycingular.net [166.137.9.172] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oB92mlXL028770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Dec 2010 18:49:02 -0800 (PST)
References: <AANLkTin4-uiFXoS9DaDWtTQartUb6DKEee+B8717odm5@mail.gmail.com> <4CFFFD8D.2000601@isi.edu> <AANLkTi=KG_CL5hQ0k4JQAy6oB=3RV3UWGQxTbYzGmsR3@mail.gmail.com>
In-Reply-To: <AANLkTi=KG_CL5hQ0k4JQAy6oB=3RV3UWGQxTbYzGmsR3@mail.gmail.com>
Mime-Version: 1.0 (iPhone Mail 8C148)
Content-Type: text/plain; charset=us-ascii
Message-Id: <72504C2E-CE17-4AE0-ACBC-E6BB4F002267@isi.edu>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPhone Mail (8C148)
From: Joe Touch <touch@isi.edu>
Date: Wed, 8 Dec 2010 21:48:41 -0500
To: Pete McCann <mccap@petoni.org>
X-MailScanner-ID: oB92mlXL028770
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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 02:47:57 -0000

Hi Pete,

Sorry - you said transport payload, which - in hindsight - is ambiguous. 

First, as my old portnames ID explained, the strings need only be in the SYN. Using the data in the SYN for options has been proposed before, and there are many known issues. 

FYI. 

Joe

On Dec 8, 2010, at 8:38 PM, Pete McCann <mccap@petoni.org> wrote:

> Hi, Joe,
> 
> I understand that ports are in the transport header.
> 
> The shim I am proposing goes *after* the transport header and
> provides an encapsulation for the transport payload.  That way,
> middleboxes see what looks like a standard IP/TCP header,
> followed by a payload which contains the new stuff.  Think of
> it as a way to get a lot of new options space without confusing
> any of the middleboxes (unless they do try to parse beyond the
> transport header like a "transparent" HTTP proxy.  The new stuff
> I am proposing would confuse those kinds of boxes).  I only say
> "not backwards compatible" because both endpoints need to be
> upgraded to support the new extensions.  Middleboxes that have
> not been upgraded shouldn't care; it looks like standard TCP or
> UDP to them.  I agree that defining a new transport protocol is
> a non-starter in today's deployed IPv4 network.  I think there will
> always be only TCP, UDP, and maybe ICMP (the latter shouldn't
> be trusted anyway) so I'm essentially trying to layer on top of them.
> 
> I know the choice of a DNS TXT record for public keys is controversial,
> but it is very similar to the approach taken for DKIM which has been
> quite successful.  The problem with new record types is that you have
> to wait for all the servers and their configuration interfaces to support
> them.
> 
> -Pete
> 
> On Wed, Dec 8, 2010 at 3:50 PM, Joe Touch <touch@isi.edu> wrote:
>> Hi, Pete,
>> 
>> This seems a little backwards. The port is in the context of the transport
>> protocol, but if it's in the shim between IP and TCP it is - at best - a
>> parameter to IP, not the transport (TCP, UDP, or other).
>> 
>> Using a transport other than TCP or UDP also puts it on the slow path (or
>> just blackholes it) for anything that looks beyond the IP header, too.
>> 
>> As to where to put public keys, there's an RFC regarding reasons not to use
>> TXT records for new DNS capabilities you might want to dig up (sorry - I'm
>> in the airport and can't find it quickly - it was written by the IAB I
>> think).
>> 
>> Joe
>> 
>> On 12/8/2010 9:21 AM, Pete McCann wrote:
>>> 
>>> I've uploaded a new draft relevant to the name-based sockets
>>> discussion and several others that have been going on in the
>>> Internet Area and elsewhere:
>>> 
>>> https://datatracker.ietf.org/doc/draft-mccann-picklepacket/
>>> 
>>> It describes a framework for putting DNS names into transport
>>> packets that is a bit different from the approaches I've seen
>>> advocated on the NBS list.  For one thing, I wanted to work
>>> with IPv4 as well as IPv6, which means avoiding all IP options
>>> which cause packets to go on the slow path or get dropped.
>>> The TCP options space is too limited for carrying DNS names,
>>> let alone the extra authentication payloads that I wanted to
>>> put there.  So, I'm proposing essentially extending the transport
>>> options space in a non-backwards compatible way by shimming
>>> in a magic number where the transport payload would normally
>>> go.  This would apply to UDP as well.  I've defined a new header
>>> which I think is relatively compact yet provides all the flexibility
>>> we need, and a TLV format for carrying the DNS names and
>>> public-key authentication tags.  I'm proposing to put public keys
>>> into DNS TXT records so that they can be retrieved by middleboxes
>>> that want to verify the transport connections passing through them.
>>> Also, middleboxes can add their own names and authentication
>>> tags, which allows them to make themselves known to the endpoints.
>>> This enables them to be used as mobility anchor points in case the
>>> path changes.
>>> 
>>> The focus of the introduction is on preventing denial-of-service attacks
>>> but I think the protocol has many other useful features.
>>> Names can be used to route connections such as multiple servers
>>> sitting behind a NAT all on the same port.  Routing on names does
>>> require some state to be kept in the middleboxes if we don't want
>>> to put DNS names into every packet.  So, I'm proposing that each
>>> middlebox choose a 32-bit cookie value that it can use to index the
>>> flow state.  These cookies get distributed in the same round-trip as
>>> the initial transport connection setup.
>>> 
>>> I'm very curious to have your feedback on the approach.  There is a
>>> lot of stuff in the draft and the protocol is rather heavyweight, but
>>> I think it addresses a lot of different themes that I've seen being
>>> discussed in different working groups (TCP Auth Option, MPTCP,
>>> NBS, MEXT, DKIM, KEYASSURE, etc).
>>> 
>>> -Pete
>>> _______________________________________________
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>>