Re: [nbs] A suggestion for an "on-demand API".

[Javier Ubillos <[e-mail]>]

On Wed, 2010-12-15 at 10:45 -0500, [e-mail] wrote:
> On (12/15/10 09:17), Javier Ubillos wrote:
> > 
> > The way I picture it, not necessarily. I think that the name-exchange
> > should be an optional part (perhaps default?). In the exchange above 
>    :
> > What could go wrong is if 
> >    * B requires authenticated connections.
> 
> If B is the passive side of the connection, how would it mandate that
> it requires authenticated connections e.g., if it got a SYN without
> a name, what should it do? (I think this also brings us back to Erik's
> original point about exposure to DOS)

In the TCP scenario, the SYNACK would include a name-extension header
(or some similar mechanism) with some flag requiring the initiator to
send whatever is necessary for authentication. In the simplest-case this
could be a name-extension header with a resolvable name (FQDN).
As we are still using IP "on-the-wire", and I think the syn-cookies may
not use the names in the hashes, I don't think any new weaknesses are
introduced. 
Host-to-host, each TCP flow must still have it's own four-tuple to avoid
the syn-cookie ordeal. This does mean that the stack needs an internal
coordination (making sure that flows bound to names do not collide in
their four-tuples). I don't think this is  

> >    * A has name name(a).
> >    1. A sends a packet to B with a name-exchange.
> >    2. A changes name to name(a')
> >    3. B now tries to authenticate A.
> > 
> > My spontaneous answer is that the connection _should_ fail.
> > If the responder cannot authenticate the packet, it shouldn't accept it.
> > It could be that A has changed names, but it could also be that the
> > resolution system does not have a mapping name(A) => A for B (e.g. if
> > the resolution system is some DHT based solution and A & B are on
> > different partitions).
> > Or it could be a phishing attempt.
> > Assuming that B does require authentication, if the authentication fails
> > it shouldn't be accepted. Independently if whether the reason is because
> > a record has "just become invalid" or it is in fact invalid :)
> 
> But what if the authentication fails after several data packets have
> been exchanged? How frequently should you reverify the [name(A), A]
> mapping?

That is up to the application.

I don't think names should be re-verified. However, if there would be a
reason for doing this, it could either be triggered/configured by the
application or be a default for whichever name-resolution mecanism one
chooses. In the DNS/FQDN case, I don't see why one would need to
re-verify the mapping during the session. If it is due to impersonation
attacks, I'd suggest the exchange of a nonce. Perhaps this should be
default behavior.

The name-resolution mechanism may provide a level of authenticity in the
first step (whenever the check is made). I would argue that, from that
point and onwards, it is up to the two hosts to maintain the
relationship. I can imagine that some one would want to have a continual
polling of the name->locator mapping, but I cant see what the scenario
would be. Do you have any good case to test the idea with?

> > > > Of course, the initiator could also set requirements for the
> > > > communication.
> > > 
> > > Please clarify - what sort of requirements?
> > 
> > I was thinking requirements, both hard and soft as
> > * Authenticity (of sender)
> 
> of receiver, you mean? Anyway, lots of missing details as you point out
> below.

I was actually thinking in both ways.
If either side requests an authenticity check of the name->locator
mapping of the remote party. The application may just request the check
and then decide what to do (with some sensible default behavior).

And yes, I do leave out a lot of details. Because I don't have all the
details. I'm not trying to push a ready-made proposal, but rather trying
to get a discussion going on what the API/behavior _should_ be.
We do have a prototype (which does not yet reflect the API very well),
but I don't want to insist on having that experiment as a defined
standard.

I welcome more comments on ... everything and anything. There are still
plenty of details to work out, and I think this is the best way of
finding them and working them out.
"The devil is in the details.", and this is the exorcism :)

// Javier

> 
> > * Integrity (of data)
> > * Multi-homing / mobility /multi-path exploitation
> > * Security (encryption of data)
> > 
> > I can also imagine a scenario where this mechanism becomes even more
> > flexible and intelligent, but I think it might be a bit premature to
> > introduce those bits just yet :)
> > 
> > 
> > // Javier
> > 
> 
>