Re: [v6ops] I-D Action: draft-link-v6ops-6mops-00.txt

[Mark Smith <[e-mail]>]

On Wed, 6 Mar 2024, 06:16 Tom Herbert, <tom=[e-mail]>
wrote:

> On Tue, Mar 5, 2024 at 11:04 AM Brian E Carpenter
> <[e-mail]> wrote:
> >
> > On 05-Mar-24 14:29, Jen Linkova wrote:
> > > On Tue, Mar 5, 2024 at 12:17 PM Brian E Carpenter
> > > <[e-mail]> wrote:
> > >> This draft is an excellent start.
> > >
> > > Thank you!
> > >
> > >> The security considerations seem a bit short.
> > >
> > > It's a side effect of the draft submission deadline ;) Will be fixed
> in -01 ;)
> > >
> > >>> This document does not introduce any privacy considerations
> > >>
> > >> Are we sure about that? For example, some people (not me) will claim
> > >> that the privacy benefits of NAT are lost for the IPv6-only hosts.
> > >
> > > If we compare the proposed design with a dual-stack approach, the
> > > privacy considerations are the same:
> > > - if the destination is a dual-stack (or IPv6-only) IPv6 will be used
> > > in both cases;
> > > - if the destination is IPv4-only, the traffic will go through NAT44
> > > (dual-stack) or NAT64 (IPv6-mostly)
> > >
> > > Would adding a text that privacy considerations are inherited from a
> > > dual-stack design?
> >
> > What I realised when considering your question is that we have no generic
> > reference for IPv6 privacy considerations. RFC 7721 is specific to
> address
> > generation, RFC 7824 is specific to DHCPv6, RFC 8065 is specific to
> adaptation
> > layers, and that's about it. So I guess it is reasonable to say that
> "mostly"
> > adds no new privacy risks compared to dual stack, but the "only" hosts
> avoid
> > all IPv4-related risks and may benefit from IPv6-related protections
> such as
> > temporary addresses.
> >
> > The NAT lovers will disagree though, because they believe that NAT is a
> > privacy feature.
>
> Brian,
>
> It's less about being a NAT lover, but more just realizing that CGNAT
> offers better privacy in addressing that IPv6 without NAT (this has
> been confirmed by LE,
>
> https://www.internetsociety.org/blog/2018/03/cgn-ipv6-fighting-online-crime/
> ).
>

Just like security, privacy is relative.

Claims of better privacy need to be in the context of from whom you're
trying to be private from and from which privacy breaching methods you're
attempting to mitigate against.

For example, IP address privacy from a remote website that could be
provided by CGNAT is easily defeated by HTTP cookies or web browser
fingerprinting.

It's impossible to remain absolutely anonymous and yet participate in
bidirectional communication. Either identities have to be disclosed to each
party directly or to trusted intermediaries.

In this scenario the CGNAT would be the trusted intermediary, because it is
anonymising the addresses. However, then the CGNAT becomes the point of
potential privacy failure, and cannot be mitigated very well by the privacy
seeking end user, because they don't control or operate the CGNAT.

How much can you trust the CGNAT operator to protect your privacy when you
don't operate it? How do you know that the CGNAT operator (perhaps under
mandate from a government who considers you to be an enemy) isn't the party
you should be actively trying to be private from? You can only assure what
you can control.

Increasing the default anonymity of IPv6 addresses has some value e.g.
temporary IPv6 addresses or RFC 7217 addresses, however I think the
perceived privacy that NAT/GCNAT provides is over estimated because it's so
easily defeated at higher layers and in the case of CGNAT you're
outsourcing your privacy measures to somebody else who may not have your
best privacy interests at heart.

Regards,
Mark.


> Tom
>
> >
> >      Brian
> >
> > >
> > >> Is there any interaction with site policies (dis)allowing temporary
> > >> addresses? Any interaction with randomized MAC addresses?
> > >
> > > It's all existing in any other IPv6 deployment, right? Nothing
> > > specific to IPv6-mostly. I didn't consider enumerating all IPv6
> > > privacy implications, but maybe I should..
> > >
> > >> On 05-Mar-24 01:27, [e-mail] wrote:
> > >>> Internet-Draft draft-link-v6ops-6mops-00.txt is now available.
> > >>>
> > >>>      Title:   IPv6-Mostly Networks: Deployment and Operations
> Considerations
> > >>>      Author:  Jen Linkova
> > >>>      Name:    draft-link-v6ops-6mops-00.txt
> > >>>      Pages:   16
> > >>>      Dates:   2024-03-04
> > >>>
> > >>> Abstract:
> > >>>
> > >>>      This document discusses an deployment scenario called "an
> IPv6-Mostly
> > >>>      network", when IPv6-only and IPv4-enabled endpoints coexist on
> the
> > >>>      same network (network segment, VLAN, SSID etc).
> > >>>
> > >>> The IETF datatracker status page for this Internet-Draft is:
> > >>> https://datatracker.ietf.org/doc/draft-link-v6ops-6mops/
> > >>>
> > >>> There is also an HTML version available at:
> > >>> https://www.ietf.org/archive/id/draft-link-v6ops-6mops-00.html
> > >>>
> > >>> Internet-Drafts are also available by rsync at:
> > >>> rsync.ietf.org::internet-drafts
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> I-D-Announce mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/i-d-announce
> > >>>
> > >>
> > >> _______________________________________________
> > >> v6ops mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > >
> > >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>