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

From: Mark Smith <[email-masked]>
Date: Fri, 1 Mar 2019 21:29:33 +1100

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.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Mar 2019 04:13:58 -0300

Hello, Mark,

Thanks *a lot* for your review! -- Please find my comments in-line....

> IETF 102 Questions

Do you mean that:
1) The "a la rfc7217" should be kept, along with the other algorithms?, or,

2) that "a la rfc7217" should be kept in the doc, and the other
algorithms should be removed?, or,

3) something else?

> addresses to be generated.

[me thinking out loud]

Maybe one additional item to consider here is whether keeping the
addresses might expose the previous addresses on a possibly new network?

Maybe one possible alternative could be to tie generation of new privacy
addresses to the underlying MAC address in the sense that:

1) If you've produced a new randomized mac address, then you should also
produce new temporary addresses.

2) then, despite 1), if the node implements DNAv6, and attachement to a
new network is inferred, also regenerate the temporary address?

> whether to generate a new Link-Local temporary address or not.

fwiw, at the time of this writing, there's not really such a thing as
"temporary mac addresses".

> of DHCPv6-PD itself [RFC3633].

It would seem to me that there will not be multiple solutions to this.
If anything, this document may contain a few possible algorithms to
generate randomized IIDs...

So, in that case, it would seem that the best way to go would be to keep
the requirements here...

>    in the design of IETF protocols, where possible."

Agreed.

> to it having a relatively limited CLI.

I wonder what's the way to go here:
1) Incorporate an Applicability statement, or,
2) Simply assume that a router will not implement rfc4941bis

Thoughts?

> used to run end-user applications.

It would seem to me that since link-locals essentially have the same
scope as the MAC addresses, then one might want that, for temporary-only
addresses, one might want to use the MAC address for the Network_Iface
parameter in RFC7217, such that a new randmized mac addresses will
result in a new link-local address.

*For temporary-only hosts*, changing link-local addresses upon change of
the underlying mac address would make sense. OTOH, if it's
stable+temporary it wouldn't make much sense.

Thoughts?

> Some Other General Thoughts

How about using the MAC address for Network_Iface?

> used widely by telcos who provide mobile to Wifi offload via their

Agreed. But this should be chained to the mac address. -- I.e., changing
the link-local address while maintaining the underlying mac address
wouldn't make much sense...

> General Comments on ID Sections

Unless a significant number of folks comment on this issue, I will start
a new thread to get input from the wg -- particularly because this is a
change from rfc4941.

> machine that functions only as a client ..." paragraph.

Point taken.

> as possible the RFC7217 algorithm for temporary addresses.

One argument that was made in favor of using the prng was that in the
event a flaw were found, it would be addressed by the OS... whereas if
we were to use something else, then any flaw in the algorithm we use
would have to be specifically fixed for temp addr generation.

However, the scheme you propose seems to be a mix of both.. so it should
be okay.

> DAD_Counter are changed as above each time a temporary address is

Not really. As long as one or some of the arguments to the hash function
change, we're fine....

> generating temporary addresses from stable address generation events.

Good point. Will do.

> excess temporary address generation relates to this section.

Could you please elaborate?

>    disable such a facility, and the facility MUST be disabled by

Is this a quotation from RFC4861?

If not, I'n unroll the double-negation , which makes it harder to parse
the text.

> suggested optimsation might be too contrary to what RFC4861 specifies.

I agree with this. However, this seems to go a bit over rfc4941bis -- se
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations

... and there's the tricky bit of how to handle connectionless protocols
such as UDP.

I will raise the topic in a separate thread to the wg.. but i'd believe
that this is kind of "out of scope" for rfc4941bis

> temporary address generation with low value timers.

Yes.

> address for longer than the temporary address lifetime.

Could you please elaborate?

> PIOs. The new RA PIO prefixes would trigger the generation of new

I'd say that we could point to DNA or elsewhere... but getting into
details on "how to detect a new link" would seem like opening a can of
worms for this document.

Thoughts?

> prefix is an anycast prefix.

Or could be ULA...

> this would have to be achieved via some out-of-band host configuration

My understanding is that this "site settings" are actually host-based
settings.

> are being disabled (either entirely or on a per-prefix basis.)

I think this would be getting into too many details. Besides, at the end
of the day, the site rules. e,e,g, a site mite limit the number of
IPv6addresses per underlyng MAC address, etc.

> privacy addresses, I'd instead choose not to use their network.

