Re: [nbs] NBS and TCP connection identification

Erik Nordmark <erik.nordmark@oracle.com> Tue, 21 September 2010 15:58 UTC

Return-Path: <erik.nordmark@oracle.com>
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 1D09E3A6A3F for <nbs@core3.amsl.com>; Tue, 21 Sep 2010 08:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.353
X-Spam-Level:
X-Spam-Status: No, score=-106.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, 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 nAjE15Lq2nkU for <nbs@core3.amsl.com>; Tue, 21 Sep 2010 08:58:41 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D00273A6964 for <nbs@ietf.org>; Tue, 21 Sep 2010 08:58:41 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8LFx13T017459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Sep 2010 15:59:03 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8LAPGF8027238; Tue, 21 Sep 2010 15:58:59 GMT
Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 623767741285084439; Tue, 21 Sep 2010 08:53:59 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Sep 2010 08:53:57 -0700
Message-ID: <4C98D525.1030808@oracle.com>
Date: Tue, 21 Sep 2010 08:54:13 -0700
From: Erik Nordmark <erik.nordmark@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100817 Lightning/1.0b2 Thunderbird/3.1.1
MIME-Version: 1.0
To: Javier Ubillos <jav@sics.se>
References: <4C97D9A8.2050001@oracle.com> <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com> <4C9826D0.2060703@oracle.com> <1285067950.2068.59.camel@bit>
In-Reply-To: <1285067950.2068.59.camel@bit>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Christian Vogt <christian.vogt@ericsson.com>, nbs@ietf.org
Subject: Re: [nbs] NBS and TCP connection identification
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: Tue, 21 Sep 2010 15:58:43 -0000

On 09/21/10 04:19 AM, Javier Ubillos wrote:

> Perhaps I misunderstand your concern, but I'll try to answer.
> On the individual host, there is a change to the implementation in the
> sense that the 4-tuple is now
> name, service (port), name service(port)
> instead of the prevous
> ip, port, ip port.
>
> There are no changes to the "on the wire" protocol.

In my book "protocol" = "packet formats" + "behavior".

I'd agree there isn't any changes to the TCP packet formats (but you do 
have some added IP options/extension headers). But AFAICT there is a 
rather profound change to the TCP protocol behavior around connection 
establishment.

> There are two ways of doing this.
> 1. Hashing the name into something that fits into the ip-address field.
> 2. Having a specialized TCP implementation.
>
> I promote alternative 2.
> In fact, we already have that bit working in the prototype.

Please correct me if I'm wrong, but you are proposing that when TCP 
receives a SYN packet it checks if the packet has the IP 
option/extension to carry a name, and if so creates the TCB for the 
name/port 4-tuple, whereas if the name is not present the TCB would be 
for the IP/port 4-tuple.

That requires some care, and I don't understand how you propose to apply 
this to UDP.

> Hmmm, you might have a point here.
> We're going to have to consider this more.
>
> There are two ideas on the table:
> a) Do nothing.
> b) When receiving a name in an option, resolve that name and compare
> IP's with the just received IP.
>
> Case a) _will_ happen if the name is not a resolvable FQDN.
> Case b) ... perhaps this is an issue we need to look at.
> I need to do some readingup on the subject.

As I said, doing b) on the SYN is opening a huge DoS attack opportunity.

FWIW I know how to avoid this complexity if we reuse the shim6-style 
exchange from the start (with ULID replaced by the name). The I1/R1 
exchange does the initial exchange, and on I2 (which can also carry the 
TCP SYN I guess) the receiver can do the DNS lookup with less of a DoS 
concern. Doing things in that order also ensures that TCP (and UDP) 
would have a (verified) name when the first packet is received. But that 
approach has some other downsides.

>>
>>> - Hosts that don't have a name registered in the DNS will derive a
>>> DNS name from their IP address.  This will give them session
>>> continuity, albeit no reachability.
>>
>> But that doesn't allow them to use SHIM6 to move around.
>> A CBID as a name allows them to move around.
>
> It does, in the most primitive scenario, one enters an IP into the
> name-based socket, and that IP is used just as a label.

How do you secure the movement in that case?
Suppose the client has IP address 129.146.228.81, thus the server would 
see the client as having name 81.228.146.129.in-addr.arpa.
Then the client switches to being on IP address 36.1.2.3. How can you 
know that it is indeed the same client so that it is secure for the 
server to start sending the packets to 36.1.2.3?
You can't rely on DNS validation (unless you assume that the client can 
update the DNS records for 81.228.146.129.in-addr.arpa, which is very 
unlikely.)
Thus how do you secure this?

    Erik