Hiya, On 11/06/14 15:38, mohamed.boucad...@orange.com wrote: > Re-, > > Please see inline. > > Cheers, Med > >> -----Message d'origine----- De : ietf-privacy >> [mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen >> Farrell Envoyé : samedi 7 juin 2014 15:21 À : Dan Wing Cc : >> ietf-priv...@ietf.org; Internet Area; Joe Touch Objet : Re: >> [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers >> >> >> Hi Dan, >> >> On 07/06/14 02:38, Dan Wing wrote: >>> >>> Stephen, >>> >>> It seems NAPT has become IETF's privacy feature of 2014 because >>> multiple users are sharing one identifier (IP address and >>> presumably randomized ports [RFC6056], although many NAPT >>> deployments use address ranges because of fear of compressing log >>> files). As a former co-chair of BEHAVE it is refreshing to see >>> the IETF embracing NAPT as a desirable feature. >> >> Embracing seems like significant overstatement to me, but maybe >> that's understandable given how calmly NAT is generally debated. >> >> NATs have both good and bad properties. The slightly better >> privacy is one of the good ones. >> >> Recognising that reality is neither embracing nor refreshing IMO, >> nor does it mean NAPT is (un)desirable overall. (That's an >> argument I only ever watch from the side-lines thanks:-) >> >>> However, if NAPT provides privacy and NAT Reveal removes it, >>> where does that leave a host's IPv6 source address with respect >>> to BCP188? >>> >>> Afterall, an IPv6 address is quite traceable, even with IPv6 >>> privacy addresses (especially as IPv6 privacy addresses are >>> currently deployed which only obtain a new IPv6 privacy address >>> every 24 hours or when attaching to a new network). If BCP188 >>> does not prevent deployment of IPv6, I would like to understand >>> the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to >>> the privacy leakage of IPv6+privacy_address. >> >> I'm frankly amazed that that's not crystal clear to anyone who has >> read all 2.5 non-boilerplate pages of the BCP. Or even just the >> last two words of the 1-line abstract (hint: those say "where >> possible.") >> >> Yes, source addresses leak information that affects privacy. But we >> do not have a practical way to mitigate that. So therefore BCP188 >> does not call for doing stupid stuff, nor for new laws of physics >> (unlike -04 of the draft we're discussing;-) > > [Med] FWIW, this draft does not hint solutions but it aims to > describe scenarios with problems. I understand you have concerns with > privacy but this is not an excuse to abuse and characterize this > effort as "stupid".
Apologies if you took it that way. What I meant was that BCP188 does not call for stupid stuff, I was not characterising the draft as stupid, but rather the assertion that BCP188 calls for such. > Privacy implications should be assess on a per > use case basis Where do I find the per-use-case analysis of privacy implications? > (see for example cases where all involved entities > belong to same administrative entity). Furthermore, the document > (including -04) says the following : "the document does not elaborate > whether explicit authentication is enabled or not." > >> >> Adding new identifiers with privacy impact, as proposed here, is >> quite different. > > [Med] I have already clarified this point: the scenario draft does > not propose any identifier! I think its unrealistic to assert that any solution is possible without such. I would be interested in reading about any proposal that did not require a new identifier. So yes, I do assert that a need for a new identifier is implicit in the draft, even if that is not stated explicitly, and would be interested in arguments as to why I'm wrong about that. S. > >> >> S. >> >> PS: If someone wants to propose what they think is a practical way >> to mitigate the privacy issues with source addresses, please write >> a draft first and then start a separate thread somewhere. >> >> >>> >>> -d >>> >> >> _______________________________________________ ietf-privacy >> mailing list ietf-priv...@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-privacy > > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
