Re: [nbs] A suggestion for an "on-demand API".
Javier Ubillos <jav@sics.se> Wed, 15 December 2010 08:15 UTC
Return-Path: <jav@sics.se>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7733A6E7C for <nbs@core3.amsl.com>; Wed, 15 Dec 2010 00:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.643
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8gaJ9ekdEab for <nbs@core3.amsl.com>; Wed, 15 Dec 2010 00:15:32 -0800 (PST)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 42B1C3A6E45 for <nbs@ietf.org>; Wed, 15 Dec 2010 00:15:30 -0800 (PST)
Received: from [193.10.66.63] (bit.sics.se [193.10.66.63]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 238D74011A; Wed, 15 Dec 2010 09:17:12 +0100 (CET)
From: Javier Ubillos <jav@sics.se>
To: sowmini.varadhan@oracle.com
In-Reply-To: <20101214144734.GC12378@quasimodo.us.oracle.com>
References: <20101214144734.GC12378@quasimodo.us.oracle.com>
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
Cc: nbs@ietf.org, christian.vogt@ericsson.com
Subject: Re: [nbs] A suggestion for an "on-demand API".
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Dec 2010 08:15:33 -0000
On Tue, 2010-12-14 at 09:47 -0500, sowmini.varadhan@oracle.com wrote: > jav@sics.se 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
- [nbs] A suggestion for an "on-demand API". Javier Ubillos
- Re: [nbs] A suggestion for an "on-demand API". sowmini.varadhan
- Re: [nbs] A suggestion for an "on-demand API". Javier Ubillos
- Re: [nbs] A suggestion for an "on-demand API". sowmini.varadhan
- Re: [nbs] A suggestion for an "on-demand API". Javier Ubillos
- Re: [nbs] A suggestion for an "on-demand API". sowmini.varadhan
- [nbs] Name->Locator validation. (Was: Re: A sugge… Javier Ubillos
- [nbs] (Was: Re: A suggestion for an "on-demand AP… Javier Ubillos
- Re: [nbs] Name->Locator validation. (Was: Re: A s… Brian E Carpenter
- Re: [nbs] (Was: Re: A suggestion for an "on-deman… sowmini.varadhan
- Re: [nbs] Name->Locator validation. (Was: Re: A s… Javier Ubillos
- Re: [nbs] (Was: Re: A suggestion for an "on-deman… Javier Ubillos