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

From: RJ Atkinson <[email-masked]>
Date: Mon, 22 Apr 2013 09:34:26 -0400

Earlier, Eliot Lear wrote:
% Put simply, you are over-specifying the RID 
% and derive no benefit from doing so.

There is benefit to implementers in having a specific
example that is known to meet the requirements of
this specification.  This benefit also accrues to users,
as implementers are more likely to correctly implement
when giving a specific example that they may reuse.

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

It would reduce consensus within the WG and the IETF as a whole
to remove that text -- as it clarifies that other mechanisms for
generating such IDs are not affected by this specification.

Text to this effect was specifically requested by various WG 
participants, precisely because it is not "self-evident" and 
instead was confusing.

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

Yes, it is required, for technical reasons relating to multiple
IPv6-related standards-track RFCs.

I oppose Eliot's proposed edits on grounds that they would
reduce the clarity of the specification and also would
reduce IETF and WG consensus about this specification.

Yours,

Ran

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Apr 2013 09:56:59 -0400

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:

    RJ> I oppose Eliot's proposed edits on grounds that they would
    RJ> reduce the clarity of the specification and also would reduce
    RJ> IETF and WG consensus about this specification.

Ran,  I just checked, and you don't seem to be a 6man chair. We
generally ask chairs, not involved participants to judge WG consensus
and ADs to judge IETF consensus.

So, I think  what you're saying boils down to you disagree with Eliot
because you believe his comments would reduce clarity. You believe
others within the WG and outside the WG are likely to agree with you.
That's all fine and is valuable to contribute.

However, I don't think it promotes open and honest technical discussion
when participants try to call consensus. 
Thanks for considering my input.

---

From: [email-masked] (Martin Rex)
Date: Mon, 22 Apr 2013 16:32:42 +0200 (CEST)

Sam Hartman wrote:
>
> RJ Atkinson <[email-masked]> writes:
> 
> 

This applies not only to individuals alleging "consensus", but in just
the same way to WG chairs, ADs and the IESG to allege "consensus" for
a change without performing a consensus call that properly lists
options and their tradeoffs.

The only exception is, that IETF leadership (WG chairs, AD, IESG)
could assert their leadership privilege to make a specific choice.
In this case, however, they should label it as such (a leadership
decision).  For resolving issues that individuals have with
leadership decisions, there is the appeals process.

-Martin

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Apr 2013 12:03:26 -0400

>and ADs to judge IETF consensus.

Bovine dung.  Or more politely - nonsense.  Participants judge WG consensus all the time.  Occasionally WG chairs will "declare" consensus to more the process forward, but that's rarer than the normal group think.

>Thanks for considering my input.

And I don't think it promotes open and honest technical discussion when you attack "standing" of a participant who *has* participated in the formation of a document to take an action, ask a question, or make a comment, rather than addressing the substance of the comment(s) made by that participant.

It's unclear from what you wrote that you considered the substance of Ran's comment.  

>participants, precisely because it is not "self-evident" and 

What *I* heard was:  "Elliot, the section you want to remove was added specifically through working group discussion to gain consensus for the document".   Assuming that I understood that was what he meant, and that it represents the reality of the process, Ran drawing the conclusion that removing that text would tend to "reduce consensus" seems to be a reasonable one and targeted specifically at the edit.

Mike

---

From: SM <[email-masked]>
Date: Mon, 22 Apr 2013 10:53:00 -0700

>generating such IDs are not affected by this specification.

The document shepherd write-up mentioned that there is "Nothing in 
particular" to report about the working group discussions.  There 
were two WG participants discussing about 
draft-ietf-6man-stable-privacy-addresses during the WGLC (excluding 
the listed author and the WG Chairs).

I'll comment on the draft.  The document is well-written.

 From Section 1:

   'The "Privacy Extensions for Stateless Address Autoconfiguration in
    IPv6" [RFC4941] were introduced to complicate the task of
    eavesdroppers and other information collectors to correlate the
    activities of a node, and basically result in temporary (and random)
    Interface Identifiers that are typically more difficult to leverage
    than those based on IEEE identifiers.'

