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

From: "Marksteiner, Stefan" <[email-masked]>
Date: Mon, 24 Sep 2012 20:03:06 +0200

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.

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.

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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 24 Sep 2012 13:37:14 -0700 (PDT)

Hi Stefan,

----- Original Message -----

> From: "Marksteiner, Stefan" <[email-masked]>
> To: IPv6 Ops WG <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Marksteiner, Stefan" <[email-masked]>
Date: Tue, 25 Sep 2012 11:42:42 +0200

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.

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 [[email-masked]]
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 -----

Regards,

Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Sep 2012 14:27:51 +0100

> 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

---

From: "Marksteiner, Stefan" <[email-masked]>
Date: Tue, 25 Sep 2012 16:18:59 +0200

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

Regards,

Stefan

________________________________________
Von: Brian E Carpenter [[email-masked]]
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

    Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 25 Sep 2012 12:42:14 -0700 (PDT)

----- Original Message -----
> Cc: Mark ZZZ Smith <[email-masked]>
> 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).

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.

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

---

From: "Marksteiner, Stefan" <[email-masked]>
Date: Wed, 26 Sep 2012 09:16:12 +0200

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.
Maybe I have been stuck  in my mindset a little, as we use only static addresses in our productive IPv4 network. 
Thanks :)

Cheers,

Stefan

-----Ursprüngliche Nachricht-----
Von: Mark ZZZ Smith [mailto:[email-masked]] 
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 -----
> 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).

Regards,
Mark.

> Betreff: Re: [v6ops] Operational guidelines for a company/organization 
> IPv6 address scheme supplemental to RFC5157
> 
> 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.
>> 
> 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.
>> 
> don't need Internet connection, but what about workstations for 
> employees needing the Internet?
>> 
> ::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.
> 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
> 
> 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.
>> 
> 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
>> 
>> 
>>  Betreff: Re: [v6ops] Operational guidelines for a 
>> company/organization IPv6
> address scheme supplemental to RFC5157
>> 
>>  Hi Stefan,
>> 
>>>  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
>>>  mitigation methods may be deemed difficult to handle for 
>>> administrators
> (SEND
>>>  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.
>> 
>> 
> inclined to attack you - for a typical non-Internet services 
> organisation, I think it's more likely going to be
>>>  a sequential host number. The first requires the scheme to be 
>>> slightly
> different
>>>  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.
>>> 
>> 
> 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.
>> 
> Internet, they can be not assigned a global prefix, and numbered from 
> either the ULA address space (RFC4193) or left as link-locals only

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Sep 2012 13:15:15 +0100

> 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

---

From: "Marksteiner, Stefan" <[email-masked]>
Date: Wed, 26 Sep 2012 16:59:54 +0200

Hi,

>IID part of the addresses.

yes, that's exactly my point.

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

I strongly agree.

Regards,

Stefan
________________________________________
Von: Brian E Carpenter [[email-masked]]
Gesendet: Mittwoch, 26. September 2012 14:15
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

   Brian

---

From: Philipp Kern <[email-masked]>
Date: Thu, 27 Sep 2012 00:27:45 +0200

On Wed, Sep 26, 2012 at 09:16:12AM +0200, Marksteiner, Stefan wrote:
> 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).

Wouldn't it be better to track the tables of your switches and routers
(possibly with port info) instead? Because everybody can infer the subnet from
one stateful DHCPv6 reply and just use another address. Well, unless your
hardware can already do DHCPv6 snooping at the edge, which seems to be sort of
rare.

Kind regards
Philipp Kern

---

From: John Mann <[email-masked]>
Date: Thu, 27 Sep 2012 09:23:31 +1000

Hi,

> hardware can already do DHCPv6 snooping at the edge, which seems to be

I'm trying
a) to track which addresses are used by which hosts for forensics and
Internet authentication, and
b) allow for some basic network-level filtering (e.g. only allow those PCs
to ssh into this host)

Currently PCs get
1) MAC-based SLAAC addresses
2) a new Privacy IPv6 addresses every day -- that lasts for n days

There is no global event (like DHCPv4 traffic or RADIUS 802.1x) that
signifies when a new SLAAC or privacy address starts or stops being used.

Polling all routers for IPv6 neighbour tables (e.g. every hour) is
certainly possible, but it leads to lots of data.
It helps to do a FF02::1 multicast ping out each Vlan to refresh the tables
first, but many PCs have firewalls that drop all pings ...
If a PC is using a Privacy address for outbound communication, do you ever
see the MAC-based address?

As a test, I ran a ISC dhcpd to do stateful DHCPv6 address assignment to
get some sticky-ness to the IPv6 address used by a PC when connected to a
particular Vlan, and
3) the test PCs got an *extra* DHCPv6-assigned IPv6 address
But the PCs still preferred Privacy addresses for new outbound connections!!

To get PCs to use DHCPv6-assigned addresses instead of Privacy addresses,
do I need to change the RAs to disable all use of SLACC addresses
and then risk breaking IPv6 for any devices that don't support DHCPv6??

I'm at a University and have no control over the mixed BYOD fleet, just
over the network and DHCPv* servers.

Thanks,
    John

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Sep 2012 20:26:32 +0200

Stefan,

On 09/25/2012 11:42 AM, Marksteiner, Stefan wrote:
> 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.

If so, you should implement draft-ietf-6man-stable-privacy-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.

It's also nullified for other reasons. Please see:
<http://www.si6networks.com/presentations/IETF84/fgont-ietf84-opsec-host-scanning.pdf>

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

draft-ietf-6man-stable-privacy-addresses aims at exactly that.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Sep 2012 20:43:09 +0200

On 09/26/2012 09:16 AM, Marksteiner, Stefan wrote:
> 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). 

You might want to use ipv6mon for that:
<http://www.si6networks.com/tools/ipv6mon>

> Privacy extensions would perhaps be too unpredictable to manage, but
> stateful DHCPv6 combined with a suitable IPAM-solution would probably
> do the trick. Maybe I have been stuck  in my mindset a little, as we
> use only static addresses in our productive IPv4 network. 

Either the above, and/or implement draft-ietf-6man-stable-privacy-addresses

Thanks,