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

From: Mark Smith <[email-masked]>
Date: Wed, 7 Jun 2017 11:23:00 +1000

On 7 June 2017 at 09:30, Job Snijders <[email-masked]> wrote:
> On Tue, 6 Jun 2017 at 16:28, Brian E Carpenter <[email-masked]>
> 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.

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.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Tue, 6 Jun 2017 22:24:49 -0500

> 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.

> can provide more capability and value than just the ability to connect

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:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Jun 2017 20:37:23 -0700

> will be compromised if the manually configured addresses are from a

Or advertised in DNS?

I would expect that any address configured manually would also be advertised in DNS, the latter being the reason for the former. If the address is publicly announced, does one have a reasonable expectation of privacy?

---

From: Job Snijders <[email-masked]>
Date: Wed, 07 Jun 2017 03:40:41 +0000

I don't think so.

On Tue, 6 Jun 2017 at 20:37, Fred Baker <[email-masked]> wrote:

> I would expect that any address configured manually would also be
> advertised in DNS, the latter being the reason for the former. If the
> address is publicly announced, does one have a reasonable expectation of
> privacy?

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 6 Jun 2017 23:48:08 -0400

> address is publicly announced, does one have a reasonable expectation of
for the router interface case there's also just:
  1) traceroute, see interfaces in question
  2) ddos engine on!

there are many ways to skin this cat, address 'privacy' here isn't really
the thing that helps (make routers less vulnerable to randos and packet
cannons)

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Jun 2017 20:48:38 -0700

> I don't think so.
Right. This security technique doesn't help any servers on the
Internet that have public DNS addresses or other situations where the
addresses can be discovered. In reality, hosts should never assume
that the network provides any security which is why we need to spend a
lot of effort hardening stacks to handle SYN and other types of
attacks. It's great if this makes attackers work harder, but I would
never count on for security from a host perspective.

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: [email-masked]
Date: Wed, 07 Jun 2017 07:51:31 +0200 (CEST)

> I would expect that any address configured manually would also be advertised in DNS, the latter being the reason for the former. If the address is publicly announced, does one have a reasonable exp…

That's precisely the point. I configure fixed addresses typically for
servers, and I put the addresses in the DNS. I *want* those addresses
to be publically known. Security and privacy is not relevant in this
particular case.

Steinar Haug, AS2116

---

From: Erik Kline <[email-masked]>
Date: Wed, 7 Jun 2017 17:53:05 +0900

> to be publically known. Security and privacy is not relevant in this

For an authoritative server, sure.

But if you're a recursive resolver then using privacy addresses while doing
recursion (and changing the privacy addresses frequently) might indeed be
very useful.  (In fact: a unique source address per query is wonderful.)

---

From: [email-masked]
Date: Wed, 07 Jun 2017 14:29:36 +0200 (CEST)

> very useful.  (In fact: a unique source address per query is wonderful.)

Different strokes for different folks. I'm fine with fixed addresses
for the query sources of my recursive resolvers, and have no plans to
change this. I have no problems with others using a unique source
address per query.

Steinar Haug, AS2116

---

From: Fernando Gont <[email-masked]>
Date: Wed, 7 Jun 2017 15:03:18 +0300

> lose privacy and security properties and value.

Measurements indicate that when folks do manual configuration, they do
"low-byte" addresses -- i.e., no matter the prefix length, they just set
the IID to all zeroes except for the last byte or so. -- having "easy to
remember" addresses seems to be the goal in that case.

In that sense, I'd say that the security/privacy properties are closely
tied to *both* the prefix length *and* the mechanism employed to
configure the address. -- for instance, a DHCPv6 server that leases
addresses from a small pool or with a specific pattern still results in
the same properties, even if the subnet is a /64.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Wed, 7 Jun 2017 15:07:06 +0300

> I would expect that any address configured manually would also be advertised in DNS, the latter being the reason for the former. If the address is publicly announced, does one have a reasonable exp…

Not for rivacy, I'd say. However, posting addresses in the DNS is not
necessarily an excuse for making the predictable.

If a company posts addresses on the DNS, but the addressses are not
predictable (they do not follow patterns), in the even that I want to
target "all of such organization's servers" IPv6 address scans is not an
option., so I'd have to resort to DNS bruteforcing, reverse-mapings dns
lookups, or some alternative technique.

OTOH, if the ORG employs predictable/patter addresses, then I can simply
resort to address scans.

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Jun 2017 12:13:49 +1000

In message <[email-masked]>, [email-masked] writ
> change this. I have no problems with others using a unique source

