Re: [nbs] NBS and TCP connection identification

Jan M <jmgm@iki.fi> Tue, 12 October 2010 18:21 UTC

Return-Path: <jmgm@iki.fi>
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 CBB3E3A6A2C for <nbs@core3.amsl.com>; Tue, 12 Oct 2010 11:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 8ixJHKTa0BXc for <nbs@core3.amsl.com>; Tue, 12 Oct 2010 11:21:20 -0700 (PDT)
Received: from smtp.melen.org (foxgw.melen.org [84.20.145.65]) by core3.amsl.com (Postfix) with ESMTP id 2255D3A6A22 for <nbs@ietf.org>; Tue, 12 Oct 2010 11:21:20 -0700 (PDT)
Received: from smtp.melen.org (wolfxx123.shadow.melen.org [192.168.1.251]) by smtp.melen.org (Postfix) with ESMTP id BB97B314D49B; Tue, 12 Oct 2010 18:22:31 +0000 (UTC)
Received: from [IPv6:::1] (unknown [IPv6:2001:1bc8:101:f200::25]) by smtp.melen.org (Postfix) with ESMTP id 647BB314D495; Tue, 12 Oct 2010 18:22:31 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Jan M <jmgm@iki.fi>
In-Reply-To: <C0F28CE9-B47D-416A-907D-394AC2FAF487@ericsson.com>
Date: Tue, 12 Oct 2010 21:22:30 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <383DC7DE-389D-471E-8402-3B5816880F55@iki.fi>
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> <C3056CB3-DDD3-4B13-A80F-552350031FEF@free.fr> <C0F28CE9-B47D-416A-907D-394AC2FAF487@ericsson.com>
To: Christian Vogt <christian.vogt@ericsson.com>
X-Mailer: Apple Mail (2.1081)
X-Virus-Scanned: ClamAV using ClamSMTP
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, 12 Oct 2010 18:21:23 -0000

Hi Christian,

First of all I'm new to the list so maybe this has been asked already but hopefully somebody could clarify also to me.

How will a host with a RFC1918 address be able to synthesize its name or will all RFC1918 hosts have the same name? How will NBS separate these hosts or is it assumed that server will always sees the same name? Or do the end hosts see different names e.g. server sees the synthesized name of NAT and client sees the name of RFC1918?

If there was a host at certain IP A (obtained via DHCP) with synthesized name A when the next host (different) gets the same IP A from DHCP will it have the same name A? What should the peer be able to determine from this name and how will it know that it is different or same instance as the previous?

 Regards,
   Jan

On Oct 12, 2010, at 7:58 PM, Christian Vogt wrote:

> 
> You wrote:
> 
>>> 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.
> 
> Remi:
> 
> The reason why I think we do need synthesized names is because of their semantics:  They name the host that was located at the encoded IP address at the time of session initiation.  Unlike the semantics of an IP address, which can name the host that /currently/ is located at the address, a synthesized name could be stable across a session.
> 
> Does this make sense?
> 
> - Christian
> 
> _______________________________________________
> nbs mailing list
> nbs@ietf.org
> https://www.ietf.org/mailman/listinfo/nbs