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

[Javier Ubillos <[e-mail]>]

On Tue, 2010-12-14 at 09:47 -0500, [e-mail] wrote:
> [e-mail] wrote:
<snip>
> > * A web-server only requires a session-handle, the web-server will reply
> > to any-one initiating a session. No "extras" are asked for.
> > 
> > * Some other application might require authenticity of name->IP binding,
> > and is also prepared to pay the cost for that authenticity (typically a
> > round-trip).
> > 
> > An example:
> > 
> > Host A (A.left.org) and host b (B.right.org).
> > 
> > * Host A.left.net resolves "B.right.net" to IP(B).
> > 
> > * The packet received by B contains only IP(A) & IP(B).
> > 
> > * The application at B receives only a session-handle.
> > 
> > * Now, B can simply accept the session-handle and respond with data.
> > This would be the typical behavior for a web-server.
> 
> In this model, would there be any name piggybacking in the packet at all?
> I'm guessing the answer is "yes" based on the comment about authentication
> below..

The way I picture it, not necessarily. I think that the name-exchange
should be an optional part (perhaps default?). In the exchange above 

Either the initiator (A) starts off with a piggy-backed name-exchange,
or the name exchange is initiated on the responders (B) request. 

Or the name-exchange is simply not used.

The point is to not introduce any extra overhead/costs unless either
side requests something that requires it. 

I suggest the name-exchange should be enabled by default, the
overhead/cost for the name-exchange is negligible unless for certain
very specialized situations.

The short answer is: There would only be name piggybacking if either
side requests it. Both A and B could do this in the above example.

> > * Or, if B wants to know more, e.g. the IP and/or the name of the sender
> > it needs to query the API asking for it.
> > 
> > 
> > Asking for the IP should be trivial.
> > Authenticating the name (with the IP) would most likely come with a
> > cost. Either a round-trip to A, or a round-trip to DNS verifying the
> > name->IP.
> 
> [Assuming that names would still be piggybacked as described in 
> http://tools.ietf.org/pdf/draft-ubillos-name-based-sockets]
> 
> If the authentication fails, then the action that the authenticator
> should take is not clear to me.. in your example, let's say that DNS maps
> A.left.org to IP(A) when the connection is set up, and the authentication
> attempted by B at that time succeeds. Now at some later point, A
> changes its hostname to A1.left.org (but still keeps IP(A)). In a
> world where name-resolution is done before connection establishment,
> the connection would stay unaffected since it only cares about IP
> address (i.e., IP(A)) itself. But in the new proposal, if B tries to
> re-authenticate, it will find that authentication of
> (name == A.left.org, IP(A)) will fail.  How does B know decide this
> was always an invalid name manufactured by the sender, or whether this
> "just became invalid"?

Good question, I hadn't given that scenario much thought.

What could go wrong is if 
   * B requires authenticated connections.
   * 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 :)

What do you think? Does this make sense?

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