Re: [nbs] NBS and TCP connection identification

[Erik Nordmark <[e-mail]>]

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

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.

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

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

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

    Erik