Re: [nbs] NBS and TCP connection identification

Erik Nordmark <erik.nordmark@oracle.com> Wed, 22 September 2010 17:12 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 1FAFF3A69E3 for <nbs@core3.amsl.com>; Wed, 22 Sep 2010 10:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.758
X-Spam-Level:
X-Spam-Status: No, score=-105.758 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_47=0.6, 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 GRYum0u8CA02 for <nbs@core3.amsl.com>; Wed, 22 Sep 2010 10:12:12 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 776A23A69B4 for <nbs@ietf.org>; Wed, 22 Sep 2010 10:12:12 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8MHCWfG014039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Sep 2010 17:12:34 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8MF6Q7h030920; Wed, 22 Sep 2010 17:12:30 GMT
Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 621899941285175439; Wed, 22 Sep 2010 10:10:39 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Sep 2010 10:10:39 -0700
Message-ID: <4C9A38A1.9060307@oracle.com>
Date: Wed, 22 Sep 2010 10:10:57 -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> <4C98D525.1030808@oracle.com> <1285148838.2211.60.camel@bit>
In-Reply-To: <1285148838.2211.60.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: Wed, 22 Sep 2010 17:12:22 -0000

On 09/22/10 02:47 AM, Javier Ubillos wrote:

>> 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.
>
> So, there are changes to the protocol(s).
> TCP: Applications now bind to a name+service rather than an IP+port.
> This is an API change, the workings under the hood can and AFAIKT should
> remain unchanged.

But there is also the TCP behavior change associated with connection 
establishment, where AFAICT TCP receives a SYN from IPa to IPb, but is 
supposed to create a TCB from NAMEa to NAMEb.
That is the part I'd like to understand better, and the draft doesn't 
have anything about it.

> There is a change coming soon to the draft. Where the name-exchange
> becomes an optional component.

That still doesn't answer how TCP connection setup would work - in fact 
it raises more questions about how it could work.

> So, a potential SYN-flood.
> We do need to deal with this.
> One way of doing this could be to simply not use the name-resolution
> requirement for a FQDN-name exchange, just as we do when we use a nonce
> or an arbitrary label, it becomes a simple session identifier.
>
> I would prefer to find a way of allowing it, without a blocking
> hand-shake or, ofcourse, opening up to an attack. I guess this would be
> an item for a potential future WG.

It would be good to have some idea that nbs can be made to work. I guess 
we can always say that if shim6 (using names as ULID) is done first, 
then TCP can run using the names (or hashes of names) after that. Such 
an approach is suboptimal, but it at least provides an existence proof 
of a solution, which means that we can have a WG go look at ways to make 
it perform better.

> Movement is, in the name-based sockets + shim6, handled by shim6.
> The shim6 handshake is performed out-of-band. Before that is done, no
> mobility/multi-homing is available. Shim6 deals with validation. We do
> add locators to be tested found in DNS, but AFAIKT shim6 deals with this
> nicely, and yes, we cannot trust DNS to that extent.
> If it is the case that shim6 does not deal with this as I expected, then
> we'll have to find a way to do it. E.g. that shim6 (if it already
> doesn't) has a validation process for each new locator which has not
> been inserted by vanilla-shim6 it self.

Sure, shim6 does that already.

The issues are around how nbs and shim6 fit together; the devil is in 
the details ;-)

I still don't see how using names like 81.228.146.129.in-addr.arpa in 
nbs solves any problem, since they can't be secured AFAICT.

    Erik