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

["Marksteiner, Stefan" <[e-mail]>]

Hi,


>And if you care about easy-to-guess addresses, use a pseudorandom method to assign the
>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 [[e-mail]]
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

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:[e-mail]]
> 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" <[e-mail]>
>> To: IPv6 Ops WG <[e-mail]>
>> Cc: Mark ZZZ Smith <[e-mail]>
>> 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 [[e-mail]]
>> 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 [[e-mail]]
>>>  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"
>> <[e-mail]>
>>>>  To: IPv6 Ops WG <[e-mail]>
>>>>  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
>>>>  [e-mail]
>>>>  https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>  _______________________________________________
>>>  v6ops mailing list
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/v6ops
>>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>