Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00)

[Mark Smith <[e-mail]>]

On 9 June 2017 at 03:17, Fernando Gont <[e-mail]> wrote:
> On 06/08/2017 02:41 PM, Lorenzo Colitti wrote:
>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
<snip>
>
> The point is that when employing manual configuration, addresses always
> have small entropy. Hence employing a lot of bits doesn't buy much,
> because folks simply do not use them for additional entropy.
>

So I was specifically talking about network infrastructure devices
benefiting from large entropy in 64 bit IIDs.

My view comes from slides like this one, showing in 2012 there were
268 000 Cisco IOS devices SNMP exposed to the Internet with a
'public' community, and 18 000 with 'private'.

https://speakerdeck.com/hdm/derbycon-2012-the-wild-west?slide=54

Cisco IOS devices obviously aren't hosts. People have very
successfully scanned for and discovered devices that network operators
should be securing.

Here's more recent similar data from 2016. Much better, however still
a lot of targets.

https://www.shodan.io/report/mTVIRLZi


I'm not aware of similar data for other network equipment vendors.
Cisco is going to be the biggest target.

This is about raising the security bar, and with manually configured
addresses with high entropy, or RFC7217 on routers and switches out of
the box, raising it by default. If the device can't be discovered, it
isn't possible to send a packet to it.

If you choose to specifically lower device security against discovery
by putting routers in DNS, or allowing routers to respond to
traceroutes, you consciously know you're lowering it for the specific
device and can be vigilant when taking other measures to raise it
again (ACLs etc.)

Note that I'm not saying this is the only security measure you should
have. It is an additional defence in depth measure that IPv6
addressing can provide to network infrastructure devices that IPv4
addressing could not.

Regards,
Mark.