Re: [nbs] NBS and TCP connection identification

Rémi Després <remi.despres@free.fr> Tue, 28 September 2010 09:39 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 C21633A6C31 for <nbs@core3.amsl.com>; Tue, 28 Sep 2010 02:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.374
X-Spam-Level:
X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001]
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 rVixeROdITkj for <nbs@core3.amsl.com>; Tue, 28 Sep 2010 02:39:54 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by core3.amsl.com (Postfix) with ESMTP id 7D5D43A6C43 for <nbs@ietf.org>; Tue, 28 Sep 2010 02:39:54 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id 07DA5700008C; Tue, 28 Sep 2010 11:40:35 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id 8D3067000088; Tue, 28 Sep 2010 11:40:34 +0200 (CEST)
X-SFR-UUID: 20100928094034578.8D3067000088@msfrf2316.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: <DC2EB1A1-B9BE-49B0-B443-B513873B9AF2@ericsson.com>
Date: Tue, 28 Sep 2010 11:40:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EBB53DE6-2EEB-43C2-9451-0A38EBD10BAA@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>
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, 28 Sep 2010 09:39:56 -0000

Hi Christian,

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?

RD


Le 28 sept. 2010 à 00:20, Christian Vogt a écrit :

> 
> Erik Nordmark wrote:
> 
>> How do you secure the movement in that case?
>> Suppose the client has IP address 129.146.228.81, thus the server would 
>> see the client as having name 81.228.146.129.in-addr.arpa.
>> Then the client switches to being on IP address 36.1.2.3. How can you 
>> know that it is indeed the same client so that it is secure for the 
>> server to start sending the packets to 36.1.2.3?
>> You can't rely on DNS validation (unless you assume that the client can 
>> update the DNS records for 81.228.146.129.in-addr.arpa, which is very 
>> unlikely.)
>> Thus how do you secure this?
> 
> 
> Erik,
> 
> a way to secure IP address changes without the help of Shim6 would be the following:
> 
> - Exchange a randomly generated token at the old IP address.
> 
> - Verify the peer's knowledge of this token at the new IP address.
> 
> - Upon successful verification, associate the peer's new IP address with the peer's DNS name, which happens to encode the IP address that the peer had used during session initiation.
> 
> This procedure would be very similar to the Mobile IPv6 care-of address check.
> 
> - Christian
> 
> _______________________________________________
> nbs mailing list
> nbs@ietf.org
> https://www.ietf.org/mailman/listinfo/nbs