[nbs] NBS and TCP connection identification

Erik Nordmark <erik.nordmark@oracle.com> Mon, 20 September 2010 22:00 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 1C3C63A67B6 for <nbs@core3.amsl.com>; Mon, 20 Sep 2010 15:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.349
X-Spam-Level:
X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 W9lehHDUTqxC for <nbs@core3.amsl.com>; Mon, 20 Sep 2010 15:00:45 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3251A3A677E for <nbs@ietf.org>; Mon, 20 Sep 2010 15:00:45 -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 o8KM17aG011032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nbs@ietf.org>; Mon, 20 Sep 2010 22:01:08 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 o8KD3E5l016843 for <nbs@ietf.org>; Mon, 20 Sep 2010 22:01:06 GMT
Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 621081751285020055; Mon, 20 Sep 2010 15:00:55 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 Sep 2010 15:00:54 -0700
Message-ID: <4C97D9A8.2050001@oracle.com>
Date: Mon, 20 Sep 2010 15:01:12 -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: nbs@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [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: Mon, 20 Sep 2010 22:00:47 -0000

I'm quite intriqued by name-based sockets, but I don't understand how 
things are supposed to work.
I've read draft-ubillos-name-based-sockets-03.txt and 
draft-xu-name-shim6-00.txt, but some aspects appear to be missing.

Does with NBS what identifies a TCP connection? Today it is identified 
by a pair of IP addresses and port numbers, but that wouldn't work with 
NBS since we want the TCP connection to survive renumbering the IP 
addresses. Is the intent that the connection be identified by a pair of 
names? By fixed-length hashes of the names?

What are the security issues introduced by the additional name mapping? 
(Part of that answer depends on how TCP connections are identified.) It 
might be useful to review RFC 4218 and see what threats apply to NBS.

In name-shim6-00.txt there is a suggestion to communicate the names in 
NBS, and then in addition communicate the names (or MD5-hashes of the 
names) in shim6. That seems to be overkill.


Instead of a nonce as a name I think it makes more sense to use a 
crypto-based identifier (see
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.139.4051&rep=rep1&type=pdf). 
Such a name/ID means that even a host which does not have a FQDN can 
benefit from multihoming and mobility using NBS without introducing any 
security issues.

    Erik