[nbs] To verify or not to verify a name. (Was: Re: NBS and TCP connection identification)

Javier Ubillos <jav@sics.se> Fri, 22 October 2010 14:51 UTC

Return-Path: <jav@sics.se>
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 673783A6934 for <nbs@core3.amsl.com>; Fri, 22 Oct 2010 07:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.845
X-Spam-Level:
X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_SE=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 cJBMzYX+IJeH for <nbs@core3.amsl.com>; Fri, 22 Oct 2010 07:50:59 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 4CB073A692C for <nbs@ietf.org>; Fri, 22 Oct 2010 07:50:59 -0700 (PDT)
Received: from [193.10.66.63] (bit.sics.se [193.10.66.63]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 0338E40313; Fri, 22 Oct 2010 16:52:36 +0200 (CEST)
From: Javier Ubillos <jav@sics.se>
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-a98f7rY3h7gxqnNMhxcF"
Date: Fri, 22 Oct 2010 16:52:27 +0200
Message-ID: <1287759147.2189.463.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Cc: Christian Vogt <christian.vogt@ericsson.com>, "nbs@ietf.org" <nbs@ietf.org>
Subject: [nbs] To verify or not to verify a name. (Was: Re: 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: Fri, 22 Oct 2010 14:51:00 -0000

Hi Rémi.

Some food for thought...

In the e-mail below and an earlier one by Christian Vogt, I think we
have touched a subject witch might be decisive for the whole discussion
about synthesized names.

Rémis e-mail:
http://www.ietf.org/mail-archive/web/nbs/current/msg00036.html
Christians e-mail:
http://www.ietf.org/mail-archive/web/nbs/current/msg00034.html


The issue is basically:
From which point does a name matter?

The options I see are.
1) Should the name->ip relation be authenticated.
2) If it should, when
2a) When the connection is setup
2b) When some particular network-feature which needs it requests it
(example below)

Let's use the current name-based shim6 as a scenario:
Assuming that the server accepts connections w/o filtering on names or
IPs

* In the initial connection setup, names are not too interesting. What
is important is to locally have a session identifier.
This is simply a legacy point-to-point communication with no fancy
features.

* The name-based shim6 heuristic kicks in, and locators are now
negotiated. In this step, it becomes important to have a name which is
resolvable to a locator (or multiple). The service suggested in the
draft is DNS. (should it fail, the current implementation still allows
situations where one host moves, but not the simultaneous-move
scenario).

Not until this point does it matter that we give the remote peer a
functional name. So, until now, no authing is needed.

What I'm getting at is that if this kind of decision-tree is OK, then we
arrive at a point where the whole ordeal of synthesized names.
It becomes a non-issue.


123456789012345678901234567890123456789012345678901234567890123
                   |    Has a FQDN     |   Does not have FQDN
-------------------+-------------------+------------------------
Do not require     |    Fine           |   Fine
initially auth     |                   |
-------------------+-------------------+------------------------
Do require         |   Lookup in       |   n/a or
initial auth       |   DNS (-SEC?)     |   get a name
-------------------+-------------------+------------------------
Particular feature |   Out of band     |   n/a or
requires auth      |   negotiation     |   get a name
-------------------+-------------------+------------------------

I'm not a stranger to the thought of NBS not doing any verifications at
all, leaving that to sub-features and to the applications. Very much as
DNS-dependent applications do today. But this needs to be discussed (at
the BoF ?)

// Javier