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

[<[e-mail]>]

Hi Reinaldo,

IMHO, deployment considerations are key aspects if you want this model to fly. Having the material in one document is better (at least in early stages to socialize the proposed framework within IETF). 

Cheers,
Med

>-----Message d'origine-----
>De : Reinaldo Penno (repenno) [mailto:[e-mail]]
>Envoyé : vendredi 19 juillet 2013 13:33
>À : BOUCADAIR Mohamed OLNC/OLN; Toerless Eckert (eckert)
>Cc : Charles Eckel (eckelcu); [e-mail]
>Objet : Re: [Int-area] FW: New Version Notification for draft-eckert-
>intarea-flow-metadata-framework-01.txt
>
>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