Subject: Comments on <draft-gont-6man-stable-privacy-addresses-01>

From: Bob Hinden <[email-masked]>
Date: Tue, 17 Apr 2012 16:58:36 -0700

Fernando,

This is my personal views from reading the draft.

Generally I support the idea in this draft that another type of privacy addresses would be useful to add to IPv6.  For example, to not expose the vendor IDs in IEEE MAC addresses.  I have some comments on the internet draft.

Bob

------

Introduction

In the Introduction the draft mentions that the IEEE MAC based interface identifiers don't eliminate the threat from host scanning.  To justify this the document references two documents [Gont-DEEPSEC2011] [CPNI-IPv6].  The first is a presentation you prepared and the second is also written by you but not publicly available (the reference says "available on request").  I was able to find the presentation online.  It makes an argument that host scanning is possible because (in my words) that there is structure in how Internet IDs are formed.  It lists different type of IIDs found and reported in a paper by Malone.  This paper is primarily about the observed types of address in an operational test.  It includes stats on the percentage of IPv6 address types observed in live traffic (e.g., 50% SLACC based, 20% IPv4 based, etc.).   

The problem I see is that this doesn't justify the claim that there is a problem with host scanning with MAC based interface identifiers.  It would be helpful if you could provide some data or analysis that justifies this to quantify the risk.  In my reading the references don't do that.  

-------

2. Design Goals

Could these types of Interface Identifiers also be generated by DHCPv6 servers.  I would think that it would be useful to generate these hard to predict IIDs when a DHCPv6 server is providing addresses.  This would be much better than assigning them linearly that are easy to predict and scan for.  

That is, the same approach could be used to create IIDs for SLAAC and DHCPv6.  

---------

5. Security Considerations

In the second paragraph the document says 

  "We note that this algorithm is meant to replace Modified EUI-64 format identifiers".  

This is the first time the document says this.  If it intends to do this, it should be in the main part of the document and not first appear in the security considerations.  The document makes a clear argument why it is preferable to MAC based IIDs, but it doesn't justify replacing Modified EUI-64 identifiers.  It's a would be a major change to the IPv6 Address Architecture that I don't think is warranted.

The algorithm in Section 3. even clears the U/L bit to be compatible with the Modified EUI-64 IIDs.   I think document may be confusing IEEE MAC based Modified EUI-64 Interface IDs with the format defined in the IPv6 Address Architecture that can accommodate different types of tokens (MAC based, random number based, manual assignment, etc.) to create IIDs.

Please clarify?

-------

Sections 7.

I don't understand the purpose of this section.  It comes after the Acknowledgement section and before References.  It reads like open issues and says it might be removed.  Is it meant as an appendix?  Perhaps rewriting it to show how addresses based on these IIDs prevent these problems.

----

References:

   [CPNI-IPv6]
              Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)",  UK Centre for the Protection of
              National Infrastructure, (available on request).

I am not sure this will be acceptable by the RFC-Editor.   There isn't enough information to know who to ask to to get a copy.  It would be better if it was available online.

---

From: Karl Auer <[email-masked]>
Date: Wed, 18 Apr 2012 10:58:31 +1000

On Tue, 2012-04-17 at 16:58 -0700, Bob Hinden wrote:
> Could these types of Interface Identifiers also be generated by DHCPv6
> servers.  I would think that it would be useful to generate these hard
> to predict IIDs when a DHCPv6 server is providing addresses.  This
> would be much better than assigning them linearly that are easy to
> predict and scan for.  

Some DHCPv6 servers may assign IPv6 addresses linearly. Industrial
strength DHCPv6 servers don't (eg Nominum DCS). Linear assignment in
DHCPv6 is IMHO basically a bug. If a DHCPv6 server assigns a random
address to a new client, then you have everything stable addresses give
you - it's not based on the hardware address, it's the same whenever you
are in the same network, it's different on different networks.

A DHCPv6 server that allocates addresses linearly would be better fixed
not to do so, than to go to the trouble of implementing stable addresses
a la Gont.

The DHCPv6 model is one where the client defers to the server. While a
client can request specific addresses, and so could request one it had
generated using the stable address algorithm, it would still be entirely
up to the server whether or not to honour that request.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Apr 2012 01:25:26 -0300

Hi, Karl,

> not to do so, than to go to the trouble of implementing stable addresses

Not sure what you mean. -- Having the DHCPv6 server implement
draft-gont-6man-stable-privacy-addresses might be interesting such that
stable addresses are leased to nodes state-lessly.

> up to the server whether or not to honour that request.

Exactly. Hence the DHCPv6 server could be computing the algorithm in
draft-gont-6man-stable-privacy-addresses.

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Apr 2012 01:33:49 -0300

Hi, Bob,

Thanks so much for your feedback! Please find my responses in-line...

On 04/17/2012 08:58 PM, Bob Hinden wrote:
> In the Introduction the draft mentions that the IEEE MAC based
> interface identifiers don't eliminate the threat from host scanning.
> To justify this the document references two documents
> [Gont-DEEPSEC2011] [CPNI-IPv6].
[....]
> The problem I see is that this doesn't justify the claim that there
> is a problem with host scanning with MAC based interface identifiers.
> It would be helpful if you could provide some data or analysis that
> justifies this to quantify the risk.  In my reading the references
> don't do that.

Fair enough. I will address this in the next rev of the document.

> 2. Design Goals
> 
> Could these types of Interface Identifiers also be generated by
> DHCPv6 servers.  I would think that it would be useful to generate
> these hard to predict IIDs when a DHCPv6 server is providing
> addresses.  This would be much better than assigning them linearly
> that are easy to predict and scan for.
> 

Agreed. Do you think this should be incorporated in this I-D, or that
this should be addressed in a different I-D?

> "We note that this algorithm is meant to replace Modified EUI-64

Note: What I meant here is that there are meant to be used instead of
the MAC-based addresses. Based on your comment (and after re-reading the
relevant specs), it seems that this para needs to be tweaked as follows:

1) s/to replace/to be an alternative to/
2) s/Modified EUI-64 identifiers/IIDs based on IEEE identifiers/

Thoughts?

> This is the first time the document says this.  If it intends to do
> this, it should be in the main part of the document and not first
> appear in the security considerations.  The document makes a clear
> argument why it is preferable to MAC based IIDs, but it doesn't
> justify replacing Modified EUI-64 identifiers.  It's a would be a
> major change to the IPv6 Address Architecture that I don't think is
> warranted.

I could certainly live with this document simply specifying an
alternative scheme for generating addresses (without formally
replacing/obsoleting any other method). However, I think it would be
appropriate that we recommend (somewhere... either in this doc, in a
document updating node requirements, in a future node-requirements-bis,
or wherever), that a scheme such as this is RECOMMENDED over the ones
embedding IEEE identifiers.

> The algorithm in Section 3. even clears the U/L bit to be compatible
> with the Modified EUI-64 IIDs.   I think document may be confusing
> IEEE MAC based Modified EUI-64 Interface IDs with the format defined
> in the IPv6 Address Architecture that can accommodate different types
> of tokens (MAC based, random number based, manual assignment, etc.)
> to create IIDs.
> 
> Please clarify?

You're right. Throughout the document, most references to "Modified
EUI-64 identifiers" really mean "IEEE-derived IIDs".

That said, documents such as "Transmission of IPv6 Packets over Ethernet
Networks" mandate the generation of Modified-EUI-64 format identifiers
from IEEE identifiers. So I'm not sure what the right approach
(specs-wise) would be. e.g., formally update RFC 4291, noting that
besides what's in the "Transmission of IPv6 Packets over XXX" documents,
IIDs can be generated as specified in
draft-gont-6man-stable-privacy-addresses, or something else?

> Sections 7.
> 
> I don't understand the purpose of this section.  

This Section was essentially added to address the comments during my
presentation of this document at the Paris IETF (e.g., that RFC4941
address, by themselves, the problem of host-tracking).

> It comes after the
> Acknowledgement section and before References.  It reads like open
> issues and says it might be removed.  Is it meant as an appendix?

Yes. I realized of the wrong placement of this section *after*
submitting it, and hence this shows up as Section 7 rather than as an
Appendix. -- I've already fixed this in my working copy of the I-D, and
hence this will appear as an Appendix in the next rev.

> Perhaps rewriting it to show how addresses based on these IIDs
> prevent these problems.

FWIW, this section tries to show that if you implement RFC4941 while
still implementing the MAC-based addresses, both host-scanning attacks
and host-tracking remain possible.

> References:
> 
> [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol 
> version 6 (IPv6)",  UK Centre for the Protection of National
> Infrastructure, (available on request).
> 
> I am not sure this will be acceptable by the RFC-Editor.   There
> isn't enough information to know who to ask to to get a copy.  It
> would be better if it was available online.

I'm working to make this happen.

Thanks!

Best regards,

---

From: [email-masked]
Date: Wed, 18 Apr 2012 13:02:33 +0800

Regards~~~

-Sujing Zhou

> stable addresses are leased to nodes state-lessly.

Will the DHCP server use the same secret key in computation of so many 
random interface identifiers?
If so, the computation of RID may need to be modified, because there is 
little left to tweak (the only difference between 
clients is Modified_EUI64) in case address collision occurs.
and have you ever thought of refreshing the secret key in SLAAC?

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Apr 2012 04:18:10 -0300

Hi, Zhou,

Please find my comments in-line...

>  random interface identifiers?

Yes. Note that F() should be cryptographically secure. And hence even if
the server had to compute say 1000 addresses, that wouldn't be an issue.

> If so, the computation of RID may need to be modified, 

As already noted on this thread, we might include a "retry" variable in
the hash (initialized to 0, but incremented by 1 each time DAD fails),
to be used to compute a new RID if DAD fails. In any case, no matter how
many the devices, were talking about 2**64 addresses here -- so you'd
have to be very unlucky for DAD to fail. :-)

> because there is

In the case of using this algorithm with DHCPv6, I guess the UID would
be used instead of Modified_EUI64.

> and have you ever thought of refreshing the secret key in SLAAC?

If you refresh the secret key, you get a whole new set of addresses. My
take is that only in very rare circumstances you'd want to do this.

Thanks,

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 Apr 2012 13:55:34 -0700

Fernando,

> Fair enough. I will address this in the next rev of the document.

This is an area I would like to know more about, and it would be good to quantify the problem.  

Off the top of my head, if an attacker knew the subnet prefix, it could guess a company_id, it would have to scan ~17M (2^24) addresses per company_id.  That would only result in finding the devices using that company_id.  This would have to be repeated many times to find even the majority of devices on a single subnet.  This is clearly easier than having to scan 2^64 addresses in a single subnet, but still considerably harder than than a /24 IPv6 subnet.

> this should be addressed in a different I-D?

Not sure.  If the algorithm could be the same, then it would make sense to include both use cases (SLACC and DHCPv6).

> 2) s/Modified EUI-64 identifiers/IIDs based on IEEE identifiers/

I think for now, I suggest an alternative approach.  

This should be stated earlier in the document too.

> embedding IEEE identifiers.

I think there are some tradeoff here that we are discussing.  We may need some more experience before making a decision.  In the short term pushing for a compete change might well be perceived as a disruptive change to IPv6 deployment.  A good starting point is defining them as an alternative.

> EUI-64 identifiers" really mean "IEEE-derived IIDs".

Thanks, as I suspected.

> draft-gont-6man-stable-privacy-addresses, or something else?

I suggest looking at RFC4941 Privacy Extentions as the model.  That created the privacy IIDs without having update any other documents.  I think the IPv6 Address Architecture supports a range of Interface IDs and this draft fall under that.  For example, the IPv6 over <foo> documents, don't keep people from using manually configured addresses, privacy addresses, etc.  

> hence this will appear as an Appendix in the next rev.

Sounds good.

> I'm working to make this happen.

Cool!

Thanks,
Bob

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2012 03:50:23 -0300

Hi, Bob,

On 04/18/2012 05:55 PM, Bob Hinden wrote:
>>> The problem I see is that this doesn't justify the claim that
>>> there is a problem with host scanning with MAC based interface
>>> identifiers.
>> 

I've just posted this drafty I-D, which hopefully shed some light on the
subject (or triggers further discussion):
<http://www.ietf.org/id/draft-gont-opsec-ipv6-host-scanning-00.txt>

(this one might be a better reference)

> Off the top of my head, if an attacker knew the subnet prefix, it
> could guess a company_id, it would have to scan ~17M (2^24) addresses
> per company_id.  That would only result in finding the devices using
> that company_id.

Agreed. But in a number of scenarios (e.g., ISP X provisioned with
vendor X) that may be all you need. That said, please look at the
discussion on virtualization in draft-gont-opsec-ipv6-host-scanning-00.txt

