Re: [nbs] NBS and TCP connection identification

Jan M <jmgm@iki.fi> Thu, 14 October 2010 17:46 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 0EEA93A6B8E for <nbs@core3.amsl.com>; Thu, 14 Oct 2010 10:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6]
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 I0PyW2Cr2xUt for <nbs@core3.amsl.com>; Thu, 14 Oct 2010 10:46:13 -0700 (PDT)
Received: from smtp.melen.org (foxgw.melen.org [84.20.145.65]) by core3.amsl.com (Postfix) with ESMTP id C36183A6B8D for <nbs@ietf.org>; Thu, 14 Oct 2010 10:46:12 -0700 (PDT)
Received: from smtp.melen.org (wolfxx123.shadow.melen.org [192.168.1.251]) by smtp.melen.org (Postfix) with ESMTP id 8ADC3314D4A3; Thu, 14 Oct 2010 17:47:28 +0000 (UTC)
Received: from [IPv6:::1] (unknown [IPv6:2001:1bc8:101:f200::25]) by smtp.melen.org (Postfix) with ESMTP id F1FB1314D491; Thu, 14 Oct 2010 17:47:27 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-38--466398822
From: Jan M <jmgm@iki.fi>
In-Reply-To: <1287070131.2253.92.camel@bit>
Date: Thu, 14 Oct 2010 20:47:26 +0300
Message-Id: <BD5AB885-66D1-4E39-AA45-2A524C3B1245@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> <383DC7DE-389D-471E-8402-3B5816880F55@iki.fi> <7C1C5C58-BE14-48E7-AFAA-9ECEDE3B2441@ericsson.com> <BC6EB98A-5DB8-4E9E-8FE3-3BB56D048850@iki.fi> <1287070131.2253.92.camel@bit>
To: Javier Ubillos <jav@sics.se>
X-Mailer: Apple Mail (2.1081)
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: Christian Vogt <christian.vogt@ericsson.com>, "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: Thu, 14 Oct 2010 17:46:15 -0000

Hi,

See the question at the bottom....

On Oct 14, 2010, at 6:28 PM, Javier Ubillos wrote:

> On Thu, 2010-10-14 at 08:45 +0300, Jan M wrote:
>> Hi Christian,
>> 
>> On Oct 13, 2010, at 9:19 PM, Christian Vogt wrote:
>> 
>>>> 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?
>>> 
>>> Yes, if DHCP hands out the same IP address to different hosts sequentially, and if those hosts are both legacy, the hosts' synthesized names will look the same.  But this is in line with the semantics of a synthesized name:  A synthesized name refers to the host that used the encoded IP address at the time of session initiation.  By implication, synthesized names are good only throughout a session -- for session identification across address changes.  Synthesized names cannot be used to re-identify a host across sessions.
>>> 
>>> Does this make sense?
>> 
>> Actually I don't see how this could work for either session identification. If the host initiates the session with RFC1918 address behind the NAT then the peer sees synthesized name NAT.in-addr.arpa and client thinks it is RFC1918.in-addr.arpa. Now it tries to use this name on the other interface it has and it sends to the peer "Hi, I'm RFC1918.in-addr.arpa I would like to add V.X.Y.Z. address to the existing RFC1918.in-addr.arpa session" but the peer has only session NAT.in-addr.arpa so it wont be able to identify the session or am I missing something? So I guess you need some network support to resolve that the name of the session is actually NAT.in-addr.arpa not RFC1918.in-addr.arpa?
>> 
>> Additionally the session identification comes even more complex when you have multiple hosts behind the as not all can identify themselves as NAT.example.com or how do you plan to avoid situation where multiple hosts are saying that "Hi I'm NAT.in-addr.arpa and I would like to add address to address on port 80" so how would the peer know which session to associate new address as the source port is probably not usable as you can't count on it to be same all session to be added?
> 
> 
> Consider the synthesized name an arbitrary label. Completely irrelevant
> for the communication.
> 
> Assume that host A is behind a NAT,
> and assume that we're talking TCP.
> 
> Host A has  |  Host B has
> IP(A)       |  IP(B)
> Port(A)     |  Port(B)
> Name(A)     |  Name(B)
> 
> When Host A sends a packet to B, and only receives Bs address in a
> literal manner, the packet on the network is still sent to
> IP(B):TcpPort(B). The names Name(A) & Name(B) are added in an extension
> header, but for the network, it is considered payload only.
> 
> When it arrives at Host B, Name(A) will be used as a sessionlabel with
> no particular semantics. The label will never be derived to an IP, hence
> there is no risk that the IP changes owner. This is all managed by
> name-based sockets (e.g. by the shim6 extension).
> 
> Conversely, when the reply from Host B to A is sent, it follows normal
> IP+NAT protocol. The names are, from a network perspective, just
> payload.
> 
> What _could_ be an issue to be solved, is what happens when labels
> collide. But I don't think this will be a major problem, as long as each
> socket is well isolated from other sockets.


Are you saying that the labels wouldn't be derived from the addresses? Earlier Christian said that they would? If not then how do you generate the label and ensure that it is unique enough? Is the label a hash of something or what are the semantics? 

Is the plan to generate this session label also in the case where the peer has a FQDN or not? If not then again I guess that would mean that you have two different ways of naming sockets depending whether the FQDN was know or not when the socket was bound?

    Jan