netdev - Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes

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]

Date:	Wed, 23 Nov 2011 16:49:41 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.hengli.com.au
Cc:	steffen.klassert@...unet.com, netdev@...r.kernel.org
Subject: Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for
 input routes

From: Herbert Xu <herbert@...dor.hengli.com.au>
Date: Wed, 23 Nov 2011 23:52:45 +0800

> Steffen Klassert <steffen.klassert@...unet.com> wrote:
>> The pmtu informations on the inetpeer are visible for output and
>> input routes. On packet forwarding, we might propagate a learned
>> pmtu to the sender. As we update the pmtu informations of the
>> inetpeer on demand, the original sender of the forwarded packets
>> might never notice when the pmtu to that inetpeer increases.
>> So use the mtu of the outgoing device on packet forwarding instead
>> of the pmtu to the final destination.
> 
> I disagree.  MTU increases are detected by the source retrying,
> so they most certainly should notice if our cached value expires.

Herbert, consider the issue one level higher :-)

The issue is that "we", the forwarding entity, end up with a cached on
the input route and report this cached PMTU to the sender.

This takes a while to time out.

So even if the sender "probes" he will be kept from seeing new MTU space
becomming available due to our cached value.

What Steffen is doing is simply re-instating the behavior we had
before the inetpeer conversion occurred.  We never used learned PMTU
information on input routes, only output routes stored them.

But now that input and output routes share learned information from
the same set of inetpeer entries, we have to accomodate cases like this
one.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html