[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANP3RGfxOn=8JYJNUiPOH884PpONbWnOLm5pKA-zr29D1vEM7g@mail.gmail.com>
Date: Thu, 31 Aug 2023 10:51:25 -0700
From: Maciej Żenczykowski <maze@...gle.com>
To: Patrick Rohr <prohr@...gle.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Linux Network Development Mailing List <netdev@...r.kernel.org>, Lorenzo Colitti <lorenzo@...gle.com>,
Jen Linkova <furry@...gle.com>
Subject: Re: [PATCH net-next] net: add sysctl to disable rfc4862 5.5.3e
lifetime handling
On Thu, Aug 31, 2023 at 10:35 AM Maciej Żenczykowski <maze@...gle.com> wrote:
>
> On Thu, Aug 31, 2023 at 10:23 AM Patrick Rohr <prohr@...gle.com> wrote:
> >
> > This change adds a sysctl to opt-out of RFC4862 section 5.5.3e's valid
> > lifetime derivation mechanism.
> >
> > RFC4862 section 5.5.3e prescribes that the valid lifetime in a Router
> > Advertisement PIO shall be ignored if it less than 2 hours and to reset
> > the lifetime of the corresponding address to 2 hours. An in-progress
> > 6man draft (see draft-ietf-6man-slaac-renum-07 section 4.2) is currently
> > looking to remove this mechanism. While this draft has not been moving
> > particularly quickly for other reasons, there is widespread consensus on
> > section 4.2 which updates RFC4862 section 5.5.3e.
> >
> > Cc: Maciej Żenczykowski <maze@...gle.com>
> > Cc: Lorenzo Colitti <lorenzo@...gle.com>
> > Cc: Jen Linkova <furry@...gle.com>
> > Signed-off-by: Patrick Rohr <prohr@...gle.com>
> > ---
> > Documentation/networking/ip-sysctl.rst | 11 ++++++++
> > include/linux/ipv6.h | 1 +
> > net/ipv6/addrconf.c | 38 +++++++++++++++++---------
> > 3 files changed, 37 insertions(+), 13 deletions(-)
> >
> > diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
> > index a66054d0763a..7f21877e3f78 100644
> > --- a/Documentation/networking/ip-sysctl.rst
> > +++ b/Documentation/networking/ip-sysctl.rst
> > @@ -2304,6 +2304,17 @@ accept_ra_pinfo - BOOLEAN
> > - enabled if accept_ra is enabled.
> > - disabled if accept_ra is disabled.
> >
> > +ra_pinfo_rfc4862_5_5_3e - BOOLEAN
> > + Use RFC4862 Section 5.5.3e to determine the valid lifetime of
> > + an address matching a prefix sent in a Router Advertisement
> > + Prefix Information Option.
> > +
> > + - If enabled, RFC4862 section 5.5.3e is used to determine
> > + the valid lifetime of the address.
> > + - If disabled, the PIO valid lifetime will always be honored.
> > +
> > + Default: 1
> > +
> > accept_ra_rt_info_min_plen - INTEGER
> > Minimum prefix length of Route Information in RA.
> >
> > diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> > index 5883551b1ee8..f90cf8835ed4 100644
> > --- a/include/linux/ipv6.h
> > +++ b/include/linux/ipv6.h
> > @@ -35,6 +35,7 @@ struct ipv6_devconf {
> > __s32 accept_ra_min_hop_limit;
> > __s32 accept_ra_min_lft;
> > __s32 accept_ra_pinfo;
> > + __s32 ra_pinfo_rfc4862_5_5_3e;
> > __s32 ignore_routes_with_linkdown;
> > #ifdef CONFIG_IPV6_ROUTER_PREF
> > __s32 accept_ra_rtr_pref;
> > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> > index 47d1dd8501b7..1ac23a37e8eb 100644
> > --- a/net/ipv6/addrconf.c
> > +++ b/net/ipv6/addrconf.c
> > @@ -204,6 +204,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
> > .accept_ra_min_hop_limit= 1,
> > .accept_ra_min_lft = 0,
> > .accept_ra_pinfo = 1,
> > + .ra_pinfo_rfc4862_5_5_3e = 1,
> > #ifdef CONFIG_IPV6_ROUTER_PREF
> > .accept_ra_rtr_pref = 1,
> > .rtr_probe_interval = 60 * HZ,
> > @@ -265,6 +266,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
> > .accept_ra_min_hop_limit= 1,
> > .accept_ra_min_lft = 0,
> > .accept_ra_pinfo = 1,
> > + .ra_pinfo_rfc4862_5_5_3e = 1,
> > #ifdef CONFIG_IPV6_ROUTER_PREF
> > .accept_ra_rtr_pref = 1,
> > .rtr_probe_interval = 60 * HZ,
> > @@ -2657,22 +2659,23 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,
> > stored_lft = ifp->valid_lft - (now - ifp->tstamp) / HZ;
> > else
> > stored_lft = 0;
> > - if (!create && stored_lft) {
> > +
> > + /* RFC4862 Section 5.5.3e:
> > + * "Note that the preferred lifetime of the
> > + * corresponding address is always reset to
> > + * the Preferred Lifetime in the received
> > + * Prefix Information option, regardless of
> > + * whether the valid lifetime is also reset or
> > + * ignored."
> > + *
> > + * So we should always update prefered_lft here.
> > + */
> > + update_lft = !create && stored_lft;
> > +
> > + if (update_lft && in6_dev->cnf.ra_pinfo_rfc4862_5_5_3e) {
> > const u32 minimum_lft = min_t(u32,
> > stored_lft, MIN_VALID_LIFETIME);
> > valid_lft = max(valid_lft, minimum_lft);
> > -
> > - /* RFC4862 Section 5.5.3e:
> > - * "Note that the preferred lifetime of the
> > - * corresponding address is always reset to
> > - * the Preferred Lifetime in the received
> > - * Prefix Information option, regardless of
> > - * whether the valid lifetime is also reset or
> > - * ignored."
> > - *
> > - * So we should always update prefered_lft here.
> > - */
> > - update_lft = 1;
> > }
> >
> > if (update_lft) {
> > @@ -6846,6 +6849,15 @@ static const struct ctl_table addrconf_sysctl[] = {
> > .mode = 0644,
> > .proc_handler = proc_dointvec,
> > },
> > + {
> > + .procname = "ra_pinfo_rfc4862_5_5_3e",
> > + .data = &ipv6_devconf.ra_pinfo_rfc4862_5_5_3e,
> > + .maxlen = sizeof(int),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec_minmax,
> > + .extra1 = SYSCTL_ZERO,
> > + .extra2 = SYSCTL_ONE,
> > + },
> > #ifdef CONFIG_IPV6_ROUTER_PREF
> > {
> > .procname = "accept_ra_rtr_pref",
> > --
> > 2.42.0.283.g2d96d420d3-goog
>
> Reviewed-by: Maciej Żenczykowski <maze@...gle.com>
>
> Obviously 'ra_pinfo_rfc4862_5_5_3e' isn't a particularly pretty name...
> But we couldn't come up with anything that was better.
> In particular it shouldn't start with 'accept_ra_' since it's not
> relevant to actually accepting it.
> Similarly it shouldn't end in _lft since it's a boolean and not a
> length of time...
>
> As for why we want to be able to disable it:
> The existing 2hours is extremely arbitrary.
> It was added to prevent security attacks from rogue RAs expiring things.
> However, any network without RA guard (which would prevent this attack)
> is already susceptible to so many other possible RA attacks, that it
> just doesn't matter.
> What it does do however, is prevent expiring client devices ip/route information
> when the upstream configuration of a router changes (cable modem
> reconnects, etc).
>
> Unfortunately the old behaviour has to stay the default, to pass some
> certification tests...
> (until the RFC actually gets updated)
btw. net-next is currently closed (and this isn't a fix)
https://patchwork.hopto.org/net-next.html
You'll most likely be asked to resend in ~1.5 weeks.
Powered by blists - more mailing lists