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

Bob Hinden <> Fri, 20 April 2012 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E3F921F8674 for <>; Fri, 20 Apr 2012 10:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.548
X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Neg4DQh6kiIZ for <>; Fri, 20 Apr 2012 10:27:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA22F21F85A2 for <>; Fri, 20 Apr 2012 10:26:59 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so6112838yhk.31 for <>; Fri, 20 Apr 2012 10:26:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=bjtvdFmHBRVmo3e014XAJMJWZWBzg4PC1UICrotituk=; b=UuGBEN6Q93ZZT8W1jGC66JA2AcG4wGymcgnT8ZSLieeCXl8vPaXxeehKzYwycYJUGc gohf671cTdeAD4FU5ttQr/54mzibBYtbSu/0WKHVE3jOo/rAzlaRzxXFccrZ2ttchbVh fYhkVjlAsymRE9/RAsAVI0tQ3lzKtjrXgeBiXY0C9NBBHtvtzWC+Ig/cTAtJvyM/rmxQ stGQSjzUiluYtA/0tQifPPs6BR7Vgmn6Dsg4IFc1bd+S9IqK2BLxuhX9KT6xo6ybFgFn m+d1w3VbyTX8klvlQ0i3KMuR/sci6lGh1gI/IRx0D7zeoyGr/dlFmZmpvV4OX9OGDe1Q BQQw==
Received: by with SMTP id af5mr9773039oec.72.1334942819217; Fri, 20 Apr 2012 10:26:59 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id m2sm7071326obk.9.2012. (version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 10:26:57 -0700 (PDT)
Subject: Re: Comments on <draft-gont-6man-stable-privacy-addresses-01>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Bob Hinden <>
In-Reply-To: <>
Date: Fri, 20 Apr 2012 10:26:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Fernando Gont <>
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 WG Mailing List <>, Bob Hinden <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Apr 2012 17:27:01 -0000


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

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.



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