Re: [nbs] NBS and TCP connection identification

[Javier Ubillos <[e-mail]>]

On Mon, 2010-09-20 at 20:30 -0700, Erik Nordmark wrote:
> On 09/20/10 06:15 PM, Christian Vogt wrote:
> > Hi Erik:
> >
> > Thanks for reviewing both documents.  A few comments; Javier will
> > fill in the rest.
> >
> > - You are right that TCP connections will be identified by a pair of
> > DNS names.  Implementation-wise, this could be realized by hashing
> > the DNS names into 128-bit strings.  Then, a TCP-for-IPv6
> > implementation could pretty much be reused.
> 
> But that requires that the hash of the DNS name be carried in the TCP 
> SYN and SYN|ACK, since you can't setup that state after the connection 
> is setup. This adds complexity (and the details are missing) since TCP 
> needs to handle both a NBS peer and a normal TCP peer (the latter will 
> create a connection based on the IP addresses.)
> I don't know how this is intended to work for UDP.

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.

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.

> > - Security-wise, the idea is to bind DNS names to IP addresses by
> > means of a forward lookup in the DNS.  This gives the same level of
> > security that we have for DNS-based applications today, except that
> > the forward lookup would not just be done by the connection
> > initiator, but also by the connection responder.  Where higher
> > security is required, we recommend DNSSEC.  Thus we can avoid extra
> > cryptographic identifiers.
> 
> If X can predict that A will talk to B (using port1/port2), then X can 
> send a SYN claiming to have A's name (and port1) destined to B/port2.
> Later when A sends its SYN something on B has to be able to resolve 
> things. The easy way is to verify that the initiator actually "owns" the 
> name A before creating the TCP state for A/port1.
> 
> I don't understand what you mean by the forward lookup being done by the 
> responder. Clearly the responder can't do a forward lookup when it 
> receives a SYN packet, because that can be used to DoS the responder out 
> of existence.

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.

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

// Javier