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

Joe Touch <touch@isi.edu> Fri, 10 December 2010 06:52 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 018223A6C7F; Thu, 9 Dec 2010 22:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level:
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 scoYUZd8iFcW; Thu, 9 Dec 2010 22:52:21 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 650F33A6C72; Thu, 9 Dec 2010 22:51:48 -0800 (PST)
Received: from [75.211.110.142] (142.sub-75-211-110.myvzw.com [75.211.110.142]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oBA6qTc2025945 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 9 Dec 2010 22:52:40 -0800 (PST)
Message-ID: <4D01CE2A.9090804@isi.edu>
Date: Thu, 09 Dec 2010 22:52:26 -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> <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>
In-Reply-To: <AANLkTi=j1NdofgpJUDjFPcGSTT_96GByLaNTRxx7yuCy@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" <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 06:52:28 -0000

Hi, Pete,

On 12/9/2010 2:38 PM, Pete McCann wrote:
...
>> However, this option is useful only in the SYN, IMO - as portnames pointed
>> out. And that's the place where NATs are most problematic (stripping data,
>> etc.).
>
> "this option" is doing a lot more than just putting DNS names in.
> The SYN contains a public key signature and information to bootstrap
> keys for use in authentication tags of subsequent packets.  I hope
> you can find the time to read the draft.

I have, albeit briefly. Some comments:

- 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

- 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

- 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)

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

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.

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.

Joe