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

Bob Hinden <bob.hinden@gmail.com> Wed, 18 April 2012 20:55 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 0A43711E80C0 for <ipv6@ietfa.amsl.com>; Wed, 18 Apr 2012 13:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.932
X-Spam-Level:
X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, 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 v2PZPqA1+LdY for <ipv6@ietfa.amsl.com>; Wed, 18 Apr 2012 13:55:47 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4935E11E80AF for <ipv6@ietf.org>; Wed, 18 Apr 2012 13:55:38 -0700 (PDT)
Received: by obbwd20 with SMTP id wd20so6555192obb.31 for <ipv6@ietf.org>; Wed, 18 Apr 2012 13:55:37 -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=/LZ1XvkA6w7E//nzZ4kDC0+7FuBmW6tMDG+p1ml+im0=; b=YEQVcMIoG6pw6W5lUoK/4QyR1PVbFEb3ihyJLtg5RMV5PSXgF6WQEbvAFuifEYuzP0 Rp0iBdILL/Sx61IbU6LI7Ns1ijMACt33M+1+HypWdPrFOwW8jxRZ/GcS5mRDqPGjDaoK fqQxfmSfETg1F0vVeQEzkZG6c/lKPmWhOorCe9xdcfqpHitvSHvy/se01+GRYvuMFOpz r8SwrpfDckJxsKVM3oXj08oL9pqZY8lrIJnk1OSiwK7lAC6FW/gZdlQruAI+kiwI2tUq 4j9dgy2g9qWpTaDolBR/CrA3KrL87mdND9dBJ2pXphsIx/j6BiMHRnQ+A6KASMGyyqOk OJhA==
Received: by 10.182.169.68 with SMTP id ac4mr5257297obc.19.1334782537891; Wed, 18 Apr 2012 13:55:37 -0700 (PDT)
Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id k2sm44395obl.14.2012.04.18.13.55.35 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 13:55:36 -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: <4F8E442D.1090700@si6networks.com>
Date: Wed, 18 Apr 2012 13:55:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE1520D5-4E80-4940-86F8-8114FF3A5C6D@gmail.com>
References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <4F8E442D.1090700@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: Wed, 18 Apr 2012 20:55:48 -0000

Fernando,

On Apr 17, 2012, at 9:33 PM, Fernando Gont wrote:

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

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.

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


> 
> 
> 
>> 5. Security Considerations
>> 
>> In the second paragraph the document says
>> 
>> "We note that this algorithm is meant to replace Modified EUI-64
>> format identifiers".
> 
> 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/

I think for now, I suggest an alternative approach.  

This should be stated earlier in the document too.


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

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.


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

Thanks, as I suspected.

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

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

Sounds good.

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

Cool!

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