Re: [nbs] NBS and TCP connection identification

Javier Ubillos <> Thu, 14 October 2010 12:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43F5F3A68F8 for <>; Thu, 14 Oct 2010 05:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=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 p69wF2c+5Hbu for <>; Thu, 14 Oct 2010 05:06:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C65483A6986 for <>; Thu, 14 Oct 2010 05:06:38 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id B28AE40008; Thu, 14 Oct 2010 14:07:54 +0200 (CEST)
From: Javier Ubillos <>
To: Erik Nordmark <>
In-Reply-To: <>
References: <> <> <> <1285067950.2068.59.camel@bit> <> <1285148838.2211.60.camel@bit> <> <1285251552.2225.109.camel@bit> <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ilUqP/vZjzS5t+LdZlD2"
Date: Thu, 14 Oct 2010 14:07:53 +0200
Message-ID: <1287058073.2253.81.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, 14 Oct 2010 12:06:40 -0000

Hi Erik, please excuse me for taking so long to answer.

On Fri, 2010-10-01 at 09:37 -0700, Erik Nordmark wrote:
> 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, 
> 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 '' name back.
> But none of that helps TCP AFAICT.
> When a SYN arrives from with a name, 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:
> 	remote port: 123
> 	remote locators:
> 	local name:
> 	local port: 80
> Suppose we know receive a SYN from port 123 and some other IP address, 
> and also claiming to be
> What should TCP do?

How to prevent SYN-floods.
I.e. how should a syn-cookie work with name-based sockets.

I don't have a great solution for this (yet).
These are the lines of thought I have followed so far.

a. Let the 24bit hash which previously included srcIP, dstIP, srcPort
and dstPort also include srcName and dstName.
This means that a single host, which before could create 65k cookies by
changing the source-port (assuming no IPspoofing) can now create
Not entirely true, there are only 24bits for the result of the hash, so
in essence, it would be 2^24 (about 16M). It is still not a good

b. Don't change anything.
If a packet from IP(B), PORT(B1), NAME(B1) comes, a normal TCP handshake
is done.
If another packet arrives from IP(B), PORT(B1), NAME(B2) within the same
64time frame, the cookie should still be there, and a connection will be
immediatly accepted.
We don't have the same problem with saturating the
syn-cookie-hash-space. But now all of a sudden, a single malicious host
can create 2^(255*8) TCBs. Not cool.

c. Don't let a single IP+port map to multiple TCBs.
In other words, don't make the name part of the TCP-internal tuple.
We'll still let the application bind to a name, but internally to TCP,
this would simply be an indirection to a IP+port 4-tuple.
This is not architecturally clean, but I believe this is the most viable
way to go.

I would very much appreciate more comments on this as I think this is
one of those details where Mr.Devil resides, and we need to find an
acceptable solution.

// Javier