Subject: Detailed review of draft-ietf-6man-stable-privacy-addresses-13 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

From: Ray Hunter <[email-masked]>
Date: Fri, 06 Sep 2013 09:56:31 +0200

The 6man chairs and the author have requested that I perform an
additional detailed review of

A Method for Generating Semantically Opaque Interface Identifiers with
            IPv6 Stateless Address Autoconfiguration (SLAAC)
              draft-ietf-6man-stable-privacy-addresses-13

High Level
==========

The document is well-written and has been subject to intense debate in
the WG.

I support taking it further.

Summary Recommendations
=======================

1. Proceed with the document and the proposed solution.

2. Given the likely ubiquitous deployment of this standard,
I think it would greatly enhance the credibility of the resulting RFC if
the WG could see running code on:
- Linux
- an embedded device or other memory-constrained device.
- (BSD implementation is already OK AFAIK)

3. I think there should be some words on the quality requirements of the
PRF F(), and also any security impact of this being weak/ predictable.

4. Add something on backwards compatibility
e.g. "An implementation MAY avoid using RIDs with u=1 if the implementor
is concerned about backwards compatibility with older SLAAC
implementations sharing the same L2 link."
Section 3 brushes this issue aside, but I still have doubts.

5. Add random delay before regenerating temporary addresses when
incrementing the DAD counter to avoid lock step behavior (section 4).

6. Clarify that "The use of non-volatile memory is optional, and hosts
that do not implement this feature are still compliant to the protocol
specification." (in section 4)

7. Restructure the intro.

8. Handle the nits.

Goals
=====

There's a balance between the requirements of an IID being opaque to
prevent unwanted correlation and tracking,
and the need for network managers to be able manage a network, and
remote users to connect to server processes.

Although far from being a universal solution, I think this document hits
the design goals that it sets out to achieve.

There are likely to be other solutions proposed for IID generation in
the future that have different design goals.
This document does not block such proposals, provided they implement DAD.

The incorporation of the shared secret mitigates that bad guys can
trivially guess or correlate
the opaque IID with much certainty when machines change IPv6 prefix
(although I recognise that there's a limited number
of bits of entropy in an IID and there are plenty of other mechanisms
that can be used
to achieve the same result.)

There is also extensive documentation on the "how to" section of the IID
generation,
which is likely to be useful if at any time the opaque IID has to be
"predicted" remotely by an administrator
who is a "good guy" (and thus who knows the shared secret and PRF).

Future Innovation & Backwards Compatibility
===========================================

A possible future extension of this IID generation mechanism (which is
currently contentious) could be to allow
SLAAC with IID of lengths other than 64 bits, and thus allow coexistence
of full CIDR + autoconfigured IPv6,
which could potentially solve issues with mobile tethering and Homenet
using a single /64 delegation.

Section 3 addresses backwards compatibility.

Technical
=========

I have some doubts about the (lack of) specification of the PRF F().
Achieving 64 bits of entropy is not trivial (especially on smaller
systems or those without many external inputs)

/IPv6 implementations conforming to this specification MUST generate
   Interface Identifiers using the algorithm specified in this section
   in replacement of any other algorithms used for generating "stable"
   addresses with SLAAC/
  
Is this MUST per interface or per IPv6 node?

AFAICS there'd be no harm if a specialised LAN interface on a router
used MAC based SLAAC on one interface, but opaque addresses on another.

/Implementations conforming to this specification SHOULD provide the
   means for a system administrator to enable or disable the use of this
   algorithm for generating Interface Identifiers./
  
Again, per interface or per node?

Section 3 brushes aside likely IID collisions with older SLAAC
implementations  but I still have doubts.
How about "An implementation of this algorithm MAY avoid using RIDs with
u=1 if the implementor is concerned about backwards compatibility with
older SLAAC implementations sharing the same L2 link."

Section 4 /Resolving Duplicate Address Detection (DAD) conflicts/
Should there be some words about random back-off / retry time to avoid
nodes lock-step incrementing the DAD counter?

e.g. "Hosts SHOULD introduce some random delay before regenerating a new
temporary address when incrementing the DAD counter, to avoid lock-step
behavior of multiple hosts" ?

Clarify that non-volatile memory is optional (in section 4)
e.g. "The use of non-volatile memory is optional, and hosts that do not
implement this feature are still compliant to the protocol specification."

Editorial
=========

IMHO The intro is a long slog to read and could do with having some
information either culled or broken up or moved elsewhere.

Specifically: The natural end of the introduction to me is the line
"Hence, there is a motivation to improve the properties of "stable"
   addresses regardless of whether temporary addresses are employed or not."
  
   plus
  
   "This document specifies a method to generate Interface Identifiers
   that are stable/constant for each network interface within each
   subnet, but that change as hosts move from one network to another,
   thus keeping the "stability" properties of the Interface Identifiers
   specified in [RFC4291], while still mitigating address-scanning
   attacks and preventing correlation of the activities of a node as it
   moves from one network to another."

