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;-) Adding new identifiers with privacy impact, as proposed here, is quite different. 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 > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
