Re: [nbs] NBS and TCP connection identification

[Javier Ubillos <[e-mail]>]

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

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
65k*2^(8*255).
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
solution.

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