In the case where a security gateway is providing services on behalf
   of one or more hosts on a trusted subnet, the security gateway is
   responsible for establishing the security association on behalf of
   its trusted host and for providing security services between the
   security gateway and the external system(s).  In this case, only the
   gateway need implement ESP, while all of the systems behind the
   gateway on the trusted subnet may take advantage of ESP services
   between the gateway and external systems.

   A gateway which receives a datagram containing a recognised
   sensitivity label from a trusted host should take that label's value
   into consideration when creating/selecting a Security Association for
   use with ESP between the gateway and the external destination.  In
   such an environment, a gateway which receives a IP packet containing
   the ESP should appropriately label the decrypted packet that it
   forwards to the trusted host that is the ultimate destination.  The
   IP Authentication Header should always be used on packets containing
   explicit sensitivity labels to ensure end-to-end label integrity.








 
RFC 1825              Security Architecture for IP           August 1995


   If there are no security gateways present in the connection, then two
   end systems that implement ESP may also use it to encrypt only the
   user data (e.g., TCP or UDP) being carried between the two systems.
   ESP is designed to provide maximum flexibility so that users may
   select and use only the security that they desire and need.

   Routing headers for which integrity has not been cryptographically
   protected SHOULD be ignored by the receiver.  If this rule is not
   strictly adhered to, then the system will be vulnerable to various
   kinds of attacks, including source routing attacks [Bel89] [CB94]
   [CERT95].

   While these documents do not specifically discuss IPv4 broadcast,
   these IP security mechanisms MAY be used with such packets.  Key
   distribution and Security Association management are not trivial for
   broadcast applications.  Also, if symmetric key algorithms are used
   the value of using cryptography with a broadcast packet is limited
   because the receiver can only know that the received packet came from
   one of many systems knowing the correct key to use.

1.4 Security Associations

   The concept of a "Security Association" is fundamental to both the IP
   Encapsulating Security Payload and the IP Authentication Header.  The
   combination of a given Security Parameter Index (SPI) and Destination
   Address uniquely identifies a particular "Security Association".  An
   implementation of the Authentication Header or the Encapsulating
   Security Payload MUST support this concept of a Security Association.
   An implementation MAY also support other parameters as part of a
   Security Association.  A Security Association normally includes the
   parameters listed below, but might include additional parameters as
   well:

   - Authentication algorithm and algorithm mode being used with
     the IP Authentication Header [REQUIRED for AH implementations].

   - Key(s) used with the authentication algorithm in use with
     the Authentication Header [REQUIRED for AH implementations].

   - Encryption algorithm, algorithm mode, and transform being
     used with the IP Encapsulating Security Payload [REQUIRED for
     ESP implementations].

   - Key(s) used with the encryption algorithm in use with the
     Encapsulating Security Payload [REQUIRED for ESP implementations].







 
RFC 1825              Security Architecture for IP           August 1995


   - Presence/absence and size of a cryptographic synchronisation or
     initialisation vector field for the encryption algorithm [REQUIRED
     for ESP implementations].

   - Authentication algorithm and mode used with the ESP transform
     (if any is in use) [RECOMMENDED for ESP implementations].

   - Authentication key(s) used with the authentication algorithm
     that is part of the ESP transform (if any) [RECOMMENDED for
     ESP implementations].

   - Lifetime of the key or time when key change should occur
     [RECOMMENDED for all implementations].