Subject: [EME] progress on EME

From: "Paul Francis" <[email-masked]>
Date: Wed, 6 Jun 2007 13:32:56 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/eme

---

From: Paul Francis <[email-masked]>
Date: Fri, 15 Jun 2007 14:07:57 -0400

Gang,

I've been chatting with Tom Henderson about the synergies between HIP and
NUTSS.  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.

Am wondering if folks are interested in making our meeting a joint meeting
with the EME RG at IETF.  The "joint" part would be mainly discussion of how
we can encourage larger experiments that benefits both of our charters.

PF

---

From: Paul Francis <[email-masked]>
Date: Fri, 15 Jun 2007 14:07:57 -0400

Gang,

PF

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Jun 2007 11:42:28 -0700

...
> 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.

A "HIP ACL" (for lack of a better term) seems perfect.  Consider,
for example, if I'm trying to establish communications with you --
I know you're [email-masked], and I'd like to only have
communications with you.  I'd like some way to tickle my firewall
to only allow your communication (and not everyone else on the
Internet).  

So, however that flow is identified as coming from you would be
very useful.  Doesn't seem to matter much if it's a certificate
or a HIP identifier or what.  Just that you tell me what that
identifier is so that I can tell my firewall(s).  IP address
isn't adequate due to IP address spoofing and due to NATs
which rewrite addresses willy nilly and we don't know which
address realm I'm in or you're in or the relationship between
those address realms.

...
> 5.  There was one suggestion that EME be stopped, because 
> we should be discouraging middleboxes, not making them 
> easier to deploy.

Do share with us the home IP address of whoever made that
suggestion so they might be sent a few thousand pps to
saturate their access link.  (I'm only half joking.)

-d

---

From: Paul Francis <[email-masked]>
Date: Mon, 18 Jun 2007 08:45:45 -0400

inline. 

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: Friday, June 15, 2007 2:42 PM
> To: Paul Francis; [email-masked]
> Subject: RE: [EME] progress on EME
> 
>  
> ...
> A "HIP ACL" (for lack of a better term) seems perfect.  
> Consider, for example, if I'm trying to establish 
> communications with you -- I know you're 
> [email-masked], and I'd like to only have 
> communications with you.  I'd like some way to tickle my 
> firewall to only allow your communication (and not everyone 
> else on the Internet).  
> 
> So, however that flow is identified as coming from you would 
> be very useful.  Doesn't seem to matter much if it's a 
> certificate or a HIP identifier or what.  Just that you tell 
> me what that identifier is so that I can tell my firewall(s). 
>  IP address isn't adequate due to IP address spoofing and due 
> to NATs which rewrite addresses willy nilly and we don't know 
> which address realm I'm in or you're in or the relationship 
> between those address realms.

Its the "just that you tell me what that identifier is" part that is the
sticking point.  What if you are an adversary, or otherwise not in a position
to tell me?  What if you are a user logging in from a different machine?
What if you are a service at a lot of different machines?  What if I want to
filter a whole domain?

NUTSS is one answer to all these questions...the name-based signaling phase
supplies the binding to the lower-level info (which if it is HIP is great,
cause then it is authenticatable at multiple places), which allows the
firewalls to filter on that lower level info even though the administrator
setup firewall rules using names.

> we should be 

;)

PF

---

From: Scott W Brim <[email-masked]>
Date: Mon, 18 Jun 2007 09:11:11 -0400

> we can encourage larger experiments that benefits both of our charters.

HIP is good for everything, and I like the joint meeting idea, but
I'll be in RRG all day Friday :-( .  I am unhappy about missing HIP
RG.  Will I end up unhappy about missing EME as well?

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 18 Jun 2007 07:33:38 -0700

> From: Scott W Brim [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 6:11 AM
> To: Paul Francis
> Cc: [email-masked]
> Subject: Re: [EME] joint meeting with HIP RG at IETF?
> 

Scott,
We've received several requests to move the HIP RG off of its Friday
meeting slot, to avoid conflicts with the RRG.  If we were to have some
kind of a joint or back-to-back meeting with EME, it would not be on
Friday.

Tom

---

From: Paul Francis <[email-masked]>
Date: Mon, 18 Jun 2007 10:40:41 -0400

As it now stands, EME has a 2-hour slot on Monday afternoon.  If this would
be enough time for a joint meeting (which I think it should be), then we
could just use the slot we already have.

PF 

> From: Henderson, Thomas R [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 10:34 AM
> To: Scott W Brim; Paul Francis
> Cc: [email-masked]
> Subject: RE: [EME] joint meeting with HIP RG at IETF?
> 
>  
> 
> We've received several requests to move the HIP RG off of its 
> Friday meeting slot, to avoid conflicts with the RRG.  If we 
> were to have some kind of a joint or back-to-back meeting 
> with EME, it would not be on Friday.
> 
> Tom
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Jun 2007 21:23:45 +0200

Hi all,

I went through the requirements draft and the strawman proposal. 
Initially, I did not plan to comment because I just wasn't quite sure 
whether I misunderstood the entire proposal completely.

When I first read the document then I got the impression that all this 
stuff already exists. I thought that you are replicating the 3GPP IMS 
work (without referencing it). The only difference I saw was that backup 
paths were established but I wasn't quite sure whether this is a good 
idea anyway.

So, what is the new idea about combining SIP (name-based routing) with 
path-coupled signaling?

Ciao
Hannes

PS: I haven't read the recent HIP proposal 
http://saikat.guha.cc/pub/sigcomm07-nutss.pdf.

---

From: Scott W Brim <[email-masked]>
Date: Mon, 18 Jun 2007 09:11:11 -0400

---

From: Paul Francis <[email-masked]>
Date: Tue, 19 Jun 2007 13:27:01 -0400

We are looking at having the joint meeting in the current EME slot on Monday.

PF 

> Sent: Monday, June 18, 2007 9:11 AM
> To: Paul Francis
> Cc: [email-masked]
> > Am wondering if folks are interested in making our meeting a joint 
> > meeting with the EME RG at IETF.  The "joint" part would be mainly 
> > discussion of how we can encourage larger experiments that 
> benefits both of our charters.
> 
> HIP is good for everything, and I like the joint meeting 
> idea, but I'll be in RRG all day Friday :-( .  I am unhappy 
> about missing HIP RG.  Will I end up unhappy about missing 
> EME as well?
>