IETF Logo Mail Archive

Re: [nbs] NBS and TCP connection identification

Christian Vogt <christian.vogt@ericsson.com> Tue, 12 October 2010 16:57 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 307C23A69B9 for <nbs@core3.amsl.com>; Tue, 12 Oct 2010 09:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.751
X-Spam-Level:
X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 IcxOWocsMI8p for <nbs@core3.amsl.com>; Tue, 12 Oct 2010 09:57:20 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 5DD163A69A1 for <nbs@ietf.org>; Tue, 12 Oct 2010 09:57:20 -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 o9CGwWRT032416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Oct 2010 11:58:33 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.27]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 12 Oct 2010 12:58:28 -0400
From: Christian Vogt <christian.vogt@ericsson.com>
To: Rémi Després <remi.despres@free.fr>
Date: Tue, 12 Oct 2010 12:58:26 -0400
Thread-Topic: [nbs] NBS and TCP connection identification
Thread-Index: ActqLrDgBd3EDs7MQ3i2ZU7/u1LXqA==
Message-ID: <C0F28CE9-B47D-416A-907D-394AC2FAF487@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> <EBB53DE6-2EEB-43C2-9451-0A38EBD10BAA@free.fr> <CD376A37-C756-47E5-BBC7-205595F523AB@ericsson.com> <C3056CB3-DDD3-4B13-A80F-552350031FEF@free.fr>
In-Reply-To: <C3056CB3-DDD3-4B13-A80F-552350031FEF@free.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
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: Tue, 12 Oct 2010 16:57:21 -0000

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

v2.23.0 | Report a Bug | By Email