Re: [EME] First cut at eme requirements

[Scott W Brim <[e-mail]>]

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