Re: [Int-area] L. Eggert's comment (draft-boucadair-intarea-host-identifier-scenarios)

[<[e-mail]>]

Hi Joel,

This is indeed acceptable, in particular, for scenarios that are specific to a single administrative domain or that requires an agreement between the entity that owns the information and the one that will make use of that information. 

Cheers,
Med

>-----Message d'origine-----
>De : joel jaeggli [mailto:[e-mail]]
>Envoyé : mercredi 23 juillet 2014 15:23
>À : BOUCADAIR Mohamed IMT/OLN; Internet Area ([e-mail])
>Cc : [e-mail]
>Objet : Re: [Int-area] L. Eggert's comment (draft-boucadair-intarea-host-
>identifier-scenarios)
>
>On 7/23/14, 8:42 AM, [e-mail] wrote:
>> I figure out this text: "and a better solution that would preserve
>> privacy should be considered." may not reflect exactly the point made by
>> Stephen, so I'm inserting his words:
>>
>>
>>
>> "I'd be delighted if those who could get a better solution
>>
>> implemented/deployed were to attempt to try to address the
>>
>> privacy issues with XFF but it seems that at least in that
>>
>> case relevant folks don't care (sufficiently;-) deeply about
>>
>> our privacy to go do that."
>
>The proposal for a HIAPS bof staked out a particular position with
>respect to this
>
>  "First it has to be ensured that the server on the receiver side is
>well justified
>  to receive the   information. Next it will be granted that the
>communication is
>  not visible to on-path observers using the most state-of-art ways of
>securing
>  the communication."
>
>I found that acceptable, it is however incompatible with some of the
>proposed solutions.
>
>> Cheers,
>>
>> Med
>>
>>
>>
>> *De :*Int-area [mailto:[e-mail]] *De la part de*
>> [e-mail]
>> *Envoyé :* mercredi 23 juillet 2014 14:33
>> *À :* Internet Area ([e-mail])
>> *Cc :* [e-mail]
>> *Objet :* [Int-area] L. Eggert's comment
>> (draft-boucadair-intarea-host-identifier-scenarios)
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Lars raised a point about
>> draft-boucadair-intarea-host-identifier-scenarios that is basically to
>> question whether it is worth continuing this effort if no viable
>> solutions can be designed to solve this problem.
>>
>>
>>
>> I do agree this is a fair point. I have several comments to make here:
>>
>>
>>
>> ·         The lack of a recommendation in RFC6967 should not be
>> interpreted as there is no working solution.
>>
>> ·         The analysis in RFC6967 is specific to particular cases that
>> span many administrative domains (read CGN). So, the drawbacks of
>> several solutions discussed in RFC6967 are irrelevant for scenarios that
>> are restricted to a single administrative domain (or where an
>> administrative relationship is setup between involved parties).
>>
>> ·         The IETF recognizes there are solutions for specific
>> applications: RFC7239 was published after RFC6967!
>>
>> ·         Some solutions such as the use of an IP option are viable ones
>> when involved devices are under the control of the same administrative
>> entity.
>>
>> ·         Some of the scenarios can be solved by protocol extensions
>> (e.g., http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01,
>> querying the MIB in
>> http://tools.ietf.org/html/draft-ietf-behave-nat-mib-11, announcing port
>> sets http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-01,
>> etc.) without requiring injecting an identifier in the packet.
>>
>> ·         I know Lars is not supportive to the use of a TCP option, but
>> IMHO the use of a tcp option is superior to RFC7239. The TCP option is a
>> working solution for the TCP proxy, https and other scenarios.
>>
>> ·         Stephen (Farrel) mentioned in the list he has concerns with
>> RFC7239 and a better solution that would preserve privacy should be
>> considered.
>>
>>
>>
>> The rationale in the scenarios draft is as follows: instead of advancing
>> specifications that are scoped to a specific scenario, it is worth
>> having a means that will help linking all these scenarios to hopefully
>> make common solutions possible.
>>
>>
>>
>> Cheers,
>>
>> Med
>>
>>
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
>>
>