Re: [nbs] NBS and TCP connection identification

Rémi Després <remi.despres@free.fr> Tue, 05 October 2010 08:07 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 9F4083A6D98 for <nbs@core3.amsl.com>; Tue, 5 Oct 2010 01:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.427
X-Spam-Level:
X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=0.522, 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 gxwyDn4W31xM for <nbs@core3.amsl.com>; Tue, 5 Oct 2010 01:07:32 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id 328963A6BF0 for <nbs@ietf.org>; Tue, 5 Oct 2010 01:07:32 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 61422700009A; Tue, 5 Oct 2010 10:08:28 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id B3056700009F; Tue, 5 Oct 2010 10:08:27 +0200 (CEST)
X-SFR-UUID: 20101005080827733.B3056700009F@msfrf2109.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <CD376A37-C756-47E5-BBC7-205595F523AB@ericsson.com>
Date: Tue, 5 Oct 2010 10:08:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3056CB3-DDD3-4B13-A80F-552350031FEF@free.fr>
References: <4C97D9A8.2050001@oracle.com> <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com> <4C9826D0.2060703@oracle.com> <1285067950.2068.59.camel@bit> <4C98D525.1030808@oracle.com> <DC2EB1A1-B9BE-49B0-B443-B513873B9AF2@ericsson.com> <EBB53DE6-2EEB-43C2-9451-0A38EBD10BAA@free.fr> <CD376A37-C756-47E5-BBC7-205595F523AB@ericsson.com>
To: Christian Vogt <christian.vogt@ericsson.com>
X-Mailer: Apple Mail (2.1081)
Cc: "nbs@ietf.org" <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, 05 Oct 2010 08:07:33 -0000

Hi Christian,

Sorry for so late an answer.
More below.

 
Le 29 sept. 2010 à 20:47, Christian Vogt a écrit :

> 
> Remi wrote:
> 
>> In my understanding NBS and address changes can remain independent, and therefore should remain so.
>> - A connection initiation starts with the source and destination names chosen by the initiator (and with valid addresses for them at that time).
>> The acceptor advertises at the NBS the names it received.
>> It may have before that checked, with a direct a DNS query, that source address and source name are consistent, or do it after signaling the incoming connection, or never, at its own choice. 
>> - Shim6, if present, works as before.
>> 
>> Does this make sense to you?
> 
> 
> I think it does.  So let me summarize:  
> 
> You are proposing that the responder should present the initiator's name as received to the responding application, without verification.  It is then up to the responding application to verify the initiator's name if needed.  Correct?

To be more precise, the proposal could be:
- For backward compatibility, the API permits the application to indicate whether or not it wants, for incoming connections, names at the API (by default, it doesn't).
- If it does, it also indicates whether it wants name-address consistencies, for sources and/or destinations, to be checked BEFORE or AFTER signaling the incoming connection at the API.
- For source names that are are provided in connection-initiating packets, direct DNS lookups are sufficient. Otherwise, reverse lookups are necessary.

RD


> Needless to say, if the initiator does not provide a name -- e.g., because it does not have a name registered in the DNS --, the responder would generate a name for the initiator based on the initiator's IP address.  Such a "synthesized" name does not have to be verified; it already provides the same level of security that we have today.

It isn't clear to me that synthesized names are needed. 
NBS APIs could instead continue to provide, in their binary format, addresses found in session originating packets, and let application ignore them if they aren't interested.


> 
> Is this summary accurate?
> 
> - Christian
>