Subject: Re: Chair's review: draft-ietf-6man-ipv6-address-generation-privacy

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Apr 2015 15:33:44 -0300

Hi, Ole,

On 03/06/2015 05:51 PM, Ole Troan wrote:
> Issue #1: The reference to RFC2462 in the Introduction; is that meant
> as a "historical" reference, then it should point to RFC1971,
> otherwise it should be updated to RFC4862.

You're right. Changed!

> Issue #2: With regards to the use of "network" in several places,
> e.g "An address that does not vary over time within the same
> network."
> 
> Suggest s/network/IPv6 link/ A "network" can be a larger piece of
> topology where addresses would change.

Good point. Change applied!

> Issue #3 (nit): Title: 3 . Weaknesses in IEEE-identifier-based IIDs 
> It might be more general to replace IEEE-identifier-based IIDs with
> "Constant IIDs" which you define in the terminology session? Or
> define it?

The current text is more specific. IEEE-identifier-based IIDs allow for
device (hardware)-specific attacks, while other constant IIDs don't.

> Issue #4 - section 3.1: CURRENT: As with other identifiers, an IPv6
> address can be used to correlate the activities of a host for at
> least as long as the lifetime of the address.  The correlation made
> possible by IEEE-identifier-based IIDs is of particular concern
> because MAC addresses are much more permanent than, say, DHCP leases.
> MAC addresses tend to last roughly the lifetime of a device's network
> interface, allowing correlation on the order of years, compared to
> days for DHCP.
> 
> ItÂs our understanding that DHCP doesnÂt change addresses when the
> lease expires, it just does a renew.  This means that a DHCP provided
> address could last for a long time and have many of the correlation
> problems that IEEE MAC based addresses have.  Further, we think that
> even for a node that leave a link and comes back later, it may be
> given the same IP address (if available) as it had before because the
> DHCP server remembered it MAC address.  We think the text in the
> draft overstates the differences and implies that DHCP addresses are
> much better in this regard.

Fixed. Changed to:
"   As with other identifiers, an IPv6 address can be used to correlate
   the activities of a host for at least as long as the lifetime of the
   address.  The correlation made possible by IEEE-identifier-based IIDs
   is of particular concern since they last roughly for the lifetime of
   a device's network interface, allowing correlation on the order of
   years."

(discussing DHCPv6 here was rather off-topic)

> Issue #5 - section 3.2:
> 
> OLD: Even if the host does not respond, the first hop router will
> usually respond with an ICMP Address Unreachable when the host is not
> present, and be silent when the host is present.
> 
> NEW: Even if the host does not respond, the first hop router will
> usually respond with an ICMPv6 Destination Unreachable message when
> the host is not present, and be silent when the host is present.

Fixed as:

"Even if the host  does not respond, the first hop router will usually
respond with an  ICMP Destination Unreachable/Address Unreachable (type
1, code 3) when the host is not present, and be silent  when the host is
present."

> Issue #6 - section 3.3: OLD: This erases much of the protection
> against address scanning that the larger IPv6 address space was
> supposed to provide as compared to IPv4.
> 
> NEW: This erases some of the protection against address scanning that
> the larger IPv6 address space could provide as compared to IPv4.
> 
> As far as we remember, the IPv6 was not designed specifically to
> protect against scanning attacks, it was a by product of the design. 
> ÂErases much of the protectionÂ seems overstated and we suggest
> replacing ÂmuchÂ with ÂsomeÂ.

We've changed it to:
"This erases much of the protection against address scanning that the
larger IPv6 address space could provide as compared to IPv4."

(IEEE-derived IIDs can reduce the initial 2**64  search space to 2**24
-- that's "much").

> Issue #7- section 4: OLD: The idea was for temporary addresses to be
> used for outgoing connections (e.g., web browsing) while maintaining
> the ability to use a stable address when more address stability is 
> desired (e.g., in DNS advertisements).
> 
> NEW: The idea was for temporary addresses to be used for outgoing
> connections (e.g., web browsing) while maintaining the ability to use
> a stable address when more address stability is desired (e.g.,
> published in DNS).

Changed to:
"They use IIDs that are randomly generated and change daily by default.
The idea was for temporary addresses to be  used for outgoing
connections (e.g., web browsing) while maintaining the ability to use
a stable address when more address stability is desired (e.g., for IPv6
addresses published in the DNS)."

> Issue #8 - section 5.2: s/MAC-derived suffixes/IEEE-identifier-based
> IIDs

Fixed!

> Issue #9 - section 5.3: There is nothing actionable here, we suggest
> this section is removed.

This section notes that some IIDs (like CGAs) might be challenging to
implement for non-technical reasons. We've kept this section. But please
let us know if you strongly feel about this change. (If so, hopefully we
could remove it as part of IETF LC).

> Issue #10 - References: The references section may need more review.
> There are very few references that this document depends on. For the
> Normative references it might be prudent to move obsoleted document
> references out of the normative secion. RFC1972, RFC2462, RFC3041,
> RFC3484. RFC3314 and RFC6265 may also go in the Informative section.

You're right. Fixed!

Thanks so much!

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Apr 2015 15:48:43 -0300

On 03/09/2015 05:57 AM, Mark ZZZ Smith wrote:
> 
> Issue #4 - section 3.1:
> CURRENT:
>   As with other identifiers, an IPv6 address can be used to correlate
>   is of particular concern because MAC addresses are much more
>   permanent than, say, DHCP leases.  MAC addresses tend to last roughly
>   the lifetime of a device's network interface, allowing correlation on
>   the order of years, compared to days for DHCP.
> 
> It’s our understanding that DHCP doesn’t change addresses when the lease expires, it just does a renew.  This means that a DHCP provided address could last for a long time and have many of the correlation problems that IEEE MAC based addresses have.  Further, we think that even for a node that leave a link and comes back later, it may be given the same IP address (if available) as it had before because the DHCP server remembered it MAC address.  We think the text in the draft overstates the differences and implies that DHCP addresses are much better in this regard.
> 
> / Actually, looking at the DHCPv6 text in the draft, it is probably necessary to state that DHCPv6 address selection is influenced by whether the client requests an IA_NA (Identity association for non-temporary addresses) or an IA_TA (
> Identity association for temporary addresses) (discussed in section 12. of RFC3315)

We've fixed this section, and have also added some related text (as the
one you've suggested) to the DHCPv6 section.

Thanks!

Best regards,