Internet Protocol security architecture

See also: communications security

Both Internet Protocol version 4 and Internet Protocol version 6 can run more securely if features of the Internet Protocol security architecture (IPSec) are enabled. IPv6 security can use these features in a way more integrated with regular packet processing than can IPv4, but the basic mechanisms are common.

IPv6 has two optional headers, authentication header and encapsulating security payload. The Authentication Header (AH) offers atomic integrity (i.e., an sssurance individual records have not been altered) and data origin sender authentication, with optional features, which provide certain aspects of sequential integrity. The property of sequential integrity establishes that a sequence of information structures is correct: no record has been deleted, duplication (i.e., "replayed") or deleted.

The Encapsulating Security Payload (ESP) protocol offers the same set of services, and also offers content confidentiality. ESP is almost always used in addition to AH, but AH alone can provide some useful functions. ESP, with its confidentiality features enabled, provides limited traffic flow confidentiality, also called protection against traffic analysis. Traffic analysis is not always a threat; the relevant security policy must show a need for it.

Both AH and ESP offer mechanism access control, enforced through the distribution of cryptographic keys and the management of traffic flows as dictated by the Security Policy Database (SPD). This Database is outside the protocol proper and part of the security infrastructure.

                       Unprotected
                        ^       ^
                        |       |
          +-------------|-------|-------+
          | +-------+   |       |       |
          | |Discard|<--|       V       |
          | +-------+   |B  +--------+  |
        ................|y..| AH/ESP |..... IPsec Boundary
          |   +---+     |p  +--------+  |
          |   |IKE|<----|a      ^       |
          |   +---+     |s      |       |
          | +-------+   |s      |       |
          | |Discard|<--|       |       |
          | +-------+   |       |       |
          +-------------|-------|-------+
                        |       |
                        V       V
                        Protected

Establishing the Security Association

Before any use can be made of AH and ESP, various parameters need to be negotiated, in each direction of transmission, between the source and endpoints. IPSec can establish either point-to-point or point-to-multipoint associations.

Authentication Header

In the header below, the Security Parameters Index points to a prenegotiated Security Association, which establishes the context in which the other security-related fields of the AH should be validated. It must be possible to find the SPI in the Security Association Database (SAD); its not being present immediately causes the authentication to fail.

An authenticator, for IPv4, has the value 51 in its Protocol ID or in its IPv6 Next Header. The AH contains the information below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Next Header   |  Payload Len  |          RESERVED             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Security Parameters Index (SPI)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Sequence Number Field                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                Integrity Check Value-ICV (variable)           |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+