ingress firewall: filter destination IPs of incoming packets

[smira]

An optional feature to filter out the packets coming into the system by destination IP.

This is incompatible with native pod IP routing (e.g. BGP), so it should be optional.

For CNIs with encapsulation, the following should hold: any packet arriving from the external interface (to be specified by the user) should have a destination of one of the host addresses.

A proposed machine config rule (draft):

apiVersion: v1alpha1
kind: InputFilterConfig (?)
name: enp0s2 # name of the external link
addresses: # if not specified, defaults to host addresses, otherwise an explicit rule is used
 - 10.0.0.0/24

The rule should be injected into the prerouting chain of nftables, before any processing happens.

[smira]

https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

[Orzelius]

After a bit of thought and learning, a few ideas:

1. I think a name like NetworkDestinationFilterConfig or LinkDestinationFilterConfig would be well suited for the document
2. making links a list will make maintenance easier for users and will allow to add a selector if we want to later
3. always include host addresses known to Talos and make the addresses field an additive additionalDestinations or something similar. Reasoning:
   3.1. The addresses list being an override can easily cause drastic user error (e.g. a user who wants to additionally permit 10.0.0.0/24 adds that address only and silently drops traffic to every other address the node owns)
   3.2. I don't really see anybody really wanting to replace the host addresses, only to add more

[Orzelius]

Another idea: fib daddr type instead of an address set from the NodeAddress resource.
something like:
iifname "enp0s2" fib daddr type != { local, broadcast, multicast } counter drop

Benefits:

1. no race with address changes
2. Link-local, loopback, multicast and broadcast are classified correctly automatically (these are not part of the NodeAddress resource and would have to be added to the address set)
3. No dependency on NodeAddress in the new controller (if a new controller is made)

[smira]

apiVersion: v1alpha1
kind: NetworkLinkIngressConfig
name: enp0s2 # name of the link to apply filtering to (might also be an alias)
destinationAddresses: # if not specified, defaults to host addresses, otherwise an explicit list is used
 - 10.0.0.0/24

Example, if one has just a single link, then the default list (of NodeAdressses minus k8s addresses) should work well:

apiVersion: v1alpha1
kind: NetworkLinkIngressConfig
name: enp0s2 

Example, with two VLANs, one for public traffic, and another for private/management LAN:

apiVersion: v1alpha1
kind: NetworkLinkIngressConfig
name: enp0s2.35
destinationAddresses:
  - 1.2.3.4/32
---
apiVersion: v1alpha1
kind: NetworkLinkIngressConfig
name: enp0s2.37
destinationAddresses:
  - 192.168.10.0/24

If CNI native routing is used, this filtering should not be applied at all.

[Orzelius]

Traffic	Destination	Consequence if dropped
IPv6 Neighbor Solicitation	solicited-node multicast ff02::1:ffXX:XXXX	Neighbor discovery fails. Once cache entries expire, IPv6 on that link stops working entirely — this is IPv6's ARP.
IPv6 Router Advertisement	ff02::1	SLAAC addresses and the default route expire and are never renewed.
MLD / MLDv2 queries	ff02::1, ff02::16	Multicast group membership breaks.
Unicast NDP replies, DHCPv6	fe80::... (link-local)	Same class of failure — link-local is excluded from the set.
IPv4 broadcast	255.255.255.255, subnet broadcast	DHCP server→client offers, some discovery protocols.
VRRP / keepalived	224.0.0.18	External VIP failover breaks.
IGMP, OSPF, mDNS	224.0.0.x	Whatever depends on them.

[smira]

Should we accept traffic to link addresses of with fib? And expand the match to NodeAddresses via the table as the next step?

Also fib for multicast/broadcast (if possible?)