Re: [nbs] NBS and TCP connection identification

Christian Vogt <christian.vogt@ericsson.com> Tue, 21 September 2010 01:15 UTC

Return-Path: <christian.vogt@ericsson.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 211823A68BB for <nbs@core3.amsl.com>; Mon, 20 Sep 2010 18:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Djd8RfVwboIa for <nbs@core3.amsl.com>; Mon, 20 Sep 2010 18:15:15 -0700 (PDT)
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by core3.amsl.com (Postfix) with ESMTP id 845BF3A6893 for <nbs@ietf.org>; Mon, 20 Sep 2010 18:15:14 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id D30CF48D; Mon, 20 Sep 2010 21:15:33 -0400 (EDT)
Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 20 Sep 2010 21:15:33 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=xI8bNVO6SkZbmGLbttK4JG9ppnw=; b=IPoZ61JQffDQQVYW6qVlxE5chSrkRzLRLYX/7SkXtw5hWYpCJ4VO/8OgcVgNPHZ8hW4G2YpeIM8s7B1dpjzru7YG43WtUn8qDqR/lreO+fTb/OUpZkJKJjBn6ERcmgAjVqSBPOzCTtBAKLs1tJFRJMOQglpokSvfz96v8Q9/c8c=
X-Sasl-enc: 11x7Dm/Fx7Qpnzh86jPe0jqzm/v71V6SpDIHPhO+MvDU 1285031733
Received: from [10.0.1.2] (adsl-76-192-129-50.dsl.pltn13.sbcglobal.net [76.192.129.50]) by mail.messagingengine.com (Postfix) with ESMTPSA id 48D5840A4D8; Mon, 20 Sep 2010 21:15:33 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Christian Vogt <christian.vogt@ericsson.com>
In-Reply-To: <4C97D9A8.2050001@oracle.com>
Date: Mon, 20 Sep 2010 18:15:29 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com>
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 01:15:27 -0000

Hi Erik:

Thanks for reviewing both documents.  A few comments; Javier will fill in the rest.

- You are right that TCP connections will be identified by a pair of DNS names.  Implementation-wise, this could be realized by hashing the DNS names into 128-bit strings.  Then, a TCP-for-IPv6 implementation could pretty much be reused.

- Security-wise, the idea is to bind DNS names to IP addresses by means of a forward lookup in the DNS.  This gives the same level of security that we have for DNS-based applications today, except that the forward lookup would not just be done by the connection initiator, but also by the connection responder.  Where higher security is required, we recommend DNSSEC.  Thus we can avoid extra cryptographic identifiers.

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

Does this make sense?

So long,
- Christian



You wrote:

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