> This would have to be repeated many times to find
> even the majority of devices on a single subnet.  This is clearly
> easier than having to scan 2^64 addresses in a single subnet, but
> still considerably harder than than a /24 IPv6 subnet.

I think the key question here is whether these attacks are feasible or not.

For example, consider an attacker remotely-scanning the v6-enabled IETF
meeting network. He'd probably target:

* Apple's (Macs, iPads, iPhones)
* Dell's
* IBM's
* HP's
* Toshiba's
* Samsung's

and he'd already discover a fair share of the hosts connected to the
network.

Certainly not perfect, certainly harder than in IPv4, but still feasible.

Now, if the same nodes implemented
draft-gont-6man-stable-privacy-addresses, the attacker would be better
off trying something else.

>>> DHCPv6 servers.  I would think that it would be useful to
>>> generate these hard to predict IIDs when a DHCPv6 server is
>>> providing addresses.  This would be much better than assigning
>>> them linearly that are easy to predict and scan for.
>>> 
>> Agreed. Do you think this should be incorporated in this I-D, or
>> that this should be addressed in a different I-D?
> 
> Not sure.  If the algorithm could be the same, then it would make
> sense to include both use cases (SLACC and DHCPv6).

The algorithm could be essentially the same, probably with slight
modifications (e.g., DUID rather than Modified_EUI64). -- Just thinking
whether procedurally-speaking it'd be better to incorporate this here,
or have it as a separate document in dhcwg.

>> replacing/obsoleting any other method). However, I think it would
>> be appropriate that we recommend (somewhere... either in this doc,
>> in a document updating node requirements, in a future
>> node-requirements-bis, or wherever), that a scheme such as this is
>> RECOMMENDED over the ones embedding IEEE identifiers.
> 
> I think there are some tradeoff here that we are discussing.  

FWIW, when it comes to draft-gont-6man-stable-privacy-addresses vs
IEEE-derived ones, the only tradeoff I can think of is, if anything,
simplicity for privacy.

But yes, when one thinks about IIDs as a whole (IEEE-derived,
draft-gont-6man-stable-privacy-addresses, and RFC4941) there are a
number of aspectes to consider.

> We may
> need some more experience before making a decision.  In the short
> term pushing for a compete change might well be perceived as a
> disruptive change to IPv6 deployment.  A good starting point is
> defining them as an alternative.

I can certainly live with that.

>> That said, documents such as "Transmission of IPv6 Packets over
>> Ethernet Networks" mandate the generation of Modified-EUI-64 format
>> identifiers from IEEE identifiers. So I'm not sure what the right
>> approach (specs-wise) would be. e.g., formally update RFC 4291,
>> noting that besides what's in the "Transmission of IPv6 Packets
>> over XXX" documents, IIDs can be generated as specified in 
> I suggest looking at RFC4941 Privacy Extentions as the model.  That
> created the privacy IIDs without having update any other documents.

Will do. I should note, however, that privacy addresses do not seem to
be widely implemented, and even less widely enabled by default (and they
have been around for 10+ years).

> I think the IPv6 Address Architecture supports a range of Interface
> IDs and this draft fall under that.  For example, the IPv6 over <foo>
> documents, don't keep people from using manually configured
> addresses, privacy addresses, etc.

My point was mostly about how to signal implementers that this
alternative exists, and also how to provide advice regarding what
algorithm is most desirable.

Being able to benefit from the increase IPv6 address space to mitigate
host-scanning attacks would be a good thing, and an improvement over IPv4.

Thanks!

Best regards,

---

From: Tim Chown <[email-masked]>
Date: Fri, 20 Apr 2012 08:22:15 +0100

> <http://www.ietf.org/id/draft-gont-opsec-ipv6-host-scanning-00.txt>

Don't forget RFC5157, which talks about other ways addresses can be gleaned, and thus attackers could scan around those addresses.  i.e. that brute force sweeps across an entire subnet aren't feasible, but an attacker will do whatever they can to narrow the search space.

That text reinforces the need for randomised host addresses, and, for example, DHCPv6 servers not to allocate addresses in a predictable way.  The stable privacy address draft adds pretty much the same feature for SLAAC.

The ND cache exhaustion issue is also linked in to the scanning topic.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2012 05:00:44 -0300

Hi, Tim,

On 04/20/2012 04:22 AM, Tim Chown wrote:
>> I've just posted this drafty I-D, which hopefully shed some light
>> on the subject (or triggers further discussion): 
> Don't forget RFC5157, which talks about other ways addresses can be
> gleaned, 

