| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <19147ac34b9.11eb4e51f218946.9156409800195270177@shytyi.net>
Date: Mon, 12 Aug 2024 19:39:13 +0200
From: Dmytro Shytyi <dmytro@...tyi.net>
To: ""Maciej Żenczykowski"" <maze@...gle.com>
Cc: "ek" <ek@...n.com>, "ekietf" <ek.ietf@...il.com>,
"Jakub Kicinski" <kuba@...nel.org>,
"yoshfuji" <yoshfuji@...ux-ipv6.org>,
"liuhangbin" <liuhangbin@...il.com>, "davem" <davem@...emloft.net>,
"netdev" <netdev@...r.kernel.org>, "David Ahern" <dsahern@...il.com>,
"Joel Scherpelz" <jscherpelz@...gle.com>
Subject: Re: [PATCH net-next V9] net: Variable SLAAC: SLAAC with prefixes of
arbitrary length in PIO
Dear Maciej, Erik,
Thank you for your response and for highlighting that this topic
has been discussed multiple times within IETF and other forums.
I understand that "race to the bottom" is a term that has been
used in various discussions, but I’ve noticed that a concrete
definition of "fundamental problem" (in ML, mail of EK, 2021-10-14 18:26:30)
"race to the bottom", particularly in the
context [2], has been somewhat elusive.
The fundamental problem "race to the bottom" was
brought up as a issue in the current topic,
therefore, could Erik or you provide a more detailed explanation
or point me to specific documents or discussions where this
fundamental problem "race to the bottom" has been _clearly
defined_ and _well contextualized_ regarding these two questions?
[1]. Would you be kind to send us the explanation of
"race to the bottom problem" in IP context with examples.
[2]. Would you be kind to explain how the possibility of configuration of
prefix lengths longer that 64, enables
fundamental problem "race to the bottom"?
Understanding this more concretely would
be very helpful as we continue to address the issues.
Thank you for your guidance and support.
Best regards,
Dmytro Shytyi et al.
---- On Mon, 12 Aug 2024 18:34:56 +0200 Maciej Żenczykowski wrote ---
> On Sun, Aug 11, 2024 at 10:16 AM Dmytro Shytyi dmytro@...tyi.net> wrote:
> >
> > Hello Erik Kline,
> >
> > You stated that, VSLAAC should not be accepted in large part because
> > it enables a race to the bottom problem for which there is no solution
> > in sight.
> >
> > We would like to hear more on this subject:
> > 1. Would you be kind to send us the explanation of
> > "race to the bottom problem" in IP context with examples.
> >
> > 2. Would you be kind to explain howt he possibility of configuration of
> > prefix lengths longer that 64, enables "race to the bottom problem"?
>
> This has been discussed multiple times in IETF (and not only), I don't
> think this is the right spot for this sort of discussion.
>
> >
> > We look forward for your reply.
>
> NAK: Maciej Żenczykowski maze@...gle.com>
> >
> > Best regards,
> > Dmytro SHYTYI, et Al.
> >
> > >
> > >
> > >
> > > ---- On Mon, 12 Jul 2021 19:51:19 +0200 Erik Kline ek@...gle.com> wrote ---
> > >
> > > VSLAAC is indeed quite contentious in the IETF, in large part because
> > > it enables a race to the bottom problem for which there is no solution
> > > in sight.
> > >
> > > I don't think this should be accepted. It's not in the same category
> > > of some other Y/N/M things where there are issues of kernel size,
> > > absence of some underlying physical support or not, etc.
> > >
> > >
> > > On Mon, Jul 12, 2021 at 9:42 AM Dmytro Shytyi dmytro@...tyi.net> wrote:
> > > >
> > > > Hello Jakub, Maciej, Yoshfuji and others,
> > > >
> > > > After discussion with co-authors about this particular point "Internet Draft/RFC" we think the following:
> > > > Indeed RFC status shows large agreement among IETF members. And that is the best indicator of a maturity level.
> > > > And that is the best to implement the feature in a stable mainline kernel.
> > > >
> > > > At this time VSLAAC is an individual proposal Internet Draft reflecting the opinion of all authors.
> > > > It is not adopted by any IETF working group. At the same time we consider submission to 3GPP.
> > > >
> > > > The features in the kernel have optionally "Y/N/M" and status "EXPERIMENTAL/STABLE".
> > > > One possibility could be VSLAAC as "N", "EXPERIMENTAL" on the linux-next branch.
> > > >
> > > > Could you consider this possibility more?
> > > >
> > > > If you doubt VSLAAC introducing non-64 bits IID lengths, then one might wonder whether linux supports IIDs of _arbitrary length_,
> > > > as specified in the RFC 7217 with maturity level "Standards Track"?
> > > >
> > > > Best regards,
> > > > Dmytro Shytyi et al.
> > > >
> > > > ---- On Mon, 12 Jul 2021 15:39:27 +0200 Dmytro Shytyi dmytro@...tyi.net> wrote ----
> > > >
> > > > > Hello Maciej,
> > > > >
> > > > >
> > > > > ---- On Sat, 19 Dec 2020 03:40:50 +0100 Maciej Żenczykowski maze@...gle.com> wrote ----
> > > > >
> > > > > > On Fri, Dec 18, 2020 at 6:03 PM Jakub Kicinski kuba@...nel.org> wrote:
> > > > > > >
> > > > > > > It'd be great if someone more familiar with our IPv6 code could take a
> > > > > > > look. Adding some folks to the CC.
> > > > > > >
> > > > > > > On Wed, 16 Dec 2020 23:01:29 +0100 Dmytro Shytyi wrote:
> > > > > > > > Variable SLAAC [Can be activated via sysctl]:
> > > > > > > > SLAAC with prefixes of arbitrary length in PIO (randomly
> > > > > > > > generated hostID or stable privacy + privacy extensions).
> > > > > > > > The main problem is that SLAAC RA or PD allocates a /64 by the Wireless
> > > > > > > > carrier 4G, 5G to a mobile hotspot, however segmentation of the /64 via
> > > > > > > > SLAAC is required so that downstream interfaces can be further subnetted.
> > > > > > > > Example: uCPE device (4G + WI-FI enabled) receives /64 via Wireless, and
> > > > > > > > assigns /72 to VNF-Firewall, /72 to WIFI, /72 to Load-Balancer
> > > > > > > > and /72 to wired connected devices.
> > > > > > > > IETF document that defines problem statement:
> > > > > > > > draft-mishra-v6ops-variable-slaac-problem-stmt
> > > > > > > > IETF document that specifies variable slaac:
> > > > > > > > draft-mishra-6man-variable-slaac
> > > > > > > >
> > > > > > > > Signed-off-by: Dmytro Shytyi dmytro@...tyi.net>
> > > > > > >
> > > > >
> > > > > > IMHO acceptance of this should *definitely* wait for the RFC to be
> > > > > > accepted/published/standardized (whatever is the right term).
> > > > >
> > > > > [Dmytro]:
> > > > > There is an implementation of Variable SLAAC in the OpenBSD Operating System.
> > > > >
> > > > > > I'm not at all convinced that will happen - this still seems like a
> > > > > > very fresh *draft* of an rfc,
> > > > > > and I'm *sure* it will be argued about.
> > > > >
> > > > > [Dmytro]
> > > > > By default, VSLAAC is disabled, so there are _*no*_ impact on network behavior by default.
> > > > >
> > > > > > This sort of functionality will not be particularly useful without
> > > > > > widespread industry
> > > > >
> > > > > [Dmytro]:
> > > > > There are use-cases that can profit from radvd-like software and VSLAAC directly.
> > > > >
> > > > > > adoption across *all* major operating systems (Windows, Mac/iOS,
> > > > > > Linux/Android, FreeBSD, etc.)
> > > > >
> > > > > [Dmytro]:
> > > > > It should be considered to provide users an _*opportunity*_ to get the required feature.
> > > > > Solution (as an option) present in linux is better, than _no solution_ in linux.
> > > > >
> > > > > > An implementation that is incompatible with the published RFC will
> > > > > > hurt us more then help us.
> > > > >
> > > > > [Dmytro]:
> > > > > Compatible implementation follows the recent version of document: https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ The sysctl usage described in the document is used in the implementation to activate/deactivate VSLAAC. By default it is disabled, so there is _*no*_ impact on network behavior by default.
> > > > >
> > > > > > Maciej Żenczykowski, Kernel Networking Developer @ Google
> > > > > >
> > > > >
> > > > > Take care,
> > > > > Dmytro.
> > > > >
> > > >
> > >
> > >
> > >
> >
>
> --
> Maciej Żenczykowski, Kernel Networking Developer @ Google
>
Powered by blists - more mailing lists