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

On Fri, Jun 9, 2017 at 1:18 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
> Hi Tom,
>
> On 9 Jun. 2017 13:03, "Tom Herbert" <tom@herbertland.com> wrote:
>
> 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>
>
>> 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?
>
>
>
> Yes. You know the IID is valid at the point in time you send the packet,
> meaning the IID is in use by a device and the device can be targetted with
> an attack.
>
> This is mitigation against discovery of IIDs assigned to devices via
> probing, prior to launching the attack on the device.
>
> I'm pointing out that concerns about discovery of valid addresses on
> conventional hosts via probing can also be concerns for networking devices
> with IPv6 addresses as well, such as routers and switches, and that large
> entropy IIDs can provide them with an additional level of defence in depth
> that wasn't possible to have in IPv4. The control planes of networking
> devices are performing host functions too, so host security mitigations are
> applicable.
>
> Some seem to believe that network devices software/firmware is far more
> robust and they're universally configured far more securely such that
> limiting the exposure and discoverability of the devices' addresses provides
> no value. I think the links I provided earlier and the following links to
> network OS vulnerabilities shows that this isn't the case.
>
> https://www.cvedetails.com/vulnerability-list/vendor_id-874/product_id-3989/Juniper-Junos.html
>
> https://www.cvedetails.com/vulnerability-list/vendor_id-16/product_id-19/Cisco-IOS.html
>
And wannacry exploits an OS vulnerability in Windows. I think the
intent of address randomization might be in the right place, but there
too many caveats to call this real security for hosts. As I said, when
we do host development we can never assume that every network
uniformly provides any in sort of security. It is prudent to assume
the opposite: the network is an untrusted entity, anyone can intercept
our packets, there is no firewall to protect us. Anything sent in the
clear, including IP addresses, should be considered as being exposed
to the whole world. If you want to hide something it needs to be
encrypted. This is the correct mindset to start with for building
robust and secure host implementations.

Tom

>
> Regards,
> Mark.
>
>
> 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.
>
>
> 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
>> --------------------------------------------------------------------
>
>