RE: [EME] progress on EME

Paul Francis <francis@cs.cornell.edu> Mon, 18 June 2007 12:45 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 1I0GcF-0004Eh-Ri; Mon, 18 Jun 2007 08:45:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0GcE-0004Ec-Sb for eme@irtf.org; Mon, 18 Jun 2007 08:45:54 -0400
Received: from mail-hub-1.cs.cornell.edu ([128.84.103.138] helo=exch-hub1.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0GcC-0000dT-Id for eme@irtf.org; Mon, 18 Jun 2007 08:45:54 -0400
Received: from exchfe2.cs.cornell.edu (128.84.97.34) by mail-hub.cs.cornell.edu (128.84.103.140) with Microsoft SMTP Server id 8.0.700.0; Mon, 18 Jun 2007 08:45:52 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 08:45:47 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [EME] progress on EME
Date: Mon, 18 Jun 2007 08:45:45 -0400
Message-ID: <E6F7A586E0A3F94D921755964F6BE006C97FF2@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <04fc01c7af7c$ecdcb040$c2f0200a@amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [EME] progress on EME
Thread-Index: AceoYLhXIgrUaKAnRhab3zsmPFuJwQHG4+vwAAJKjZA=
From: Paul Francis <francis@cs.cornell.edu>
To: Dan Wing <dwing@cisco.com>, <eme@irtf.org>
X-OriginalArrivalTime: 18 Jun 2007 12:45:47.0085 (UTC) FILETIME=[97AEC7D0:01C7B1A6]
Received-SPF: None (mail-hub.cs.cornell.edu: francis@cs.cornell.edu does not designate permitted sender hosts)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc:
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

inline. 

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com] 
> Sent: Friday, June 15, 2007 2:42 PM
> To: Paul Francis; eme@irtf.org
> Subject: RE: [EME] progress on EME
> 
>  
> ...
> > 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 
> francis@cs.cornell.edu, 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.

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

;)

PF

> 
> -d
> 

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme