Re: [nbs] NBS and TCP connection identification
Erik Nordmark <erik.nordmark@oracle.com> Fri, 01 October 2010 16:38 UTC
Return-Path: <erik.nordmark@oracle.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 BB8A43A6C19 for <nbs@core3.amsl.com>; Fri, 1 Oct 2010 09:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.355
X-Spam-Level:
X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, 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 rvIpPF4PERyE for <nbs@core3.amsl.com>; Fri, 1 Oct 2010 09:38:31 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AEB023A6F73 for <nbs@ietf.org>; Fri, 1 Oct 2010 09:38:27 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o91GcB0J031984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Oct 2010 16:38:12 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o919vvRD001618; Fri, 1 Oct 2010 16:38:10 GMT
Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 654865091285951030; Fri, 01 Oct 2010 09:37:10 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Oct 2010 09:37:06 -0700
Message-ID: <4CA60E4B.9050803@oracle.com>
Date: Fri, 01 Oct 2010 09:37:31 -0700
From: Erik Nordmark <erik.nordmark@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100817 Lightning/1.0b2 Thunderbird/3.1.1
MIME-Version: 1.0
To: Javier Ubillos <jav@sics.se>
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> <1285148838.2211.60.camel@bit> <4C9A38A1.9060307@oracle.com> <1285251552.2225.109.camel@bit>
In-Reply-To: <1285251552.2225.109.camel@bit>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Christian Vogt <christian.vogt@ericsson.com>, 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: Fri, 01 Oct 2010 16:38:36 -0000
On 09/23/10 07:19 AM, Javier Ubillos wrote: > Ok, I see your point. > I'm going to try to make some time to describe this bit better. > I'll have to get back to you on it. > I think the threat analysis is a good case for a potential WG. > > One option could be > Drop the resolution on the responder side. > Let the TCB creation be limited in the same way(s) as for 'normal IP'. > Hence, do not imply anything with the name other than as a session > identifier. > Later on, when some feature requires some authentication of the name (as > proposed in draft-xu-name-shim6-00), authentication (resolution) is done > out-of band. > > Consequences: > No blocking or delaying resolution. > No security initially, simply a session identifier. > > Does this make sense? Somewhat, but there are two parts to it; what do things look like at the API, and how would TCP work. If we look at the API, in the case when the application doesn't ask for the name (i.e., no name returned in accept, getpeername, or recvfrom) then clearly from the application's perspective there isn't any need to verify the binding of the name. However, if the peer is using NBS and the application does ask for a name at the API, should that trigger a name verification? The alternative would be to return a name like 81.228.146.129.in-addr.arpa, which the application can at least use to return traffic back to the peer. One could envision a way to have the application specified whether it wants a .arpa name, or a verified 'bob.example.com' name back. But none of that helps TCP AFAICT. When a SYN arrives from 129.146.228.81 with a name bob.example.com, I think the intent is to have the TCB be associated with name name (or some hash of it). Is that correct? If TCP complex the SYN exchange without any verification of the peer's name you'd end up with a TCB with remote name: bob.example.com remote port: 123 remote locators: 129.146.228.81 local name: foo.example.net local port: 80 Suppose we know receive a SYN from port 123 and some other IP address, and also claiming to be bob.example.com. What should TCP do? > I am hesitant to solutions that infer delays in the connection setup. Some perspective on this might be useful. Depending on who you ask you find that the community has thought about or worked on id/locator separation for 30 years, or merely 15 years. As we've discussed this radical change to the architecture, much of the feedback is around "you can't change X", where different folks are concerned about different values of X. The result is that we haven't changed anything, and as a result we've made no progress. It is pretty clear to me that if we want some form of id/locator separation architecture, then some things will change. We definitely have to be cognizant of this and understand the tradeoffs, but starting off with "we can't change X" for any value of X isn't likely to be a good approach. From what I understand from folks at Google a significant part of the "connection setup" is actually the DNS lookup, and for the case of a web browser doing lots of connections there are approaches to 'prefetch' and parallelize that part. Potentially similar approaches can be applied if there is a need to do some validation or other exchanges in an id/locator system. Erik
- Re: [nbs] NBS and TCP connection identification RJ Atkinson
- [nbs] NBS and TCP connection identification Erik Nordmark
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Erik Nordmark
- Re: [nbs] NBS and TCP connection identification Rémi Després
- Re: [nbs] NBS and TCP connection identification Rémi Després
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Rémi Després
- Re: [nbs] NBS and TCP connection identification Erik Nordmark
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Erik Nordmark
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Steven Blake
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Rémi Després
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Erik Nordmark
- Re: [nbs] NBS and TCP connection identification Erik Nordmark
- Re: [nbs] NBS and TCP connection identification David Harrington
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Rémi Després
- Re: [nbs] NBS and TCP connection identification David Harrington
- [nbs] NBS assumptions: What can change?(was: Re: … Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS assumptions: What can change?(was: … Brian E Carpenter
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Jan M
- Re: [nbs] NBS and TCP connection identification Christian Vogt
- Re: [nbs] NBS and TCP connection identification Jan M
- Re: [nbs] NBS and TCP connection identification Rémi Després
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Rémi Després
- Re: [nbs] NBS and TCP connection identification Javier Ubillos
- Re: [nbs] NBS and TCP connection identification Jan M