Security Architecture for the Internet Protocol
RFC 1825

Document Type RFC - Proposed Standard (August 1995; No errata)
Obsoleted by RFC 2401
Author Randall Atkinson 
Last updated 2013-03-02
Replaces draft-ietf-ipngwg-sec
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1825 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        R. Atkinson
Request for Comments: 1825                     Naval Research Laboratory
Category: Standards Track                                    August 1995

            Security Architecture for the Internet Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


   This memo describes the security mechanisms for IP version 4 (IPv4)
   and IP version 6 (IPv6) and the services that they provide.  Each
   security mechanism is specified in a separate document.  This
   document also describes key management requirements for systems
   implementing those security mechanisms.  This document is not an
   overall Security Architecture for the Internet and is instead focused
   on IP-layer security.

1.1 Technical Definitions

   This section provides a few basic definitions that are applicable to
   this document.  Other documents provide more definitions and
   background information [VK83, HA94].

           The property of knowing that the data received is the same as
           the data that was sent and that the claimed sender is in fact
           the actual sender.

           The property of ensuring that data is transmitted from source
           to destination without undetected alteration.

           The property of communicating such that the intended
           recipients know what was being sent but unintended
           parties cannot determine what was sent.

           A mechanism commonly used to provide confidentiality.

Atkinson                    Standards Track                     [Page 1]
RFC 1825              Security Architecture for IP           August 1995

           The property of a receiver being able to prove that the sender
           of some data did in fact send the data even though the sender
           might later desire to deny ever having sent that data.

           Acronym for "Security Parameters Index".  An unstructured
           opaque index which is used in conjunction with the
           Destination Address to identify a particular Security

   Security Association
           The set of security information relating to a given network
           connection or set of connections.  This is described in
           detail below.

   Traffic Analysis
           The analysis of network traffic flow for the purpose of
           deducing information that is useful to an adversary.
           Examples of such information are frequency of transmission,
           the identities of the conversing parties, sizes of packets,
           Flow Identifiers used, etc. [Sch94].

1.2 Requirements Terminology

   In this document, the words that are used to define the significance
   of each particular requirement are usually capitalised.  These words

   - MUST

      This word or the adjective "REQUIRED" means that the item is an
      absolute requirement of the specification.


      This word or the adjective "RECOMMENDED" means that there might
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before taking a different course.

   - MAY

      This word or the adjective "OPTIONAL" means that this item is
      truly optional.  One vendor might choose to include the item
      because a particular marketplace requires it or because it
      enhances the product, for example; another vendor may omit the
      same item.

Atkinson                    Standards Track                     [Page 2]
RFC 1825              Security Architecture for IP           August 1995

1.3 Typical Use

   There are two specific headers that are used to provide security
   services in IPv4 and IPv6.  These headers are the "IP Authentication
   Header (AH)" [Atk95a] and the "IP Encapsulating Security Payload
   (ESP)" [Atk95b] header.  There are a number of ways in which these IP
   security mechanisms might be used.  This section describes some of
   the more likely uses.  These descriptions are not complete or
   exhaustive.  Other uses can also be envisioned.

   The IP Authentication Header is designed to provide integrity and
   authentication without confidentiality to IP datagrams.  The lack of
   confidentiality ensures that implementations of the Authentication
   Header will be widely available on the Internet, even in locations
   where the export, import, or use of encryption to provide
   confidentiality is regulated.  The Authentication Header supports
Show full document text