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
- [nbs] New draft related to name-based sockets Pete McCann
- [nbs] New draft related to name-based sockets RJ Atkinson
- Re: [nbs] New draft related to name-based sockets Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] New draft related to name-based sockets Javier Ubillos
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Mirja Kuehlewind
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch