# Presentation: 685580

## CERBERUS

**An IPsec Reference Implementation**
- Rob Glenn
- Rob.Glenn@nist.gov

## IPsec & IKE

- IPsec is defined by the following sets of specifications:
- Security Architecture For IP
- Authentication Header Protocol (AH)
- Encapsulated Security Protocol (ESP)
- Internet Key Exchange (IKE)
- Algorithms

- NIST/ITL/ANTD

## Security Architecture For IP

- “...to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6”.
- Offers access control, connectionless integrity, data origin authentication, protection against replays, confidentiality, and limited traffic flow confidentiality.
- Provides host-to-host, router-to-router, and host-to-router security services.
- Independent of any particular algorithms.
- Secure communications between two systems is defined by Security Associations (SAs).

- NIST/ITL/ANTD

## Security Architecture For IP (continued)

- SAs are indexed by the triple, Security Parameter Index (SPI),  Destination Address, Protocol.
- Security is provided by two encapsulation protocols, ESP & AH
- SAs can be setup manually or dynamically through the use of IKE.
- SA bundles allow for multiple encapsulations between systems.
- Some pre-defined IP functions are affected by ESP & AH, (e.g. PMTU, ICMP, Fragmentation).
- Encapsulations can be within a IP-IP Tunnel.

- NIST/ITL/ANTD

## AH

- “...provides connectionless integrity, data origin authentication, and an optional anti-replay service.”
- Provides access control through the distribution of secret cryptographic keying material.
- Outbound packets compute and include cryptographic checksum over entire IP packet.
- Inbound packets compute and compare cryptographic checksum.
- Anti-replay is provided by including and verifying a 32-bit sequence number.

- NIST/ITL/ANTD

## AH Packet Format

**AH Packet Format**

- NIST/ITL/ANTD

## ESP

- MAY provide confidentiality, limited traffic flow confidentiality, connectionless integrity, data origin authentication, and an anti-replay service.
- “One or more of these services must be applied whenever ESP is invoked.”
- Provides access control through the distribution of secret cryptographic keying material.
- Confidentiality is provided by encrypting outbound packets and decrypting inbound packets.

- NIST/ITL/ANTD

## ESP (continued)

- Integrity and authentication is provided in a very similar manner to AH (excludes the IP header when computing the cryptographic checksum).
- Traffic flow confidentiality is provided by concealing the IP addresses, and including extra padding to conceal the message length.
- Anti-replay is provided by including and verifying a 32-bit sequence number.

- NIST/ITL/ANTD

## ESP Packet Format

**ESP Packet Format**

- NIST/ITL/ANTD

## IKE

- A scalable, automated, SA management protocol to facilitate the use of the anti-replay features of AH and ESP, and to accommodate the on-demand creation of SAs.
- Combines the ISAKMP framework  (which is independent of key exchanges) with a particular key exchange algorithm to provide authentication, key exchange, and SA management.
- SAs established as part of a 2 Phase exchange of messages
- In Phase I the two IKE peers use a Diffie-Helman exchange to establish a secure authenticated channel with which to communicate.

- NIST/ITL/ANTD

## IKE (continued)

- In Phase II the secure channel from Phase I is used to negotiate and exchange SA parameters.
- Allows for perfect forward secrecy by performing Phase I with each Phase II.
- Uses either digital signatures, public keys, or pre-shared secret keys for authentication.

- NIST/ITL/ANTD

## Algorithms

- IPsec is independent of the cryptographic algorithms used to secure traffic
- IPsec algorithms specifications remove some of the variable aspects of particular algorithms to assist with interoperability.
- Specifications re-iterate aspects of particular algorithms to emphasize issues that pertain to interoperability and the correctness of the implementation.

- NIST/ITL/ANTD

## Cerberus

- Cerberus has been developed to assist developers, researchers, and potential users in better understanding this new technology.
- Interoperability testing tool.
- Connecting home and corporate offices.

- NIST/ITL/ANTD

## Cerberus Software Architecture

**SADB **
**Management**