There are some warnings in RFC 4941 about correlation.  I don't see 
any notes about that in this draft.  My reading of this proposal is 
that it is to mitigate address scanning.  I could not find any 
guidance on whether to use RFC 4941 or this draft for "privacy addresses".

 From Section 3:

   "The aforementioned algorithm MUST be employed for generating
    the interface identifiers for all of the IPv6 addresses
    configured with SLAAC for a given interface, including IPv6
    link-local addresses."

The requirement is repeated in the note:

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

I read that as meaning that this document informally obsoletes or 
deprecates some of the existing algorithms but it's better not to say 
it formally as it would be controversial.

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

If the implementation does not provide the means for the 
administrator to enable or disable the use of the algorithm, does it 
conform to this specification?

Regards,
-sm

---

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

Hi, SM,

On 04/22/2013 12:53 PM, SM wrote:
> There are some warnings in RFC 4941 about correlation.  I don't see any
> notes about that in this draft.

PLease see the Appendix.

> My reading of this proposal is that it
> is to mitigate address scanning.  I could not find any guidance on
> whether to use RFC 4941 or this draft for "privacy addresses".

Privacy addresses are employed in addition to traditional SLAAC
addresses -- hence they don't mitigate address scanning. FWIW, this is
all discussed in the I-D.

> If the implementation does not provide the means for the administrator
> to enable or disable the use of the algorithm, does it conform to this
> specification?

It'd be "conditionally-compliant", but not fully-compliant.

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

---

From: SM <[email-masked]>
Date: Mon, 22 Apr 2013 13:39:32 -0700

Hi Fernando,

Please note that this is not an objection.

>PLease see the Appendix.

I read that.  I was confused by the short title (Stable Privacy 
Addresses) at first.  I didn't see much discussion in the draft about 
privacy considerations.  For what it is worth there isn't much in RFC 
4941 either.  I am not sure whether it is worth covering that angle 
in the draft; it may end up being too much work.

>all discussed in the I-D.

Yes, I read that.  Privacy is a bit more than address scanning.  From 
an implementation perspective the document is good.  It is difficult 
to tell how the document fits in the bigger (IPv6) picture.  I'll 
mention it; I am not suggesting that anything be done about it.

>It'd be "conditionally-compliant", but not fully-compliant.

It would be easier to say:

   It is RECOMMENDED that implementations provide a configuration option to
   enable or disable the use of this algorithm for generating Interface
   Identifiers.

I didn't include an explanation for the recommendation as it seems 
obvious to me.

BTW, you could steal some text from RFC 4941 for the 64-bit comment:

  "Note that an IPv6 identifier does not necessarily have to be 64 bits in
   length, but the algorithm specified in this document is targeted towards
   64-bit interface identifiers."

Regards,
-sm

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Apr 2013 11:36:50 -0500

On 04/22/2013 03:39 PM, SM wrote:
> privacy considerations. 

There's some discussion in the Intro and the Appendix.

> For what it is worth there isn't much in RFC
> 4941 either.  I am not sure whether it is worth covering that angle in
> the draft; it may end up being too much work.

What (specifically) do you have in mind? Both RFC4941 and this document
note that if you use the underlying IEEE identifier for the IID, that
becoames a "super cookie" that allows correlations. Is the much more to
say on the subject than that?

> Yes, I read that.  Privacy is a bit more than address scanning.  

Agreed.

> From an
> implementation perspective the document is good.  It is difficult to
> tell how the document fits in the bigger (IPv6) picture. 

For (auto-configured) stable addresses you have two choices:
* traditional slacc addresses
* draft-ietf-stable-privacy-addresses

>   enable or disable the use of this algorithm for generating Interface

Can't "SHOULD" and "RECOMMENDED" be used interchangeably?

>   64-bit interface identifiers."

Well this is not that different from the current text -- still ties the
document to 64-bit IIDs.

Thanks,

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Apr 2013 17:02:13 +0000

After reading the document again, the main issue is that the document specifies a solution to a problem by detailing a specific implementation, but does not explain the design choices behind that solution. As such, we end up with an over constrained specification, which at the same time fails to explain the problems at hand. The specification aims at providing addresses that are "stable and different," so that the same host connecting will have different and uncorrelated addresses when connecting to different networks, but will keep the same address when connecting repeatedly to the same network. 

