Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

[Stephen Farrell <[e-mail]>]

Hi Med,

On 06/06/14 12:41, [e-mail] wrote:
> [Med] I'm not sure about this Ted. There are other initiatives that
> try to solve the issue for particular use cases, see for instance
> this effort for HTTP:
> http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The
> rationale of the "host identifier scenarios" document is to group all
> use cases suffering from the same problem instead of focusing on one
> single case. This allows having a big picture view of the problem
> space.

I think XFF is actually a good example of why we ought not adopt
this work.

XFF is widely deployed already but somewhat flakey in terms of
interop so the authors of the above draft aimed to produce a spec
that just addressed interop. (*) That was adopted by an area WG
without (IMO) ever really considering the privacy implications,
and definitely without any effort having been made to develop a
more privacy-friendly mechanism (which could have been done, again
IMO) to solve what were the claimed use-cases. By the time it
got to the IESG that was in practice unfixable and after some
fairly painful discussions it ended up with 4 abstain ballots,
including mine. [1] (For those who quite reasonably don't need
to care about IESG balloting, an abstain means approximately
"yuk.":-)

Of course that all also pre-dated BCP188 and the last year's
shenanigans so I'd hope we have learned to not keep doing that.

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.

S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/

(*) To be clear: I think the authors were genuinely just
trying to fix what they saw as an interop problem.