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

[[e-mail]]

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)

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

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

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