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

Le 09/06/2017 à 05:03, Tom Herbert a écrit :
> On Thu, Jun 8, 2017 at 7:46 PM, Mark Smith <markzzzsmith@gmail.com> 
> wrote:
>> On 9 June 2017 at 03:17, Fernando Gont <fgont@si6networks.com> 
>> wrote:
>>> On 06/08/2017 02:41 PM, Lorenzo Colitti wrote:
>>>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont 
>>>> <fgont@si6networks.com <mailto:fgont@si6networks.com>> 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.
>> 
> Mark,
> 
> I don't quite understand this statement. Isn't is true that If I send
> a packet to any IID in the prefix for a device it will reach the
> device and be processed?

Well depends on the link on which that device is.

If it is on a ptp link like current cellular then yes, it receives all
the packets addressed to all IIDs within the /64 it is allocated.  It is
this property that is exploited by '64share' technique to make such
devices routers.  It is not a good property, but yes there is.

On another hand, if it is a device on a more shared link more like true
Ethernet, then it receives only packets addressed to the addresses
within that /64 that have been configured on the interface (for which it
answers with NA).

Remark also that there are proposals of acting more like ptp even in the
second case (the 'WiFi /64 unique prefix per host' document).

So - it depends on the link.

> I may not get a response because that's not the IID randomly chosen 
> as the address of the device, but it still seems like that could be 
> used for DOS (like a tuple attack on a NIC queue) if the prefix is 
> discovered or predictable.

This is the case if the link is ptp, or if it is WiFi with a /64
assigned per host.

It is not the case (not all packets to all IIDs in a /64 reach a host
which has not configured them on the iface) if the link is WiFi and the
/64 is shared among all hosts on that link.

(which makes think what you say above is a security risk that could be
literally be pointed to the /64-per-host
draft-v6ops-unique-ipv6-prefix-per-host proposal in v6ops WG; and that
there are some RFCs about network scanning like RFC5157 "Implications of
IPv6 Network Scanning").

And, even if the /64 is shared among multiple hosts on that link,
sending an arbitrary packet (TCP Ack?) in a D-DoS manner to all
addresses in a /64 prefix is an attack to the Router in charge of that
link and on the link itself: there could be very many NSs sent to the
link (a 'storm').  The larger the plen the bigger the storm.

Alex

> Tom
> 
>> 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.
>> 
>> --------------------------------------------------------------------
>>
>>
>> 
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests: 
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>
>>
>> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 