As Mike St-Johns pointed out, the solution is trivial: create a different random number each time the host connect to a new network; make sure that the same random number is reused if the host reconnect to the same network. The latter property can be achieved either by keeping of log of previously visited networks and the corresponding address, or by using a "master random number" and combining it with the identification of the visited network. In theory, that's about all what the IETF ought to specify.

Instead, the draft goes into great details on how to actually implement the random number generator. Apart from not being necessary, some of these details are wrong. For example, the suggested algorithm includes an "interface index," but different operating systems have different ways of enumerating interfaces, and the variations in enumeration could end up violating the "stable address" property. 

I would suggest reworking the draft to separate a normative section, effectively a variation of the 3 lines paragraph above, and an informational section, the current specification of the algorithm as  "an example of a way to achieve this result if the operating system meets certain condition, like stable interface identifiers."

I would also explain the inherent issues that have to be solved, e.g., swapping interfaces, or enabling multi-homed hosts. And I would observe that the DAD problem cannot be solved ina  reliable way.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Apr 2013 12:40:04 -0500

Hi, Christian,

On 04/23/2013 12:02 PM, Christian Huitema wrote:
> After reading the document again, the main issue is that the document
> specifies a solution to a problem by detailing a specific
> implementation,

I personally disagree (see below).

> but does not explain the design choices behind that
> solution. As such, we end up with an over constrained specification,
> which at the same time fails to explain the problems at hand.

Could you please elaborate?

> As Mike St-Johns pointed out, the solution is trivial:

Can you post an URL for such comment? -- Because I've not been able to
find anything sent by Mike along those lines.

[....]
> Instead, the draft goes into great details on how to actually
> implement the random number generator. 

I disagree. In the draft, F() is the PRF. Where in the I-D are we trying
to provide details on how to implement F()?

> Apart from not being
> necessary, some of these details are wrong. For example, the
> suggested algorithm includes an "interface index," but different
> operating systems have different ways of enumerating interfaces, and
> the variations in enumeration could end up violating the "stable
> address" property.

Which vaiations are you referring to?

(FWIW, this I-D does not require any particular namespeace fr the
INterface Index).

> I would also explain the inherent issues that have to be solved,
> e.g., swapping interfaces, or enabling multi-homed hosts.

FWIW, constant addreses when swapping interfaces is not really a goal f
tis dcument, but rather a byproduct of it.

> And I would
> observe that the DAD problem cannot be solved ina  reliable way.

Could you please elaborate?

Thanks!

Best regards,

---

From: SM <[email-masked]>
Date: Tue, 23 Apr 2013 21:59:49 -0700

Hi Fernando,
>say on the subject than that?

I don't have anything in mind at the moment.  I suggest ignoring 
it.  I don't want to give anyone a reason to generate a DISCUSS. :-)

>Can't "SHOULD" and "RECOMMENDED" be used interchangeably?

Please note that this is my opinion only.  The short answer is yes.

I don't use the two interchangeably.  I used "RECOMMENDED" as it was 
to provide advice.  Here are two examples:

  (i)  The person RECOMMENDED that this matter be dropped.

  (ii) The person stated that this matter SHOULD be dropped.

The second example may sound oppressive.

Regards,
-sm

---

From: t.p. <[email-masked]>
Date: Thu, 25 Apr 2013 10:00:54 +0100

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: "Fernando Gont" <[email-masked]>; "SM" <[email-masked]>
Cc: "RJ Atkinson" <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 23, 2013 6:02 PM

<snip>

Instead, the draft goes into great details on how to actually implement
the random number generator. Apart from not being necessary, some of
these details are wrong. For example, the suggested algorithm includes
an "interface index," but different operating systems have different
ways of enumerating interfaces, and the variations in enumeration could
end up violating the "stable address" property.

<tp>

The ifIndex, as it appears in the IF-MIB is not stable; it can change
on each and every re-boot of a system, depending on the order in which
modules are loaded.  It remains the same only until the next re-boot. I
do not know what impact this has on the ipi6_ifindex as used in the
IPv6 API, whether that in turn is unstable.

(This is a property of the IF-MIB and is a reason why the YANG
equivalent
has used a name to index the interface table and not the index value,
which may give the users of the YANG module, also currently in Last
Call, an interesting migration problem).

So if you want a stable address, perhaps you should not use the
interface index.

Tom Petch

