Documentation ¶
Overview ¶
Package ipsec provides the Linux datpaath specific abstraction and useful helpers to manage IPSec via Linux xfrm.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func DeleteIPsecEndpoint ¶
DeleteIPsecEndpoint deletes a endpoint associated with the remote IP address
func EnableIPv6Forwarding ¶ added in v1.5.0
func EnableIPv6Forwarding() error
EnableIPv6Forwarding sets proc file to enable IPv6 forwarding
func LoadIPSecKeysFile ¶
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) Returns the authentication overhead in bytes, the key ID, and an error.
func UpsertIPsecEndpoint ¶
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.