And it really don't add much in terms of privacy as the /64 would
be the same.  Nor is it needed to combat spoofing of responses.  We
have DNS COOKIES for that.  We are looking at removing port
randomisation when talking with servers that support DNS COOKIES.
Send a query with a cookie then if we don't get a cookie response
resend using a random port.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 08 Jun 2017 11:27:04 +0100

Mark Smith wrote:
> the attacker can't find it via unsolicited inbound probing.

this is a non argument and obscure addresses are of no value to network
operators:

1. most routers will answer traceroute probes, so it's trivial to find
out the address of a bgp-enabled router.

2. if you are serious about protecting infrastructure, you install
infrastructure ACLs which actually fix the problem.

Nick

---

From: Mark Smith <[email-masked]>
Date: Thu, 8 Jun 2017 21:16:37 +1000

> this is a non argument and obscure addresses are of no value to network

Next you'll say that stripes have no value to zebras and camouflage
has no value to armies.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 08 Jun 2017 13:31:17 +0200

>Next you'll say that stripes have no value to zebras and camouflage

I find this a bizar discussion. We already have plenty of options for providing
nodes with addresses that have lots of randomness.

Some operators don't care about that feature and would like to be able to use
those bits elsewhere.

So if you want to make it hard to discover a node, assign a /64 to a link and
use put a random value in the remaining bits.

That should not proclude other people from using /120 prefixes and numbering 
nodes 1, 2, 3.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Jun 2017 20:41:49 +0900

> remember" addresses seems to be the goal in that case.

I don't think you have measurements that prove this. You almost certainly
can make a statement that there are a number of low-entropy addresses where
the top bytes are all zeros, and that those are *likely* statically
configured. I don't think you can prove that the high-entropy addresses
with lots of nonzero bits are NOT manually configured.

As for "last byte" - using the last 32 bits of the address to store the
IPv4 address seems pretty common too. Akamai has published data about this,
I believe.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 8 Jun 2017 17:30:57 +0100

Lorenzo Colitti <[email-masked]> wrote:

> As for "last byte" - using the last 32 bits of the address to store the IPv4 address seems pretty common too. Akamai has published data about this, I believe.

That's an understandable approach to take - in a transitional environment (ie almost all of them these days) it's going to make it easier to remember and type addresses.
On that, it's not unreasonable to assume that a lot of operators might be deliberately using "lots of zeroes" simply to make it easier for humans to work with stuff. Eg, it's a lot less typing to type (say) 2001:470:7f09:cbb::57 than 2001:470:7f09:cbb:756e:20d6:e7f6:a544 ! In environments where the DNS just isn't done right, which in my experience is the vast majority of small/medium business networks*, this is even more important.

* Yes, this irritates me, but I've met few network admins below "big corporate" level who seem to care about DNS. It generally seems to come down to "the Windows AD controller does all that's needed" in making servers accessible to clients.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 8 Jun 2017 20:17:27 +0300

On 06/08/2017 02:41 PM, Lorenzo Colitti wrote:
> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I don't think you have measurements that prove this. You almost
> certainly can make a statement that there are a number of low-entropy
> addresses where the top bytes are all zeros, and that those are *likely*
> statically configured.

Are you assuming that such low-byte addresses are the result of
automatic configuration? How come?

> I don't think you can prove that the high-entropy
> addresses with lots of nonzero bits are NOT manually configured.

That's the point: there are not a lot of high-entropy addresses. See the
measurements in RFC7707.

> IPv4 address seems pretty common too. Akamai has published data about
> this, I believe.

we have similar measurements in RFC7707. However, using the low-order 32
bits in such way is equivalent to simply setting the low byte of the
addresses.

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.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 9 Jun 2017 09:20:01 +0900

> automatic configuration? How come?

No, what I'm saying is: I don't think you can prove that high-entropy
addresses are *not* the result of manual configuration or DHCPv6 address
assignment.

> measurements in RFC7707.

Oh, I see. You're talking about publicly-accessible servers, not clients.

> bits in such way is equivalent to simply setting the low byte of the

Equivalent in what way? It provides 4 times more nonzero bits, does it not?

> because folks simply do not use them for additional entropy.

But they could. If the server had a /64 prefix, then it could store useful
information in the 64 bits. For example, SNI (which sends information in
the clear) might not be necessary any more.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 03:35:52 +0300

On 06/09/2017 03:20 AM, Lorenzo Colitti wrote:
> On Fri, Jun 9, 2017 at 2:17 AM, Fernando Gont <[email-masked]

Look at the percentage of addresses with high entropy in the
measurements in RFC7707: they are marginal.

> Oh, I see. You're talking about publicly-accessible servers, not clients. 

Exactly. I doubt clients do manual configuration.

