netdev - Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit of dev mtu

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220616153916.26bc2876@elisabeth>
Date:   Thu, 16 Jun 2022 15:39:16 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>,
        Maciej Żenczykowski <maze@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        David Ahern <dsahern@...nel.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Linux NetDev <netdev@...r.kernel.org>,
        "Kaustubh Pandey" <quic_kapandey@...cinc.com>,
        Sean Tranchetti <quic_stranche@...cinc.com>
Subject: Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit
 of dev mtu

[Subash, please fix quoting of replies in your client, it's stripping
email authors. I rebuilt the chain here but it's kind of painful]

On Wed, 15 Jun 2022 23:36:10 -0600
"Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com> wrote:

> On Wed, 15 Jun 2022 18:21:07 -0700
> Maciej Żenczykowski <maze@...gle.com> wrote:
> >
> > On Wed, Jun 15, 2022 at 5:35 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > >
> > > CC maze, please add him if there is v3
> > >
> > > I feel like the problem is with the fact that link mtu resets protocol
> > > MTUs. Nothing we can do about that, so why not set link MTU to 9k (or
> > > whatever other quantification of infinity there is)

2^16 - 1, works for both IPv4 and IPv6.

> > > so you don't have
> > > to touch it as you discover the MTU for v4 and v6?  
> 
> That's a good point.
> 
> > > My worry is that the tweaking of the route MTU update heuristic will
> > > have no end.
> > >
> > > Stefano, does that makes sense or you think the change is good?  

It makes sense -- I'm also worried that we're introducing another small
issue to fix what, I think, is the smallest possible inconvenience.

> The only concern is that current behavior causes the initial packets 
> after interface MTU increase to get dropped as part of PMTUD if the IPv6 
> PMTU itself didn't increase. I am not sure if that was the intended 
> behavior as part of the original change. Stefano, could you please confirm?

Correct, that was the intended behaviour, because I think one dropped
packet is the smallest possible price we can pay for, knowingly, not
having anymore a PMTU estimate that's accurate in terms of RFC 1191.

> > I vaguely recall that if you don't want device mtu changes to affect
> > ipv6 route mtu, then you should set 'mtu lock' on the routes.
> > (this meaning of 'lock' for v6 is different than for ipv4, where
> > 'lock' means transmit IPv4/TCP with Don't Frag bit unset)  

"Locked" exceptions are rather what's created as a result of ICMP and
ICMPv6 messages -- I guess you can have a look or run the basic
pmtu_ipv4() and pmtu_ipv6() to get a sense of it.

With the existing implementation, if you increase the link MTU to a
value that's bigger than the locked value from PMTU discovery, it will
not increase in general: the exception is locking it. That's what's
described in the comment that this patch is removing.

It will increase only under that specific condition, namely, if the
current PMTU estimate is the same as the old link MTU, because then we
can take the reasonable assumption that our link was the limiting
factor, and not some other link on the path. It might be wrong, but I
still maintain it's a reasonable assumption, and, most importantly, we
have no way to prove it wrong without PMTU discovery.

-- 
Stefano