RE: [EME] First cut at eme requirements
"Paul Francis" <francis@cs.cornell.edu> Mon, 04 December 2006 16:28 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGg1-0000FA-IM; Mon, 04 Dec 2006 11:28:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGg0-0000EQ-2U for eme@irtf.org; Mon, 04 Dec 2006 11:28:20 -0500
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 1GrGfx-0005Bq-O5 for eme@irtf.org; Mon, 04 Dec 2006 11:28:20 -0500
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 11:28:17 -0500
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] First cut at eme requirements
Date: Mon, 04 Dec 2006 11:28:16 -0500
Message-ID: <E6F7A586E0A3F94D921755964F6BE00672E280@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <456C903F.4000202@employees.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [EME] First cut at eme requirements
Thread-Index: AccTJPa1JZ7G53XLSLWUeE59ZFsdkwEnBABA
From: Paul Francis <francis@cs.cornell.edu>
To: Scott W Brim <swb@employees.org>
X-OriginalArrivalTime: 04 Dec 2006 16:28:17.0226 (UTC) FILETIME=[3405A2A0:01C717C1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: eme <eme@irtf.org>
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
These are all reasonable comments...happy to incorporate them in the next revision. PF -----Original Message----- From: Scott W Brim [mailto:swb@employees.org] Sent: Tuesday, November 28, 2006 2:39 PM To: Paul Francis Cc: eme Subject: Re: [EME] First cut at eme requirements On 11/28/2006 10:30 AM, Paul Francis wrote: > Middlebox: A middlebox refers to a network element assisting > endpoints to communicate through that network. A middlebox may > keep per-flow state or may be stateless. Like endpoints, > middleboxes may also have local policy governing which endpoints > may communicate over the particular network. This isn't an easy definition. Not all middleboxes "assist" communication -- some either restrict it or allow it. Also I believe we want to exclude routers from the definition. Finally, some middleboxes are pure control, some are pure data plane, some are mixed. What about pure policy boxes? How about (combining what you have and a few words from rfc3234): A middlebox refers to a network element which involves itself in communication between endpoints by performing functions apart from standard functions of an IP router. A middlebox may keep per-flow state or may be stateless. Like endpoints, middleboxes may also have local policy governing which endpoints may communicate over the particular network. > Policy: A policy is a rule defined by a network administrator (or > endpoint user) that controls which endpoints can communicate over > that particular network (or communicate with that particular > endpoint). It's finer-grained than just binary "communicate or not". Below you talk about policy in which flows can succeed. I like that because it allows service/app-specific policy, QoS- or path-specific policy, even time-specific policy, etc. How about: Policy: A policy is a rule defined by a network administrator (or endpoint user) that controls how endpoints can communicate over that particular network (or communicate with that particular endpoint). > 3. Requirements > This section lists the EME research group requirements. The > requirements include authentication, access control and DoS > protection, privacy, middlebox control, steering, anycast, mobility, > protocol negotiation, multi-homing, multicast delivery, and > performance. Use Authorization -- it's a superset of access control. Authentication is who you are, while authorization is what you are allowed to do. After authentication, we have requirements on authorization for interactions with endpoints, application features (which might determine what you are redirected to), etc. See below for more on authorization. > 3.1. Access Control > > REQ-2: The Internet MUST allow endpoint administrators (users or > otherwise) to control which other endpoints and middleboxes > the endpoint can communicate with and how. The Internet MUST > allow network administrators to control which endpoints can > communicate over that network and how. > > A flow on the Internet must be subjected to the policy of the > endpoints as well as the networks through which the flow is routed. > Only flows that are authorized by all stakeholders should be allowed > to succeed. There must be mechanisms that allow endpoints and > middleboxes to inform each other when a flow violates policy and > allow the negotiation of flows that satisfy policies. This is good because it goes beyond authentication and access control. I would title this section Authentication & Authorization. > Furthermore, while endpoint authentication does not, by itself, solve > the DoS problem it compartmentalizes the DoS problem to the > authentication phase that precedes the actual flow. By abstracting > DoS from applications into a common authentication phase, the > Internet can include application-agnostic infrastructure to protect > against DoS. I'm not sure, but you may be lumping authentication and authorization here. It depends on what you mean. > Endpoints must not be required to reveal their network address to > untrusted middleboxes and endpoints. Network addresses should be > made available after authentication as the address can be used to > direct a DoS attack to a bottleneck link. and authorization. After a flow is authenticated and authorized, then IP addresses may be known. One other thing - is the "should" in the seocnd line really a "must"? Thanks! Scott _______________________________________________ EME mailing list EME@irtf.org https://www1.ietf.org/mailman/listinfo/eme
- [EME] First cut at eme requirements Paul Francis
- Re: [EME] First cut at eme requirements Stephen Farrell
- RE: [EME] First cut at eme requirements Paul Francis
- Re: [EME] First cut at eme requirements Scott W Brim
- Re: [EME] First cut at eme requirements Mark Baugher
- RE: [EME] First cut at eme requirements Paul Francis
- RE: [EME] First cut at eme requirements Paul Francis
- Re: [EME] First cut at eme requirements Mark Baugher
- Re: [EME] First cut at eme requirements Rémi Després
- RE: [EME] First cut at eme requirements Paul Francis
- RE: [EME] First cut at eme requirements Paul Francis
- Re: [EME] First cut at eme requirements Rémi Després
- Re: [EME] First cut at eme requirements Mark Baugher
- Re: [EME] First cut at eme requirements Saikat Guha