Subject: RE: [EME] First cut at eme requirements

From: "Paul Francis" <[email-masked]>
Date: Mon, 4 Dec 2006 11:28:16 -0500

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

PF

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

---

From: Rémi Després <[email-masked]>
Date: Tue, 05 Dec 2006 11:05:01 +0100

I wonder whether an easy characterization of EME middleboxes couldn't be 
that they may modify IP packets.
("IP Packets" are no longer E2E. Only part of their semantics is.)

RD

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 5 Dec 2006 11:31:19 -0500

Do you find Scott's definition to be insufficient or too involved?  (Repeated
here for convenience)
 
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.

PF

________________________________

From: Rémi Després [mailto:[email-masked]] 
Sent: Tuesday, December 05, 2006 5:05 AM
To: Paul Francis
Cc: Scott W Brim; eme
Subject: Re: [EME] First cut at eme requirements

I wonder whether an easy characterization of EME middleboxes couldn't be that
they may modify IP packets.
("IP Packets" are no longer E2E. Only part of their semantics is.)

RD

Paul Francis wrote : 

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

	-----Original Message-----
	From: Scott W Brim [mailto:[email-masked]] 
	Sent: Tuesday, November 28, 2006 2:39 PM
	To: Paul Francis
	Cc: eme
	Subject: Re: [EME] First cut at eme requirements

		   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?

---

From: Rémi Després <[email-masked]>
Date: Tue, 05 Dec 2006 18:20:48 +0100

Good question!
Scott's definition in my view has two parts.
- The first sentence is the definition per se
- The two others are comments.

My point is only about the first sentence (the comments are OK).

the current wording, "Functions apart from standard functions of an IP 
router" is somewhat involved, and IMO ambiguous (if a router has more 
functions than a "standard" router, as defined by IETF, does it become 
an EME middlebox?).
Now, a question remains: is it intended by some in the group that a box 
could be an EME middlebox although it would never modify any E2E IP packets?
(A router that encapsulates a packet is seen as NOT modifying the "E2E 
packet".)
It don't se the need for that, but it should be a conscious collective 
decision.

The following definition would take my point:
A middlebox refers to a network element which involves itself in
communication between endpoints and modifies end-to-end IP packets more 
than by updating their TTL.
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.

RD

Paul Francis a écrit :
>  Do you find Scott's definition to be insufficient or too involved?
>  (Repeated here for convenience)
>
>
>
>
>  PF
>
>  From: Rémi Després [mailto:[email-masked]] Sent: Tuesday,
>  December 05, 2006 5:05 AM To: Paul Francis Cc: Scott W Brim; eme
>  I wonder whether an easy characterization of EME middleboxes couldn't
>  be that they may modify IP packets. ("IP Packets" are no longer E2E.
>  Only part of their semantics is.)
>
>  RD
>
>  Paul Francis wrote :
>
>  next revision.  PF    -----Original Message----- From: Scott W Brim
>  [mailto:[email-masked]] 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:
>
>  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.
>
>  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?  
>
>
>