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:	Thu, 24 Nov 2011 09:49:52 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for
 input routes

On Thu, Nov 24, 2011 at 09:01:47AM +0800, Herbert Xu wrote:
> On Wed, Nov 23, 2011 at 07:17:58PM -0500, David Miller wrote:
> >
> > It means there is a propagation delay of PMTU increasing which is on the
> > order of the number of hops between the sender and the PMTU increased link.
> > So if the PMTU timeout is X, the propagation time is X * N_HOPS.
> 
> That assumes that each router in the path would constantly probe
> to refresh its cached value, as otherwise they should all expire
> after X.

Well, it simply got unpredictable how long pmtu propagation takes.
This depends now on the network activity of the routers and on the
individual configuration of the expiration time on each router. With
the original behaviour, we could expect to notice a pmtu increase
if we probe after our timeout X. Now we don't know when this is going
to happen.

Btw. we leak a trigger to check if the learned pmtu information has
expired in our current tree, the learned pmtu informations never
expire. So we are doing good to not propagate our learned pmtu
to other hosts :)

--
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