Page MenuHomeFreeBSD

Add net.inet.ip.source_address_validation
ClosedPublic

Authored by glebius on Nov 9 2021, 8:35 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Feb 19, 11:08 AM
Unknown Object (File)
Thu, Feb 19, 11:08 AM
Unknown Object (File)
Thu, Feb 19, 11:08 AM
Unknown Object (File)
Wed, Feb 18, 4:38 PM
Unknown Object (File)
Wed, Feb 18, 11:39 AM
Unknown Object (File)
Wed, Feb 18, 11:39 AM
Unknown Object (File)
Tue, Feb 17, 3:42 AM
Unknown Object (File)
Tue, Feb 17, 3:42 AM

Details

Summary

Drop packets arriving from the network that have our source IP
address. If maliciously crafted they can create evil effects
like an RST exchange between two of our listening TCP ports.
Such packets just can't be legitimate. Enable the tunable
by default. Long time due for a modern Internet host.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Nov 9 2021, 9:47 PM
This revision now requires review to proceed.Nov 11 2021, 12:30 AM

Thank you for including the fib.

This revision is now accepted and ready to land.Nov 11 2021, 7:55 AM
This revision was automatically updated to reflect the committed changes.

Today I was doing a loopback test across two Mellanox ConnectX-4 LX ports on the same NIC, with a fresh 25GBE SFP+ DAC cable. This is with a fresh install of 15.0-RELEASE on a plain Samsung EVO SATA SSD, with a recycled Dell Optiplex 3020.

The mce(4) ports are not enabled at all by FreeBSD on boot, as we'd expect; they have not been explicitly configured; Moreover, according to sysrc -A, "ipv6_activate_all_interfaces" defaults to NO, so I am purely using IPv4 for my testing here. Had I not done that, I may not have run into the issue.

I proceeded to force my IPv4 packets to transit 802.3, rather than loopback, in the traditional way for this:
ifconfig mce0 192.168.1.1/30
ifconfig mce1 192.168.1.2/30
route -n del 192.168.1.0/30
route -n del 192.168.1.1
route -n del 192.168.1.2

Then, the ICMPv4 ECHO test:

  1. bypass routing table to reach mce1, force source to be mce0
  2. i.e. do *not* use -iface routes.

ping -S 192.168.1.1 -r 192.168.1.2

Then I discovered sysctl net.inet.ip.source_address_validation was blocking the packets. A new feature to me.

However, setting sysctl net.inet.ip.source_address_validation=0 did not appear to have an effect, until an ARP cache invalidation was forced:
ifconfig mce1 down
ifconfig mce1 up

Then, I got ICMP ECHO responses back just fine, and I went on to run iperf 2.x TCP and UDP tests.
Is this by design? This is probably worth reporting to others in case it is unexpected, but it certainly broke POLA for me.

While I'm here, note that I never got to submit my patches for bwping(8) back to the author from my PhD work in 2014/15, and lost them in my life crisis. At that time, bwping could only have its test load controlled by a "volume of bytes to send" parameter, and not a duration, unlike iperf. It has since moved to GitHub; this may have changed.

For such a test you'd better move one of the interfaces into VIMAGE jail. This will isolate not only from this particular problem, but from other potential problems.