Subject: last call comments for draft-ietf-6man-stable-privacy-addresses-06

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Apr 2013 08:20:15 +0200

In the process of doing the apps area review, I came across some points
that were not related to applications.  The basis for these comments is
precisely the sentiment that Russ Housley expressed, which is that the
specification is done when there is no more to remove.  With this
document, I wonder if quite a bit could be removed.

Specifically, a great deal of discussion goes into the PRF involving DAD
counters, etc, when all that is needed is a suitable PRF.  The draft in
fact says this in Section 3 after an explanation of the inputs.  Any PRF
that follows the guidelines of RFC 4086 should do fine and not cause
interoperability OR security problems.  Put simply, you are
over-specifying the RID and derive no benefit from doing so.

Also, the following text in section 3 Page 7 is contorted:

      This means that this document does not formally obsolete or
      deprecate any of the existing algorithms to generate Interface IDs
      (e.g. such as that specified in [RFC2464]).  However, those IPv6
      implementations that employ this specification must generate all
      of their "stable" addresses as specified in this document.

My suggestion is to simplify remove it as it is self-evident.

Finally, this algorithm requires that the resultant host portion be 64
bits.  Is that necessary?

Eliot

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Apr 2013 11:06:01 -0500

Hi, Eliot,

On 04/22/2013 01:20 AM, Eliot Lear wrote:
> specification is done when there is no more to remove.

I'd probaby disagree with such statement. One thing is removing tuff
from the mechanism or algorithm that you're standardizing, in the hopes
of keeping it simple (this one I'd agree with). Another is removing text
from specifications, which essentially means that the gut implementing
the spec has more to figure out by himself, and hence more chances for
failures.

>  With this
> counters, etc, when all that is needed is a suitable PRF.

Not sure what you mean...What's thetext that you think could/should be
removed?

> The draft in
> interoperability OR security problems.

If you're referring to the text that explains why we're not mandating
any specific PRF, that text is there because the issue was raisen in the wg,

> My suggestion is to simplify remove it as it is self-evident.

What's the part that is evident? The one about not deprecating existing
algorithms? -- Because the other ne certainly isn't: if you're going to
use this algorithm for generating addresses *in addition* to those
generated by traditional SLAAC, then this document wouldn't mitigate
address-scanning attacks.

> Finally, this algorithm requires that the resultant host portion be 64

Well, yes- If the PRF produces a bit string larger than 64 bits,  and
you say nothing about how you grab the IID, then the algorithm is
underspecified.

The easier it is for a developer to go through this document and come up
with an implementation, the better. The more the open questions, the worse.

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Apr 2013 18:22:24 +0200

Hi Fernando,

Thanks very much for your response.

> the spec has more to figure out by himself, and hence more chances for

Fair point, of course.

> Not sure what you mean...What's thetext that you think could/should be

Sorry I wasn't clear: what is the benefit of specifying the algorithm,
when simply popping out another PRF will in just about any instance do
the job (unless you are reinitializing the PRF with the same seed)?

> any specific PRF, that text is there because the issue was raisen in the wg,

Ok.  So what I gather is that there was a negotiation within the WG and
that the algorithm is optional.  Ok.  From an outside point of view, I
didn't need to know that, and the question is what was the value of
still specifying the PRF.  I think Ran Atkinson answered that.  He feels
he wants a fully specified algorithm from which to start.  Ok.  My only
response is that I don't understand the need (generating 64 bits that
aren't the same shouldn't be that hard), but if the WG really believes
there is one, okay.

> address-scanning attacks.

How would an IPv6 implementation employing this specification vary from
this specification in a way you or the working group would find
objectionable?  Also, did you mean "MUST"?  If not, this language is all
the more confusing and I don't know what you mean.

> with an implementation, the better. The more the open questions, the worse.

I think we are underestimating our developers but if the working group
feels differently, okay.  I asked the above question because it is at
least conceivable that at some point host portion != 64 bits and this is
the only place in the document where the requirement is stated.  Yes,
screwing with the 64 bit boundary today is bound to cause all sorts of
breakage.  I'm not thinking of today but the future.  And yes, another
argument would be that there isn't enough address space for this to be
effectively private.  Those are two different issues, but fixing the
boundary here reminds me of mistakes we made with IPv4 way back when. 
In this day and age we're talking about a lot more cleanup later.

Eliot

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Apr 2013 14:23:11 -0500

Hi, Eliot,

> the job (unless you are reinitializing the PRF with the same seed)?

There seems to be a disconnect here:

