Subject: AD Evaluation: draft-ietf-6man-stable-privacy-addresses

From: Brian Haberman <[email-masked]>
Date: Mon, 08 Apr 2013 10:46:57 -0400

All,
      I have performed by AD review of 
draft-ietf-6man-stable-privacy-addresses.  For the most part, this is a 
well-written document.  I only have a few comments that should be 
resolved prior to moving this to IETF Last Call...

1. Section 1 : I understand that the fourth paragraph is indented since 
it is quoting from another document.  I do not see why the fifth 
paragraph is indented.  The same confusion exists for the second 
paragraph of Section 3.

2. Section 3 :

* The PRF is fed several variables in order to generate a random number. 
  I appreciate that the issues with different identifiers being 
generated for the same prefix due to varying values of DAD_Counter are 
discussed (Section 4).  What is missing is discussion of when the 
Interface_Index value changes.  On many systems, the value returned via 
the socket APIs is based on the ifIndex value assigned to the interface. 
  There are a variety of situations where the ifIndex can change within 
a system and these should be mentioned.  This can impact design goal #2.

* What are the assumptions on this algorithm with respect to multi-homed 
devices that could have different network interfaces available to attach 
to the same network?  For example, if I have a quad-port network card, I 
could attach to a network via eth0 and get an identifier for prefix X. 
The next time I attach to that network, I use eth2 and I will not get 
the same identifier even though I still get a PIO containing prefix X. 
This issue directly contradicts design goal #1.

3. I think it would be good to explicitly state that this IID generation 
mechanism is incrementally deployable since there are no 
interoperability issues with IID generation.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Apr 2013 03:27:57 -0300

Hi, Brian,

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

> paragraph is indented.  The same confusion exists for the second

Indented ṕararagraphs, unless otherwise noted, are parenthetical notes,
rather than quotes from other documents (i.e., text that provides
additional information, but that you may skip reading if you want).

>  I appreciate that the issues with different identifiers being generated
> for the same prefix due to varying values of DAD_Counter are discussed
> (Section 4).  What is missing is discussion of when the Interface_Index
> value changes.  On many systems, the value returned via the socket APIs
> is based on the ifIndex value assigned to the interface.  There are a
> variety of situations where the ifIndex can change within a system and
> these should be mentioned.  This can impact design goal #2.

HOw about the following text:

"The Interface Index is expected to remain constant across system
reboots and other events. However, we note that it might change upon
removal of a network interface (typically one with a smaller value for
the Interface Index, when such naming scheme is used). When such
Interface Index changes occur, the IPv6 addresses resulting from this
algorithm for an interface index is likely to change, thus affecting the
stability property of this approach. We note that we expect these
scenarios to be unusual."

Maybe in the corresponding "bullet"? Or right after the paragraph that
says "Including the SLAAC prefix in the PRF computation causes the..."?

> This issue directly contradicts design goal #1.

This algorithm aims to produce stable addresses for each interface. SO
as long as the same interface gets the same addresses, the algorithm is
achieving it's goal.

> interoperability issues with IID generation.

Good point.

How about adding this to the Intro, right after the para that starts
with "This document specifies a method to generate interface
identifiers...":

"We note that this method is is incrementally deployable, since it
doesn't pose any interoperability implications when deployed on networks
where other nodes do not implement or employ it".

?

Thanks!

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 09 Apr 2013 11:21:41 -0400

> additional information, but that you may skip reading if you want).

We have had this discussion before... I am not a fan of these 
parenthetical notes, but to each his own.

> scenarios to be unusual."

I don't like "likely to change".  In what cases would a change to an 
input value *not* change the output of the PRF?

Additionally, I will note that this scenario may not be as unusual as 
you think.  For example, the ifIndex on some Cisco gear will change 
enough that IOS has a configuration command to make it stable.

> says "Including the SLAAC prefix in the PRF computation causes the..."?

The latter would be preferable, but it raises another question.  If 
there is discussion on input values changing in section 3, the text on 
the impact of DAD_Counter changes in section 4 should probably be moved 
to section 3.

> as long as the same interface gets the same addresses, the algorithm is

Then something needs to be said in the document about this limitation. 
This approach does not create stable addresses *per prefix*.

> where other nodes do not implement or employ it".

The above is fine as long as you remove the redundant "is".

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Apr 2013 22:40:19 -0300

Hi, Brian,

> parenthetical notes, but to each his own.

