Security, Stackable Destination, and XFRM - Linux

IPSec has been the security mechanism of choice for many years. The security features for TCP/IP were first specified in the mid-1990s. The security architecture for IP, known collectively as IPSec, was revised in the late 1990s [RFC 2401]. It was revised to include a definition of an Authentication Header (AH) [RFC 2402], an Encapsulating Security Payload (ESP) [RFC 2406], and Internet Key Exchange (IKE) for key management [RFC 2409]. This book won’t go into the theory of network security, but we will explore some of the internal structures used to support IPSec. It also supports the concept of Security Associations (SAs). SAs can be thought of as secure connections. The management of SAs involve a three-tuple consisting of a Security Parameter Index (SPI), a destination address, and a security protocol, which can be either ESP or SH. With certain types of SAs, the IP traffic passes through an IP tunnel where an outer IP header specifies the IPSec information and an inner header that is the “real” IP header. Linux supports the PF_KEY key management API version 2 [RFC 2367]. The PF_KEY type address family is defined in file linux/include/linux/pfkeyv2.h.

To support these security features, Linux provides a Security Policy Database (SPD), which contains the rules to implement the secure policy. It also provides a Security Association Database (SAD) to manage the secure connections. The destination cache, covered earlier in this chapter, is used to assign a destination to a packet, which could be an external host machine or an internal packet handler. Starting with Linux 2.6, there is a mechanism called the Transformer (XFRM) that transforms destination cache entries based on the security policy. The essentials of the xfrm implementation consist of a policy rule implemented as a structure called xfrm_policy. In addition, it defines a transformer with the xfrm_state structure definition from file linux/include/net/xfrm.h.

The SPD contains the transform rules that are implemented as a list of xfrm_policy instances, ordered by priority. The transformer allows the dst_entry structures to be accumulated into bundles. In addition, the dst_entry structure has a new field, xfrm_state, which points to a xfrm_state instance.

The SPD is accessed when protocol output routines do a lookup in the SPD by calling xfrm_lookup, defined in file linux/include/net/dst.h.

int xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl, struct sock
*sk, int flags);

Xfrm_lookup finds a match in the SPD and then checks the action in the xfrm_policy entry. If the action is XFRM_POLICY_BLOCK, it returns an error. If the action is XFRM_POLICY_ALLOW, then a "bundle" of destinations is accumulated and returned. The xfrm_state structure is defined in file linux/include/net/xfrm.h.

There must also be a way for applications to manage the SPD. Linux provides two interfaces between the SPD and the socket layer. The first interface uses PF_KEY type sockets. In addition, messages can be sent to the SPD from the applications using netlink(7).

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Linux Topics