both the bandwidth consumed and the protocol processing costs for
   users that don't need to keep the entire IP datagram confidential.




 
RFC 1825              Security Architecture for IP           August 1995


   ESP works with both unicast and multicast traffic.

3.2.3 Performance Impacts of ESP

   The encapsulating security approach used by ESP can noticeably impact
   network performance in participating systems, but use of ESP should
   not adversely impact routers or other intermediate systems that are
   not participating in the particular ESP association.  Protocol
   processing in participating systems will be more complex when
   encapsulating security is used, requiring both more time and more
   processing power.  Use of encryption will also increase the
   communications latency.  The increased latency is primarily due to
   the encryption and decryption required for each IP datagram
   containing an Encapsulating Security Payload.  The precise cost of
   ESP will vary with the specifics of the implementation, including the
   encryption algorithm, key size, and other factors.  Hardware
   implementations of the encryption algorithm are recommended when high
   throughput is desired.

   For interoperability throughout the worldwide Internet, all
   conforming implementations of the IP Encapsulating Security Payload
   MUST support the use of the Data Encryption Standard (DES) in
   Cipher-Block Chaining (CBC) Mode as detailed in the ESP
   specification.  Other confidentiality algorithms and modes may also
   be implemented in addition to this mandatory algorithm and mode.
   Export and use of encryption are regulated in some countries [OTA94].

3.3 COMBINING SECURITY MECHANISMS

   In some cases the IP Authentication Header might be combined with the
   IP Encapsulating Security Protocol to obtain the desired security
   properties.  The Authentication Header always provides integrity and
   authentication and can provide non-repudiation if used with certain
   authentication algorithms (e.g., RSA).  The Encapsulating Security
   Payload always provides integrity and confidentiality and can also
   provide authentication if used with certain authenticating encryption
   algorithms.  Adding the Authentication Header to a IP datagram prior
   to encapsulating that datagram using the Encapsulating Security
   Protocol might be desirable for users wishing to have strong
   integrity, authentication, confidentiality, and perhaps also for
   users who require strong non-repudiation.  When the two mechanisms
   are combined, the placement of the IP Authentication Header makes
   clear which part of the data is being authenticated.  Details on
   combining the two mechanisms are provided in the IP Encapsulating
   Security Payload specification [At94b].







 
RFC 1825              Security Architecture for IP           August 1995


3.4 OTHER SECURITY MECHANISMS

   Protection from traffic analysis is not provided by any of the
   security mechanisms described above.  It is unclear whether
   meaningful protection from traffic analysis can be provided
   economically at the Internet Layer and it appears that few Internet
   users are concerned about traffic analysis.  One traditional method
   for protection against traffic analysis is the use of bulk link
   encryption.  Another technique is to send false traffic in order to
   increase the noise in the data provided by traffic analysis.
   Reference [VK83] discusses traffic analysis issues in more detail.

4. KEY MANAGEMENT

   The Key Management protocol that will be used with IP layer security
   is not specified in this document.  However, because the key
   management protocol is coupled to AH and ESP only via the Security
   Parameters Index (SPI), we can meaningfully define AH and ESP without
   having to fully specify how key management is performed.  We envision
   that several key management systems will be usable with these
   specifications, including manual key configuration.  Work is ongoing
   within the IETF to specify an Internet Standard key management
   protocol.

   Support for key management methods where the key management data is
   carried within the IP layer is not a design objective for these IP-
   layer security mechanisms.  Instead these IP-layer security
   mechanisms will primarily use key management methods where the key
   management data will be carried by an upper layer protocol, such as
   UDP or TCP, on some specific port number or where the key management
   data will be distributed manually.

   This design permits clear decoupling of the key management mechanism
   from the other security mechanisms, and thereby permits one to