There's no mechanism available for the network to convey this info --
hence, you try to use temp addresses... and they may or may not work....

> mobile telco, with /64s being assigned to each "User Equipment" i.e.

Well, if you get PERIODIC connections fROM the same , say /64 , only one
address is active at a time, and then eventually the address changes...
then it's possible to infer that it's just a single host....

> rather than a single one.

THat would be the case if the addresses were "use and throw away". But
if temp addresses are refreshed every few hours, then stability period,
and change of active address with no overlapping period will essentially
leak that's it's just a single host.

> switch this sort of logging on and off.

You mean include the port numbers in the log, or what?

> based temporary addresses would impose if they had low timer values.

And there's the API issue, too. see
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations

Thanks!

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

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Mar 2019 15:23:15 +1100

Hi Fernando,

> algorithms should be removed?, or,

Single algorithm. Stable RFC7217, with minor adjustments to input parameters.

> new network is inferred, also regenerate the temporary address?

It really depends on whether implementations are going to be smart
about what the cause of an interface down/up event is.

If they're going to be simple, and always assume that a interface
down/up event is always a movement to a new network, then temporary
addresses will have to be removed and then generated upon every
interface down/up event. This issue will be ignored.

> "temporary mac addresses".

Easy to miss, I am referring to temporary FE80:: addresses, not
temporary MAC addresses.

> 2) Simply assume that a router will not implement rfc4941bis

Given how critical privacy is, an Applicability statement.

I think it is reasonable to assume any time there is ambiguity about
what is required, privacy will be compromised. So we need to be
prescriptive.

> stable+temporary it wouldn't make much sense.

I think it is a mistake to be so tightly coupling IPv6 temporary
addresses to random MAC addresses and when they're generated.

> How about using the MAC address for Network_Iface?

This is starting to sound like it is turning into a specification for
when MAC addresses need to be randomised.

> wouldn't make much sense...

At this point, if this is the direction, then I'd suggest:

- abandon this Internet Draft

- write a new Internet Draft that says,

  - random MAC addresses are required

  - how often MAC addresses are randomised

  - state that every time the MAC address is randomised, re-execute
stable RFC7217

  - private/temporary IPv6 addresses are not available on link-layers
that don't have link-layer addresses

I wouldn't agree with that approach, the link-layer and network layer
are supposed to be decoupled as much as possible, not coupled as
tightly as possible.

I don't really want to spend anymore time on this until it is decided
whether random MAC addresses are required, otherwise I'm going to have
to constantly be saying, "Assuming there are no random MAC addresses,
" for every comment the rest of this email.

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Mar 2019 23:03:43 +1100

Hi Fernando,

A bit more broader follow up.

> Hi Fernando,

So I've realised I may have taken the wrong approach with this review. I
took the approach of treating it like it was a brand new ID, as usually
that's what I read. Consequently it means that I start with a view point of
there being a lot more flexibility in what can be changed. It also meant
that I have made suggestions that could have also applied to RFC4941 itself
and perhaps its ancestor.

I'm starting to wondering about what level and amount of change could be
made in RFC4941bis.

I think there are two possible types of change:

- do an incremental update to RFC4941, resolving specific direct issues
with RFC4941 i.e. allow devices to have only temporary addresses and
replace MD5 with a different and better hash function.

- design a "next generation" RFC4941, starting by revisiting the problem
space, incorporating things that have been learned, possibly unrealised
threats when RFC4941 was developed, and leveraging mechanisms that have
been invented since RFC4941, was developed, such as RFC7217, and then do a
new design that satisfies those requirements (while leveraging existing
RFC4941 methods/mechanisms if useful).

For example, the threat that inspired my thoughts on also having temporary
Link-Local addresses is that there is now active collecting of Wifi MAC
addresses and also bluetooth addresses in public places to track people's
locations (see http://www.earthping.com/ for the bluetooth example, which I
came across because I looked for Android apps that would discover
advertising bluetooth devices - "Bluetooth 4.0 Scanner").

I could see it would be easy to do something similar with globally unique
stable Link-Local addresses that RFC7217 generates (and I've since realised
that a link doesn't need to have an IPv6 router - hosts will send out IPv6
RSes with LL src addrs on an IPv4 only link, and that's enough to record
their identity and location.)

The inclusion of the RFC7217 algorithm made me think it was the latter.
There would be more freedom in that case. On the other hand, if it is just
an incremental update, then I wonder if including the RFC7217 algorithm is
too much of a change.

Regards,
Mark.