**MSS/**
**PMTU**

**Transforms and Algorithms**

- TCP

- UDP

**IPsec**
**Calls**

- Linux Kernel

**Linux**
**Netlink**
**Sockets**

**IKE**

**Cerberus Software Architecture**

- IPv6

- Applications

**TCP/IP Data Flow**

- NIST/ITL/ANTD

## SADB

- Made up of 3 databases.  A system policy database, an inbound SA database, and an outbound SA database.
- The policy database is a simple table that allows IPsec to determine how to use the information in the SADB (or lack thereof) to process IP packets.  This is specified as levels such that:
- 0 - All traffic must be IPsec traffic (ESP or AH)
- 1 - Null SAs can be used
- 2 - Traffic in the clear (i.e. No SA present) is allowed

- NIST/ITL/ANTD

**Notes:**
A Null SA is an SA with no security services specified.  It allows a system to communicate with a non-IPsec system when Level 2 is not specified.

A level of 3 is an OR of 0 and 1 and 2

## SADB (continued)

- SAs are stored in two sorted chained hash tables as a single piece of data with two sets of pointers.
- SADB is organized for both unidirectional SAs and bi-directional SAs
- The fields that make up an SA entry are as follows:
- Destination Address, Prefix Length, Local SPI, Peer Address, Peer SPI, Linked SPI, Linked Protocol, Sequence Number, Replay Window Bitmap, Last Sequence Number Received, Flags: <M, C, T>, Protocol: (ESP, AH, NULL_SA)

- NIST/ITL/ANTD

## SADB (continued)

- For ESP protocol:
- Crypto Algorithm Identifier, Ivec Length, Outbound Key, Inbound Key, Auth Algorithm Identifier, Outbound Key, Inbound Key, Auth Data Length
- For AH protocol:
- Auth Algorithm Identifier, Outbound Key, Inbound Key, Auth Data Length

- NIST/ITL/ANTD

## SADB Management Routines

- SADB management routines receive requests through a Linux Netlink socket in the form of an SADB message:
- SADBM_ADD
- SADBM_DELETE
- SADBM_GET
- SADBM_FLUSH

- NIST/ITL/ANTD

**Notes:**
SADBM_SET verifies the syntactic and semantic correctness of the SA, creates pre-processed data (e.g. cryptographic keys), and adds the SA to both inbound and outbound SADB tables.

SADBM_DELETE frees pre-processed data memory and deletes the SA from both SADB tables.
SADBM_FLUSH goes through the entire outbound SADB table and deletes each SA.
SADBM_GET performs a lookup on a specific SA and reports back the information via the Netlink socket.  If no specific SA is requested, the entire outbound SADB table is sent.
For multiple messages, an end-of-message message is sent to let the user know when it has received the final message.

## User Interface

- A command line interface (sadb) originally based on the BSD route command.
- Allows systems administrators to manually manage SAs.
- Reads SA arguments from the command line, performs simple syntax checking, and sends a completed SADBM message via a Netlink socket to the Linux kernel.
- For SADBM_GET messages, sadb waits for incoming SADBM messages and processes them until an end-of-message message is received.

- NIST/ITL/ANTD

## Inbound IPsec Processing

- Inbound IPsec processing is processed in the following steps.
- If not encapsulated, check policy.
- Verify the correctness of the protocol information.
- Lookup the SA using source address in packet (matched to peer address), SPI, and protocol.
- Check the sequence number.
- For ESP, lookup the authentication transform, ***verify the authentication data***, lookup the crypto transform, ***decrypt the packet***.

- NIST/ITL/ANTD

**Notes:**
IPsec only receives packets destined for this system.  All packets destined for this system go through IPsec processing.

If policy doesn’t allow then either return the packet to IP or drop the packet and log a failure.  Check for NULL_SA.

(e.g. SPI > 255).

against the window to verify that no replay has occurred.

If no SA is found  drop the packet and log a failure.

## Inbound IPsec Processing (continued)

- For AH, lookup the authentication transform, ***verify the authentication data***.
***Build non-encapsulated packet***.
- Remove tunnel.
- Return the IP packet to IP for forwarding or sinking.
- All failures are logged.
- Inbound processing is recursive.

- NIST/ITL/ANTD

**Notes:**
Using the original SKBUF, rebuild the original, non-ipsec encapsulated IP packet, removing the applied tunnel if necessary.

Upon any failure in the above steps, the packet is dropped, the error counters are incremented, and an error message is logged via the printk/klogd system.
The inbound processing function is recursive to allow for packets with multiple encapsulations.  Policy to verify the the encapsulations are in some specified order is not implemented at this time.

## Outbound IPsec Processing

- Outbound IPsec processing is processed in the following steps.  All IP packets go through IPsec processing.
- Lookup SA based on the destination address.
- If no SA is found, check policy and either return the packet to IP for further processing or drop the packet and log a failure.
- Check the sequence number for wrapping.
***Prepare for tunnel if specified in SA***.
- For ESP, lookup the crypto transform, ***encrypt the packet***, lookup the authentication transform, ***compute the authentication data***.

- NIST/ITL/ANTD

**Notes:**
The first, most significant SA that matches the destination address is used.  Local policy to assist in selecting outbound SAs is not implemented.

A printk/klogd message is logged if wrapping is about to happen.  Once a wrap occurs, the packets are dropped and a failure is logged.

If the SA specifies a tunnel, then create a new IP header using this system and the peer address.  The original IP header is included as part of the data to be protected.

Bold and italics are done in transform.

## Outbound IPsec Processing (continued)

- For AH, lookup the authentication transform, ***compute the authentication data***.
- Return the IP packet to IP for  forwarding.
- All failures are logged.
- Outbound processing is recursive.

- NIST/ITL/ANTD

**Notes:**
A new IP packet is created inside a new SKBUF.
Upon any failure in the above steps, the packet is dropped, the error counters are incremented, and an error message is logged via the printk/klogd system.
The outbound processing function is recursive to allow for packets with multiple encapsulations.  The order in which encapsulations is applied is via the linked SA fields in the SADB.

## Transforms & Crypto Routines

- Most of the specified algorithms have been included:
- DES/CBC, 3DES/CBC, IDEA/CBC, RC5/CBC, Blowfish/CBC, HMAC-SHA1-96, HMAC-MD5-96, ESP-NULL, Auth-Test, Crypto-Test
- The transform object is made up of a name, ID, input function, output function, add function, and delete function.
- Transforms are stored in a small hash table indexed by algorithm identifiers.
- Transforms can be compiled and run a complete and separate Linux run-time modules.

- NIST/ITL/ANTD

**Notes:**
The majority of the cryptographic algorithm code, was ported from other implementations.  Some modifications were made to enhance performance.

Transforms provide most of the functionality needed to encapsulate/decapsulate IPsec protected packets.

## TCP & IP Interface

- IP<->IPsec hooks
- ip_build_xmit heavily modified.
- TCP was modified to allow for the extra bytes added to the IP packet that has to be accounted for in the PMTU and MSS calculations.

- NIST/ITL/ANTD

**Notes:**
IP hooks include simple compile-time & run-time flags that when included and set to true, call the appropriate ipsec-input or ipsec-output functions.
Because of the multiple paths IP SKBUFs can take in the Linux kernel, ip_build_xmit was modified.  This modification creates the SKBUF, does the IPsec processing, and then calls the more generic fragmentation routine.  This is a performance hit and detracts from the highly optimized code in ip_build_xmit.
A maximum possible delta for all connections is maintained by IPsec and used in all PMTU and MSS calculations.  This is inefficient in many cases.

## Future Work

- Better way to handle TCP MSS calculations.
- Tune performance by tying SAs to routing table.
- Better way to handle the ip_build_xmit problem.
- Additional policy support.
- IKE reference implementation
- Session/port specific SAs.
- Compression (IPPCP)
- Port to IPv6
- PKIX client support for IKE authentication
- Mobile IPsec

- NIST/ITL/ANTD

## Additional Information

- IETF IPsec WG Charter, RFCs, and Internet Drafts:
- http://www.ietf.org/html.charters/ipsec-charter.html
- Cerberus
- http://www.antd.nist.gov/cerberus/
- NIST IP Security Project
- http://www.antd.nist.gov/antd/html/security.html
- NIST Internetworking Technologies Group
- http://www.antd.nist.gov/html/itg.html

- NIST/ITL/ANTD