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

Bob Hinden <bob.hinden@gmail.com> Fri, 20 April 2012 17:27 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3F921F8674 for <ipv6@ietfa.amsl.com>; Fri, 20 Apr 2012 10:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.548
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Neg4DQh6kiIZ for <ipv6@ietfa.amsl.com>; Fri, 20 Apr 2012 10:27:00 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA22F21F85A2 for <ipv6@ietf.org>; Fri, 20 Apr 2012 10:26:59 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so6112838yhk.31 for <ipv6@ietf.org>; Fri, 20 Apr 2012 10:26:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.60.169.165 with SMTP id af5mr9773039oec.72.1334942819217; Fri, 20 Apr 2012 10:26:59 -0700 (PDT)
Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id m2sm7071326obk.9.2012.04.20.10.26.56 (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 <bob.hinden@gmail.com>
In-Reply-To: <4F91072F.1070406@si6networks.com>
Date: Fri, 20 Apr 2012 10:26:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6466F90-E028-40FF-9952-27EF0ED09A0E@gmail.com>
References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <4F8E442D.1090700@si6networks.com> <EE1520D5-4E80-4940-86F8-8114FF3A5C6D@gmail.com> <4F91072F.1070406@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 WG Mailing List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2012 17:27:01 -0000

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: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>