Re: [nbs] NBS and TCP connection identification

Javier Ubillos <> Thu, 23 September 2010 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 117673A6AAC for <>; Thu, 23 Sep 2010 07:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.86
X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_47=0.6, MIME_QP_LONG_LINE=1.396, NORMAL_HTTP_TO_IP=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u7BKuw1pVE90 for <>; Thu, 23 Sep 2010 07:18:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9A4483A69E5 for <>; Thu, 23 Sep 2010 07:18:45 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 4BF90401EA; Thu, 23 Sep 2010 16:19:13 +0200 (CEST)
From: Javier Ubillos <>
To: Erik Nordmark <>
In-Reply-To: <>
References: <> <> <> <1285067950.2068.59.camel@bit> <> <1285148838.2211.60.camel@bit> <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DxVg+VMsSEtymJpwNRPo"
Date: Thu, 23 Sep 2010 16:19:12 +0200
Message-ID: <1285251552.2225.109.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Cc: Christian Vogt <>,
Subject: Re: [nbs] NBS and TCP connection identification
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Sep 2010 14:18:47 -0000

On Wed, 2010-09-22 at 10:10 -0700, Erik Nordmark wrote:
> On 09/22/10 02:47 AM, Javier Ubillos wrote:
> >> I'd agree there isn't any changes to the TCP packet formats (but you do
> >> have some added IP options/extension headers). But AFAICT there is a
> >> rather profound change to the TCP protocol behavior around connection
> >> establishment.
> >
> > So, there are changes to the protocol(s).
> > TCP: Applications now bind to a name+service rather than an IP+port.
> > This is an API change, the workings under the hood can and AFAIKT should
> > remain unchanged.
> But there is also the TCP behavior change associated with connection 
> establishment, where AFAICT TCP receives a SYN from IPa to IPb, but is 
> supposed to create a TCB from NAMEa to NAMEb.
> That is the part I'd like to understand better, and the draft doesn't 
> have anything about it.

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
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.

No blocking or delaying resolution.
No security initially, simply a session identifier.

Does this make sense?

> > There is a change coming soon to the draft. Where the name-exchange
> > becomes an optional component.
> That still doesn't answer how TCP connection setup would work - in fact 
> it raises more questions about how it could work.
> > So, a potential SYN-flood.
> > We do need to deal with this.
> > One way of doing this could be to simply not use the name-resolution
> > requirement for a FQDN-name exchange, just as we do when we use a nonce
> > or an arbitrary label, it becomes a simple session identifier.
> >
> > I would prefer to find a way of allowing it, without a blocking
> > hand-shake or, ofcourse, opening up to an attack. I guess this would be
> > an item for a potential future WG.
> It would be good to have some idea that nbs can be made to work. I guess 
> we can always say that if shim6 (using names as ULID) is done first, 
> then TCP can run using the names (or hashes of names) after that. Such 
> an approach is suboptimal, but it at least provides an existence proof 
> of a solution, which means that we can have a WG go look at ways to make 
> it perform better.

I am hesitant to solutions that infer delays in the connection setup.

> > Movement is, in the name-based sockets + shim6, handled by shim6.
> > The shim6 handshake is performed out-of-band. Before that is done, no
> > mobility/multi-homing is available. Shim6 deals with validation. We do
> > add locators to be tested found in DNS, but AFAIKT shim6 deals with this
> > nicely, and yes, we cannot trust DNS to that extent.
> > If it is the case that shim6 does not deal with this as I expected, then
> > we'll have to find a way to do it. E.g. that shim6 (if it already
> > doesn't) has a validation process for each new locator which has not
> > been inserted by vanilla-shim6 it self.
> Sure, shim6 does that already.
> The issues are around how nbs and shim6 fit together; the devil is in 
> the details ;-)
> I still don't see how using names like in 
> nbs solves any problem, since they can't be secured AFAICT.

It's not about securing them, but about using them as a session
Consider using a randomly generated string.
Using the canonical ".arpa" is just that with a small difference, it
gives you the information of from where the connection was initiated.
I do admit that this is not a big deal, which is why we wanted to leave
it open.

// Javier