Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 26 September 2012 12:15 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB7721F87F3 for <v6ops@ietfa.amsl.com>; Wed, 26 Sep 2012 05:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.262
X-Spam-Level:
X-Spam-Status: No, score=-103.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMiGNY4XMvm7 for <v6ops@ietfa.amsl.com>; Wed, 26 Sep 2012 05:15:10 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B207B21F858F for <v6ops@ietf.org>; Wed, 26 Sep 2012 05:15:10 -0700 (PDT)
Received: by iec9 with SMTP id 9so1383420iec.31 for <v6ops@ietf.org>; Wed, 26 Sep 2012 05:15:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nrbSPQS5gq0eYM56Ak7cvIbGi+zOC2gqlkeMS6/Kf3o=; b=LShI9JecoWye/mFwOmnF4bbM4k/+YqxDlF/2//hry2ls8FWQAI/eng39RvnRnURD7X Q357/oaIuLGnSMp6s/LEUAL+ScRJwnB8q0hJR96kYePVB6uKyKFhHNOoHCOwsw5AGwan dX2GfsYfZ4u7mwY45E7Twc/+9tUayJC+4mMZEwZQ8jVIj/wBgNsRrSlAbQpqy6jIh+BZ LlsGDLicP0fWHG1TZYKYKN9FAe+2hBUsikSB2bE66SJun9sEr1dUsHAsa01qs01eQ6gN frnAMCQQcQe6prZ5V20of2E0TpnONLAN6Jlme0UCRSGViXZ17xfo5Vdom6c4z7E7GpDp Rycw==
Received: by 10.50.57.194 with SMTP id k2mr295790igq.17.1348661710164; Wed, 26 Sep 2012 05:15:10 -0700 (PDT)
Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id hz10sm10194077igc.12.2012.09.26.05.15.09 (version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 05:15:09 -0700 (PDT)
Message-ID: <5062F1D3.2030601@gmail.com>
Date: Wed, 26 Sep 2012 13:15:15 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Marksteiner, Stefan" <stefan.marksteiner@joanneum.at>
References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local>, <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local>
In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: 'IPv6 Ops WG' <v6ops@ietf.org>
Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2012 12:15:12 -0000

On 26/09/2012 08:16, Marksteiner, Stefan wrote:
> Hi,
> 
> There's a variety of reasons to keep track of addresses from usage and statistics to forensic purposes in security incidents (also those which are perpetrated from inside sources to outside targets).
> Privacy extensions would perhaps be too unpredictable to manage, but stateful DHCPv6 combined with a suitable IPAM-solution would probably do the trick.

And if you care about easy-to-guess addresses, use a pseudorandom method to assign the
IID part of the addresses.

> Maybe I have been stuck  in my mindset a little, as we use only static addresses in our productive IPv4 network. 

We do need to get away from that as much as possible (see 6renum WG for more).

   Brian

> Thanks :)
> 
> Cheers,
> 
> Stefan
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au] 
> Gesendet: Dienstag, 25. September 2012 21:42
> An: Marksteiner, Stefan; IPv6 Ops WG
> Betreff: Re: AW: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157
> 
> 
> 
> 
> 
> ----- Original Message -----
>> From: "Marksteiner, Stefan" <stefan.marksteiner@joanneum.at>
>> To: IPv6 Ops WG <v6ops@ietf.org>
>> Cc: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>> Sent: Wednesday, 26 September 2012 12:18 AM
>> Subject: AW: [v6ops] Operational guidelines for a company/organization 
>> IPv6 address scheme supplemental to RFC5157
>>
>> Hi Brian,
>>
>> SLAAC is *somewhat* predictable, especially when you already have one 
>> address as a starting point (then you've got a vendor ID plus a 
>> probable batch which narrows the scanning address room significantly).
>> Of course I assume workstation machines not to be in public a DNS zone...
>>  
> 
> So if you want unpredictable, you use privacy addresses. They're not hard to enable, and in some cases (recent Windows OSes, Fedora 17) they're enabled by default.
> 
> If you've chosen to go down the stateful DHCPv6 path, I'd verify what sort of allocation scheme it uses or can be enabled - there may and perhaps will likely be a "random" option.
> 
> What problem are you trying to solve by having technical staff being able to determine addresses? Is it to record addresses in use? Or address utilisation within the subnet?
> 
> Regards,
> Mark.
> 
>> Regards,
>>
>> Stefan
>>
>>
>> ________________________________________
>> Von: Brian E Carpenter [brian.e.carpenter@gmail.com]
>> Gesendet: Dienstag, 25. September 2012 15:27
>> An: Marksteiner, Stefan
>> Cc: Mark ZZZ Smith; IPv6 Ops WG
>> Betreff: Re: [v6ops] Operational guidelines for a company/organization 
>> IPv6 address scheme supplemental to RFC5157
>>
>> On 25/09/2012 10:42, Marksteiner, Stefan wrote:
>>>  Hi Mark,
>>>
>>>  First of all I think I've forgotten to clarify that I'm talking
>> about IIDs, sorry ;)
>>>  The aim of my thoughts would be to make it harder for externals to 
>>> scan for
>> attackable addresses. One often cited (mostly by marketeers) benefit 
>> of IPv6 is the vast amount of addresses per subnet making it seemingly 
>> harder to scan, which would be nullified if companies used simple sequential addressing.
>>>  You're of course right that most (potential) attackers are insiders 
>>> -
>> but they likely wouldn't have to scan anyway, instead the would 
>> probably already have knowledge of alive (and maybe even vulnerable) 
>> hosts. Thus, they aren't my focus in this matter, but instead are 
>> "black box"-scanners and Internet worms.
>>>  ULA/LLA are, as you've correctly stated, the best choice if you
>> don't need Internet connection, but what about workstations for 
>> employees needing the Internet?
>>>  I'm suggesting to recommend companies to use a different scheme as
>> ::1;::2 or ::BABE;::CAFE or even ::4593;4594 and so on which according 
>> to some studies (e.g. [1], pp.65-75, especially 68) most 
>> administrators unfortunately do.
>>>  What might be needed to change this would be a scheme which is 
>>> practicably
>> administrable in the easiest possible way.
>>
>> It depends what you mean by "administrable" but SLAAC doesn't need a 
>> scheme and therefore doesn't need administration. For machines that 
>> are in public DNS it doesn't matter anyway, so any scheme will do.
>>
>>     Brian
>>
>>>  This would have, in my opinion, two benefits. Firstly it would 
>>> render
>> standard scanning procedures for IPv6 like sequential scanning and 
>> scanning for "funny" addresses pretty much useless. Secondly, if the 
>> numbers are, seen from the outside, seemingly random, it wouldn't help 
>> a scanner or worm if he or it discovered a single address by chance 
>> (e.g. by a log entry) and took it as a starting point for further scanning.
>>>  I'm aware of the discussions about security by obscurity and that a
>> good firewall is needed anyway to secure internal assets, but I would 
>> find it nice if the often cited "security argument" that IPv6 subnets 
>> are merely impossible to scan would be true (again) :)
>>>
>>>  Cheers,
>>>
>>>  Stefan
>>>
>>>
>>>  [1]http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf
>>>  ________________________________________
>>>  Von: Mark ZZZ Smith [markzzzsmith@yahoo.com.au]
>>>  Gesendet: Montag, 24. September 2012 22:37
>>>  An: Marksteiner, Stefan; IPv6 Ops WG
>>>  Betreff: Re: [v6ops] Operational guidelines for a 
>>> company/organization IPv6
>> address scheme supplemental to RFC5157
>>>  Hi Stefan,
>>>
>>>  ----- Original Message -----
>>>
>>>>  From: "Marksteiner, Stefan" 
>> <stefan.marksteiner@joanneum.at>
>>>>  To: IPv6 Ops WG <v6ops@ietf.org>
>>>>  Cc:
>>>>  Sent: Tuesday, 25 September 2012 4:03 AM
>>>>  Subject: [v6ops] Operational guidelines for a company/organization 
>>>> IPv6
>> address scheme supplemental to RFC5157
>>>>
>>>>  Hi Folks,
>>>>
>>>>  RFC5157 presents hazards of sequentially numbering IPv6 networks 
>>>> and
>> technical
>>>>  means (like CGAs and privacy extensions) to mitigate them. 
>> Unfortunately these
>>>>  mitigation methods may be deemed difficult to handle for 
>>>> administrators
>> (SEND
>>>>  may be too complicated to implement, PEs bring difficulties to keep
>> track of IP
>>>>  addresses). Therefore there may be demand for an addressing scheme
>> (rather than
>>>>  a technical method) that makes IPv6 addresses easy to predict for 
>>>> tech
>> staff but
>>>>  difficult to do so by outsiders, building a low-end supplement for 
>>>> the
>> methods
>>>>  mentioned in RFC5157.
>>>
>>>  I think it might be worth having a bit more of a think about who 
>>> might be
>> inclined to attack you - for a typical non-Internet services 
>> organisation, I think it's more likely going to be
>>>  disgruntled ex-staff, and it'll be hard to make them forget
>> "numbers" / addresses or prevent them copying the mapping application 
>> if they have an inkling they're going to get fired.
>>>
>>>>  What I have in mind is an simple mental arithmetic operation, which
>> generates an
>>>>  address out of a company fixed part plus a sequential number for host.
>>>>  Alternatively a Hash-Operation consisting again of a secret
>> organisational plus
>>>>  a sequential host number. The first requires the scheme to be 
>>>> slightly
>> different
>>>>  in every organisation in order to have a negative impact on IPv6
>> scanning from
>>>>  external sources, the second is more secure but requires an 
>>>> internal
>> web site or
>>>>  smartphone app in order for field engineers to calculate an address 
>>>> out
>> of the
>>>>  sequential information.
>>>>
>>>  It sounds like here you're talking about a subnet numbering scheme. 
>>> The
>> common prefix size for most organisations is going to be /56 or 256 
>> /64 subnets, or /48 or 65K /64 subnets. Many providers seem to be 
>> leaning towards /56s unless their customers ask for a /48, which 
>> provides very little address space to effectively hide the in-use 
>> subnet numbers from a scanning based attack (and that's one of the 
>> reasons why I'd be giving customers /48s from the outset). One 
>> advantage though of IPv6 is that it is possible to phase in and phase 
>> out addressing using the address/prefix lifetimes mechanism, so it would be possible to change assigned in your network prefixes on e.g. a weekly basis.
>>>  If your fundamental goal is to make internal links unreachable from 
>>> the
>> Internet, they can be not assigned a global prefix, and numbered from 
>> either the ULA address space (RFC4193) or left as link-locals only 
>> ("unnumbered"). You may be interested in the following, which 
>> discusses link-local only addressing -
>>>  "Using Only Link-Local Addressing Inside an IPv6 Network"
>>>  http://tools.ietf.org/html/draft-behringer-lla-only-01
>>>
>>>
>>>  Regards,
>>>
>>>  Mark.
>>>
>>>>  My question is, in your opinion, would this be worthwhile to be
>> formulated as an
>>>>  ID an be drafted or does this idea sound absurd?
>>>>
>>>>
>>>>  Cheers,
>>>>
>>>>  Stefan
>>>>  _______________________________________________
>>>>  v6ops mailing list
>>>>  v6ops@ietf.org
>>>>  https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>  _______________________________________________
>>>  v6ops mailing list
>>>  v6ops@ietf.org
>>>  https://www.ietf.org/mailman/listinfo/v6ops
>>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>