</tp>
I would suggest reworking the draft to separate a normative section,
effectively a variation of the 3 lines paragraph above, and an
informational section, the current specification of the algorithm as
"an example of a way to achieve this result if the operating system
meets certain condition, like stable interface identifiers."

I would also explain the inherent issues that have to be solved, e.g.,
swapping interfaces, or enabling multi-homed hosts. And I would observe
that the DAD problem cannot be solved ina  reliable way.

-- Christian Huitema

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 26 Apr 2013 13:43:17 +1000

Further to that, ifindexes of tunnels and PPP sessions can change
dynamically as the bearer connection goes up and down, even if the
interface has the same name and authenticated identity.  That raises the
interesting question of whether even the interface name is stable, as on
many systems it is pure chance if the same name-identity mapping repeats
itself.

If you want a stable address, you want to use something that actually has
the exact stability properties you require, and interface indexes and names
are seldom what you actually need.

Andrew

---

From: Ole Troan <[email-masked]>
Date: Fri, 26 Apr 2013 11:11:28 +0200

> Further to that, ifindexes of tunnels and PPP sessions can change dynamically as the bearer connection goes up and down, even if the interface has the same name and authenticated identity.  That raises the interesting question of whether even the interface name is stable, as on many systems it is pure chance if the same name-identity mapping repeats itself.
> 
> If you want a stable address, you want to use something that actually has the exact stability properties you require, and interface indexes and names are seldom what you actually need.

could we simplify the hash to only include the prefix, cookie and DAD counter:

RID = F(Prefix, secret_key, DAD_Counter)

an implementation that wants a stable address for cases where DAD_Counter > 0,
must keep state. e.g. maintain a table of prefix, dad_counter or list of previous addresses.

cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Apr 2013 08:47:50 -0400

>>>>> "Andrew" == Andrew McGregor <[email-masked]> writes:
    Andrew> Further to that, ifindexes of tunnels and PPP sessions can change
    Andrew> dynamically as the bearer connection goes up and down, even if the
    Andrew> interface has the same name and authenticated identity.
    Andrew> That raises the 
    Andrew> interesting question of whether even the interface name is
    Andrew> stable, as on 

I agree that this happens, and that it is a problem.
I wonder if this isn't a bug in the OSes involved that the ifindex can
not be more clearly specified by a daemon, or that the order of
interface bringup in the OS couldn't be more deterministic.

I think that non-contiguous ifindexes are a pain in the ass (based upon
my understanding of enumeration of interfaces in the interface MIB), but
are they essentially forbidden?  Having holes would make it easier to
keep things consistent.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Apr 2013 16:05:47 -0300

Hi, Ole,

On 04/26/2013 06:11 AM, Ole Troan wrote:
>> If you want a stable address, you want to use something that
>> actually has the exact stability properties you require, and
>> interface indexes and names are seldom what you actually need.
> 
> an implementation that wants a stable address for cases where
> DAD_Counter > 0, must keep state. e.g. maintain a table of prefix,
> dad_counter or list of previous addresses.

You you do not include some sort of "Interface ID", then, when two
interfaces are employed to connect to the same network, you are
guaranteed to get a collision...

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Apr 2013 16:19:27 -0300

Hi, Andrew,

On 04/26/2013 12:43 AM, Andrew McGregor wrote:
> dynamically as the bearer connection goes up and down,

Would we be doing SLAAC for these?

> even if the

So... how would you set up e.g. firewall rules for those systems? (not
to mention configuration of daemoss such as rtadvd and others...)

Thanks,

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 28 Apr 2013 21:08:25 -0700

Hi -

> From: "Michael Richardson" <[email-masked]>
> To: "ietf" <[email-masked]>; "Andrew McGregor" <[email-masked]>
> Cc: "Christian Huitema" <[email-masked]>; "SM" <[email-masked]>
> Sent: Friday, April 26, 2013 5:47 AM
> Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06
...
> are they essentially forbidden?  Having holes would make it easier to

This is exactly what RFC 2863 (The Interfaces Group MIB)
specifies.  Non-contiguous ifIndex values are permitted.

This issue was considered at some length in the development
of RFC 2863.  Section 3.1.5 explains in detail why the semantics
of ifIndex were changed (from their original MIB-II definition)
to permit "holes", while the semantics of ifNumber were left
untouched.

Randy