Thread (14 messages) 14 messages, 3 authors, 2013-11-05

Re: [PATCH net-next] ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE

From: David Miller <davem@davemloft.net>
Date: 2013-10-29 04:08:45

From: Hannes Frederic Sowa <redacted>
Date: Sat, 26 Oct 2013 22:11:58 +0200
Sockets marked with IP_PMTUDISC_INTERFACE won't do path mtu discovery,
their sockets won't accept and install new path mtu information and they
will always use the interface mtu for outgoing packets. It is guaranteed
that the packet is not fragmented locally. But we won't set the DF-Flag
on the outgoing frames.

Florian Weimer had the idea to use this flag to ensure DNS servers are
never generating outgoing fragments. They may well be fragmented on the
path, but the server never stores or usees path mtu values, which could
well be forged in an attack.

(The root of the problem with path MTU discovery is that there is
no reliable way to authenticate ICMP Fragmentation Needed But DF Set
messages because they are sent from intermediate routers with their
source addresses, and the IMCP payload will not always contain sufficient
information to identify a flow.)
I do not like this reasoning.  You have several more acceptable paths to take
to resolve this problem:

1) "I don't trust path MTU information at all"

   Just turn it off globally, end of story.  It has the same effect as your
   new per-application mode.

2) "I don't trust path MTU information unless the full socket ID is available
    in the ICMP packets quoted headers"

   Then simply implement a policy as such and submit it to me.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help