Re: [nbs] NBS and TCP connection identification

Rémi Després <remi.despres@free.fr> Tue, 21 September 2010 08:28 UTC

Return-Path: <remi.despres@free.fr>
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 64C233A692A for <nbs@core3.amsl.com>; Tue, 21 Sep 2010 01:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.297
X-Spam-Level:
X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 eMzUnfk6+RGc for <nbs@core3.amsl.com>; Tue, 21 Sep 2010 01:28:56 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id C38893A67FA for <nbs@ietf.org>; Tue, 21 Sep 2010 01:28:55 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2122.sfr.fr (SMTP Server) with ESMTP id D8C1C7000094; Tue, 21 Sep 2010 10:29:18 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2122.sfr.fr (SMTP Server) with ESMTP id 730E27000092; Tue, 21 Sep 2010 10:29:18 +0200 (CEST)
X-SFR-UUID: 20100921082918471.730E27000092@msfrf2122.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <4C97D9A8.2050001@oracle.com>
Date: Tue, 21 Sep 2010 10:29:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C99E120C-F1B5-4AE5-B75C-BF3AA209C76B@free.fr>
References: <4C97D9A8.2050001@oracle.com>
To: Erik Nordmark <erik.nordmark@oracle.com>
X-Mailer: Apple Mail (2.1081)
Cc: 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 08:28:57 -0000

Le 21 sept. 2010 à 00:01, Erik Nordmark a écrit :

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

In my understanding, this is what is consistent and clean.
For this, a TCP option seems appropriate, to convey to the server the source the destination names used by the client (when they exist).
Thus, servers may query to the direct DNS (rather than the reverse DNS) to validate the names of connection initiators. 
In the absence of such names, applications that need to identify where connections come from can refuse them.

RD 




> 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
> 
> 
> _______________________________________________
> nbs mailing list
> nbs@ietf.org
> https://www.ietf.org/mailman/listinfo/nbs