IETF Logo Mail Archive

Re: [nbs] NBS and TCP connection identification

Christian Vogt <christian.vogt@ericsson.com> Mon, 27 September 2010 22:20 UTC

Return-Path: <christian.vogt@ericsson.com>
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 A2A513A69DD for <nbs@core3.amsl.com>; Mon, 27 Sep 2010 15:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.069
X-Spam-Level:
X-Spam-Status: No, score=-103.069 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100]
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 XS-39H+8JKmV for <nbs@core3.amsl.com>; Mon, 27 Sep 2010 15:20:18 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 79EFE3A69B4 for <nbs@ietf.org>; Mon, 27 Sep 2010 15:20:18 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o8RMXjfZ008975; Mon, 27 Sep 2010 17:34:27 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.214]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 27 Sep 2010 18:20:25 -0400
From: Christian Vogt <christian.vogt@ericsson.com>
To: Erik Nordmark <erik.nordmark@oracle.com>
Date: Mon, 27 Sep 2010 18:20:24 -0400
Thread-Topic: [nbs] NBS and TCP connection identification
Thread-Index: Acteki6LJQiDRt6ZRMuG1FMDip/X/Q==
Message-ID: <DC2EB1A1-B9BE-49B0-B443-B513873B9AF2@ericsson.com>
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>
In-Reply-To: <4C98D525.1030808@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 27 Sep 2010 22:20:19 -0000

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

v2.23.0 | Report a Bug | By Email