Yes, as noted in Section 1 of the I-D, this is a very drafty version,
pushed out to answer Bob's question. :-)  -- There's lots of stuff that
still needs to be added.

> The ND cache exhaustion issue is also linked in to the scanning

Yep. Note: Some text present in the document on which
draft-gont-opsec-ipv6-host-scanning is based has been deliberately
excluded from draft-gont-opsec-ipv6-host-scanning-00: the aforementioned
document on which this draft is based was mostly about *designing* a
port scanner, and targeted a different audience. (e.g.,
draft-ietf-v6ops-v6nd-problems was being referenced in a section about
"selecting the probe rate").

P.S.: I will try to incorporate some of the missing stuff, and rev
shortly --  in any case, I felt it was more productive to submit this
drafty version of the draft, than answering Bob's question/request with
a two-liner in an e-mail.

Thanks!

Best regards,

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 Apr 2012 10:26:55 -0700

Fernando,

> (this one might be a better reference)

Thanks.  I will take a look.

> * Apple's (Macs, iPads, iPhones)

I agree, I would do that too :-)

However, it also depends a lot on how many companies IDs each vendor has and how they allocate them to their devices.  

For example, I looked at 

  http://standards.ieee.org/develop/regauth/oui/public.html

and did a search for Apple and found about 150 assigned company_id's.  [Note: It's "about" because some companies have "Apple" in their address].  The IEEE page also says: "Firms and numbers listed may not always be obvious in product implementations, as some manufacturers subcontract component manufacture and others include registered firm OUIs in their products."

The point I am trying to make here is that we should characterize the risk here accurately.  It's not as simple as get one company_id and then start scanning.

> off trying something else.

Agreed.  It also hides the company_id.  

> host-scanning attacks would be a good thing, and an improvement over IPv4.

Agreed.  

Thanks,
Bob

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2012 14:46:51 -0300

Hi, Bob,

On 04/20/2012 02:26 PM, Bob Hinden wrote:
>> For example, consider an attacker remotely-scanning the v6-enabled
>> IETF meeting network. He'd probably target:
>> 
>> * Apple's (Macs, iPads, iPhones) * Dell's * IBM's * HP's *
>> Toshiba's * Samsung's
> 
> However, it also depends a lot on how many companies IDs each vendor
> has and how they allocate them to their devices.

Of the top of my head, they use OUIs mostly sequentially. So, e.g., the
first OUI assigned to, say, Apple, in unlikely to be in actual use nowadays.

That aside, scanning a network such as "the IETF meeting network" is
kind of "the worst case scenario", since there are heterogeneous
systems. In a typical organizational scenario, you have, at most, a few
providers (they make large purchases from the same vendor).

> and did a search for Apple and found about 150 assigned company_id's.
> [Note: It's "about" because some companies have "Apple" in their
> address]. 

I will double-check... But most of the cases I checked didn't have more
than 10 OUIs or so.

> The IEEE page also says: "Firms and numbers listed may not
> always be obvious in product implementations, as some manufacturers
> subcontract component manufacture and others include registered firm
> OUIs in their products."

Yes, but as the idea develops, it wouldn't be hard to imagine an "OUI
matrix" document (or watchamacallit :-) ) that maps vendors to OUIs in a
more precise way.

> The point I am trying to make here is that we should characterize the
> risk here accurately.  It's not as simple as get one company_id and
> then start scanning.

As far as I've checked, it can work pretty well that way. That said, as
noted by Ray, it's not that the lower 24 bits are selected in a random
order, but rather sequentially. So you don't even need to search the
24-bit space linearly: Take samples "randomly", and once you find an
alive host, try sequential addresses starting from there.

That said, it's not as bad as "this company has 10 OUIs, and I need to
go through all of them".

(I will try to get more experimental data, anyway).

>> and he'd already discover a fair share of the hosts connected to
>> the network.
>> 
>> draft-gont-6man-stable-privacy-addresses, the attacker would be
>> better off trying something else.
> 

Exactly. And the search space becomes 64 bits (well, 63, since there's
the U/L bit), with no patterns. -- That's a whole different game.

>> Being able to benefit from the increase IPv6 address space to
>> mitigate host-scanning attacks would be a good thing, and an
>> improvement over IPv4.
> 
> Agreed.

Thanks!

Best regards,