Re: [nbs] NBS and TCP connection identification

[Javier Ubillos <[e-mail]>]

On Wed, 2010-09-22 at 10:10 -0700, Erik Nordmark wrote:
> On 09/22/10 02:47 AM, Javier Ubillos wrote:
> 
> >> 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.
> 
> But there is also the TCP behavior change associated with connection 
> establishment, where AFAICT TCP receives a SYN from IPa to IPb, but is 
> supposed to create a TCB from NAMEa to NAMEb.
> That is the part I'd like to understand better, and the draft doesn't 
> have anything about it.

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?


> > There is a change coming soon to the draft. Where the name-exchange
> > becomes an optional component.
> 
> That still doesn't answer how TCP connection setup would work - in fact 
> it raises more questions about how it could work.
> 
> > 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.
> 
> It would be good to have some idea that nbs can be made to work. I guess 
> we can always say that if shim6 (using names as ULID) is done first, 
> then TCP can run using the names (or hashes of names) after that. Such 
> an approach is suboptimal, but it at least provides an existence proof 
> of a solution, which means that we can have a WG go look at ways to make 
> it perform better.

I am hesitant to solutions that infer delays in the connection setup.

> > 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.
> 
> Sure, shim6 does that already.
> 
> The issues are around how nbs and shim6 fit together; the devil is in 
> the details ;-)
> 
> I still don't see how using names like 81.228.146.129.in-addr.arpa in 
> nbs solves any problem, since they can't be secured AFAICT.

It's not about securing them, but about using them as a session
identifier.
Consider using a randomly generated string.
Using the canonical ".arpa" is just that with a small difference, it
gives you the information of from where the connection was initiated.
I do admit that this is not a big deal, which is why we wanted to leave
it open.

// Javier