Long overdue review of draft-ietf-6man-rfc4941bis-00

[Mark Smith <[e-mail]>]

Hi,

Quite a number of months ago Fernando asked me to have a look at the
IETF 102 questions and to do a review of
draft-ietf-6man-rfc4941bis-00. Apologies to Fernando and the WG for
taking so long.

I do have nits, minor text suggestions, however I'll leave those until later.

Below are IETF 102 question answers, some general thoughts, and then
some thoughts on specific sections in the draft.

Regards,
Mark.



IETF 102 Questions
~~~~~~~~~~~~~~~~~~

Q. Algorithms?

- I think having a single specified and well known algorithm is best,
as it removes a point or points of implementation ambiguity.

- I think "a la rfc7217" is better.

I would think that on a normally "temporary address only" device, if
temporary addresses are disabled for troubleshooting or local
administrative policy, then the device should fall back to having
RFC7217 stable addresses.

Otherwise, if a normally "temporary address only" device has temporary
addresses disabled, the result would be to have no IPv6 addresses on
the device at all, making it entirely unreachable via IPv6.

So using and having available the RFC7217 algorithm on a normally
"temporary address only" device means that the fall back to RFC7217
stable addresses is possible.

Of course, on a device that has both temporary and stable addresses,
RFC7217 algorithm can be used for both types of addresses.


Q. When to change IIDs?

Question regarding if/how we could prevent on-ink glitches from
triggering IID rgeneration?

It's my understanding that the trigger events for generating a new
temporary address for a prefix are:

- Receiving an RA with new and formerly unknown PIO prefix

- Ageing out of an existing temporary address


So a link down/up event shouldn't directly cause new temporary
addresses to be generated.

However, indirectly a link down/up event could indicate that the
device has moved to a new link, and therefore there would be new PIO
prefixes received in the RAs the new link. In that case, new temporary
addresses would need to be generated for the new PIO prefixes.

Device implementations that remove all IPv6 addresses from an
interface upon a link down event regardless, would be prone generating
new temporary addresses upon each link flap. They'd also be prone to
causing excessive multicast DAD and MLD Solicited Node Group
membership traffic as they generate new addresses each time the link
flaps.

These implementations should probably implement Detecting Network
Attachment in IPv6 [RFC6059] or similar to determine whether they're
reattaching to the same network or a new one upon link down/up event,
and only generate new temporary addresses if attaching to a new
network. It would also be better if they delayed removing obsolete
addresses from their interfaces until after the DNAv6 old link/new
link determination had been made, rather than directly after the link
went down.


