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

[Fernando Gont <[e-mail]>]

Hello, Mark,

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

On 1/3/19 07:29, Mark Smith wrote:
> 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.

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?




> 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.

[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?



> 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.

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



> 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].

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...



> 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."

Agreed.



> 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.

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?



> 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.

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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> - 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.

How about using the MAC address for Network_Iface?




> 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.

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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> - 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.

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.


> 
> 
> - 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.

Point taken.




> - 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.

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.



> 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.

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




> - 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.

Good point. Will do.


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

Could you please elaborate?



> - 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."

Is this a quotation from RFC4861?

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



> 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.

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


> 
> - 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.

Yes.


> 
> 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.

Could you please elaborate?



> 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'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?


> (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.

Or could be ULA...



> - 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.

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



> 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.)

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.
>


> 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.

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....



> 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.

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....


> 
> 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.

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.


> - 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.

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



> - 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.

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492