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

["Reinaldo Penno (repenno)" <[e-mail]>]

Hi Med,

I agree with you that we need to cover in more detail the managed CPE
deployments but I wonder if this is the best document to do it.

Maybe a use-cases draft based on very concrete scenarios would be best.

Thanks,

Reinaldo


On 7/19/13 4:57 AM, "[e-mail]"
<[e-mail]> wrote:

>Dear Toerless,
>
>Please see inline.
>
>Cheers,
>Med
>
>>-----Message d'origine-----
>>De : Toerless Eckert [mailto:[e-mail]]
>>Envoyé : vendredi 19 juillet 2013 05:13
>>À : BOUCADAIR Mohamed OLNC/OLN
>>Cc : Reinaldo Penno (repenno); Charles Eckel (eckelcu); [e-mail]
>>Objet : Re: [Int-area] FW: New Version Notification for draft-eckert-
>>intarea-flow-metadata-framework-01.txt
>>
>>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.
>
>[Med] Section 3.1.4.1 as it is does not provide decent discussion of
>these deployment issues and considerations. Sketching the expected
>behavior of such intermediary functions would even be better. This
>applies also for the other deployment-related issues I listed in my
>initial e-mail.
>
>>
>>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.
>>
>[Med] this discussion about trust is worth to be elaborated further in
>the document. For sure, this point will be raised by others.
>
>>Cheers
>>    Toerless