Hi Stephen,
On 06/07/2014 09:20 AM, Stephen Farrell wrote:
> Adding new identifiers with privacy impact, as proposed here, is
> quite different.
It is not the intention of the authors for this to be a solution draft.
The draft is intended to describe address sharing use cases and
deployment scenarios.
Would you please indicate where the draft proposes a new identifier? If
you are seeing a proposal for protocol changes somewhere in the draft,
editing work is required in order to either clarify or excise the
associated text.
Thanks,
--Brandon
On 06/07/2014 09:20 AM, Stephen Farrell wrote:
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
--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
