Subject: [EME] First cut at eme requirements

From: "Paul Francis" <[email-masked]>
Date: Tue, 28 Nov 2006 10:30:24 -0500

Gang,

Attached is a rough draft of a requirements document for EME.  This is meant
to be the union of the requirements that Handley and I presented at the BOF
in Montreal.  The goal here is to be ambitious but realistic, and to try to
limit ourselves to basic and important requirements.  This really is a rough
draft, and is meant to motivate and focus discussion.

Mark W, could you post on the wiki when you get a chance?

Thanks,

PF (and Saikat)
_______________________________________________
EME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/eme

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Nov 2006 15:36:26 +0000

That conflates privacy and confidentiality which are different things.

REQ-4 talks about confidentiality but the nearby text talks about things
like (anon)nymity.

I suggest separating those, at least.

Stephen.

Paul Francis wrote:
> ------------------------------------------------------------------------
>

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 28 Nov 2006 12:08:04 -0500

Well taken...thanks.

PF 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, November 28, 2006 10:36 AM
To: Paul Francis
Cc: eme
Subject: Re: [EME] First cut at eme requirements

REQ-4 talks about confidentiality but the nearby text talks about things like
(anon)nymity.

Stephen.

Paul Francis wrote:
> Gang,
> 
> Attached is a rough draft of a requirements document for EME.  This is 
> meant to be the union of the requirements that Handley and I presented 
> at the BOF in Montreal.  The goal here is to be ambitious but 
> realistic, and to try to limit ourselves to basic and important 
> requirements.  This really is a rough draft, and is meant to motivate and
focus discussion.

---

From: Scott W Brim <[email-masked]>
Date: Tue, 28 Nov 2006 14:38:39 -0500

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