[nbs] Some comments on draft-ubillos-name-based-sockets-03

Georg Wittenburg <georg.wittenburg@inria.fr> Mon, 21 March 2011 16:04 UTC

Return-Path: <georg.wittenburg@inria.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 CFB643A6886 for <nbs@core3.amsl.com>; Mon, 21 Mar 2011 09:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 uMOaNhfpl39q for <nbs@core3.amsl.com>; Mon, 21 Mar 2011 09:04:31 -0700 (PDT)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 61EEC3A6881 for <nbs@ietf.org>; Mon, 21 Mar 2011 09:04:31 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.63,219,1299452400"; d="scan'208";a="90846215"
Received: from sphinx.lix.polytechnique.fr (HELO marlin.localnet) ([129.104.11.1]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2011 17:06:02 +0100
From: Georg Wittenburg <georg.wittenburg@inria.fr>
Organization: INRIA
To: nbs@ietf.org
Date: Mon, 21 Mar 2011 17:06:00 +0100
User-Agent: KMail/1.13.5 (Linux/2.6.37-2-686; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201103211706.01105.georg.wittenburg@inria.fr>
Subject: [nbs] Some comments on draft-ubillos-name-based-sockets-03
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, 21 Mar 2011 16:04:32 -0000

Hi all!

I'm interested in name-based sockets as a way to support distributed services 
in ad hoc networks (see http://cst.mi.fu-berlin.de/projects/SPi/ for details).

After carefully reading draft-ubillos-name-based-sockets-03 [ubillos-03], 
draft-xu-name-shim6-00 [xu-00], Christian Vogt's "Simplifying Internet 
Applications Development With A Name-Based Sockets Interface" 
[vogt_simplifying], and parts of the mailing list archives, here are some 
high-level comments on the current draft. I apologize if some of these issues 
have been raised and discussed previously.

In Sec. 3.2 of [ubillos-03] (or somewhere nearby), it would be helpful to put 
the approach taken with NBS in the general context of work done by the LISP 
working group (chartered "to decouple locators and identifiers [...]"). It 
should be pointed out in how far the NBS approach is complimentary to this 
work.

The "complete feature set" mentioned in Secs. 3.5 and 4. should be defined 
somewhere (possibly in Sec. 3.1).

Sec. 4. of [ubillos-03] does not (yet?) cover the method for DNS name 
verification as proposed in [vogt_simplifying, Sec. "Initial Name 
Notification"]. If this methods -- which relies on a DNS lookup -- is to be 
included in the draft, then clarification is needed how to handle the initial 
data packets while the lookup is in progress. Passing them to the application 
opens a window for attack; delaying them until the lookup completes introduces 
delays in connection setup.

More generally, Sec. 3.4 states that "the responding host does not need to do 
any reverse-DNS resolution (explained below)." Hence, the packets exchanged as 
part of the NBS connection setup would be the only source for the name-to-
address mapping at the responding host. If this mapping is not externally 
verified, then it should be made clear somewhere (possibly in Sec. 6) that 
implementations must not use this information outside of the context of the 
current connection.

A motivation should be given why Secs. 4.2 and 4.3 are within the scope of the 
document. Service naming and transport selection has per se nothing to do with 
host identification.

In Sec. 5., the proposed API differs significantly from the BSD/POSIX socket 
interface. Functions such as socket(), bind(), and connect() are absent while 
the signatures of other functions differ from the standard.

Finally, [xu-00] proposes in Sec. 4.1.2 to "internally represent the name as a 
128-bit MD5-hash and use this MD5-hash as the [identifier]". If a 128-bit 
identifier is regarded as advantageous with regard to compatibility, e.g., with 
IPv6 and/or the work of the LISP WG, then one should think about whether or 
not to include this in [ubillos-03]. This may, however, have side-effects on 
the connection setup process.

I hope this is helpful. Maybe we get a chance to discuss these points in more 
detail at IETF80.

Regards,

	Georg

-- 
Dr. Georg Wittenburg
Postdoctoral Researcher
INRIA / École Polytechnique, HIPERCOM Team
Laboratoire d'Informatique de l'École Polytechnique (LIX)
Route de Saclay, 91128 Palaiseau (CEDEX)
Phone: +33-(0)1-69334126, Fax: +33-(0)1-69334044
http://www.lix.polytechnique.fr/~wittenburg/