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

[Bob Hinden <[e-mail]>]

Fernando,

On Apr 19, 2012, at 11:50 PM, Fernando Gont wrote:

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

Thanks.  I will take a look.

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

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.


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


Agreed.  It also hides the company_id.  


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

Agreed.  

Thanks,
Bob


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