We want an algorithm that, roughly speaking, whenever you connect to the
same network, gives you the same address. But such address should be
different for each network you connect to.

The question here is: How do you achieve that?

You might argue that, clearly, the autoconf prefix needs to be part of
the seed (I'd personally not expect developers to figure this one out).

But there are more issues. e.g., say that my node has to network
interfaces. If I use both of them to connect to the same network, the
address they get should be different (but still have the same properties
stated above). How do you achieve that? -- Well, yu need *something*
that changes from one interface to another. But even if you figure
*something* you mght use for that it might be non-optimal. -- for
example, if you use the MAC address, then your address changes if you
replace the NIC. If you use the interface index, it doesn't.

At the end of the day, the devil lies in the small details.

And I'd argue that if it had all been that obvious, it'd have been done
before.

> that the algorithm is optional.

The "negotiation" was that this dspec does not replace the traditional
slaac algorithm that, in the case of Ethernet, embeds IEEE identifers in
the Interface ID.

> Ok.  From an outside point of view, I

We're not just "randomizing" the addresses. The are *constant* within
each network, but change across networks.

> objectionable?  

If, for the same interface you employ this algorithm *and* the
traditional SLAAC algorithm, that's objectionable.

> Also, did you mean "MUST"?  If not, this language is all

Yes, I meant "MUST". -- I will fix this.

> feels differently, okay.

I don't think so. Lots of folks code on so many different areas, that
it'd be unrealistic to expect them to figure everything out by themselves.

Yes, there are some smart folks that can figure a lot by themselves...
but that's the exception rather than the rule.

And even if they were all that smart, we want to make their lives
easier: the less they have to figure out by themselves, the better.

> I asked the above question because it is at
> breakage.

My understanding is that we're all set for 64-bit identifiers -- with
the exception of point to point links where subnets < 64 bits are
allowed (fro the most part, as a workaround to buggy implementations
that are vulnerable to NCE attacks).

> I'm not thinking of today but the future.  And yes, another

I guess this raises a more fundamental question with respect to whether
we want 64-bit identifiers to be the standard, or not.

A compromise might be to add a *parenthetical* note such as:

"The current IPv6 Addressing architecture defines Interface-Identifiers
to be 64 bits long, hence the low-order 64-bits of F() are employed for
the Interface-ID. Were the IPv6 Addressing Architecture updated to allow
any arbitrary length for the Interface ID, an implementation would need
to be prepared to select as many bits from F() (rather than the fixed
64-bits specified above) for the Interface ID, such that an Interface ID
of appropriate length is obtained"

I'd personally have no issues with that *if* the wg agrees. But I
wouldn't want to remove the text on grabbing the low-order 64-bits,
since that's makes the spec more clear for the current times.

Thanks,

---

From: Philipp Kern <[email-masked]>
Date: Mon, 22 Apr 2013 20:04:27 +0200

Eliot,

am Mon, Apr 22, 2013 at 06:22:24PM +0200 hast du folgendes geschrieben:
> I asked the above question because it is at least conceivable that at
> some point host portion != 64 bits and this is the only place in the
> document where the requirement is stated.  Yes, screwing with the 64
> bit boundary today is bound to cause all sorts of breakage.  I'm not
> thinking of today but the future.  And yes, another argument would be
> that there isn't enough address space for this to be effectively
> private.  Those are two different issues, but fixing the boundary here
> reminds me of mistakes we made with IPv4 way back when.  In this day
> and age we're talking about a lot more cleanup later.

especially as there are already existing RFCs that are flexible in the
boundaries. Oddly RFC 4862 IPv6 Stateless Address Autoconfiguration is
one of them (e.g., 5.3, the creation of the link-layer address), which
is pretty much fixed by implementations to operate at the 64 bit
boundary. Granted, that's mostly when dealing with Ethernet-based
infrastructures and the document does explain that the length of the
interface identifier depends on the link type (5.5.3 d).

Kind regards
Philipp Kern

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Apr 2013 22:30:59 +0200

H Fernando,

> different for each network you connect to.

Thank you, and yes there was a disconnect.  Indeed now I get it.  For
some reason I had assumed that you meant for some short period of time,
but the algorithm is clearly aimed at longer periods of time (e.g.,
across reboots).  Given that, the inputs the WG has stated seem
perfectly reasonable.

> traditional SLAAC algorithm, that's objectionable.

Right.  With you now.

Thanks again...

Eliot

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Apr 2013 13:07:54 -0700 (PDT)

Hi,

<snip>

> since that's makes the spec more clear for the current times.

While this part of RFC4291 should make the 64 bit statements safe:

"For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format."

The /127 prefix length RFC changed that, so I'd suggest it might be safer to generalise and say take the number of bits from the hash that correspond to the IID length in use, and then reference 64 bit IIDs as an example.

Regards,
Mark.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Apr 2013 16:41:43 +0000

> We want an algorithm that, roughly speaking, whenever you connect to the same network, gives you the same address. But such address should be different for each network you connect to.
> 
> You might argue that, clearly, the autoconf prefix needs to be part of the seed (I'd personally not expect developers to figure this one out).

This is the kind of attitude that really does not go well with actual developers. You are basically saying that you expect developers to be too dumb to understand what they are doing, and thus you feel compelled to specify an algorithm in its most minute details, even though there are dozens of equally good ways to achieve the same result. The net result of such over-specification is that developers will discard the spec as arrogant, and implement what they fell like implementing. 

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Apr 2013 16:41:54 -0500

On 04/23/2013 11:41 AM, Christian Huitema wrote:
>> You might argue that, clearly, the autoconf prefix needs to be part
>> of the seed (I'd personally not expect developers to figure this
>> one out).
> 
> This is the kind of attitude that really does not go well with actual
> developers. You are basically saying that you expect developers to be
> too dumb to understand what they are doing, 

You're misreading me.

I'm saying that developers work across across many different areas and
are busy people, and I cannot expect them to figure out stuff what *we*
were lazy or dumb enough to leave unspecified.

If I'm the guy producing a spec, my goal is to produce a spec that is
clear as possible, and only leave open those bits that are necessary to
leave open.

> and thus you feel
> compelled to specify an algorithm in its most minute details, even

That's incorrect. For instance, that's why we don't mandate a specific
PRF: because for that particular case, developers are in a better
position of judging what's the best PRF to use.

> though there are dozens of equally good ways to achieve the same
> result.

So far you have only mentioned one (recording the Prefix/IIDs pairs),
which IMHO is not elegant. Any others?

FWIW, you'll realize that e.g. RFC 4941 has even more detail than this spec.

> The net result of such over-specification is that developers
> will discard the spec as arrogant, and implement what they fell like
> implementing.

I cannot control people's thoughts. However, I'd say that I'm fairly
well-known for socializing stuff among developers, well-before a
document is published as an RFC.

Much of the work that I've done over these years have resulted in
patches from a variety of OSes, because I cared to discuss them with
developers. Of course, documents that I've authored have benefited from
input from developers during that discussion process.

(Not to mention that the contents of the documents I've written have
generally been very influenced by the input of a number of
participants... anyone who has ever sent me feedback on a document I've
authored/co-authored knows I do my best to address all feedback, no
matter whether that implies re-writing large portions of the document in
question.)

Make the spec as clear as possible save time and energy on all sides.

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Apr 2013 00:45:12 +0000

> If I'm the guy producing a spec, my goal is to produce a spec that is clear as possible, and only leave open those bits that are necessary to leave open.

Well, that might work for internal specs when you are managing a project, but that's probably not the right way to approach standards. A standard, being the rules of the network, shall only constrain what must be constrained for interoperability. 

All implementations are tradeoffs. Developers will necessarily make them, based on the different resource, priorities, usage scenarios. It is much better to explain to give clear guidelines than to merely mandate an implementation.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Apr 2013 20:28:06 -0500

On 04/23/2013 07:45 PM, Christian Huitema wrote:
>> If I'm the guy producing a spec, my goal is to produce a spec that
>> is clear as possible, and only leave open those bits that are
>> necessary to leave open.
> 
> Well, that might work for internal specs when you are managing a
> project, but that's probably not the right way to approach standards.

That probably depends on *what* you're specifying (please see below).

> A standard, being the rules of the network, shall only constrain what
> must be constrained for interoperability.

This document is not about a rule of the network, but about a local
policy. Therefore, by definition, as long as the address you select is
unique, nothing in this document will affect interoperability.

> All implementations are tradeoffs. Developers will necessarily make
> them, based on the different resource, priorities, usage scenarios.
> It is much better to explain to give clear guidelines than to merely
> mandate an implementation.

We probably have different views here. We're not mandating an
implementation (e.g., we're not mandating any specific PRF for F(), nor
how you store addresses in memory if you do store them).

I see the algorithm in this document as giving more room for tradeoffs
to developers than RFC4941, and the same room for tradeoffs as e.g. RFC6528.

Based on the above, me, I don't find the idea of re-writing the I-D
compelling -- particularly at this point in time.

Thanks,