The information on "Relationship to Other standards" should probably be
separate from the Introduction, with subsections for "Temporary
Addresses", "SLAAC" and "DHCPv6" .

Key Words (2119) is also usually a separate section from what I can recall.

There are references to 2464. How about adding 2467 and 2470 or 3572?

Nits
====

indentation of /Cryptographically Generated /

indentation of / It should be noted that temporary addresses/

I understand that the indentation had some meaning, but it's lost
without the WG context.

s/ is a orthogonal to/ is orthogonal to/

s/replacing a Network Interface Card (NIC)/replacing a Network Interface
Card (NIC) or adding links dynamically to a Link Aggregation Group (LAG)/ ?

s/Including the optional Network_ID parameter when computing the RID
value above would cause the/
Including the optional Network_ID parameter when computing the RID value
above causes the/

Some pagination issues of the HTML version.

-- 
Regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Fri, 06 Sep 2013 10:25:00 +0200

Doh. Coffee hadn't kicked in.

s/temporary addresses/ a new tentative address/
 
> Ray Hunter <mailto:[email-masked]>
> 6 September 2013 09:56

-- 
Regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Sep 2013 21:58:15 -0300

Hi, Ray,

Thanks so much for the review! -- Please find my comments in-line...

On 09/06/2013 04:56 AM, Ray Hunter wrote:
> Summary Recommendations =======================
> 
> 2. Given the likely ubiquitous deployment of this standard, I think 
> it would greatly enhance the credibility of the resulting RFC if the 
> WG could see running code on: - Linux - an embedded device or other 
> memory-constrained device. - (BSD implementation is already OK 
> AFAIK)

I'm told a Linux patch is being submitted in the upcoming weeks. And
other folks are working on a BSD implementation.

My plan is to add an Ack and reference to these implementations in the
"Acknowledgements" section when they become available. I bet that by the
time the document enters the AUTH48 state, those implementations will be
out there, and I'll be able to add such acks/references.

> 3. I think there should be some words on the quality requirements of 
> the PRF F(), and also any security impact of this being weak/ 
> predictable.

mm.. should we really say more than "it is cryptographically secure", as
already stated in the document? In my head, F() would be something like
SHA-*.. but even MD5 would probably be good enough for this purpose.

> 4. Add something on backwards compatibility e.g. "An implementation 
> MAY avoid using RIDs with u=1 if the implementor is concerned about 
> backwards compatibility with older SLAAC implementations sharing the 
> same L2 link." Section 3 brushes this issue aside, but I still have 
> doubts.

I have no issues with adding that. But truth is that since Windows has
replaced the IEEE-identifier-derived IIDs with ones that use u=0. I
don't think you really improve backwards compatibility by setting u=0.

Thoughts?

> incrementing the DAD counter to avoid lock step behavior (section 

Next question is... "In what range"? 0..1 seconds?

> 6. Clarify that "The use of non-volatile memory is optional, and 
> hosts that do not implement this feature are still compliant to the 
> protocol specification." (in section 4)

Isn't that already implicit in the "MAY"?

> Technical =========

In my head, the PRF would be something like e.g. SHA-256. -- I'd argue
that even MD5 would be fine for this purpose.

F() needs to be cryptographically secure. But different implementations
may have their won preferences wrt which function to use.

> Is this MUST per interface or per IPv6 node?

The node. If you have multiple interfaces, and one of them uses a
trackable IID, you're still in trouble.

>  used MAC based SLAAC on one interface, but opaque addresses on 

I'm generally of in favor of "secure defaults". So, if we proceed this
way, I'd add "this should default to..". However, I think since we're
generally moving away from IEEE-identifier-derived IIDs, it's better
that "if you enable this, do it for all interfaces" -- "special cases
are seldomly good.

>  means for a system administrator to enable or disable the use of 
> this algorithm for generating Interface Identifiers./
> 

Per node, as per the above comment.

> implementations  but I still have doubts.

Note: One of the currently most deployed systems (Windows) has moved
away from traditional SLAAC since a long time ago

> How about "An implementation of this algorithm MAY avoid using RIDs
> with u=1 if the implementor is concerned about backwards
> compatibility with older SLAAC implementations sharing the same L2
> link."

Since we're already in the process of deprecating special bits in IIDs,
I'd prefer to use the IID as an opaque field. -- but of course I'm open
to proceed otherwise.

> Should there be some words about random back-off / retry time to 
> avoid nodes lock-step incrementing the DAD counter?
> 
> e.g. "Hosts SHOULD introduce some random delay before regenerating a 
> new temporary address when incrementing the DAD counter, to avoid 
> lock-step behavior of multiple hosts" ?

I have no objections to that. If we proceed that way, I guess the random
delay would be in the range 0..1 second?

> Clarify that non-volatile memory is optional (in section 4) e.g.
> "The use of non-volatile memory is optional, and hosts that do not 

Since this is marked as "OPTIONAL" in the algorithm spec, and as "MAY"
in section 4, I believe that's already clear. But if you still think the
clarification would be valuable, please let me know and we can add such
paragraph.

> Editorial =========
> The information on "Relationship to Other standards" should probably 
> be separate from the Introduction, with subsections for "Temporary 

Ok. I will look at the intro, and move that other text to an Appendix. I
will come back to you with a specific proposal.

> Key Words (2119) is also usually a separate section from what I can 

Some documents do it in the intro, but other do it in a separate
section. Anyway, I'll move that to a "Terminology" section.

> There are references to 2464. How about adding 2467 and 2470 or 

Sounds reasonable. How about replacing all instances of:

"(such as those specified in [RFC2464])"

with

"(such as those specified in [RFC2464], [RFC2467], and [RFC2470])"

The only downside is that there are many instances of this, and hence
the text would become a bit cumbersome.

> Nits ====

Oh... this are my parenthetical notes (borrowed in style from Rich
Stevens) that everyone hates :-). -- is there any better way to do that?

