All of lore.kernel.org
 help / color / mirror / Atom feed
* Using the fib to classify endpoints.
@ 2020-05-02 20:30 Stephen Satchell
  0 siblings, 0 replies; only message in thread
From: Stephen Satchell @ 2020-05-02 20:30 UTC (permalink / raw)
  To: netfilter

(slight bug: "describe fib_addrtype" isn't working on CentOS 8 version 
of nft(8))

I have taken the feedback provided by a number of you regarding the 
maturity of NFTABLES.  So I have decided to implement my new gigabit 
fireware using the NFTABLES hook.

Looking at the GitHub source, I have found the following Forward 
Information Base classification specifiers defined:

> static const struct symbol_table addrtype_tbl = {
> 	.base		= BASE_DECIMAL,
> 	.symbols	= {
> 		SYMBOL("unspec",	RTN_UNSPEC),
> 		SYMBOL("unicast",	RTN_UNICAST),
> 		SYMBOL("local",		RTN_LOCAL),
> 		SYMBOL("broadcast",	RTN_BROADCAST),
> 		SYMBOL("anycast",	RTN_ANYCAST),
> 		SYMBOL("multicast",	RTN_MULTICAST),
> 		SYMBOL("blackhole",	RTN_BLACKHOLE),
> 		SYMBOL("unreachable",	RTN_UNREACHABLE),
> 		SYMBOL("prohibit",	RTN_PROHIBIT),
> 		SYMBOL_LIST_END
> 	}
> };

Assuming that all the reserved, local, and known netblocks in question 
have been inserted into the FIB (a.k.a routing table), I can then screen 
packets according to my specifications, which I have already posted to 
NANOG, with some specifications referencing the FIB:

> # WAN Incoming filtering
> #       1.  WAN packets with local/LAN src address
> #       2.  WAN packets with local/LAN broadcast/net src-dst address
> #       3.  WAN packets with known broadcast/net src-dst address
> #       4.  WAN packets with dst small services
> #       5.  WAN packets with dst unimplemented services
> #       6.  WAN packets with blackholed source address
> 
> # WAN outgoing filtering
> #       1.  WAN packets with local/LAN dst address
> #       2.  WAN packets with local/LAN broadcast/net src-dst address
> #       3.  WAN packets with known broadcast/net src-dst address
> #       4.  WAN packets with dst small services
> #       5.  WAN packets with unimplemented dst services
> #       6.  WAN packets with blackholed dst address 

(Concentrating on the internet-facing part for the moment.)

I'm still trying to figure out the syntax of using the fib queries for 
source and destination addresses, but that's a learning exercise for me, 
and not part of my question to you.

One advantage of using the FIB is that BCP 153 netblocks are all 
covered, and subnet overrides happen seamlessly; for example in my 
network, 10.0.0.0/8 would be black-holed, but the longer-prefix netblock 
10.1.1.0/24 would be usable.  This is an example of letting the computer 
do the book-keeping.

So it's easy to block "net", "broadcast", "blackhole" with clear, easy 
to understand rules, and perhaps even have different ICMP responses for 
each of these if I so desire.

Well and good.  Last time I brought up this subject, though, some 
contributors said that IPSET was the way to go, and not "pollute" the 
routing table.  So my question is this:  does IPSET offer the same 
capabilities and classification tests as the FIB?  Does IPSET allow for 
overlapping netblocks?

My search-foo hasn't been good enough to find the answer to this 
question, so I ask y'all.


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-05-02 20:30 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-02 20:30 Using the fib to classify endpoints Stephen Satchell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.