[nbs] New draft related to name-based sockets

Pete McCann <mccap@petoni.org> Wed, 08 December 2010 17:19 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 481ED3A6830; Wed, 8 Dec 2010 09:19:59 -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 mE8toHcQJT9Q; Wed, 8 Dec 2010 09:19:58 -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 EF8203A6824; Wed, 8 Dec 2010 09:19:57 -0800 (PST)
Received: by wyf23 with SMTP id 23so1328291wyf.31 for <multiple recipients>; Wed, 08 Dec 2010 09:21:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.133.2 with SMTP id d2mr9388077wbt.92.1291828884858; Wed, 08 Dec 2010 09:21:24 -0800 (PST)
Received: by 10.227.155.7 with HTTP; Wed, 8 Dec 2010 09:21:24 -0800 (PST)
X-Originating-IP: [199.104.137.72]
Date: Wed, 8 Dec 2010 11:21:24 -0600
Message-ID: <AANLkTin4-uiFXoS9DaDWtTQartUb6DKEee+B8717odm5@mail.gmail.com>
From: Pete McCann <mccap@petoni.org>
To: nbs@ietf.org, int-area@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [nbs] 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 17:19:59 -0000

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