ipsec

Documentation

Overview

Package ipsec provides the Linux datpaath specific abstraction and useful helpers to manage IPSec via Linux xfrm.

Index

• func DeleteIPSecEndpoint(src, local net.IP) error
• func EnableIPv6Forwarding() error
• func LoadIPSecKeysFile(path string) error
• func UpsertIPSecEndpoint(local, remote *net.IPNet, spi int, dir IPSecDir) error
• type IPSecDir

Functions

func DeleteIPSecEndpoint

func DeleteIPSecEndpoint(src, local net.IP) error

DeleteIPSecEndpoint deletes the endpoint from IPSec SPD and SAD

func EnableIPv6Forwarding

func EnableIPv6Forwarding() error

EnableIPv6Forwarding sets proc file to enable IPv6 forwarding

func LoadIPSecKeysFile

func LoadIPSecKeysFile(path string) error

LoadIPSecKeysFile imports IPSec auth and crypt keys from a file. The format is to put a key per line as follows, (auth-algo auth-key enc-algo enc-key)

func UpsertIPSecEndpoint

func UpsertIPSecEndpoint(local, remote *net.IPNet, spi int, dir IPSecDir) error

UpsertIPSecEndpoint updates the IPSec context for a new endpoint inserted in * the ipcache. Currently we support a global crypt/auth keyset that will encrypt * all traffic between endpoints. An IPSec context consists of two pieces a policy * and a state, the security policy database (SPD) and security association * database (SAD). These are implemented using the Linux kernels XFRM implementation. * * For all traffic that matches a policy, the policy tuple used is * (sip/mask, dip/mask, dev) with an optional mark field used in the Cilium implementation * to ensure only expected traffic is encrypted. The state hashtable is searched for * a matching state associated with that flow. The Linux kernel will do a series of * hash lookups to find the most specific state (xfrm_dst) possible. The hash keys searched are * the following, (daddr, saddr, reqid, encap_family), (daddr, wildcard, reqid, encap), * (mark, daddr, spi, proto, encap). Any "hits" in the hash table will subsequently * have the SPI checked to ensure it also matches. Encap is ignored in our case here * and can be used with UDP encap if wanted. * * The implications of the (inflexible!) hash key implementation is that in-order * to have a policy/state match we _must_ insert a state for each daddr. For Cilium * this translates to a state entry per node. We learn the nodes/endpoints by * listening to ipcache events. Finally, because IPSec is unidirectional a state * is needed for both ingress and egress. Denoted by the DIR on the xfrm cmd line * in the policy lookup. In the Cilium case, where we have IPSec between all * endpoints this results in two policy rules per node, one for ingress * and one for egress. * * For a concrete example consider two cluster nodes using transparent mode e.g. * without an IPSec tunnel IP. Cluster Node A has host_ip 10.156.0.1 with an * endpoint assigned to IP 10.156.2.2 and cluster Node B has host_ip 10.182.0.1 * with an endpoint using IP 10.182.3.3. Then on Node A there will be a two policy * entries and a set of State entries, * * Policy1(src=10.182.0.0/16,dst=10.156.0.1/16,dir=in,tmpl(spi=#spi,reqid=#reqid)) * Policy2(src=10.156.0.0/16,dst=10.182.0.1/16,dir=out,tmpl(spi=#spi,reqid=#reqid)) * State1(src=*,dst=10.182.0.1,spi=#spi,reqid=#reqid,...) * State2(src=*,dst=10.156.0.1,spi=#spi,reqid=#reqid,...) * * Design Note: For newer kernels a BPF xfrm interface would greatly simplify the * state space. Basic idea would be to reference a state using any key generated * from BPF program allowing for a single state per security ctx.

Types

type IPSecDir

type IPSecDir string

const (
	IPSecDirIn   IPSecDir = "IPSEC_IN"
	IPSecDirOut  IPSecDir = "IPSEC_OUT"
	IPSecDirBoth IPSecDir = "IPSEC_BOTH"
)