Subject: I-D Action: draft-ietf-6man-rfc4941bis-00.txt

From: [email-masked]
Date: Mon, 02 Jul 2018 17:33:24 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : Privacy Extensions for Stateless Address Autoconfiguration in IPv6
        Authors         : Fernando Gont
                          Suresh Krishnan
                          Thomas Narten
                          Richard Draves
	Filename        : draft-ietf-6man-rfc4941bis-00.txt
	Pages           : 20
	Date            : 2018-07-02

Abstract:
   Nodes use IPv6 stateless address autoconfiguration to generate
   addresses using a combination of locally available information and
   information advertised by routers.  Addresses are formed by combining
   network prefixes with an interface identifier.  This document
   describes an extension that causes nodes to generate global scope
   addresses from interface identifiers that change over time.  Changing
   the interface identifier (and the global scope addresses generated
   from it) over time makes it more difficult for eavesdroppers and
   other information collectors to identify when different addresses
   used in different transactions actually correspond to the same node.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4941bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Jul 2018 13:08:17 +1200

This mainly looks good, but I have a slight concern about this
new MUST:

>    Finally, when an interface connects to a new link, a new set of
>    temporary addresses MUST be generated immediately.  If a device moves
>    from one ethernet to another, generating a new set of temporary
>    addresses ensures that the device uses different randomized interface
>    identifiers for the temporary addresses associated with the two
>    links, making it more difficult to correlate addresses from the two
>    different links as being from the same node.  The node MAY follow any
>    process available to it, to determine that the link change has
>    occurred.  One such process is described by Detecting Network
>    Attachment [RFC4135].

My concern is about momentary disconnects. A lazy implementation
will simply treat any link-layer disconnect/reconnect as a "new"
link. Do we really want a brief disconnect to rearrange a cable,
or a brief Wi-Fi disconnect due to (say) switching access points
to trigger re-addressing?

There are limits to how much we could usefully write on this
point, but at least we could note the issue.
"However, it is not desirable that a brief disconnection and
reconnection to the same link should trigger address generation."

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Jul 2018 09:16:10 +0200

Hello, Brian,

> to trigger re-addressing?

I'd say the answer would be "No... however, it may be difficult to
assess whether the network s the same, or different" -- although in any
case the document does provide hints that you probably do what's at hand
to actually check if the link is the same, o different.

> reconnection to the same link should trigger address generation."

How about: "However, to the extent that is possible, a brief
disconnection and reconnection to the same link should not trigger
address generation"?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Jul 2018 19:59:14 +1200

> disconnection and reconnection to the same link should not trigger

That's fine for me.

Thanks
    Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 3 Jul 2018 08:14:32 +0000

Hi,

> On 3 Jul 2018, at 08:59, Brian E Carpenter <[email-masked]> wrote:
> 

Sounds fine.

This subject reminds me of something you might want to add in the Security Considerations section, around the issue of too many freshly generated privacy addresses in a short period potentially triggering first hop security protections that may consider too many different IP addresses being seen for the same MAC address in time X as some from of attack.  We ran into this years ago when briefly hibernated portable devices generate a new privacy address on wake, and an early FHS implementation then blocked you from the network after just a handful of such short disconnects.

Or you might put that in your Deployment Considerations section.

There's a general question of how "sticky" the privacy address should be, under what conditions. I would say that if the device generates a new RFC7217 address, it should at the same time generate a new privacy address, as it will only do the former on a link change?

Tim