RE: rfc4941bis: On the use of multiple addresses

["Pascal Thubert (pthubert)" <[e-mail]>]

My words below can be misinterpreted, and I apologize. I’m sure that SAVI went through due review process.

I’m just disappointed that the Security Considerations do not mention the need for the SAVI node to protect itself against DoS attacks, which is what SEC_DIR asked us to do with RFC 8505, and what we did when implementing it.

Quoting RFC 8505

The registration mechanism may be used by a rogue node to attack the
   6LR or 6LBR with a denial-of-service attack against the registry.  It
   may also happen that the registry of a 6LR or 6LBR is saturated and
   cannot take any more registrations; this scenario effectively denies
   the requesting node the capability to use a new address.  In order to
   alleviate those concerns, (1) Section 5.2<https://tools.ietf.org/html/rfc8505#section-5.2> provides a sequence counter
   that keeps incrementing to detect and clean up stale registration
   information and that contributes to defeat replay attacks and
   (2) Section 5.7<https://tools.ietf.org/html/rfc8505#section-5.7> provides a number of recommendations that ensure that
   a stale registration is removed as soon as possible from the 6LR
   and 6LBR.


Sorry for that,

Pascal


From: ipv6 <[e-mail]> On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 31 janvier 2020 07:06
To: Lorenzo Colitti <lorenzo=[e-mail]>
Cc: Fernando Gont <[e-mail]>; [e-mail]
Subject: Re: rfc4941bis: On the use of multiple addresses

This is playing ostrich again.

 Limiting the amount of addresses is an obvious implication of SAVI in a managed network. When we did RFC 8505 the Sec-Dir review insisted to have text  to protect against DOS attacks. The SAVI draft did not go through that full cycle and is not complete to that regard. So I think the original text was a lot better.

And the size of the cache is mostly irrelevant to the ND churn these days. When addresses are dropping for the lack of rmemory there’s really an issue.  What’s relevant is the amount of new addresses joining the network, the number of nodes in the network that need to resolve it, and what nodes do when they sleep cycle or roam.

We measured (on the wire) several hundred multicast per second in average over 90 minutes during a keynote with a large audience. /64 per host is indeed tempting in such environment. But it boils down to IPv4 with 8 bytes addresses. We can do better.

Regards,

Pascal


Le 31 janv. 2020 à 01:18, Lorenzo Colitti <lorenzo=[e-mail]<mailto:lorenzo=[e-mail]>> a écrit :

I don't think the two RFC citations are appropriate. RFC 6583 is about the size of subnets, not about the number of hosts per subnet. RFC 7039 is about the SAVI framework, and I don't think there's anything in there about limiting the number of bindings. I also can't find anything in that document that talks about "enforcing port security that may enforce a limit on the maximum number of configured addresses per host". SAVI is a security mechanism to prevent spoofing, not a mechanism to limit the number of addresses.

draft-ietf-mboned-ieee802-mcast-problems is relevant in the sense that more addresses on the link create more neighbour discovery traffic. So how about rewording to the following?

=====
Network deployments are currently recommended to provide multiple IPv6 addresses from each prefix to general-purpose hosts. In some scenarios, use of a large number of IPv6 addresses may have negative implications on network devices that permanently maintain forwarding entries for all neighbour caches (e.g., [RFC7039]). Additionally, concurrent active use of multiple IPv6 addresses will increase neighbour discovery traffic if neighbour caches in network devices are not large enough to store all addresses on the link. This can impact performance and energy efficiency on networks on which multicast is expensive (e.g. [draft-ietf-mboned-ieee802-mcast-problems]).
=====

On Fri, Jan 31, 2020 at 7:54 AM Fernando Gont <[e-mail]<mailto:[e-mail]>> wrote:
Folks,

Based on the recent discussion regarding the possible impact of the use
of multiple addresses, I suggest we include the following text in
Section 4 of rfc4941bis:

"Network deployments are currently recommended to provide multiple IPv6
addresses from each prefix to general-purpose hosts. However, in some
scenarios, use of a large number of IPv6 addresses may have negative
implications on some network devices (e.g. [RFC6583]), exacerbate other
operational problems (e.g. [draft-ietf-mboned-ieee802-mcast-problems])
and/or may lead to traffic employing these addresses being dropped by
devices that enforcing port security that may enforce a limit on the
maximum number of configured addresses per host (e.g. [RFC7039]). A
discussion on possible approaches to allow for unconstrained use of IPv6
addresses can be found in [RFC7934]"

Thoughts?

Thanks!

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




--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------