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

sowmini.varadhan@oracle.com Tue, 14 December 2010 14:55 UTC

Return-Path: <sowmini.varadhan@oracle.com>
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 6D04B3A6DA9 for <nbs@core3.amsl.com>; Tue, 14 Dec 2010 06:55:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.587
X-Spam-Level:
X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_MED=-4]
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 x+tW2YdNHSOJ for <nbs@core3.amsl.com>; Tue, 14 Dec 2010 06:55:43 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 70FCF3A6DC1 for <nbs@ietf.org>; Tue, 14 Dec 2010 06:55:43 -0800 (PST)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBEEvJgK020794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 14:57:20 GMT
Received: from quasimodo.us.oracle.com (quasimodo.us.oracle.com [10.152.12.37]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBEEvGGF016483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2010 14:57:17 GMT
Received: from quasimodo.us.oracle.com (localhost [127.0.0.1]) by quasimodo.us.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id oBEElaFT012461; Tue, 14 Dec 2010 09:47:36 -0500 (EST)
Received: (from sowmini@localhost) by quasimodo.us.oracle.com (8.14.4+Sun/8.14.4/Submit) id oBEElYfM012460; Tue, 14 Dec 2010 09:47:34 -0500 (EST)
X-Authentication-Warning: quasimodo.us.oracle.com: sowmini set sender to sowmini.varadhan@oracle.com using -f
Date: Tue, 14 Dec 2010 09:47:34 -0500
From: sowmini.varadhan@oracle.com
To: nbs@ietf.org
Message-ID: <20101214144734.GC12378@quasimodo.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.14 (2007-03-31)
X-Source-IP: quasimodo.us.oracle.com [10.152.12.37]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4D0785CE.00A0,ss=1,fgs=0
Cc: 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: Tue, 14 Dec 2010 14:55:45 -0000

jav@sics.se wrote:

> At IETF79, at some point after the name-based sockets BoF.
> Together with Erik Nordmark and Christian Vogt, we sat down, discussed a
> bit about name-oriented APIs and gravitated towards this idea:
> 
> The cost for behavior and an API should be incremental and optional, in
> the sense that; you should only pay the price for a feature if you
> really want to have it.
> 
> E.g.
> 
> * 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..

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

> Of course, the initiator could also set requirements for the
> communication.

Please clarify - what sort of requirements?

> This way, all elements become optional, and are only used if the
> application is ready to pay the cost for them.
> In the trivial case, an application is simply only using an API which is
> friendly and not paying the cost for any of the "extra" features.

--Sowmini