netdev - Proposed addition to sysctl rp

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>] [day] [month] [year] [list]

Message-ID: <ff98f7eb-e21b-b765-f7a0-9c7126043118@satchell.net>
Date:   Wed, 9 Jun 2021 07:26:03 -0700
From:   Stephen Satchell <list@...chell.net>
To:     netdev@...r.kernel.org
Subject: Proposed addition to sysctl rp_filter documentation

I've been trying to find a definitive description how the IPv4 rp_filter 
actually works in detail, and found nothing in searching around.  There 
are hints here and there, but nothing that spells out how the filter 
works.  So I obeyed the mantra "Use the source, Luke" and dived in. 
This proposal is a distillation of what I found and believe to be 
accurate about how rp_filter works.

I appreciate a review by the people who are deep in the weeds.

After receiving comments, I plan to submit an appropriate page

After looking at the source that appears to implement rp_filter
     linux/net/ipv4/fib_frontend.c
I believe that I now understand the tests rp_filter performs to
validate the source address when net.ipv4.conf.*.rp_filter is
set to one or two for a given interface.  I have also reviewed
the commit history for fib_frontend.c to better understand the
evolution of the code.

Does the new paragraph I have written accurately reflect what
happens?

Description of rp_filter from
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
--------------------------------------------------------------------
rp_filter - INTEGER
	0 - No source validation.
	1 - Strict mode as defined in RFC3704 Strict Reverse Path
	    Each incoming packet is tested against the FIB and if the
	    interface is not the best reverse path the packet check will
	    fail. By default failed packets are discarded.
	2 - Loose mode as defined in RFC3704 Loose Reverse Path
	    Each incoming packet's source address is also tested against
	    the FIB and if the source address is not reachable via any
	    interface the packet check will fail.

	[*proposed-addition]
	
	Current recommended practice in RFC3704 is to enable strict mode
	to prevent IP spoofing from DDos attacks. If using asymmetric
	routing or other complicated routing, then loose mode is
	recommended.

	The max value from conf/{all,interface}/rp_filter is used
	when doing source validation on the {interface}.

	Default value is 0. Note that some distributions enable it
	in startup scripts.
--------------------------------------------------------------------

Recommended addition where marked with "[*proposed-addition]":
     rp_filter will examine the source address of an incoming IP
     packet by performing an FIB lookup.  In loose mode (value 2),
     the packet is rejected if the source address is neither
     UNICAST nor LOCAL(when interface allows) nor IPSEC.  For
     strict mode (value 1) the interface indicated by the FIB table
     entry must also match the interface on which the packet arrived.