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

Joe Touch <> Fri, 10 December 2010 06:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 018223A6C7F; Thu, 9 Dec 2010 22:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.534
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id scoYUZd8iFcW; Thu, 9 Dec 2010 22:52:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 650F33A6C72; Thu, 9 Dec 2010 22:51:48 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (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: <>
Date: Thu, 09 Dec 2010 22:52:26 -0800
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Pete McCann <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>, "" <>
Subject: Re: [nbs] [Int-area] New draft related to name-based sockets
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.