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

[joel jaeggli <[e-mail]>]

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
>