-- FWIW, these notes are text that provide additional detail, but you
may skip while reading the document.

P.S.: I *knew* you were ging to make me work! ;-)

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

---

From: Ray Hunter <[email-masked]>
Date: Sat, 07 Sep 2013 08:26:59 +0200

inline
> Fernando Gont <mailto:[email-masked]>
> 7 September 2013 02:58
> Hi, Ray,
>

Excellent.
> SHA-*.. but even MD5 would probably be good enough for this purpose.
I am thinking the opposite. Saying that "F MUST be cryptographically
secure" might be too onerous for embedded systems.

I think current reality of IID distribution (generated from MAC
addresses) is maybe just 20 to 24 bits of entropy with very significant
skew.

More entropy is better for privacy. Less skew is arguably better too.

But Appletalk Phase II Ethertalk networks settled down to stable address
assignments using just 8 bits for the NodeID even with say 100 nodes
sharing one layer2 link. OK there's little privacy, but you do have the
unique IIDs necessary for communication.

I'll leave how you properly word that requirement/compromise to the real
software engineers amongst us.

"SHOULD be cryptographically secure" would be OK by me.

> don't think you really improve backwards compatibility by setting u=0.
This is possibly paranoia on my part (thinking manufacturing/ automotive
and 30 year product life cycles plus the 100BaseTX auto config debacle
that still hits operations regularly)

If the WG has already reached rough consensus, who am I to overturn that?
>
>
>> 5. Add random delay before regenerating tentative addresses when 
Should probably be defined to be "between 0 and the DAD RetransTimer as
defined in RFC4862"
[yes, by default that's 0 .. 1]
> Isn't that already implicit in the "MAY"?
The IETF likes dense text. This is for the benefit of dense readers.
It's just one sentence. I can live without it.
> trackable IID, you're still in trouble.
ACK
> that "if you enable this, do it for all interfaces" -- "special cases
ACK
> Per node, as per the above comment.
ACK

> will come back to you with a specific proposal.
Not sure it needs an appendix. I think it is  just a question of adding
appropriate section breaks.
> the text would become a bit cumbersome.

I see your point.

The reason I specifically mention RFC3572 is that MAPOS has to
synthesise an EUI64 address (by borrowing from another interface),
because HDLC interfaces do not include the concept of a "burned in
address" (section 3 of RFC3572)

I think it would be very instructive to check if
stable-privacy-addresses are applicable to such link technologies that
have no native burned-in-address.

[I personally think stable-privacy-addresses are very applicable as long
as the interface can perform DAD, and maybe we should have picked this
up much earlier ;) ]
> Stevens) that everyone hates :-). -- is there any better way to do that?
plain vanilla text works for me.
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Sat, 07 Sep 2013 06:15:55 -0300

Hi, Ray,

Please find my responses in-line...

> secure" might be too onerous for embedded systems.

Well, the whole point of this scheme is that the IID is not predictable
by an attacker. So the properties of the function really matter.

While there'e whole range of embedded devices, I think this kind of
thing is not onerous these days.

> unique IIDs necessary for communication.

I think the constraints and the requirements of that time were quite
different (for instance, people used telnet for remote login at that time).

> that still hits operations regularly)

Just as a clarification: we're talking about a 64-bit long field. You
probably have more chances of getting into trouble due to MAC address
duplication than as a result of this.

And even then, you need to get the legacy device to bootstrap *second*
in order for this scenario to be problematic.

> [yes, by default that's 0 .. 1]

I'd probably specify a new variable rather than reference RetransTimer,
since the latter has a different purpose.

Thoughts?

> appropriate section breaks.

Ok, I see. I'll split the current intro and move part of the current
intro to a new section.

> have no native burned-in-address.

Given that stable-privacy-addresses does not require the use of
link-layer addresses, it certainly applies to those technologies (and
probably is as "general" as you can get in this respect).

> plain vanilla text works for me.

Ok, I'll do it.

Thanks!

Cheers,