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

Pete McCann <mccap@petoni.org> Fri, 10 December 2010 17:52 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 8023728C0D9; Fri, 10 Dec 2010 09:52:37 -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 RYJQHfi8QCS7; Fri, 10 Dec 2010 09:52:36 -0800 (PST)
Received: from mail-ew0-f53.google.com (mail-ew0-f53.google.com [209.85.215.53]) by core3.amsl.com (Postfix) with ESMTP id 9323A28C0EA; Fri, 10 Dec 2010 09:52:35 -0800 (PST)
Received: by ewy6 with SMTP id 6so2824017ewy.40 for <multiple recipients>; Fri, 10 Dec 2010 09:54:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.182.8 with SMTP id n8mr1303712wem.41.1292003645021; Fri, 10 Dec 2010 09:54:05 -0800 (PST)
Received: by 10.227.13.136 with HTTP; Fri, 10 Dec 2010 09:54:04 -0800 (PST)
X-Originating-IP: [64.53.131.166]
In-Reply-To: <4D01CE2A.9090804@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> <AANLkTi=j1NdofgpJUDjFPcGSTT_96GByLaNTRxx7yuCy@mail.gmail.com> <4D01CE2A.9090804@isi.edu>
Date: Fri, 10 Dec 2010 11:54:04 -0600
Message-ID: <AANLkTim4jRQUE=FOvtQRZa7mFH1LS1h=OwkdspEV2k_J@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: Fri, 10 Dec 2010 17:52:37 -0000

Hi, Joe,

On Fri, Dec 10, 2010 at 12:52 AM, Joe Touch <touch@isi.edu> wrote:
>> I hope
>> you can find the time to read the draft.
>
> I have, albeit briefly. Some comments:

Great, thanks!

> - it'd be useful to understand the problem this is trying to solve. The doc
> just says "avoiding unwanted traffic", but doesn't define the boundaries of
> that problem

Yes, re-reading the introduction now I see it could use some additional
explanation.

The goal is to enable middleboxes to filter out unwanted traffic as close
to the sender as possible.  By adding a public-key based authentication
tag, middleboxes unknown to the original sender at the time he sends
the first packet can independently validate the signature and check the
reputation of the sender (similar to what DKIM does for e-mail, but this
is for transport connections).  By performing a dynamic key derivation
operation, the endpoint and the middlebox can agree on a shared secret
to protect subsequent packets with an HMAC-based tag which should
be verifiable at line rate.

> - signing the headers, i.e., to provide secure 'safe packet' tags, is
> insufficient protection against attack; an attacker can still read AND
> modify the data in the packets

Completely agree; note that signing headers only is just one of the
options supported by the draft, and I expect coverage of the full
data packet will be commonly used.  But, the option to cover just
the header (or to omit the HMAC and just use a cookie) are there
to provide a low-overhead solution for particular threat models, e.g.,
when all attackers are off-path.

There have been a range of such options discussed in the literature
such as Lightweight Internet Permit System (LIPS) [1] and Passport [2].
I believe LIPS doesn't protect the payload in any way and Passport
protects only a limited portion of the payload.

> - during the TCP-AO discussion, the issue of trying to exchange keying info
> inside TCP connection establishment was considered, and determined
> infeasible (for the reasons already noted; need for too much space, and
> inability to use the data of a SYN as a shim layer)

Yes, I definitely need a lot of space to put the DNS names and public
key signatures in.  If we are dealing with a path that does TCP re-segmentation,
it might be better to use UDP as you suggest below.

> - overall, you're doing a bunch of things at once, and the rationale is not
> clear

The draft attempts to describe a complete system including both the
packet authentication tags, key distribution, and DNS-based credentials.
I know this is unusual for work in the IETF that is usually done in smaller
chunks.  The draft grabs a bunch of bits and pieces and shows how to
fit them together, but maybe an overall system diagram would help.

> It would be useful to start with a concise description of the problem you're
> trying to solve, the conditions for a solution (backward compatible or not,
> etc.), as well as a comparison of existing solutions in this space (IPsec,
> TCP-AO, SSL), and a discussion of the value this solution adds.

IPSec and SSL are end-to-end, and the Diffie-Hellman exchange done
up front means that middleboxes have no chance to even see the identities
being exchanged in the credentials, let alone validate them (I'm sure the
designers of these protocols consider that a feature).  The endpoints of
an IPSec or SSL connection have to be known to the sender in advance.

In contrast, pickle packets put the DNS names in the clear for any middlebox to
examine and validate.  They can even participate in the key distribution
and subsequently filter out packets with bad authentication tags.  All without
pre-configuring their identities into clients or adding additional round-trips
(modulo the DNS queries, which could benefit from caching).

TCP-AO is in an architecturally similar place in the stack but is also
end-to-end
and doesn't have any key management defined for it.

> However, it seems that this solution won't work unless you have a LOT of
> option space - including in the SYN - and we have no known,
> backward-compatible way of doing that.
>
> If this isn't backward compatible, and you just want to use port numbers to
> get through a NAT, you really need a framing protocol for your data inside
> TCP, or you should consider using UDP as your wrapper instead.

Yes, please note that the draft attempts to describe a transport-independent
format that should fit in *either* TCP or UDP.  If TCP re-segmentation is
being performed along a path you're right it would be better to fall back
to UDP.

[1] http://www.ee.hawaii.edu/~dong/papers/LIPS_report.pdf
[2] http://www.usenix.org/event/nsdi08/tech/full_papers/liu_xin/liu_xin.pdf