3.4. Example Usage

To make use of an AEAD algorithm, an application must define how the encryption algorithm's inputs are defined in terms of application data, and how the ciphertext and nonce are conveyed. The clearest way to do this is to express each input in terms of the data that form it, then to express the application data in terms of the outputs of the AEAD encryption operation.

For example, AES-GCM ESP [RFC4106] can be expressed as follows. The AEAD inputs are

P = RestOfPayloadData || TFCpadding || Padding || PadLength ||
    NextHeader

N = Salt || IV

A = SPI || SequenceNumber

where the symbol "||" denotes the concatenation operation, and the fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader, SPI, and SequenceNumber are as defined in [RFC4303], and the fields Salt and IV are as defined in [RFC4106]. The field RestOfPayloadData contains the plaintext data that is described by the NextHeader field, and no other data. (Recall that the PayloadData field contains both the IV and the RestOfPayloadData; see Figure 2 of [RFC4303] for an illustration.)

The format of the ESP packet can be expressed as

ESP = SPI || SequenceNumber || IV || C

where C is the AEAD ciphertext (which in this case incorporates the authentication tag). Please note that here we have not described the use of the ESP Extended Sequence Number.

3.4. Example Usage​

3.4. Example Usage