As a side note, the following text was changed during the IESG review to
explore the consequences of not releasing addresses that are not used anymore..
This text is in section "Maintaining the Registration States" and is currently
proposed as followed
A node that ceases to use an address SHOULD attempt to de-register
that
address from all the 6LRs to which it has registered the address. This
is achieved using an NS(EARO) message with a Registration Lifetime of 0..
If this is not done, the associated state will remain in the network till
the
current Registration Lifetime expires and this may lead to a situation where
the 6LR resources become saturated, even if they are correctly planned to
start with. The 6LR may then take defensive measures that may prevent this
node or some other nodes from owning as many addresses as they would expect
(see <Security Considerations section>).
Also node that the security section also as this
The Registration lifetimes SHOULD be individually configurable for
each address or group of addresses. The nodes SHOULD be configured
with a Registration Lifetime that reflects their expectation of how
long they will use the address with the 6LR to which it is
registered. In particular, use cases that involve mobility or
rapid address changes SHOULD use lifetimes that are larger yet of
a same order as the duration of the expectation of presence.
This makes the last sentence of the next paragraph, which is echoed in the mail
below, redundant; it will be removed.
All in all and though not said explicitly for that particular case, a device
that forms a privacy address each time it comes out of sleep SHOULD clean up
the previously used address that this replaces.
That clean up may happen preferably when the device goes to sleep, and at worst
when the device comes out of sleep.
The penalty for not doing it is that the infrastructure will use its own
heuristics to clean up what it will determine as obsolete in a condition that
it determines as a potential attack.
You'll note that this is already happening in the real world in snooping
devices (e.g., for SAVI). With this specification we are actually trying to put
the control back in the hands of the device.
Does that work?
Pascal
From: 6lo <[email protected]> On Behalf Of Pascal Thubert (pthubert)
Sent: samedi 24 mars 2018 09:43
To: [email protected]; Dave Thaler <[email protected]>
Subject: [6lo] Dave's comment on the minimu number of addresses per node
Dear all:
At the 6lo meeting, Dave pointed that the limitation of number of address to
protect the 6LR / 6LBR was a 6lo local problem to be handled by us.
We discussed what an arch minimum number of addresses could be. Turned out that
it would range between 3 of a hard core 6LN to 10 for a more capable device.
I reworded the relevant paragraph in the Security Considerations as follows:
The router (6LR or 6LBR) SHOULD be configurable so as to limit the
number of addresses that can be registered by a single node, but as a
protective measure only. In any case, a router MUST be able to keep a
minimum number of addresses per node. That minimum depends on the type
of device and ranges between 3 for a very constrained LLN and 10 for a
larger device. A node may be identified by its MAC address, as long as
it is not obfuscated by privacy measures. A stronger identification
(e.g., by security credentials) is RECOMMENDED.
When the maximum is reached, the router should use a
Least-Recently-Used (LRU) algorithm to clean up the addresses,
keeping at least one Link-Local Address. The router
SHOULD attempt to keep one or more stable addresses if stability
can be determined, e.g., because they are used over a much longer time
span than other (privacy, shorter-lived) addresses. Address lifetimes
SHOULD be individually configurable.
Does that work?
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
