RE: [EME] First cut at eme requirements

["Paul Francis" <[e-mail]>]

These are all reasonable comments...happy to incorporate them in the next
revision.

PF

 

-----Original Message-----
From: Scott W Brim [mailto:[e-mail]] 
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/eme