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

[Fernando Gont <[e-mail]>]

Hi, Bob,

On 04/18/2012 05:55 PM, Bob Hinden wrote:
>> 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.
>> [....]
>>> 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.
>> 
>> 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.

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.



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



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

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,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492