[EME] progress on EME
"Paul Francis" <francis@cs.cornell.edu> Wed, 06 June 2007 17:33 UTC
Return-path: <eme-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvzNb-0006xV-Pn; Wed, 06 Jun 2007 13:33:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvzNa-0006xQ-HL for eme@irtf.org; Wed, 06 Jun 2007 13:33:06 -0400
Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvzNZ-0003Bv-5k for eme@irtf.org; Wed, 06 Jun 2007 13:33:06 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 13:33:04 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 06 Jun 2007 13:32:56 -0400
Message-ID: <E6F7A586E0A3F94D921755964F6BE006C97B72@EXCHANGE2.cs.cornell.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: progress on EME
Thread-Index: AceoYLhXIgrUaKAnRhab3zsmPFuJwQ==
From: Paul Francis <francis@cs.cornell.edu>
To: eme@irtf.org
X-OriginalArrivalTime: 06 Jun 2007 17:33:04.0512 (UTC) FILETIME=[BD086800:01C7A860]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Subject: [EME] progress on EME
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Errors-To: eme-bounces@irtf.org
Gang, I've been having a number of side coversations about EME and NUTSS (though not so much the architecture ID per se). These include NUTSS with HIP, ACL usage, partial source routing issues, use with sensor networks, and whether we want EME at all. Not quite sure why folks prefer to have these on the side rather than on the list, but anyway I thought I'd summarize them here. Folks should speak up if I am misrepresenting things, or leaving things out. By the way, we are planning on having a meeting slot at the next IETF, to get feedback on the architecture and discuss where to go from here. (Monday July 23, 2007 in the Afternoon Session from 1300-1500, but of course this is subject to change). Also, one piece of good news (for me anyway) is that our NUTSS paper was accepted into sigcomm this year (http://saikat.guha.cc/pub/sigcomm07-nutss.pdf). Anyway, the summary: 1. Perhaps most interesting, I've been talking with Tom Henderson and Teemu Koponsen about synergies between NUTSS, HIP, and DONA (an architecture that Teemu has been working on that has aspects of both). In a nutshell, NUTSS provides some of the naming and rendezvous services that HIP needs, while HIP provides a way for multiple boxes (middle and end) to authenticate the packets of a given data flow. We're talking about producing combined implementations that have higher use value (i.e. NAT traversal...). But I'm sure a number of interesting research issues fall out of this. 2. Broadly there is an interesting issue about how to define ACLs (both in firewalls and endhosts). The NUTSS paper assumes a 3-tuple of <user,domain,application>, where domain is meant to be a DNS name, and can be wildcarded, application is meant to be globally unique, user can be NULL (and doesn't have to represent a human per se), and where all three are user friendly. The main question, in my mind at least, is whether domain is the best basis for ACLs, or whether certificates, for instance, is better (or, at least, has some better properties). I personally want to use domain names, given their ubiquity, but the question is nevertheless interesting, and we should know what we are giving up, both in terms of security and in terms of flexibility, by using them. Beyond this, there are questions of who creates ACLs and where, and what to do when there are conflicts. This is something the ID doesn't explore, but which we are beginning to understand is central to the problem. 3. There has been a discussion on the e2e-interest group about the evils of partial source routing, which in the EME context begs the question as to whether we (EME) assume some kind of source routing in the data stream, or rather IP header re-writing in middleboxes (after setting up a source-routed path in the name-routed signaling). We've been assuming the latter, but again more from backwards compatability than a strong architectural reason to do so. There is a general question of whether we'll get into situations where some middleboxes won't be able to forward packets to each other even though name-routing selects them. (The problem would be discovered by addr-routed signaling, but do we want to do something better?) 4. There was a discussion about whether (some extension of) NUTSS would make sense as the basis for communicating with sensors, with an assumption that the sensors would be behind gateways that speak NUTSS on one side, and something customized for the sensornet on the other. One reasons extensions are needed is because a given sensor may or may not be on at a given time. In addition, sensors might be named by the "service" they provide as well individually. 5. There was one suggestion that EME be stopped, because we should be discouraging middleboxes, not making them easier to deploy. PF _______________________________________________ EME mailing list EME@irtf.org https://www1.ietf.org/mailman/listinfo/eme
- [EME] progress on EME Paul Francis
- [EME] joint meeting with HIP RG at IETF? Paul Francis
- RE: [EME] progress on EME Dan Wing
- RE: [EME] progress on EME Paul Francis
- Re: [EME] joint meeting with HIP RG at IETF? Scott W Brim
- RE: [EME] joint meeting with HIP RG at IETF? Henderson, Thomas R
- RE: [EME] joint meeting with HIP RG at IETF? Paul Francis
- [EME] Is this IMS? Hannes Tschofenig
- RE: [EME] joint meeting with HIP RG at IETF? Paul Francis
- Re: [EME] Is this IMS? Scott W Brim
- Re: [EME] Is this IMS? Hannes Tschofenig