Page MenuHomeFreeBSD

ip6: implement RFC 8981-advised temporary IID generation
Needs ReviewPublic

Authored by zarychtam_plan-b.pwste.edu.pl on Thu, May 1, 5:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, May 20, 1:33 AM
Unknown Object (File)
Fri, May 16, 9:39 PM
Unknown Object (File)
Tue, May 13, 2:37 PM
Unknown Object (File)
Sun, May 11, 2:03 PM
Unknown Object (File)
Fri, May 9, 11:07 AM
Unknown Object (File)
Tue, May 6, 3:53 AM
Unknown Object (File)
Tue, May 6, 3:07 AM
Unknown Object (File)
Mon, May 5, 1:51 PM
Subscribers
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

We've had a patch[1] from one of the authors of RFC 8981 for some time now that:

  • reduces the valid lifetime from 1 week to 2 days,
  • limits the number of concurrent temporary addresses per prefix to 2,
  • deprecates the use of MD5 as the algorithm for computing the temporary IIDs,
  • introduces using different interface-ids for each temporary address,
  • respects the list of Reserved IPv6 Interface Identifiers.

I've been testing this solution on my desktop and laptop in CURRENT and STABLE for almost two years now, and so fa,r there have been no issues with this patch. I haven't done any tests where multiple FIBs and VNETs are involved, so the patch probably needs more attention in this regard.

This patch is not mine, but Fernando is not interested in putting it on the Phabricator. At the beginning, he tried to attract the attention of some of our devs and sent a few posts to mailing lists, but it was 5 years ago, and those people were busy. Since we don't have anything better at the moment, it's worth putting it up for discussion.

PR: 245103
Submitted by: Fernando Gont

  1. https://lists.freebsd.org/pipermail/freebsd-net/2020-April/055689.html

Update:

I later came up with a patch to adjust MAX_DESYNC_FACTOR upon net.inet6.ip6.temppltime modification. It's likely the indispensable part of the change, so now it's squashed with Fernando's original patch. The currently proposed patch brings the following changes:

  1. Deprecates the use of MD5 as the algorithm for generating temporary interface identifiers (IIDs) for IPv6 addresses, improving cryptographic robustness.
  2. Introduces per-address randomized IIDs, ensuring that each temporary address uses a distinct interface identifier to enhance privacy and avoid correlation across addresses.
  3. Updates the IID generation logic to respect the Reserved IPv6 Interface Identifiers list.
  4. Enhances sysctl_ip6_temppltime() so that ip6_temp_max_desync_factor is dynamically recalculated whenever ip6_temp_preferred_lifetime is updated via sysctl. This ensures that MAX_DESYNC_FACTOR remains approximately 3/8 of the preferred lifetime plus 5 minutes. DESYNC_FACTOR is also regenerated after each update.
  5. Timers related to temporary address regeneration were updated to match the design recommendations in RFC 8981.
  6. A new read-only sysctl variable net.inet6.ip6.temp_max_desync_factor is introduced to expose the computed value of MAX_DESYNC_FACTOR to userland for observability and debugging.
  7. Input validation to reject temppltime values too small or too large is included.

PR: 245103
Submitted by: Fernando Gont

Following the discussion on IRC comparing D50343 and D49459, I mistakenly removed the reviewers and subscribers from this review, which I now regret. That said, assigning too many reviewers initially was also not ideal.

Please feel free to test and review this code as you see fit, whether you like it or not.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

zarychtam_plan-b.pwste.edu.pl retitled this revision from Implement RFC 8981 (IPv6 SLAAC Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6; Submitted by: Fernando Gont 5 years ago) to ip6: implement RFC 8981-advised temporary IID generation.

I later came up with a patch to adjust MAX_DESYNC_FACTOR upon net.inet6.ip6.temppltime modification. It's likely the indispensable part of the change, so now it's squashed with Fernando's original patch.

The currently proposed patch brings the following changes:

Deprecate the use of MD5 as the algorithm for generating temporary
interface identifiers (IIDs) for IPv6 addresses, improving cryptographic
robustness.

Introduce per-address randomized IIDs, ensuring that each temporary
address uses a distinct interface identifier to enhance privacy and
avoid correlation across addresses.

Update the IID generation logic to respect the Reserved IPv6 Interface
Identifiers list.

Enhance sysctl_ip6_temppltime() so that ip6_temp_max_desync_factor is
dynamically recalculated whenever ip6_temp_preferred_lifetime is updated
via sysctl. This ensures that MAX_DESYNC_FACTOR remains approximately
1/32 of the preferred lifetime plus 10 minutes. DESYNC_FACTOR is also
regenerated after each update.

Timers related to temporary address regeneration were updated to match
the design recommendations in RFC 8981.

A new read-only sysctl variable net.inet6.ip6.temp_max_desync_factor
is introduced to expose the computed value of MAX_DESYNC_FACTOR to
userland for observability and debugging.

Input validation to reject temppltime values too small or too large is
included.

This all brings the temporary address lifetime handling closer to the
intended design in RFC 8981 and improves robustness against
misconfiguration.

PR: 245103
Co-authored-by: Fernando Gont

zarychtam_plan-b.pwste.edu.pl edited the summary of this revision. (Show Details)

The timers were updated to align with those proposed in RFC 8981 more closely. The MAX_TEMP_DESYNC_FACTOR_LIMIT constant was renamed to MAX_TEMP_DESYNC_FACTOR_BASE to better reflect its purpose.

des added inline comments.
sys/netinet6/nd6_rtr.c
97

temp max or max temp? pick one or the other, unless there is a reason to use two different terms for the same concept?

sys/netinet6/nd6_rtr.c
97

Thank you for the feedback. This inconsistency and apparent contradiction arise from the clash of two naming conventions - one for constants and one for variables. The constant MAX_TEMP_DESYNC_FACTOR_BASE is an evolved form of the older MAX_TEMP_DESYNC_FACTOR and follows the naming convention for constants found in sys/netinet6/nd6.h. This constant is intended to be just a component of the variable V_ip6_temp_max_desync_factor, which itself aligns with the naming used for the MAX_DESYNC_FACTOR described in RFC 8981.

The RFC does not explicitly require the introduction of such an element as MAX_DESYNC_FACTOR_BASE, but adding it improves network stability and prevents the generation of temporary addresses with a net.inet6.ip6.temppltime of a few seconds - something that, at scale, could destabilise networks and unnecessarily stress network devices.

MAX_TEMP_DESYNC_FACTOR_BASE could be completely eliminated by limiting the ability to influence net.inet6.ip6.temppltime to a reasonable minimum. With the current settings, this comes out to approximately 8 minutes. However, the proposed method not only provides a safety margin, but also increases the random desynchronization time window for short net.inet6.ip6.temppltime values, which can be a desirable effect.

If I had to choose, renaming MAX_TEMP_DESYNC_FACTOR_BASE to TEMP_MAX_DESYNC_FACTOR_BASE seems acceptable. If this change is preferred, I’ll update the patch accordingly.