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

[David Farmer <[e-mail]>]

On Tue, Jun 6, 2017 at 8:23 PM, Mark Smith <[e-mail]> wrote:

> On 7 June 2017 at 09:30, Job Snijders <[e-mail]> wrote:
> > On Tue, 6 Jun 2017 at 16:28, Brian E Carpenter <
> [e-mail]>
> > wrote:
> >>
>
> <snip>
>
> >> >
> >> > is this draft exactly:
> >> >
> >> >    IPv6 unicast routing is based on prefixes of any valid length up to
> >> >    128 [BCP198].  Interface Identifiers should be 64 bit long except
> >> >    when the addresses are manually configured, or by exceptions
> defined
> >> >    in standards track documents.  For example, [RFC6164] standardises
> >> >    127 bit prefixes on inter-router point-to-point links.  The
> rationale
> >> >    for using 64 bit Interface Identifiers can be found in [RFC7421]
> >> >
> >> > ?
> >>
> >> Yes. Put those words in 4291bis and I will be very happy. Oh ;-).
> >
>
>
> "Interface Identifiers should be 64 bit long except when the addresses
> are manually configured, or by exceptions defined in standards track
> documents."
>
> That doesn't mention that security and privacy properties of addresses
> will be compromised if the manually configured addresses are from a
> small prefix.
>
> Security and privacy properties of addresses are independent of the
> method used to configure them. Addresses configured via SLAAC, DHCPv6
> or manual configuration from within a small prefix/address range all
> lose privacy and security properties and value.
>

The security considerations for RFC4291bis-07 already says the following;

   One area relavant to IPv6 addressing is privacy.  IPv6 addresses can
   be created using interface identifiers constructed with unique stable
   tokens.  The addresses created in this manner can be used to track
   the movement of devices across the Internet.  Since earlier versions
   of this document were published, several approaches have been
   developed that mitigate these problems.  These are described in
   "Security and Privacy Considerations for IPv6 Address Generation
   Mechanisms" [RFC7721], "Privacy Extensions for Stateless Address
   Autoconfiguration in IPv6" [RFC4941], and "A Method for Generating
   Semantically Opaque Interface Identifiers with IPv6 Stateless Address
   Autoconfiguration (SLAAC)"[RFC7217].

Section 4.2 or RFC7721 already discusses manual configuration of addresses,
if you think more is necessary then maybe RFC7721 needs to be updated.

Job and others might say those privacy and security properties of
> large addresses is only useful to hosts, not infrastructure such as
> routers. I disagree.
>
> Large addresses can be of value in infrastructure addressing too. If a
> network operator wants to significantly mitigate if not prevent an
> attack such as a BGP listener TCP SYN attack from the Internet, they
> can hide the router's interface address somewhere inside a /64 so that
> the attacker can't find it via unsolicited inbound probing. If the
> attacker decides to persist, they'll have to resort to other methods
> to discover the device that are or can be made more costly.
>
> If a network operator's router vendor supports RFC7217 for interface
> addresses, they get that security advantage of large addresses by
> default when they add the /64 to the interface. Router interfaces are
> one of the motivations for RFC7217 being able to use the interface
> ifIndex value for the Net_Iface parameter (Appendix A) - the comment
> about ifIndexes being enabled to be consistent across network
> interface changes was my suggestion, and the use case in my mind was
> router interface module swaps.
>
> It is self evident that a packet that cannot reach a device cannot be
> used to attack the device.
>
> Perhaps those who commented during rfc4291bis last call and who may
> not have seen the WG's addressing privacy and security discussions
> over the last 4 years haven't realised that many more addressing bits
> can provide more capability and value than just the ability to connect
> more hosts.
>

I agree security and privacy are relevant issues for infrastructure
addressing plans, but they are by no means the only or even necessarily the
dominant considerations involved.  I'll note that at least in my network
relying on address obfuscation is not sufficient, I have to assume that the
users on my network are untrusted, I have to tell them the first hop router
one way or another, and finding the intermediate routers isn't that hard
(traceroute).

That said, I'll be poking at my routing vendors about RFC7217 support.
However, I have a long list of issues for them already, so I'm not sure
where this sits on the list of priorities with them. :)

Thanks
-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================