Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

[Toerless Eckert <[e-mail]>]

On Thu, Jul 18, 2013 at 02:11:21PM +0200, [e-mail] wrote:
> >[RP] I believe the end-point making the request for flow characteristics
> >will be the CPE in many cases where the applications is not metadata
> >aware. In other words, the CPE makes the request on behalf of applications.
> [Med] I'm more interested in this CPE flavor (managed CPE) since it avoids relying on applications to benefit from the added value of this approach. This is worth be discussed in the document too. 

See section 3.1.4.1 which talks about proxies. The problem really is where
the proxied information comes from. If the proxy is doing DPI inspection to
deduce it or some configured mappings, then it's likely going to be unreliable
(encryption) or suffer from problems in getting it provisioned.

To me these inspecting proxies are a way to get a foot in the door with
the method while it takes its time to persuade app-developers (or middleware
like browsers) to signal the information explicitly (couple of years ?...).

> [Med] The question is not whether a secure transport is used or not but to what extent the flow description is accurate (e.g., send fake flow description, systematically request treatment with higher priority, etc.).

Right. That was the intention of 3.1.4.2. Ultimately the network taking
action on the metadata needs to trust the authenticated identity
associated with the attributes to not lie about the attributes - OR
enforce the semantic of the attributes signalled.

Cheers
    Toerless