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

Javier Ubillos <> Wed, 15 December 2010 08:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A7733A6E7C for <>; Wed, 15 Dec 2010 00:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.643
X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_41=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y8gaJ9ekdEab for <>; Wed, 15 Dec 2010 00:15:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 42B1C3A6E45 for <>; Wed, 15 Dec 2010 00:15:30 -0800 (PST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 238D74011A; Wed, 15 Dec 2010 09:17:12 +0100 (CET)
From: Javier Ubillos <>
In-Reply-To: <>
References: <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pVcpZg7Or8IDZl76R1lN"
Date: Wed, 15 Dec 2010 09:17:09 +0100
Message-ID: <1292401029.4804.30.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Subject: Re: [nbs] A suggestion for an "on-demand API".
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Dec 2010 08:15:33 -0000

On Tue, 2010-12-14 at 09:47 -0500, wrote:
> wrote:
> > * 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 ( and host b (
> > 
> > * Host resolves "" 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 
> 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
> 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 (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 ==, 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