> Equivalent in what way? It provides 4 times more nonzero bits, does it not?

Equivalent in terms of entropy. If you do low-byte addresses, th entropy
is 8-16 bits. If you embed IPv4 addresses in the IID, and the IPv4
prefix is known or guessable, you get roughly the same number of bits of
entropy. In both cases, you'd have got the same entropy if you ha been
using a /120 prefix or the like.

> But they could. If the server had a /64 prefix, then it could store
> useful information in the 64 bits. For example, SNI (which sends
> information in the clear) might not be necessary any more.

We're talking about entropy here. If you want entropy, randomize your
IPv6 address (RFC7217), rather than set it manually.

---

From: Mark Smith <[email-masked]>
Date: Fri, 9 Jun 2017 12:46:44 +1000

<snip>
> 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.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 8 Jun 2017 20:03:30 -0700

> 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? 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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 9 Jun 2017 12:04:32 +0900

> IPv6 address (RFC7217), rather than set it manually.

Well, but the entropy that we care about is not the entropy of the IP
address, but the entropy of the network communications. Those can be
achieved by using many IP addresses in parallel.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 07:13:36 +0300

> That should not proclude other people from using /120 prefixes and numbering 

+1

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 9 Jun 2017 08:17:34 +0200

Le 09/06/2017 à 05:03, Tom Herbert a écrit :
>>>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont 
>>>> <[email-masked] <mailto:[email-masked]>> 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.
>>> 
>> 
>> 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.
>> 
>> 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,
> 
> 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
>> Regards, Mark.
>> [email-masked] Administrative Requests: 
>> https://www.ietf.org/mailman/listinfo/ipv6 
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Mark Smith <[email-masked]>
Date: Fri, 9 Jun 2017 18:18:00 +1000

Hi Tom,

On 9 Jun. 2017 13:03, "Tom Herbert" <[email-masked]> wrote:

<snip>

Mark,

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

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

---

From: Simon Hobson <[email-masked]>
Date: Fri, 9 Jun 2017 10:33:50 +0100

Lorenzo Colitti <[email-masked]> wrote:

> But they could. If the server had a /64 prefix, then it could store useful information in the 64 bits. For example, SNI (which sends information in the clear) might not be necessary any more.

I don't think that's much of a security feature !

Whether you use SNI or distinct addresses, it's clear what site the packets are going to. If anything, it's easier with distinct addresses as you only need to see the destination address field rather than inspect the contents of the packet to get the SNI element. The sort of people who are going to be looking into packets to get the SNI will have no trouble building a table of addresses-sites to map destination addresses to site just using destination address.

> device and can be vigilant when taking other measures to raise it

Firstly, I think you are over-estimating the skills of the "typical" network admin. In my experience, only a small minority would realise the tradeoffs and take any sensible measures - hence the figures given for the number of known Cisco devices with the front doors open. It was interesting when I pointed NetDisco at the campus network I used to admin and saw how many of the customers' routers it was able to interrogate just by following CDP neighbour information from my Cisco switches (which were locked down with non-standard SNMP community strings). These were mostly engineering firms in an industry where you'd expect security to be "somewhat better" !

But then we come to the other aspects. One of my pet peeves is people who disable pings (and/or traceroute) "for security" - and thus making network troubleshooting far more of a problem than it should be.

But if you are going to use well randomised addresses for network devices - you will have to put them in DNS if you want to be able to access them in a convenient manner. Once you put them in DNS, then you've lost half the benefit of random addresses anyway. Well you could randomise the DNS names - but then you shift the problem to knowing the DNS name !

---

From: Tom Herbert <[email-masked]>
Date: Fri, 9 Jun 2017 08:30:03 -0700

On Fri, Jun 9, 2017 at 1:18 AM, Mark Smith <[email-masked]> wrote:
> 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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 20:32:57 +0300

On 06/09/2017 05:46 AM, Mark Smith wrote:
[...]
> benefiting from large entropy in 64 bit IIDs.

Then dont do manual configuration. :-)

[...]
> isn't possible to send a packet to it.

THing here is: if you want resistence to address scanning, go for
SLAAC/RFC7217.

If you're setting addresses manually, then you probably know what you're
doing.

That's why I think that suggesting /64 for slaac (particularly for
backwards compatibility) is fine. But not for anything else.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Jun 2017 20:34:33 +0300

> achieved by using many IP addresses in parallel.

Huh?

We're talking about entropy of addresses. If you're going to use 64 bits
and randomize addresses in such space, fine.

If you're going to use 64 bits just to use the low-order 16-bits, then
you've wasted a lot of bits.

Thanks,