[prev in list] [next in list] [prev in thread] [next in thread]
List: nanog
Subject: Re: Windows 11 now implements RFC 7217 (stable privacy addresses)!
From: Douglas Fischer <fischerdouglas () gmail ! com>
Date: 2022-12-13 10:48:09
Message-ID: CAKEr4RTHRz4=QqSpYf7n_c1t+T39TfmqNtotdcRRf+GX9yMiaw () mail ! gmail ! com
[Download RAW message or body]
Good news!
Good perspectives for the future...
But this thread remembered-me about RFC 3021 and Windows... Since December
2000.
https://social.technet.microsoft.com/Forums/en-US/6da37a2d-6884-4c3c-bdd5-1b8356edfced \
/windows-102019-non-compliant-with-rfc-3021-ipv4-31-subnet-mask?forum=winserverPN
Em ter., 13 de dez. de 2022 03:45, Fernando Gont <fgont@si6networks.com>
escreveu:
> Folks,
>
> After over 10 (yes, *ten*) years, we have finally addressed
> security/privacy issues in the generation of IPv6 stable addresses in
> most popular operating systems.
>
> The traditional scheme/algorithm to generate stable IPv6 addresses with
> SLAAC required that the underlying MAC address be employed to generate
> the Interface Identifier. That is, the underlying MAC address would be
> embedded in the lower bits of an IPv6 address.
>
> This scheme allowed for host-tracking (since MAC addresses are usually
> globally-unique), address scanning (since addresses will follow specific
> patterns) and a number of other issues.
>
> In 2011, I submitted an IETF Internet-Draft proposing a scheme for
> generating stable addresses with SLAAC, meant to replace the traditional
> scheme. The scheme could be summarised and simplified as: Interface_ID =
> Hash(Prefix, Secret). Thus, interface identifiers would be stable within
> the same subnet, but vary across subnets.
>
> [Replacing the traditional scheme with this new scheme was anything but
> easy -- if you're curious, please check the "IPv6 Addressing" section in
> <
> https://www.si6networks.com/2020/08/06/a-brief-history-of-recent-advances-in-ipv6-security-part-i/>
>
> ]
>
> Over time, popular operating systems and packages adopted the proposed
> algorithm: the Linux kernel, NetworkManager, OpenBSD's slaacd, MacOS,
> etc. Eventually, virtually every popular OS had adopted the scheme....
> except Windows.
>
> Based on a recent note by Brian Carpenter, I ended up testing Windows
> 11, and I can confirm that it does implement RFC 7217 / RFC 8064!
>
> Therefore, e.g. if multiple prefixes are employed on a subnet, the
> stable addresses for each of such prefixes will employ a different
> Interface Identifier, thus avoiding the security/privacy issues
> discussed above -- this is really good news!
>
> Unfortunately, Windows still generates temporary addresses with the
> algorithm specified in RFC 4941, thus resulting in all temporary
> addresses for a given interface employing the same Interface Identifier
> (!). This problem has been addressed in RFC 8981... but it's
> implementation is not yet widespread, yet (it has been incoporated in
> e.g. the Linux kernel, though).
>
> I just hope it doesn't take Windows and others yet another 10+ years to
> implement RFC 8981, to finally address the remaining security/privacy
> issues in IPv6 address generation!
>
> [Original article with screenshots:
>
> https://www.linkedin.com/posts/fernandogont_after-over-10-yes-ten-years-we-have-activity-7008316664207290368-Wcto
> ]
>
> Thanks!
>
> Regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>
[Attachment #3 (text/html)]
<div dir="auto">Good news!<div dir="auto">Good perspectives for the \
future...</div><div dir="auto"><br></div><div dir="auto">But this thread \
remembered-me about RFC 3021 and Windows... Since December 2000.</div><div \
dir="auto"><br></div><div dir="auto"><a \
href="https://social.technet.microsoft.com/Forums/en-US/6da37a2d-6884-4c3c-bdd5-1b8356 \
edfced/windows-102019-non-compliant-with-rfc-3021-ipv4-31-subnet-mask?forum=winserverP \
N">https://social.technet.microsoft.com/Forums/en-US/6da37a2d-6884-4c3c-bdd5-1b8356edf \
ced/windows-102019-non-compliant-with-rfc-3021-ipv4-31-subnet-mask?forum=winserverPN</a></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 13 de dez. de 2022 \
03:45, Fernando Gont <<a \
href="mailto:fgont@si6networks.com">fgont@si6networks.com</a>> \
escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Folks,<br> <br>
After over 10 (yes, *ten*) years, we have finally addressed <br>
security/privacy issues in the generation of IPv6 stable addresses in <br>
most popular operating systems.<br>
<br>
The traditional scheme/algorithm to generate stable IPv6 addresses with <br>
SLAAC required that the underlying MAC address be employed to generate <br>
the Interface Identifier. That is, the underlying MAC address would be <br>
embedded in the lower bits of an IPv6 address.<br>
<br>
This scheme allowed for host-tracking (since MAC addresses are usually <br>
globally-unique), address scanning (since addresses will follow specific <br>
patterns) and a number of other issues.<br>
<br>
In 2011, I submitted an IETF Internet-Draft proposing a scheme for <br>
generating stable addresses with SLAAC, meant to replace the traditional <br>
scheme. The scheme could be summarised and simplified as: Interface_ID = <br>
Hash(Prefix, Secret). Thus, interface identifiers would be stable within <br>
the same subnet, but vary across subnets.<br>
<br>
[Replacing the traditional scheme with this new scheme was anything but <br>
easy -- if you're curious, please check the "IPv6 Addressing" section \
in <br> <<a href="https://www.si6networks.com/2020/08/06/a-brief-history-of-recent-advances-in-ipv6-security-part-i/" \
rel="noreferrer noreferrer" \
target="_blank">https://www.si6networks.com/2020/08/06/a-brief-history-of-recent-advances-in-ipv6-security-part-i/</a>> \
<br> ]<br>
<br>
Over time, popular operating systems and packages adopted the proposed <br>
algorithm: the Linux kernel, NetworkManager, OpenBSD's slaacd, MacOS, <br>
etc. Eventually, virtually every popular OS had adopted the scheme.... <br>
except Windows.<br>
<br>
Based on a recent note by Brian Carpenter, I ended up testing Windows <br>
11, and I can confirm that it does implement RFC 7217 / RFC 8064!<br>
<br>
Therefore, e.g. if multiple prefixes are employed on a subnet, the <br>
stable addresses for each of such prefixes will employ a different <br>
Interface Identifier, thus avoiding the security/privacy issues <br>
discussed above -- this is really good news!<br>
<br>
Unfortunately, Windows still generates temporary addresses with the <br>
algorithm specified in RFC 4941, thus resulting in all temporary <br>
addresses for a given interface employing the same Interface Identifier <br>
(!). This problem has been addressed in RFC 8981... but it's <br>
implementation is not yet widespread, yet (it has been incoporated in <br>
e.g. the Linux kernel, though).<br>
<br>
I just hope it doesn't take Windows and others yet another 10+ years to <br>
implement RFC 8981, to finally address the remaining security/privacy <br>
issues in IPv6 address generation!<br>
<br>
[Original article with screenshots: <br>
<a href="https://www.linkedin.com/posts/fernandogont_after-over-10-yes-ten-years-we-have-activity-7008316664207290368-Wcto" \
rel="noreferrer noreferrer" \
target="_blank">https://www.linkedin.com/posts/fernandogont_after-over-10-yes-ten-years-we-have-activity-7008316664207290368-Wcto</a> \
<br> ]<br>
<br>
Thanks!<br>
<br>
Regards,<br>
-- <br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href="mailto:fgont@si6networks.com" target="_blank" \
rel="noreferrer">fgont@si6networks.com</a><br> PGP Fingerprint: F242 FF0E A804 AF81 \
EB10 2F07 7CA1 321D 663B B494<br> </blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic