[nbs] (Was: Re: A suggestion for an "on-demand API".)
Javier Ubillos <jav@sics.se> Tue, 21 December 2010 16:40 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 D00943A67E3 for <nbs@core3.amsl.com>; Tue, 21 Dec 2010 08:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.975
X-Spam-Level:
X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 GZTSgQkfSteN for <nbs@core3.amsl.com>; Tue, 21 Dec 2010 08:40:07 -0800 (PST)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 9411D3A67D7 for <nbs@ietf.org>; Tue, 21 Dec 2010 08:40:07 -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 39FB94029F; Tue, 21 Dec 2010 17:42:03 +0100 (CET)
From: Javier Ubillos <jav@sics.se>
To: sowmini.varadhan@oracle.com
In-Reply-To: <20101217231322.GB20694@quasimodo.us.oracle.com>
References: <20101214144734.GC12378@quasimodo.us.oracle.com> <1292401029.4804.30.camel@bit> <20101215154556.GE16665@quasimodo.us.oracle.com> <1292500103.4804.1313.camel@bit> <20101217231322.GB20694@quasimodo.us.oracle.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pjPfQpK8ch68rlxkP5EB"
Date: Tue, 21 Dec 2010 17:41:51 +0100
Message-ID: <1292949711.4804.8474.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Cc: nbs@ietf.org, christian.vogt@ericsson.com
Subject: [nbs] (Was: Re: 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, 21 Dec 2010 16:40:09 -0000
On Fri, 2010-12-17 at 18:13 -0500, sowmini.varadhan@oracle.com wrote: > On (12/16/10 12:48), Javier Ubillos wrote: > > > > * B requires authenticated connections. > > >=20 > > > 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) > > > > In the TCP scenario, the SYNACK would include a name-extension header > > (or some similar mechanism) with some flag requiring the initiator to > > send whatever is necessary for authentication. In the simplest-case this > > could be a name-extension header with a resolvable name (FQDN). > > As we are still using IP "on-the-wire", and I think the syn-cookies may > > not use the names in the hashes, I don't think any new weaknesses are > > introduced.=20 > > I'm not sure I see what you have in mind since the details have to be > fleshed out, but I dont see how, for example, B can require authenticatation > of, e.g., udp. Good question! I'm not sure, can one assume that UDP might not be _able_ to have a two-way communication? If so, then there would be a clear incompatibility between using UDP and flow-requirements on the receiving host. However, if that is the case, that we cannot send _any_ replies to the UDP stream, then: a. It becomes impossible to check for bi-lateral support (unless some other channel is used). b. It becomes impossible to exchange names and/or preferences. Assuming that we _can_ have a bi-directional communication. The UDP-version could very well include some kind of feedback mechanism where names & preferences are sent back to the initiator. Is it a crazy idea to subdivide the data-gram domain into truly uni-directional flows and flows where we can have a bi-directional flow? // 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