I wasn't arguing in favor of them, but rather explaining what they were.
(FWIW, these notes predate our "discussion" on the subject... and, in
all fairness, you're not the first one to not like them :-) ).

I'll try to incorporate them into the main body -- fwiw, the reason for
which I including those paragraphs as such (parenthetical notes), is so
that the reader that is not interested in those details can easily skip
them.

> I don't like "likely to change".  

Yep, that was stupid -- how about s/for an interface index is likely to
change/for an interface will change/?

> enough that IOS has a configuration command to make it stable.

what's the "event" upon which the interface index will change?
"Interface removal", as in the suggested text, or something else?

If that's the case, I'd not expect that to happen frequently -- and even
less for hosts/servers doing SLAAC (those routers are more likely using
statically-configured addresses).

Anyway... should I add something along this lines of:
"Some implementations are known to provide configuration knobs to set
the Interface Index for a given interface. This could be leveraged to
prevent maintain the same Interface Index for an interface when e.g. the
removal of a network interface causes Interface Indexes to change"

?

> the impact of DAD_Counter changes in section 4 should probably be moved

Me, I have no objections against that. I should note that DAD_Counter is
described in Section 4 because that section is the subject of a whole
topic. I guess we have two options:

1) Add a small sentence pointing to Section 4, or,
2) Move Section 4 into Section 3.

I'd probably go with 1), but wouldn't bother doing 2). -- Please pick
one, and I'll apply it.

> This approach does not create stable addresses *per prefix*.

This is my rationale:
The internet architecture has no concept/namespace for "node". So, from
a practical point of view, different network interfaces all look like
different nodes (in the same way that you cannot use any of your
addresses for the same TCP connection, etc.).

That aside, you could also have the case where the same node connects to
the same network with two NICs, at the same time. In such scenario,
you're forced to have each NIC get a different IPv6 address. -- In a
scenario such as this, each NIC will get the same address (both in this
case and also when the node connects to that network with a single
interface).

So I'd argue that this is a desired property, rather than a drawback.

> The above is fine as long as you remove the redundant "is".

Great.

Thanks!

Best regards,

---

From: Brian Haberman <[email-masked]>
Date: Wed, 10 Apr 2013 18:01:58 -0400

> change/for an interface will change/?

That should be fine.

> "Interface removal", as in the suggested text, or something else?

My understanding is that some devices assign an ifIndex when the device 
is activated (e.g., at boot time).  Since device activation is 
non-deterministic, an interface can get assigned a different ifIndex 
each time it boots.  To deal with this behavior, IOS has a "persist" 
command that keeps state about each interfaces initial ifIndex.

> statically-configured addresses).

See above.  I am not sure to what extent other platforms have a similar 
issue.

> removal of a network interface causes Interface Indexes to change"

That should be sufficient.

> I'd probably go with 1), but wouldn't bother doing 2). -- Please pick

Option (1) should be fine as long as that sentence in section 3 raises 
awareness that DAD_Counter can change.

> case and also when the node connects to that network with a single

Whoa... If two NICs on the same system connect to the same link, they 
can't get the same address.  Those two interfaces *should* have 
different ifIndex values being fed into the PRF.

My comment above was meant to simply point out that these addresses are 
per prefix/interface combination.  That's all.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Apr 2013 04:28:31 -0300

Hi, Brian,

> command that keeps state about each interfaces initial ifIndex.

I've not experienced that myself. That said, I'd probably argue that
such changes are probably annoying for there reasons: I guess that if
the interface index changes, so does the usual suffix in the interface
name (e.g. ethN, wlanN) -- hence delaying with link-local addresses
would become more painful than necessary.

> See above.  I am not sure to what extent other platforms have a similar

I've not experienced this in Windows, *BSD, or Linux, at least.

> awareness that DAD_Counter can change.

Done.

> different ifIndex values being fed into the PRF.

Exactly. my pint was that this is the very reason for which one cannot
expect two different NICs to get the same IPv6 addresses when they
connect (separately) to the same network.

> per prefix/interface combination.  That's all.

Agreed. Should I tweak the document n any way regarding this?

Thanks!

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

---

From: Brian Haberman <[email-masked]>
Date: Thu, 11 Apr 2013 10:42:52 -0400

> Agreed. Should I tweak the document n any way regarding this?

I think it would be useful to add a sentence or two that points out that 
the generated address could be different *for the same prefix* if the 
device connects over a different physical interface.

Regards,
Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 11 Apr 2013 13:04:35 -0700 (PDT)

Hi,

