Re: [nbs] NBS and TCP connection identification

[Javier Ubillos <[e-mail]>]

Erik.
Thanks for this feedback it is very valuable to me :)

On Tue, 2010-09-21 at 08:54 -0700, Erik Nordmark wrote:
> On 09/21/10 04:19 AM, Javier Ubillos wrote:
> 
> > Perhaps I misunderstand your concern, but I'll try to answer.
> > On the individual host, there is a change to the implementation in the
> > sense that the 4-tuple is now
> > name, service (port), name service(port)
> > instead of the prevous
> > ip, port, ip port.
> >
> > There are no changes to the "on the wire" protocol.
> 
> In my book "protocol" = "packet formats" + "behavior".

Agreed.

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

IP: An optional change (I'll get back to why it is optional) is to
perform the name exchange. This means adding and extension header.
It _might_ also mean that the respondent wants to do a reverse DNS
resolution. And yes, this is an area we need to explore further, more
about it below.

> > There are two ways of doing this.
> > 1. Hashing the name into something that fits into the ip-address field.
> > 2. Having a specialized TCP implementation.
> >
> > I promote alternative 2.
> > In fact, we already have that bit working in the prototype.
> 
> Please correct me if I'm wrong, but you are proposing that when TCP 
> receives a SYN packet it checks if the packet has the IP 
> option/extension to carry a name, and if so creates the TCB for the 
> name/port 4-tuple, whereas if the name is not present the TCB would be 
> for the IP/port 4-tuple.
> 
> That requires some care, and I don't understand how you propose to apply 
> this to UDP.

There is a change coming soon to the draft. Where the name-exchange
becomes an optional component.

This still mean that we have an opening for a potential SYN-flood.
(more below :)

> > Hmmm, you might have a point here.
> > We're going to have to consider this more.
> >
> > There are two ideas on the table:
> > a) Do nothing.
> > b) When receiving a name in an option, resolve that name and compare
> > IP's with the just received IP.
> >
> > Case a) _will_ happen if the name is not a resolvable FQDN.
> > Case b) ... perhaps this is an issue we need to look at.
> > I need to do some readingup on the subject.
> 
> As I said, doing b) on the SYN is opening a huge DoS attack opportunity.
> 
> FWIW I know how to avoid this complexity if we reuse the shim6-style 
> exchange from the start (with ULID replaced by the name). The I1/R1 
> exchange does the initial exchange, and on I2 (which can also carry the 
> TCP SYN I guess) the receiver can do the DNS lookup with less of a DoS 
> concern. Doing things in that order also ensures that TCP (and UDP) 
> would have a (verified) name when the first packet is received. But that 
> approach has some other downsides.

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.

> >>
> >>> - Hosts that don't have a name registered in the DNS will derive a
> >>> DNS name from their IP address.  This will give them session
> >>> continuity, albeit no reachability.
> >>
> >> But that doesn't allow them to use SHIM6 to move around.
> >> A CBID as a name allows them to move around.
> >
> > It does, in the most primitive scenario, one enters an IP into the
> > name-based socket, and that IP is used just as a label.
> 
> How do you secure the movement in that case?
> Suppose the client has IP address 129.146.228.81, thus the server would 
> see the client as having name 81.228.146.129.in-addr.arpa.
> Then the client switches to being on IP address 36.1.2.3. How can you 
> know that it is indeed the same client so that it is secure for the 
> server to start sending the packets to 36.1.2.3?
> You can't rely on DNS validation (unless you assume that the client can 
> update the DNS records for 81.228.146.129.in-addr.arpa, which is very 
> unlikely.)
> Thus how do you secure this?
> 

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.

// Javier