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

Joe Touch <touch@isi.edu> Wed, 08 December 2010 21:49 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 D60603A696A; Wed, 8 Dec 2010 13:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BybcgqOvV8BQ; Wed, 8 Dec 2010 13:49:22 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CCFC53A6995; Wed, 8 Dec 2010 13:49:22 -0800 (PST)
Received: from [75.202.68.159] (159.sub-75-202-68.myvzw.com [75.202.68.159]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oB8Lo7pT013938 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 8 Dec 2010 13:50:17 -0800 (PST)
Message-ID: <4CFFFD8D.2000601@isi.edu>
Date: Wed, 08 Dec 2010 13:50:05 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Pete McCann <mccap@petoni.org>
References: <AANLkTin4-uiFXoS9DaDWtTQartUb6DKEee+B8717odm5@mail.gmail.com>
In-Reply-To: <AANLkTin4-uiFXoS9DaDWtTQartUb6DKEee+B8717odm5@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: int-area@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: Wed, 08 Dec 2010 21:49:24 -0000

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