>________________________________
> From: Fernando Gont <[email-masked]>
>To: Brian Haberman <[email-masked]> 
>Cc: 6man Chairs <[email-masked]>; Fernando Gont <[email-masked]>; 6man WG <[email-masked]>; [email-masked] 
>Sent: Thursday, 11 April 2013 5:28 PM
>Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses
> 
>
>Hi, Brian,
>
>A number of years ago this happened with Linux. IIRC, it was related to changing the default order of device driver loading, or changing from sequential loading of device drivers to parallel loading. That reordered the interface numbering and therefore the names, which people didn't like. The solution at the time was to use the interface MAC address to assign interfaces persistent names by renaming the interfaces late in the initialisation stage. I don't remember reference to resetting ifindexes.  
>
>
>One thing that may also influence this draft is that interfaces may be added to the system after it has booted. For example, I carry around a couple of USB/Ethernet adaptors that I'll add to my laptop if I need them for troubleshooting (and with my new laptop being wifi only, just to connect to a wired network), and I may not know if I'll need them when I boot my laptop. I also have a 3G mobile dongle that I occasionally use. I'm pretty sure Linux allocates ifindex values sequentially as the driver is loaded, so what ifindex values these dynamic interfaces gets is not going to be consistent and persistent.
>
>Regards,
>Mark.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Apr 2013 23:36:16 -0300

> device connects over a different physical interface.

I did a minor tweak in the Intro, which notes this.

I've posted a rev that hopefully addresses all your comments -- so this
one would be ready to ship.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Apr 2013 01:00:31 -0300

Hi, Mark,

On 04/11/2013 05:04 PM, Mark Smith wrote:
>> A number of years ago this happened with Linux. IIRC, it was
>> related to changing the default order of device driver loading, or
>> changing from sequential loading of device drivers to parallel
>> loading. That reordered the interface numbering and therefore the
>> names, which people didn't like.

It's not surprising that people didn't like it :-) -- e.g., if you have
per-interface fw rules, this breaks everything.

> The solution at the time was to
>> use the interface MAC address to assign interfaces persistent names
>> by renaming the interfaces late in the initialisation stage.

mm.. not sure hat you mean...

>> One thing that may also influence this draft is that interfaces may
>> be added to the system after it has booted. For example, I carry
>> around a couple of USB/Ethernet adaptors that I'll add to my laptop
>> if I need them for troubleshooting (and with my new laptop being
>> wifi only, just to connect to a wired network), and I may not know
>> if I'll need them when I boot my laptop.

Well, if you add the card once the device has been bootstrapped, that
shouldn't break the sequence of IID -- i.e., the USB/Ethernet adaptor
would get an IfInndex that is larger than all existing IfIndexes...

>> I also have a 3G mobile
>> dongle that I occasionally use. I'm pretty sure Linux allocates
>> ifindex values sequentially as the driver is loaded, so what
>> ifindex values these dynamic interfaces gets is not going to be
>> consistent and persistent.

If you always connect these cards in the same sequence, why shouldn't them?

P.S.: In any case, I've tweaked the I-D to essentially say that "the
IfIndex might change if network interfaces are installed or removed".

Thanks!

Best regards,

---

From: Mark Smith <[email-masked]>
Date: Wed, 17 Apr 2013 14:00:52 -0700 (PDT)

Hi Fernando,

----- Original Message -----

> From: Fernando Gont <[email-masked]>
> To: Mark Smith <[email-masked]>
> Cc: Fernando Gont <[email-masked]>; Brian Haberman <[email-masked]>; 6man Chairs <[email-masked]>; 6man WG <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Saturday, 13 April 2013 2:00 PM

I encountered it because I had a box I'd setup for packet capturing with multiple interfaces. The sticky labels on the back of it stopped matching up :-(

> mm.. not sure hat you mean...

The Linux kernel has an device event messaging system where kernel events generate messages that can be processed by user space. Using the "udev" daemon, that can execute various actions and/or scripts. So when a new network interface was added, a rule could be set to match on it's MAC address. If the MAC address matched, one of the available actions was to rename the interface. You can see some examples of these types of udev rules at:

https://wiki.archlinux.org/index.php/Network_Configuration#Udev_rule

> would get an IfInndex that is larger than all existing IfIndexes...

True, however the ifindex may not be the same for that USB/Ethernet adaptor as what it was last time it was installed. It's interface name might be though, because of e.g. the udev system.

> If you always connect these cards in the same sequence, why shouldn't them?

I'd expect them to. Of course I don't always connect them in sequence or connect them all at once.

Great.

Best regards,
Mark.