I think there is a case for having Link-Local temporary addresses too
(which I'll describe later). As there is no RA PIOs for the Link-Local
prefix, then I think DNAv6 is probably the only way to determine
whether to generate a new Link-Local temporary address or not.


Q. Requirements for temporary IIDs

I.e. incorporate into rfc4941bis or not?

I think it is good to couple together requirements and the
corresponding solutoin in the same document so that people can see how
the soluton is solving the problem.

However, perhaps if there is the possibility of a future alternative
and unrelated solution, then separating the requirements out into a
separate document could be useful. An example would be that that the
requirements for DHCPv6-PD are in a separate RFC [RFC3769] to that of
of DHCPv6-PD itself [RFC3633].


Q. On by default?


I think they should be enabled by default, as it would be consistent
with the advice in BCP188/RFC7258, "Pervasive Monitoring Is an
Attack":

"Pervasive monitoring is a technical attack that should be mitigated
   in the design of IETF protocols, where possible."


I think there could be a specific exception, where it is clear and
obvious that the IPv6 implementation will be being used on a device
that does not have any privacy requirements that temporary addresses
satisfy. For example, I don't think a single purpose router device's
IPv6 implementation would have a need to have these devices enabled by
default, as it is usually not running any end-user applications, due
to it having a relatively limited CLI.

A server implementation of IPv6 may not have that requirement either,
although system administrators do occasionally run end-user
applications on a server's console/screen, and those applications
should be using temporary addresses.

So the exception to the default of enabling them should be dependent
on a clearly identified implementation role and its privacy
requirements, and if there is any ambiguity at all about that role or
its need for address privacy, then temporary addresses should be
enabled by default.


Also, as discussed later, I think there should also be temporary
Link-Local addresses for devices that need temporary addresses. As
temporary global and link-local addresses would cover all current
types of addresses, with exception to the loopback address (which I
think could be considered to be a "node-local" scope address type),
perhaps the default temporary address recommendation should be more
broad - temporary addresses should be enabled by default for all
address types except when there are specific reasons for exceptions -
e.g. loopback address, the device cannot or is very unlikely to be
used to run end-user applications.


Some Other General Thoughts
~~~~~~~~~~~~~~~~~~~~~~~~~~~

- Temporary Link Local Addresses Are Necessary


I think devices should also have temporary link-local addresses.

For a stable RFC7217 link-local address, the link-local prefix is
constant across all networks/links, and the Network_ID parameter in
the RFC7217 algorithm is optional. So for implementations that don't
use Network_ID, a device will probably a persistent, stable, globally
unique Link-Local address on its interface, regardless of the network
it attaches to, unless one of the other RFC7217 parameters happens to
change e.g. DAD_Counter.

Even if the implementation does use Network_ID, it is possible that
the value could be the same across different networks. An example
would be where same Wifi SSID at different locations, such as hotel,
cafe and shopping centre chains. The exact same Wifi SSID is also be
used widely by telcos who provide mobile to Wifi offload via their
customers' CPE.


Furthermore, a device would announce its attachment to a network using
the stable, likely globally unique RFC7217 link-local address, because
the address will be used as the source address for the Router
Solicitations the device sends upon link attachment.

Link-local addresses can also be and are preferred as source addresses
for application connections if there is a choice, so they could also
be used for any application level unique end-user or device tracking,
as long as the application level logger is on the same network as the
device. For example, an on-link DNS resolver that the device uses that
is on the link, which is reached using Link-Local addresses, could log
the stable RFC7217 link-local addresses of requests.

So stable, globally unique RFC7217 link-local addresses could be used
to record a device's visits to the same network, to different networks
if either Network_ID isn't used or is the same across the different
networks, and used to record application level use by a globally
identifable device as long as the device an the application level
logger are on the same link and using link-local addresses.



General Comments on ID Sections
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


- Abstract

If agree with LLs also needing temporary addresses, then mention of
them as an address type here too in additon to global scope address
type.

Or, if agree that temporary addresses should be the default all
address types with exception to loopback, then mention that instead.


- 2.2 Possible Approaches

Suggested section to mention fall back to generating stable RFC7217
addresses if temporary addresses are disabled on a normally temporary
address only device, probably as part of the "On the other hand, a
machine that functions only as a client ..." paragraph.


- 3.2.2 Hash-based Generation of Randomized Interface Identifiers

As mentioned before, I think RFC7217 should be the single agorithm.

However, rather than modifying it, I think it would be better to keep
it and its parameters inputs and parameter names the as close as
possible to stable RFC7217 algorithm, which better leverages reusing
the stable RFC7217 algorithm's implementation code.

To use the stable RFC7217 algorithm to generate temporary addresses, I
think the following changes to how it is used.

Firstly, the 'secret_key' parameter value is generated the same way as
for stable RFC7217 addresses, i.e. a pseudo-random number of at least
128 bits. However, rather than storing it and reusing it, a new
'secret_key' value is generated each and every time the RFC7217
algorithm is used to generate a temporary address.

Secondly, I understand that there can be some issues with system
pseudo-random generators on virtual machines because the don't have
good hardware input sources. So as some temporary address RFC7217
input redundancy, I'd suggest that the DAD_Counter is incremented each
and every time the RFC7217 algorithm is used to generate a temporary
address.

I'm certainly no expert in this area, however it seems to me that it
could be useful to try to avoid having the pseudo-random number
generator be a single-point-of-failure while trying to reuse as much
as possible the RFC7217 algorithm for temporary addresses.

Per the existing advice, a MAC address could be recommended as the
default value for Net_Iface when it is random, and new IPv6 temporary
addresses generated when the random MAC address is changed. It is
probably worth noting that some link-layers don't have link-layer
addresses at all e.g. PPP. I'm not sure if it is necessary to do
anything about those types of link-layers if 'secret_key' and
DAD_Counter are changed as above each time a temporary address is
generated.

All other parameters for the RFC7217 algorithm would be collected
using the same implementation mechanisms as when the RFC7217 algorithm
is used to generate stable addresses.

If the RFC7217 algorithm used for temporary addresses is exactly as
described in RFC7217, with a variation in a couple of input
parameters, then I think it is only necessary to describe in this
document the difference in how it is used, and reference RFC7217 as
the authoritative source for the algorithm.


- 3.3 Generating Temporary Addresses

Per previous private feedback, a number of the steps in this section
are using the generation of stable addresses as the trigger for
generating temporary addresses, which is probably hang over text from
RFC4941 text. So the text will need to be changed to decouple
generating temporary addresses from stable address generation events.

The above answer to the IETF 102 question about flapping links causing
excess temporary address generation relates to this section.

- 3.4 Expiration of Temporary Addresses

Regarding the suggested optional optimsation of removing deprecated
temporary addresses if theyy're not being used by applications, there
possible needs to be some more consideration and text for this, in the
context of RFC4861, "5.5.4.  Address Lifetime Expiry".

Firstly, it would be overriding a MUST default behaviour for the use
of deprecated source addresses for new connections:

"An implementation MAY prevent any new communication from using a
   deprecated address, but system management MUST have the ability to
   disable such a facility, and the facility MUST be disabled by
   default."


Another related issue is the use of these temporary addresses for
incoming connections. This use isn't specifically excluded in this
draft, and I'm reminded of a Peter Gleitz and Steve Bellovin paper,
which is an idea that isn't too far from hosts having limited lifetime
temporary addresses independent of applications.

"Transient Addressing for Related Processes: Improved Firewalling by
Using IPV6 and Multiple Addresses per Host" (TARP)
https://www.cs.columbia.edu/~smb/papers/tarp/tarp.html

RFC4861 says

"IP and higher layers (e.g., TCP, UDP) MUST continue to accept and
   process datagrams destined to a deprecated address as normal since a
   deprecated address is still a valid address for the interface."

So unless the use of these temporary addresses for incoming
connections is explicity prohibited by this specification, the
suggested optimsation might be too contrary to what RFC4861 specifies.

- 3.5 Regeneration of Randomised Interface Identifiers

Perhaps a mention of on-demand, application generation of temporary
addresses as possible future work, and a reference to TARP (as
mentioned above). I think an on-demand TARP like scheme would further
increase privacy, while avoiding the performance impact of timer based
temporary address generation with low value timers.

Another more general observation that may be worth mentioning is these
timer driven temporary addresses are providing a baseline minimum and
also enforced level of address privacy. As these addresses will be
deprecated based on timer expiry, an application's of them will be
constrained, regardless of if the application would like to use the
address for longer than the temporary address lifetime.

Regarding the final paragraph, I think it would be good to make it
more clear that a "new link" is a different link, and that the
different link would have different on-link prefixes and therefore RA
PIOs. The new RA PIO prefixes would trigger the generation of new
temporary addresses.

(I wonder if we need to worry about a scenario where there is the same
prefix both on the old and new different link. It's a fault if it is
unintentional, however if intentional, than that is saying that the
prefix is an anycast prefix. In an anycast scenario, is there reason
to generate new temporary addresses for the prefix, or is it
acceptable to keep the old ones. A corner case situation, but not an
invalid one.)


- 3.6 Deployment Considerations

Regarding implementations providing a method to switch off temporary
addresses entirely, it probably doesn't need to be said how that would
be facilitied, as it's probably obvious that it would be an on/off
configuration setting or checkbox somewhere in the device.

Disabling on a per-prefix basis on an individual device is probably
less obvious, however the suggestion could be that once a prefix is
learned via an RA PIO, there is a configuration item or user interface
that provides temporary address on/off setting or checkbox for the
learned prefixes.

However, I don't think it is obvious how to disable temporary
addresses entirely or on a per-prefix basis at a site / network level.
Is there a mechanism available to do this, or is one being worked on
e.g. a DHCPv6 option? If there isn't, then it is probably best to say
that an IPv6 protocol mechanism for site wide disabling of temporary
addresses entirely or per-prefix doesn't currently exist, and that
this would have to be achieved via some out-of-band host configuration
method.


A related thought to site or network level disabling is that the
end-user of a device may have a different and greater privacy need and
expectation than what the site's administrator believes is needed and
expected. If privacy was breached because the site administrator
disabled temporary addresses, the end-user would be the privacy breach
victim, while the site administrator is less likely to be.

So even where the site administator is trusted, I think it should be
required that the device's end-user is given the final say on whether
temporary addresses are disabled or not, through some sort of positive
acknowledgement of acceptance of the policy that temporary addresses
are being disabled (either entirely or on a per-prefix basis.)

This sort of positive acknowledgement becomes essential if the site
administrator is less trusted or untrusted. For example, I wouldn't
want to attach my laptop or mobile phone to a hotel, conference or
cafe's networks and then have them disable privacy addresses on my
device without me accepting that. If there was an attempt to disable
privacy addresses, I'd instead choose not to use their network.

So possibly this ID needs to say that a device needs to have some form
of authenticated proof of administrative authority before it will
disable temporary addresses. Choosing to attach to a network is not
enough evidence, which means that then receiving e.g a DHCPv6 option
to disable temporary addresses would not disable them. As mentioned,
even if this authenticated proof of device administrative authority
exists, the end-user should still be required to positively
acknowledge temporary addresses being disabled.

(And of course, this is overlooking the problem of end-users ignoring
and clicking-through security warnings like they do with self-signed
or expired HTTPS certificates. Perhaps the advice should really be
that temporary addresses cannot be turned off, and for sites that wish
to have end-user address use level accountability and auditing, the
site should use someting like link-layer end-user authentication such
as 802.1x, with SAVI and something to report identified end-user
addresses use.)



Regarding the comment about a single node using a single prefix, and
therefore the single prefix subnet identifier becomes a single node or
end-user identifier, a mitigating factor is that the remote malicious
actor needs to assume or somehow determine that this is the address
assignment policy. This may be easy to assume if e.g. the Autonomous
System Number that the IPv6 addresses come from corresponds to a
mobile telco, with /64s being assigned to each "User Equipment" i.e.
phone.

For other ASNs that have a more diverse customers types could take
prefix subnet allocation measures to hide the assignment of a single
prefix to a single device, by e.g. allocating a /48 or /56 to each
customer, resembling a conventional broadband address space allocation
scheme, and then assigning a /64 from that allocation to the
individual device. The use of one or a small number of prefixes within
the /48 or /56, with a the single device periodically changing its
IID, would externally look more like multiple devices using the subnet
rather than a single one.


- 4. Implications of Changing Interface Identifiers

Regarding debugging and troubleshooting, logging of which temporary
addresses were used by which application and when on the temporary
address device itself would also be useful. It probably should be a
capability of the temporary address implementation to be able to
switch this sort of logging on and off.


- 6. Future Work

In addition to Onion routing, Transient Addresses for Related
Processes (referred to above) and similar, which could provide
applications with their own on-demand may be future work worth
pursuing, as it may provide better address privacy through shorter
lived addresses, while also avoiding the performance impact that timer
based temporary addresses would impose if they had low timer values.