linux-stable.git/Documentation/networking/ip-sysctl.txt, branch linux-3.16.y

tcp: add tcp_min_snd_mss sysctl

2019-06-20T17:11:28+00:00

commit 5f3e2bf008c2221478101ee72f5cb4654b9fc363 upstream.

Some TCP peers announce a very small MSS option in their SYN and/or
SYN/ACK messages.

This forces the stack to send packets with a very high network/cpu
overhead.

Linux has enforced a minimal value of 48. Since this value includes
the size of TCP options, and that the options can consume up to 40
bytes, this means that each segment can include only 8 bytes of payload.

In some cases, it can be useful to increase the minimal value
to a saner value.

We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility
reasons.

Note that TCP_MAXSEG socket option enforces a minimal value
of (TCP_MIN_MSS). David Miller increased this minimal value
in commit c39508d6f118 ("tcp: Make TCP_MAXSEG minimum more correct.")
from 64 to 88.

We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS.

CVE-2019-11479 -- tcp mss hardcoded to 48

Signed-off-by: Eric Dumazet 
Suggested-by: Jonathan Looney 
Acked-by: Neal Cardwell 
Cc: Yuchung Cheng 
Cc: Tyler Hicks 
Cc: Bruce Curtis 
Cc: Jonathan Lemon 
Signed-off-by: David S. Miller 
[Salvatore Bonaccorso: Backport for context changes in 4.9.168]
[bwh: Backported to 3.16: Make the sysctl global, consistent with
 net.ipv4.tcp_base_mss]
Signed-off-by: Ben Hutchings

net/ipv6: add sysctl option accept_ra_min_hop_limit

2016-03-24T09:59:05+00:00

commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4 upstream.

Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface")
disabled accept hop limit from RA if it is smaller than the current hop
limit for security stuff. But this behavior kind of break the RFC definition.

RFC 4861, 6.3.4.  Processing Received Router Advertisements
   A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time,
   and Retrans Timer) may contain a value denoting that it is
   unspecified.  In such cases, the parameter should be ignored and the
   host should continue using whatever value it is already using.

   If the received Cur Hop Limit value is non-zero, the host SHOULD set
   its CurHopLimit variable to the received value.

So add sysctl option accept_ra_min_hop_limit to let user choose the minimum
hop limit value they can accept from RA. And set default to 1 to meet RFC
standards.

Signed-off-by: Hangbin Liu 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
[ luis: backported to 3.16:
  - added missing DEVCONF_* as suggested by Yoshfuji so that uapi contains
    the same values as mainline
  - adjusted context ]
Signed-off-by: Luis Henriques

net: Document promote_secondaries

2014-01-28T04:39:21+00:00

From 038a821667f62c496f2bbae27081b1b612122a97 Mon Sep 17 00:00:00 2001
From: Martin Schwenke 
Date: Tue, 28 Jan 2014 15:16:49 +1100
Subject: [PATCH] net: Document promote_secondaries

This option was added a long time ago...

  commit 8f937c6099858eee15fae14009dcbd05177fa91d
  Author: Harald Welte 
  Date:   Sun May 29 20:23:46 2005 -0700

    [IPV4]: Primary and secondary addresses

Signed-off-by: Martin Schwenke 
Signed-off-by: David S. Miller

ipv6: add flowlabel_consistency sysctl

2014-01-20T01:12:31+00:00

With the introduction of IPV6_FL_F_REFLECT, there is no guarantee of
flow label unicity. This patch introduces a new sysctl to protect the old
behaviour, enable by default.

Changelog of V3:
 * rename ip6_flowlabel_consistency to flowlabel_consistency
 * use net_info_ratelimited()
 * checkpatch cleanups

Signed-off-by: Florent Fourcot 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

ipv4: introduce hardened ip_no_pmtu_disc mode

2014-01-13T19:22:55+00:00

This new ip_no_pmtu_disc mode only allowes fragmentation-needed errors
to be honored by protocols which do more stringent validation on the
ICMP's packet payload. This knob is useful for people who e.g. want to
run an unmodified DNS server in a namespace where they need to use pmtu
for TCP connections (as they are used for zone transfers or fallback
for requests) but don't want to use possibly spoofed UDP pmtu information.

Currently the whitelisted protocols are TCP, SCTP and DCCP as they check
if the returned packet is in the window or if the association is valid.

Cc: Eric Dumazet 
Cc: David Miller 
Cc: John Heffner 
Suggested-by: Florian Weimer 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

ipv4: introduce ip_dst_mtu_maybe_forward and protect forwarding path against pmtu spoofing

2014-01-13T19:22:54+00:00

While forwarding we should not use the protocol path mtu to calculate
the mtu for a forwarded packet but instead use the interface mtu.

We mark forwarded skbs in ip_forward with IPSKB_FORWARDED, which was
introduced for multicast forwarding. But as it does not conflict with
our usage in unicast code path it is perfect for reuse.

I moved the functions ip_sk_accept_pmtu, ip_sk_use_pmtu and ip_skb_dst_mtu
along with the new ip_dst_mtu_maybe_forward to net/ip.h to fix circular
dependencies because of IPSKB_FORWARDED.

Because someone might have written a software which does probe
destinations manually and expects the kernel to honour those path mtus
I introduced a new per-namespace "ip_forward_use_pmtu" knob so someone
can disable this new behaviour. We also still use mtus which are locked on a
route for forwarding.

The reason for this change is, that path mtus information can be injected
into the kernel via e.g. icmp_err protocol handler without verification
of local sockets. As such, this could cause the IPv4 forwarding path to
wrongfully emit fragmentation needed notifications or start to fragment
packets along a path.

Tunnel and ipsec output paths clear IPCB again, thus IPSKB_FORWARDED
won't be set and further fragmentation logic will use the path mtu to
determine the fragmentation size. They also recheck packet size with
help of path mtu discovery and report appropriate errors.

Cc: Eric Dumazet 
Cc: David Miller 
Cc: John Heffner 
Cc: Steffen Klassert 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

IPv6: add the option to use anycast addresses as source addresses in echo reply

2014-01-07T20:51:39+00:00

This change allows to follow a recommandation of RFC4942.

- Add "anycast_src_echo_reply" sysctl to control the use of anycast addresses
  as source addresses for ICMPv6 echo reply. This sysctl is false by default
  to preserve existing behavior.
- Add inline check ipv6_anycast_destination().
- Use them in icmpv6_echo_reply().

Reference:
RFC4942 - IPv6 Transition/Coexistence Security Considerations
   (http://tools.ietf.org/html/rfc4942#section-2.1.6)

2.1.6. Anycast Traffic Identification and Security

   [...]
   To avoid exposing knowledge about the internal structure of the
   network, it is recommended that anycast servers now take advantage of
   the ability to return responses with the anycast address as the
   source address if possible.

Signed-off-by: Francois-Xavier Le Bail 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

ipv4: new ip_no_pmtu_disc mode to always discard incoming frag needed msgs

2013-12-18T21:58:20+00:00

This new mode discards all incoming fragmentation-needed notifications
as I guess was originally intended with this knob. To not break backward
compatibility too much, I only added a special case for mode 2 in the
receiving path.

Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2013-12-18T21:42:06+00:00

Conflicts:
	drivers/net/ethernet/intel/i40e/i40e_main.c
	drivers/net/macvtap.c

Both minor merge hassles, simple overlapping changes.

Signed-off-by: David S. Miller

ipv4: improve documentation of ip_no_pmtu_disc

2013-12-17T20:20:15+00:00

Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller