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