[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