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

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Tue, 25 September 2012 19:42 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
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 417BD21F8897 for <v6ops@ietfa.amsl.com>; Tue, 25 Sep 2012 12:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.292
X-Spam-Level:
X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6]
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 xtHT735uMkXM for <v6ops@ietfa.amsl.com>; Tue, 25 Sep 2012 12:42:22 -0700 (PDT)
Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by ietfa.amsl.com (Postfix) with SMTP id 5B2EC21F8873 for <v6ops@ietf.org>; Tue, 25 Sep 2012 12:42:22 -0700 (PDT)
Received: from [98.139.52.194] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2012 19:42:15 -0000
Received: from [98.139.52.154] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2012 19:42:15 -0000
Received: from [127.0.0.1] by omp1037.mail.ac4.yahoo.com with NNFMP; 25 Sep 2012 19:42:15 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 760757.44403.bm@omp1037.mail.ac4.yahoo.com
Received: (qmail 74280 invoked by uid 60001); 25 Sep 2012 19:42:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1348602135; bh=PLQUdb4bis+PFuX725ZEVGwSDe403fRA6YsvlzDGtL0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xOVHaTQ0I0v9PnbyAi8FgNH/c2OIbDs5/7Jj/KDUhEtZoL9Su8ubUWBuU3DF2wNoYaTQqIVZYXeXrGwKdG+Daj4sI4xup8/SJSeiMlYhX/C7+23b6RILsdRXwrOh89nRpmPHUwqEDjIQWU/k2mxp6uYVaZgAWARmO5QnCmJxAfw=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D0ZAIlABbQt4RucgWWfeEFiNeZ+ES+bJjKUFL2yzXIeIkz7ORqWxu5AJMxwSbNhg5svCeNJRRmeUZrXsTMOu1oMnBudziQ6KUjawcNSIrp3NZHf6GOWcreMM3jisS27sWWF+cAXBA+6WuXv5rvtIzBGnvZwkCpd53+Z3IKe7c8U=;
X-YMail-OSG: MR35_6YVM1k_tGGZFxUO9gwUKMFhpnLp6os2yJXkLF1Skqk XudI3I_YPZOpURXVLQaXxNic3lzG9HvfXiS5KLD7rOVW8K0SfJHpUDAzdmFg Ryb2mkkFxAa5aG_5FzvPJOnbZwCdd_dTB_rh2obGrKPLg0OQkkEOsF3Hh0IB pps4hIy2_V9L59BDGWM4ujbTVnuE6huTTu3tXVrU_xwZjGO6DjBnkX4vH6Sp 8zabUODr94UWYZCl3GSKeAB8zEoZtonN6jVK4HU0sfS7A3kBWMfPbWCwc_B8 xbEAQgNbbbUMOMmRgMQ63fEJCdBhi5FYhOjBgdyTfY3FvKwh4E871vMEfgcX ZuRfdZv9yFPEVp7MNf6op7gc6m7iOrBDon0RCKn_Nge9eSZnCIWOeD6Yrjsl DdDeWP4nw3o9ODvJeVavLEAo8WV5dmMTTgR57XrYc50kqfdFZR0R_eH_jV9y bKtPgFrdHpGEVkXYO6wqQy3AhYlvCzRsz_yk7vZsUflSuees_9DMZVLASU6J 8gw2.bpxuul2jq6EdDOb4njA6TpQcg68WehHS8BDK7axZYN_u2CzLHRCBKSS z.euqRPh2SIFf0b59GDHq9ztOocOhbs6gZHZk6ZmJxowOQn2JEd5InXxPlQ- -
Received: from [150.101.221.237] by web32505.mail.mud.yahoo.com via HTTP; Tue, 25 Sep 2012 12:42:14 PDT
X-Mailer: YahooMailWebService/0.8.121.434
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>
Message-ID: <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com>
Date: Tue, 25 Sep 2012 12:42:14 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: "Marksteiner, Stefan" <stefan.marksteiner@joanneum.at>, IPv6 Ops WG <v6ops@ietf.org>
In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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: Tue, 25 Sep 2012 19:42:24 -0000




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