Re: [nbs] NBS and TCP connection identification

Christian Vogt <christian.vogt@ericsson.com> Mon, 04 October 2010 21:54 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 BABD13A6DB7 for <nbs@core3.amsl.com>; Mon, 4 Oct 2010 14:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.973
X-Spam-Level:
X-Spam-Status: No, score=-102.973 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, 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 cYFqq8EVC+oN for <nbs@core3.amsl.com>; Mon, 4 Oct 2010 14:54:26 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id A1D943A6CB6 for <nbs@ietf.org>; Mon, 4 Oct 2010 14:54:26 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o94LtMCY002463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Oct 2010 16:55:22 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.166]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 4 Oct 2010 17:55:21 -0400
From: Christian Vogt <christian.vogt@ericsson.com>
To: Erik Nordmark <erik.nordmark@oracle.com>
Date: Mon, 4 Oct 2010 17:55:19 -0400
Thread-Topic: [nbs] NBS and TCP connection identification
Thread-Index: ActkDtcR+/Fiaa4iSxWot7v8an5qhA==
Message-ID: <F5C12553-5CD1-4325-8103-E85BA1D3EF47@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> <DC2EB1A1-B9BE-49B0-B443-B513873B9AF2@ericsson.com> <4CA6062B.2000903@oracle.com>
In-Reply-To: <4CA6062B.2000903@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, 04 Oct 2010 21:54:27 -0000

Erik wrote:

>> 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.
> 
> Explain to me how that can be used to secure the binding between the *name* and an IP address.
> 
> I understand the Mobile-IP approach to secure a binding between two IP addresses, but that isn't the problem that NBS needs to solve.


Erik:

My email above was on verifying an address update, not on verifying a name-to-address binding.  I envision the latter to be secured in one of the following ways:

(1) The recipient operating system verifies the initiator's name by means of a forward DNS lookup.  If and only if the initiator's name is correct, it is delivered to the recipient application.  In an overload situation, the recipient operating system may instead deliver an address-derived DNS name to the recipient application.  This can serve as an identifier for the initiator throughout the session, even across address changes.

(2) Like (1), but with DNSSEC instead of DNS.  Whether to use DNSSEC is a local deployment question.

(3) The recipient operating system always delivers an address-derived DNS name for the initiator to the recipient application.  The recipient application can be provided with an API function to discover the initiator's true name, and have this verified, if so desired.

(4) The recipient operating system always delivers the initiator's name without verification to the recipient application.  The recipient application can be provided with an API function to have the initiator's name verified, if so desired.

What would be your preference among (1) through (4)?  I would be interested in your opinion.

- Christian