home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-auth-header-02.txt < prev    next >
Text File  |  1997-10-03  |  52KB  |  1,290 lines
  1.  
  2. Network Working Group                             Stephen Kent, BBN Corp
  3. Internet Draft                           Randall Atkinson, @Home Network
  4. draft-ietf-ipsec-auth-header-02.txt                       2 October 1997
  5.  
  6.  
  7.  
  8.  
  9.  
  10.                         IP Authentication Header
  11.  
  12.  
  13.  
  14.  
  15. Status of This Memo
  16.  
  17.    This document is an Internet Draft. Internet Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its Areas,
  19.    and its Working Groups. Note that other groups may also distribute
  20.    working documents as Internet Drafts.
  21.  
  22.    Internet Drafts are draft documents valid for a maximum of 6 months.
  23.    Internet Drafts may be updated, replaced, or obsoleted by other
  24.    documents at any time. It is not appropriate to use Internet Drafts
  25.    as reference material or to cite them other than as a "working draft"
  26.    or "work in progress". Please check the I-D abstract listing
  27.    contained in each Internet Draft directory to learn the current
  28.    status of this or any other Internet Draft.
  29.  
  30.    This particular Internet Draft is a product of the IETF's IPsec
  31.    Working Group. It is intended that a future version of this draft
  32.    will be submitted for consideration as a standards-track document.
  33.    Distribution of this document is unlimited.
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Kent, Atkinson                                                  [Page 1]
  58.  
  59.  
  60. Internet Draft          IP Authentication Header          2 October 1997
  61.  
  62.  
  63. Table of Contents
  64.  
  65.    1. Introduction......................................................3
  66.    2. Authentication Header Format......................................4
  67.       2.1 Next Header...................................................4
  68.       2.2 Payload Length................................................4
  69.       2.3 Reserved......................................................5
  70.       2.4 Security Parameters Index (SPI)...............................5
  71.       2.5 Sequence Number...............................................5
  72.       2.6 Authentication Data ..........................................6
  73.    3. Authentication Header Processing..................................6
  74.       3.1  Authentication Header Location...............................6
  75.       3.2  Authentication Algorithms....................................8
  76.       3.3  Outbound Packet Processing...................................9
  77.          3.3.1  Security Association Lookup.............................9
  78.          3.3.2  Sequence Number Generation..............................9
  79.          3.3.3  Integrity Check Value Calculation......................10
  80.             3.3.3.1  Handling Mutable Fields...........................10
  81.                3.3.3.1.1  ICV Computation for IPv4.....................10
  82.                   3.3.3.1.1.1 Base Header Fields.......................10
  83.                   3.3.3.1.1.2 Options..................................11
  84.                3.3.3.1.2  ICV Computation for IPv6.....................12
  85.                   3.3.3.1.2.1 Base Header Fields.......................12
  86.                   3.3.3.1.2.2 Extension Headers -- Options.............12
  87.                   3.3.3.1.2.3 Extension Headers -- non-Options.........12
  88.             3.3.3.2  Padding...........................................12
  89.                3.3.3.2.1  Authentication Data Padding..................12
  90.                3.3.3.2.2  Implicit Packet Padding......................13
  91.          3.3.4  Fragmentation..........................................13
  92.       3.4  Inbound Packet Processing...................................14
  93.          3.4.1  Reassembly.............................................14
  94.          3.4.2  Security Association Lookup............................14
  95.          3.4.3  Sequence Number Verification...........................14
  96.          3.4.4  Integrity Check Value Verification.....................15
  97.    4. Auditing.........................................................16
  98.    5. Conformance Requirements.........................................16
  99.    6. Security Considerations..........................................17
  100.    7. Differences from RFC 1826........................................17
  101.    Acknowledgements....................................................18
  102.    Appendix A -- Mutability of IP Options/Extension Headers............19
  103.       A1. IPv4 Options.................................................19
  104.       A2. IPv6 Extension Headers.......................................20
  105.    References..........................................................22
  106.    Disclaimer..........................................................23
  107.    Author Information..................................................23
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Kent, Atkinson                                                  [Page 2]
  114.  
  115.  
  116. Internet Draft          IP Authentication Header          2 October 1997
  117.  
  118.  
  119. 1.  Introduction
  120.  
  121.    The IP Authentication Header (AH) is used to provide connectionless
  122.    integrity and data origin authentication for IP datagrams (hereafter
  123.    referred to as just 'authentication'), and to provide protection
  124.    against replays.  This latter, optional service may be selected, by
  125.    the receiver, when a Security Association is established.  AH
  126.    provides authentication for as much of the IP header as possible, as
  127.    well as for upper level protocol data.  However, some IP header
  128.    fields may change in transit and the value of these fields, when the
  129.    packet arrives at the receiver, may not be predictable by the
  130.    transmitter.  The values of such fields cannot be protected by AH.
  131.    Thus the protection provided to the IP header by AH is somewhat
  132.    piecemeal.
  133.  
  134.    AH may be applied alone, in combination with the IP Encapsulating
  135.    Security Payload (ESP) [KA97b], or in a nested fashion through the
  136.    use of tunnel mode (see 'Security Architecture for the Internet
  137.    Protocol' [KA97a], hereafter referred to as the Security Architecture
  138.    document).  Security services can be provided between a pair of
  139.    communicating hosts, between a pair of communicating security
  140.    gateways, or between a security gateway and a host.  ESP may be used
  141.    to provide the same security services, and it also provides a
  142.    confidentiality (encryption) service.  The primary difference between
  143.    the authentication provided by ESP and AH is the extent of the
  144.    coverage.  Specifically, ESP does not protect any IP header fields
  145.    unless those fields are encapsulated by ESP (tunnel mode).  For more
  146.    details on how to use AH and ESP in various network environments, see
  147.    the Security Architecture document [KA97a].
  148.  
  149.    It is assumed that the reader is familiar with the terms and concepts
  150.    described in the Security Architecture document.  In particular, the
  151.    reader should be familiar with the definitions of security services
  152.    offered by AH and ESP, the concept of Security Associations, the ways
  153.    in which AH can be used in conjunction with ESP, and the different
  154.    key management options available for AH and ESP.  (With regard to the
  155.    last topic, the current key management options required for both AH
  156.    and ESP are manual keying and automated keying via Oakley/ISAKMP.)
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169. Kent, Atkinson                                                  [Page 3]
  170.  
  171.  
  172. Internet Draft          IP Authentication Header          2 October 1997
  173.  
  174.  
  175. 2.  Authentication Header Format
  176.  
  177.    The protocol header (IPv4, IPv6, or Extension) immediately preceding the
  178.    AH header will contain the value 51 in its Protocol (IPv4) or Next
  179.    Header (IPv6, Extension) field [STD-2].
  180.  
  181.     0                   1                   2                   3
  182.     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
  183.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.    | Next Header   |  Payload Len  |          RESERVED             |
  185.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.    |                 Security Parameters Index (SPI)               |
  187.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  188.    |                    Sequence Number Field                      |
  189.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.    |                                                               |
  191.    +                Authentication Data (variable)                 |
  192.    |                                                               |
  193.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.  
  195.  
  196.    The following subsections define the fields that comprise the AH
  197.    format.  All the fields described here are mandatory, i.e., they are
  198.    always present in the AH format and are included in the ICV
  199.    computation.
  200.  
  201. 2.1  Next Header
  202.  
  203.    The Next Header is an 8-bit field that identifies the type of the
  204.    next payload after the Authentication Header.  The value of this
  205.    field is chosen from the set of IP Protocol Numbers defined in the
  206.    most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
  207.    Numbers Authority (IANA).
  208.  
  209. 2.2  Payload Length
  210.  
  211.    This 8-bit field specifies the length of AH in 32-bit words (4-byte
  212.    units), minus "2".  (All IPv6 extension headers, as per RFC 1883,
  213.    encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word)
  214.    from the header length (measured in 64-bit words).  AH is an IPv6
  215.    extension header.  However, since its length is measured in 32-bit
  216.    words, the "Payload Length" is calculated by subtracting 2 (32 bit
  217.    words).)  In the "standard" case of a 96-bit authentication value
  218.    plus the 3 32-bit word fixed portion, this length field will be "4".
  219.    A "null" authentication algorithm may be used only for debugging
  220.    purposes.  Its use would result in a "1" value for this field, as
  221.    there would be no corresponding Authentication Data field.
  222.  
  223.  
  224.  
  225. Kent, Atkinson                                                  [Page 4]
  226.  
  227.  
  228. Internet Draft          IP Authentication Header          2 October 1997
  229.  
  230.  
  231. 2.3  Reserved
  232.  
  233.    This 16-bit field is reserved for future use.  It MUST be set to
  234.    "zero." (Note that the value is included in the Authentication Data
  235.    calculation, but is otherwise ignored by the recipient.)
  236.  
  237. 2.4  Security Parameters Index (SPI)
  238.  
  239.    The SPI is an arbitrary 32-bit value that, in combination with the
  240.    destination IP address and security protocol, uniquely identifies the
  241.    Security Association for this datagram.  The set of SPI values in the
  242.    range 1 through 255 are reserved by the Internet Assigned Numbers
  243.    Authority (IANA) for future use; a reserved SPI value will not
  244.    normally be assigned by IANA unless the use of the assigned SPI value
  245.    is specified in an RFC.  It is ordinarily selected by the destination
  246.    system upon establishment of an SA (see the Security Architecture
  247.    document for more details).
  248.  
  249.    The SPI value of zero (0) is reserved for local, implementation-
  250.    specific use and MUST NOT be sent on the wire.  For example, a key
  251.    management implementation MAY use the zero SPI value to mean "No
  252.    Security Association Exists" during the period when the IPsec
  253.    implementation has requested that its key management entity establish
  254.    a new SA, but the SA has not yet been established.
  255.  
  256. 2.5  Sequence Number
  257.  
  258.    This unsigned 32-bit field contains a monotonically increasing
  259.    counter value (sequence number).  It is mandatory and is always
  260.    present even if the receiver does not elect to enable the anti-replay
  261.    service for a specific SA.  Processing of the Sequence Number field
  262.    is at the discretion of the receiver, i.e., the sender MUST always
  263.    transmit this field, but the receiver need not act upon it (see the
  264.    discussion of Sequence Number Verification in the "Inbound Packet
  265.    Processing" section below).
  266.  
  267.    The sender's counter and the receiver's counter are initialized to 0
  268.    when an SA is established.  (The first packet sent using a given SA
  269.    will have a Sequence Number of 1; see Section 3.3.2 for more details
  270.    on how the Sequence Number is generated.)  If anti-replay has been
  271.    enabled, the transmitted Sequence Number must never be allowed to
  272.    cycle.  Thus, the sender's counter and the receiver's counter MUST be
  273.    reset (by establishing a new SA and thus a new key) prior to the
  274.    transmission of the 2^32nd packet on an SA.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281. Kent, Atkinson                                                  [Page 5]
  282.  
  283.  
  284. Internet Draft          IP Authentication Header          2 October 1997
  285.  
  286.  
  287. 2.6  Authentication Data
  288.  
  289.    This is a variable-length field that contains the Integrity Check
  290.    Value (ICV) for this packet.  The field must be an integral multiple
  291.    of 32 bits in length.  The details of the ICV computation are
  292.    described in Section 3.3.3 below.  This field may include explicit
  293.    padding.  This padding is included to ensure that the length of the
  294.    AH header is an integral multiple of 32 bits (IPv4) or 64 bits
  295.    (IPv6).  All implementations MUST support such padding.  Details of
  296.    how to compute the required padding length are provided below.
  297.  
  298. 3.  Authentication Header Processing
  299.  
  300. 3.1  Authentication Header Location
  301.  
  302.    Like ESP, AH may be employed in two ways: transport mode or tunnel
  303.    mode.  The former mode is applicable only to host implementations and
  304.    provides protection for upper layer protocols, in addition to
  305.    selected IP header fields.  (In this mode, note that for "bump-in-
  306.    the-stack" or "bump-in-the-wire" implementations, as defined in the
  307.    Security Architecture document, inbound and outbound IP fragments may
  308.    require an IPsec implementation to perform extra IP
  309.    reassembly/fragmentation in order to both conform to this
  310.    specification and provide transparent IPsec support.  Special care is
  311.    required to perform such operations within these implementations when
  312.    multiple interfaces are in use.)
  313.  
  314.    In transport mode, AH is inserted after the IP header and before an
  315.    upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other
  316.    IPsec headers that have already been inserted.  In the context of
  317.    IPv4, this calls for placing AH after the IP header (and any options
  318.    that it contains), but before the upper layer protocol.  (Note that
  319.    the term "transport" mode should not be misconstrued as restricting
  320.    its use to TCP and UDP.  For example, an ICMP message MAY be sent
  321.    using either "transport" mode or "tunnel" mode.)  The following
  322.    diagram illustrates AH transport mode positioning for a typical IPv4
  323.    packet, on a "before and after" basis.
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337. Kent, Atkinson                                                  [Page 6]
  338.  
  339.  
  340. Internet Draft          IP Authentication Header          2 October 1997
  341.  
  342.  
  343.                   BEFORE APPLYING AH
  344.             ----------------------------
  345.       IPv4  |orig IP hdr  |     |      |
  346.             |(any options)| TCP | Data |
  347.             ----------------------------
  348.  
  349.                   AFTER APPLYING AH
  350.             ---------------------------------
  351.       IPv4  |orig IP hdr  |    |     |      |
  352.             |(any options)| AH | TCP | Data |
  353.             ---------------------------------
  354.             |<------- authenticated ------->|
  355.                  except for mutable fields
  356.  
  357.    In the IPv6 context, AH is viewed as an end-to-end payload, and thus
  358.    should appear after hop-by-hop, routing, and fragmentation extension
  359.    headers.  The destination options extension header(s) could appear
  360.    either before or after the AH header depending on the semantics
  361.    desired.  The following diagram illustrates AH transport mode
  362.    positioning for a typical IPv6 packet.
  363.  
  364.                        BEFORE APPLYING AH
  365.             ---------------------------------------
  366.       IPv6  |             | ext hdrs |     |      |
  367.             | orig IP hdr |if present| TCP | Data |
  368.             ---------------------------------------
  369.  
  370.                       AFTER APPLYING AH
  371.             ------------------------------------------------------------
  372.       IPv6  |             |hop-by-hop, dest*, |    | dest |     |      |
  373.             |orig IP hdr  |routing, fragment. | AH | opt* | TCP | Data |
  374.             ------------------------------------------------------------
  375.             |<---- authenticated except for mutable fields ----------->|
  376.  
  377.                  * = if present, could be before AH, after AH, or both
  378.  
  379.    If more than one IPsec header/extension is required:
  380.            o the order of application of the security headers MUST be
  381.              defined by security policy
  382.            o The following 3 cases MUST be supported:
  383.                    1. [IP][AH][upper]
  384.                    2. [IP][ESP][upper]
  385.                    3. [IP][AH][ESP][upper]
  386.            o arbitrary nesting is allowed -- Senders MAY generate
  387.              arbitrary nestings of IPsec headers and Receivers SHOULD
  388.              accept arbitrary nestings of IPsec headers.
  389.  
  390.  
  391.  
  392.  
  393. Kent, Atkinson                                                  [Page 7]
  394.  
  395.  
  396. Internet Draft          IP Authentication Header          2 October 1997
  397.  
  398.  
  399.    Tunnel mode AH may be employed in either hosts or security gateways
  400.    (or in so-called "bump-in-the-stack" or "bump-in-the-wire"
  401.    implementations, as defined in the Security Architecture document).
  402.    When AH is implemented in a security gateway (to protect transit
  403.    traffic), tunnel mode must be used.  In tunnel mode, the "inner" IP
  404.    header carries the ultimate source and destination addresses, while
  405.    an "outer" IP header may contain distinct IP addresses, e.g.,
  406.    addresses of security gateways.  In tunnel mode, AH protects the
  407.    entire inner IP packet, including the entire inner IP header. The
  408.    position of AH in tunnel mode, relative to the outer IP header, is
  409.    the same as for AH in transport mode.  The following diagram
  410.    illustrates AH tunnel mode positioning for typical IPv4 and IPv6
  411.    packets.
  412.  
  413.             ------------------------------------------------
  414.       IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
  415.             |(any options)| AH | (any options) |TCP | Data |
  416.             ------------------------------------------------
  417.             |<-- authenticated except for mutable fields ->|
  418.  
  419.             --------------------------------------------------------------
  420.       IPv6  |           | ext hdrs*|    |            | ext hdrs*|   |    |
  421.             |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
  422.             --------------------------------------------------------------
  423.             |<-------- authenticated except for mutable fields --------->|
  424.  
  425.              * = construction of outer IP hdr/extensions and modification
  426.                  of inner IP hdr/extensions is discussed below.
  427.  
  428. 3.2  Authentication Algorithms
  429.  
  430.    The authentication algorithm employed for the ICV computation is
  431.    specified by the SA.  For point-to-point communication, suitable
  432.    authentication algorithms include keyed Message Authentication Codes
  433.    (MACs) based on symmetric encryption algorithms (e.g., DES) or on
  434.    one-way hash functions (e.g., MD5 or SHA-1).  For multicast
  435.    communication, one-way hash algorithms combined with asymmetric
  436.    signature algorithms are appropriate, though performance and space
  437.    considerations currently preclude use of such algorithms.  The
  438.    mandatory-to-implement authentication algorithms are described in
  439.    Section 5 "Conformance Requirements".  Other algorithms MAY be
  440.    supported.  Note: Where an algorithm yields more than 96 bits, the
  441.    output of the computation is truncated to the leftmost 96 bits.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449. Kent, Atkinson                                                  [Page 8]
  450.  
  451.  
  452. Internet Draft          IP Authentication Header          2 October 1997
  453.  
  454.  
  455. 3.3  Outbound Packet Processing
  456.  
  457.    In transport mode, the transmitter inserts the AH header after the IP
  458.    header and before an upper layer protocol header, as described above.
  459.    In tunnel mode, the outer and inner IP header/extensions can be
  460.    inter-related in a variety of ways.  The construction of the outer IP
  461.    header/extensions during the encapsulation process is described in
  462.    the Security Architecture document.
  463.  
  464.    If there is more than one IPsec header/extension required, the order
  465.    of the application of the security headers MUST be defined by
  466.    security policy.  For simplicity of processing, each IPsec header
  467.    SHOULD ignore the existence (i.e., not zero the contents or try to
  468.    predict the contents) of IPsec headers to be applied later.  (While a
  469.    native IP or bump-in-the-stack implementation could predict the
  470.    contents of later IPsec headers that it applies itself, it won't be
  471.    possible for it to predict any IPsec headers added by a bump-in-the-
  472.    wire implementation between the host and the network.)
  473.  
  474.  
  475. 3.3.1  Security Association Lookup
  476.  
  477.    AH is applied to an outbound packet only after an IPsec
  478.    implementation determines that the packet is associated with an SA
  479.    that calls for AH processing.  The process of determining what, if
  480.    any, IPsec processing is applied to outbound traffic is described in
  481.    the Security Architecture document.
  482.  
  483. 3.3.2  Sequence Number Generation
  484.  
  485.    The sender's counter is initialized to 0 when an SA is established.
  486.    The transmitter increments the Sequence Number for this SA and
  487.    inserts the new value into the Sequence Number Field.  Thus the first
  488.    packet sent using a given SA will have a Sequence Number of 1.
  489.  
  490.    If anti-replay has been enabled, the transmitter checks to ensure
  491.    that the counter has not cycled before inserting the new value in the
  492.    Sequence Number field.  In other words, the transmitter MUST not send
  493.    a packet on an SA if doing so would cause the Sequence Number to
  494.    cycle.  An attempt to transmit a packet that would result in Sequence
  495.    Number overflow is an auditable event.  (Note that this approach to
  496.    Sequence Number management does not require use of modular
  497.    arithmetic.)
  498.  
  499.    If anti-replay has not been enabled, the sender does not need to
  500.    monitor or reset the counter, e.g., in the case of manual key
  501.    management.  NOTE: If the receiver does NOT notify the sender that
  502.    anti-replay is enabled, then the sender may overflow the counter and
  503.  
  504.  
  505. Kent, Atkinson                                                  [Page 9]
  506.  
  507.  
  508. Internet Draft          IP Authentication Header          2 October 1997
  509.  
  510.  
  511.    may send packets that the receiver will reject.
  512.  
  513. 3.3.3  Integrity Check Value Calculation
  514.  
  515.    The AH ICV is computed over:
  516.            o IP header fields that are either immutable in transit or that
  517.              are predictable in value upon arrival at the endpoint for the
  518.              AH SA
  519.            o the AH header (Next Header, Payload Len, Reserved, SPI,
  520.              Sequence Number, and the Authentication Data (which is set to
  521.              zero for this computation))
  522.            o the upper level protocol data, which is assumed to be
  523.              immutable in transit
  524.  
  525. 3.3.3.1  Handling Mutable Fields
  526.  
  527.    If a field may be modified during transit, the value of the field is
  528.    set to zero for purposes of the ICV computation.  If a field is
  529.    mutable, but its value at the (IPsec) receiver is predictable, then
  530.    that value is inserted into the field for purposes of the ICV
  531.    calculation.  The Authentication Data field is also set to zero in
  532.    preparation for this computation.  Note that by replacing each
  533.    field's value with zero, rather than omitting the field, alignment is
  534.    preserved for the ICV calculation.  Also, the zero-fill approach
  535.    ensures that the length of the fields that are so handled cannot be
  536.    changed during transit, even though their contents are not explicitly
  537.    covered by the ICV.
  538.  
  539.    As a new extension header or IPv4 option is created, it will be
  540.    defined in its own RFC and SHOULD include (in the Security
  541.    Considerations section) directions for how it should be handled when
  542.    calculating the AH ICV.  If the IPSEC implementation encounters an
  543.    extension header that it does not recognize, it MUST zero the whole
  544.    header except for the Next Header and Hdr Ext Len fields.  The length
  545.    of the extension header MUST be computed by 8 * Hdr Ext Len value +
  546.    8.  If the IPSEC implementation encounters an IPv4 option that it
  547.    does not recognize, it should zero the whole option, using the second
  548.    byte of the option as the length.  (IPv6 options contain a flag
  549.    indicating mutability, which determines appropriate processing for
  550.    such options.)
  551.  
  552. 3.3.3.1.1  ICV Computation for IPv4
  553.  
  554. 3.3.3.1.1.1  Base Header Fields
  555.  
  556.    The IPv4 base header fields are classified as follows:
  557.  
  558.  
  559.  
  560.  
  561. Kent, Atkinson                                                 [Page 10]
  562.  
  563.  
  564. Internet Draft          IP Authentication Header          2 October 1997
  565.  
  566.  
  567.    Immutable
  568.              Version
  569.              Internet Header Length
  570.              Total Length
  571.              Identification
  572.              Protocol
  573.              Source Address
  574.              Destination Address (without loose or strict source routing)
  575.  
  576.    Mutable but predictable
  577.              Destination Address (with loose or strict source routing)
  578.  
  579.    Mutable (zeroed prior to ICV calculation)
  580.              Type of Service (TOS)
  581.              Flags
  582.              Fragment Offset
  583.              Time to Live (TTL)
  584.              Header Checksum
  585.  
  586.       TOS -- This field is excluded because some routers are known to
  587.              change the value of this field, even though the IP specification
  588.              does not consider TOS to be a mutable header field.
  589.  
  590.       Flags -- This field is excluded since an intermediate router might
  591.              set the DF bit, even if the source did not select it.
  592.  
  593.       Fragment Offset -- Since AH is applied only to non-fragmented IP
  594.              packets, the Offset Field must always be zero, and thus it is
  595.              excluded (even though it is predictable).
  596.  
  597.       TTL -- This is changed en-route as a normal course of processing by
  598.              routers, and thus its value at the receiver is not predictable
  599.              by the sender.
  600.  
  601.       Header Checksum -- This will change if any of these other fields
  602.              changes, and thus its value upon reception cannot be predicted
  603.              by the sender.
  604.  
  605. 3.3.3.1.1.2  Options
  606.  
  607.    For IPv4 (unlike IPv6), there is no mechanism for tagging options as
  608.    mutable in transit.  Hence the IPv4 options are explicitly listed in
  609.    Appendix A and classified as immutable, mutable but predictable, or
  610.    mutable.  For IPv4, the entire option is viewed as a unit; so even
  611.    though the type and length fields within most options are immutable
  612.    in transit, if an option is classified as mutable, the entire option
  613.    is zeroed for ICV computation purposes.
  614.  
  615.  
  616.  
  617. Kent, Atkinson                                                 [Page 11]
  618.  
  619.  
  620. Internet Draft          IP Authentication Header          2 October 1997
  621.  
  622.  
  623. 3.3.3.1.2  ICV Computation for IPv6
  624.  
  625. 3.3.3.1.2.1  Base Header Fields
  626.  
  627.    The IPv6 base header fields are classified as follows:
  628.  
  629.    Immutable
  630.              Version
  631.              Payload Length
  632.              Next Header
  633.              Source Address
  634.              Destination Address (without Routing Extension Header)
  635.  
  636.    Mutable but predictable
  637.              Destination Address (with Routing Extension Header)
  638.  
  639.    Mutable (zeroed prior to ICV calculation)
  640.              Priority
  641.              Flow Label
  642.              Hop Limit
  643.  
  644. 3.3.3.1.2.2  Extension Headers -- Options
  645.  
  646.    The IPv6 extension headers (that are options) are explicitly listed
  647.    in Appendix A and classified as immutable, mutable but predictable,
  648.    or mutable.
  649.  
  650.    IPv6 options in the Hop-by-Hop and Destination Extension Headers
  651.    contain a bit that indicates whether the option might change
  652.    (unpredictably) during transit.  For any option for which contents
  653.    may change en-route, the entire "Option Data" field must be treated
  654.    as zero-valued octets when computing or verifying the ICV.  The
  655.    Option Type and Opt Data Len are included in the ICV calculation.
  656.    All options for which the bit indicates immutability are included in
  657.    the ICV calculation.  See the IPv6 specification [DH95] for more
  658.    information.
  659.  
  660. 3.3.3.1.2.3  Extension Headers -- non-Options
  661.  
  662.    The IPv6 extension headers (that are not options) are explicitly
  663.    listed in Appendix A and classified as immutable, mutable but
  664.    predictable, or mutable.
  665.  
  666. 3.3.3.2  Padding
  667.  
  668. 3.3.3.2.1  Authentication Data Padding
  669.  
  670.    As mentioned in section 2.6, the Authentication Data field explicitly
  671.  
  672.  
  673. Kent, Atkinson                                                 [Page 12]
  674.  
  675.  
  676. Internet Draft          IP Authentication Header          2 October 1997
  677.  
  678.  
  679.    includes padding to ensure that the AH header is a multiple of 32
  680.    bits (IPv4) or 64 bits (IPv6).  If padding is required, its length is
  681.    determined by two factors:
  682.  
  683.              - the length of the ICV
  684.              - the IP protocol version (v4 or v6)
  685.  
  686.    For example, if the output of the selected algorithm is 96-bits, no
  687.    padding is required for either IPv4 or for IPv6.  However, if a
  688.    different length ICV is generated, due to use of a different
  689.    algorithm, then padding may be required for the IPv6 environment.
  690.    The content of the padding field is arbitrarily selected by the
  691.    sender.  (The padding is arbitrary, but need not be random to achieve
  692.    security.)  These padding bytes are included in the Authentication
  693.    Data calculation, counted as part of the Payload Length, and
  694.    transmitted at the end of the Authentication Data field to enable the
  695.    receiver to perform the ICV calculation.
  696.  
  697. 3.3.3.2.2  Implicit Packet Padding
  698.  
  699.    For some authentication algorithms, the byte string over which the
  700.    ICV computation is performed must be a multiple of a blocksize
  701.    specified by the algorithm.  If the IP packet length (including AH)
  702.    does not match the blocksize requirements for the algorithm, implicit
  703.    padding MUST be appended to the end of the packet, prior to ICV
  704.    computation.  The padding octets MUST have a value of zero.  The
  705.    blocksize (and hence the length of the padding) is specified by the
  706.    algorithm specification.  This padding is not transmitted with the
  707.    packet.
  708.  
  709. 3.3.4  Fragmentation
  710.  
  711.    If required, IP fragmentation occurs after AH processing within an
  712.    IPsec implementation.  Thus, transport mode AH is applied only to
  713.    whole IP datagrams (not to IP fragments).  An IP packet to which AH
  714.    has been applied may itself be fragmented by routers en route, and
  715.    such fragments must be reassembled prior to AH processing at a
  716.    receiver.  In tunnel mode, AH is applied to an IP packet, the payload
  717.    of which may be a fragmented IP packet.  For example, a security
  718.    gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
  719.    implementation (see the Security Architecture document for details)
  720.    may apply tunnel mode AH to such fragments.
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729. Kent, Atkinson                                                 [Page 13]
  730.  
  731.  
  732. Internet Draft          IP Authentication Header          2 October 1997
  733.  
  734.  
  735. 3.4  Inbound Packet Processing
  736.  
  737.    If there is more than one IPsec header/extension present, the
  738.    processing for each one ignores (does not zero, does not use) any
  739.    IPsec headers applied subsequent to the header being processed.
  740.  
  741.  
  742. 3.4.1  Reassembly
  743.  
  744.    If required, reassembly is performed prior to AH processing.  If a
  745.    packet offered to AH for processing appears to be an IP fragment,
  746.    i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
  747.    the receiver MUST discard the packet; this is an auditable event. The
  748.    audit log entry for this event SHOULD include the SPI value,
  749.    date/time, Source Address, Destination Address, and (in IPv6) the
  750.    Flow ID.
  751.  
  752. 3.4.2  Security Association Lookup
  753.  
  754.    Upon receipt of a packet containing an IP Authentication Header, the
  755.    receiver determines the appropriate (unidirectional) SA, based on the
  756.    destination IP address, security protocol (AH),and the SPI.  (This
  757.    process is described in more detail in the Security Architecture
  758.    document.)  The SA indicates whether the Sequence Number field will
  759.    be checked, specifies the algorithm(s) employed for ICV computation,
  760.    and indicates the key(s) required to validate the ICV.
  761.  
  762.    If no valid Security Association exists for this session (e.g., the
  763.    receiver has no key), the receiver MUST discard the packet; this is
  764.    an auditable event.  The audit log entry for this event SHOULD
  765.    include the SPI value, date/time, Source Address, Destination
  766.    Address, and (in IPv6) the Flow ID.
  767.  
  768. 3.4.3  Sequence Number Verification
  769.  
  770.    All AH implementations MUST support the anti-replay service, though
  771.    its use may be enabled or disabled on a per-SA basis.  (Note that
  772.    there are no provisions for managing transmitted Sequence Number
  773.    values among multiple senders directing traffic to a single,
  774.    multicast SA.  Thus the anti-replay service SHOULD NOT be used in a
  775.    multi-sender multicast environment that employs a single, multicast
  776.    SA.)
  777.  
  778.    If the receiver does not enable anti-replay for an SA, no checks are
  779.    performed on the inbound Sequence Number.  If an SA establishment
  780.    protocol such as Oakley/ISAKMP is employed, then the receiver SHOULD
  781.    notify the transmitter, during SA establishment, if the receiver will
  782.    provide anti-replay protection.
  783.  
  784.  
  785. Kent, Atkinson                                                 [Page 14]
  786.  
  787.  
  788. Internet Draft          IP Authentication Header          2 October 1997
  789.  
  790.  
  791.    If the receiver has enabled the anti-replay service for this SA, the
  792.    receiver packet counter for the SA MUST be initialized to zero when
  793.    the SA is established.  For each received packet, the receiver MUST
  794.    verify that the packet contains a Sequence Number that does not
  795.    duplicate the Sequence Number of any other packets received during
  796.    the life of this SA.  This SHOULD be the first AH check applied to a
  797.    packet after it has been matched to an SA, to speed rejection of
  798.    duplicate packets.
  799.  
  800.    Duplicates are rejected through the use of a sliding receive window.
  801.    (How the window is implemented is a local matter, but the following
  802.    text describes the functionality that the implementation must
  803.    exhibit.)  A MINIMUM window size of 32 MUST be supported; but a
  804.    window size of 64 is preferred and SHOULD be employed as the default.
  805.    Another window size (larger than the MINIMUM) MAY be chosen by the
  806.    receiver.  (The receiver does NOT notify the sender of the window
  807.    size.)
  808.  
  809.    The "right" edge of the window represents the highest, validated
  810.    Sequence Number value received on this SA.  Packets that contain
  811.    Sequence Numbers lower than the "left" edge of the window are
  812.    rejected.  Packets falling within the window are checked against a
  813.    list of received packets within the window.  An efficient means for
  814.    performing this check, based on the use of a bit mask, is described
  815.    in the Security Architecture document.
  816.  
  817.    If the received packet falls within the window and is new, or if the
  818.    packet is to the right of the window, then the receiver proceeds to
  819.    ICV verification.  If the ICV validation fails, the receiver MUST
  820.    discard the received IP datagram as invalid; this is an auditable
  821.    event.  The audit log entry for this event SHOULD include the SPI
  822.    value, date/time, Source Address, Destination Address, the Sequence
  823.    Number, and (in IPv6) the Flow ID.  The receive window is updated
  824.    only if the ICV verification succeeds.
  825.  
  826.    DISCUSSION:
  827.  
  828.       Note that if the packet is either inside the window and new, or is
  829.       outside the window on the "right" side, the receiver MUST
  830.       authenticate the packet before updating the Sequence Number window
  831.       data.
  832.  
  833. 3.4.4  Integrity Check Value Verification
  834.  
  835.    The receiver computes the ICV over the appropriate fields of the
  836.    packet, using the specified authentication algorithm, and verifies
  837.    that it is the same as the ICV included in the Authentication Data
  838.    field of the packet.  Details of the computation are provided below.
  839.  
  840.  
  841. Kent, Atkinson                                                 [Page 15]
  842.  
  843.  
  844. Internet Draft          IP Authentication Header          2 October 1997
  845.  
  846.  
  847.    If the computed and received ICV's match, then the datagram is valid,
  848.    and it is accepted.  If the test fails, then the receiver MUST
  849.    discard the received IP datagram as invalid; this is an auditable
  850.    event.  The audit log entry SHOULD include the SPI value, date/time
  851.    received, Source Address, Destination Address, and (in IPv6) the Flow
  852.    ID.
  853.  
  854.    DISCUSSION:
  855.  
  856.       Begin by saving the ICV value and replacing it (but not any
  857.       Authentication Data padding) with zero.  Zero all other fields
  858.       that may have been modified during transit.  (See section 3.3.3.1
  859.       for a discussion of which fields are zeroed before performing the
  860.       ICV calculation.)  Check the overall length of the packet, and if
  861.       it requires implicit padding based on the requirements of the
  862.       authentication algorithm, append zero-filled bytes to the end of
  863.       the packet as required.  Now perform the ICV computation and
  864.       compare the result with the saved value.  Note that if the output
  865.       of the authentication algorithm is greater than 96 bits, the
  866.       output should be truncated to the leftmost 96 bits.  (If a digital
  867.       signature and one-way hash are used for the ICV computation, the
  868.       matching process is more complex and will be described in the
  869.       algorithm specification.)
  870.  
  871.  
  872. 4.  Auditing
  873.  
  874.    Not all systems that implement AH will implement auditing.  However,
  875.    if AH is incorporated into a system that supports auditing, then the
  876.    AH implementation MUST also support auditing and MUST allow a system
  877.    administrator to enable or disable auditing for AH.  For the most
  878.    part, the granularity of auditing is a local matter.  However,
  879.    several auditable events are identified in this specification and for
  880.    each of these events a minimum set of information that SHOULD be
  881.    included in an audit log is defined.  Additional information also MAY
  882.    be included in the audit log for each of these events, and additional
  883.    events, not explicitly called out in this specification, also MAY
  884.    result in audit log entries.  There is no requirement for the
  885.    receiver to transmit any message to the purported transmitter in
  886.    response to the detection of an auditable event, because of the
  887.    potential to induce denial of service via such action.
  888.  
  889. 5.  Conformance Requirements
  890.  
  891.    Implementations that claim conformance or compliance with this
  892.    specification MUST fully implement the AH syntax and processing
  893.    described here and MUST comply with all requirements of the Security
  894.    Architecture document.  If the key used to compute an ICV is manually
  895.  
  896.  
  897. Kent, Atkinson                                                 [Page 16]
  898.  
  899.  
  900. Internet Draft          IP Authentication Header          2 October 1997
  901.  
  902.  
  903.    distributed, correct provision of the anti-replay service would
  904.    require correct maintenance of the counter state at the transmitter,
  905.    until the key is replaced, and there likely would be no automated
  906.    recovery provision if counter overflow were imminent.  Thus a
  907.    compliant implementation SHOULD NOT provide this service in
  908.    conjunction with SAs that are manually keyed.  A compliant AH
  909.    implementation MUST support the following mandatory-to-implement
  910.    algorithms:
  911.  
  912.              - HMAC with MD5 [MG97a]
  913.              - HMAC with SHA-1 [MG97b]
  914.  
  915. 6.  Security Considerations
  916.  
  917.    Security is central to the design of this protocol, and these
  918.    security considerations permeate the specification.  Additional
  919.    security-relevant aspects of using the IPsec protocol are discussed
  920.    in the Security Architecture document.
  921.  
  922.  
  923. 7.  Differences from RFC 1826
  924.  
  925.    This specification of AH differs from RFC 1826 [ATK95] in several
  926.    important respects, but the fundamental features of AH remain intact.
  927.    One goal of the revision of RFC 1826 was to provide a complete
  928.    framework for AH, with ancillary RFCs required only for algorithm
  929.    specification.  For example, the anti-replay service is now an
  930.    integral, mandatory part of AH, not a feature of a transform defined
  931.    in another RFC.  Carriage of a sequence number to support this
  932.    service is now required at all times.  The default algorithms
  933.    required for interoperability have been changed to HMAC with MD5 or
  934.    SHA-1 (vs. keyed MD5), for security reasons.  The list of IPv4 header
  935.    fields excluded from the ICV computation has been expanded to include
  936.    the OFFSET and FLAGS fields.
  937.  
  938.    Another motivation for revision was to provide additional detail and
  939.    clarification of subtle points.  This specification provides
  940.    rationale for exclusion of selected IPv4 header fields from AH
  941.    coverage and provides examples on positioning of AH in both the IPv4
  942.    and v6 contexts.  Auditing requirements have been clarified in this
  943.    version of the specification.  Tunnel mode AH was mentioned only in
  944.    passing in RFC 1826, but now is a mandatory feature of AH.
  945.    Discussion of interactions with key management and with security
  946.    labels have been moved to the Security Architecture document.
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953. Kent, Atkinson                                                 [Page 17]
  954.  
  955.  
  956. Internet Draft          IP Authentication Header          2 October 1997
  957.  
  958.  
  959. Acknowledgements
  960.  
  961.    For over 2 years, this document has evolved through multiple versions
  962.    and iterations.  During this time, many people have contributed
  963.    significant ideas and energy to the process and the documents
  964.    themselves.  The authors would like to thank Karen Seo for providing
  965.    extensive help in the review, editing, background research, and
  966.    coordination for this version of the specification.  The authors
  967.    would also like to thank the members of the IPsec and IPng working
  968.    groups, with special mention of the efforts of (in alphabetic order):
  969.    Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank
  970.    Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman
  971.    Shulman, William Simpson, and Nina Yuan.
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009. Kent, Atkinson                                                 [Page 18]
  1010.  
  1011.  
  1012. Internet Draft          IP Authentication Header          2 October 1997
  1013.  
  1014.  
  1015. Appendix A -- Mutability of IP Options/Extension Headers
  1016.  
  1017. A1.  IPv4 Options
  1018.  
  1019.    This table shows how the IPv4 options are classified with regard to
  1020.    "mutability".  Where two references are provided, the second one
  1021.    supercedes the first.  This table is based in part on information
  1022.    provided in RFC1700, "ASSIGNED NUMBERS", (October 1994).
  1023.  
  1024.                  Opt.
  1025.       Copy Class  #   Name                       Reference
  1026.       ---- ----- ---  -------------------------  ---------
  1027.       IMMUTABLE -- included in ICV calculation
  1028.         0   0     0   End of Options List        [RFC791]
  1029.         0   0     1   No Operation               [RFC791]
  1030.         1   0     2   Security                   [RFC1108(historic but in use)]
  1031.         1   0     5   Extended Security          [RFC1108(historic but in use)]
  1032.         1   0     6   Commercial Security        [expired I-D, now US MIL STD]
  1033.         1   0    20   Router Alert               [RFC2113]
  1034.         1   0    21   Sender Directed Multi-     [RFC1770]
  1035.                       Destination Delivery
  1036.       MUTABLE -- zeroed
  1037.         1   0      3  Loose Source Route         [RFC791]
  1038.         0   2      4  Time Stamp                 [RFC791]
  1039.         0   0      7  Record Route               [RFC791]
  1040.         1   0      9  Strict Source Route        [RFC791]
  1041.         0   2     18  Traceroute                 [RFC1393]
  1042.  
  1043.       EXPERIMENTAL, SUPERCEDED -- zeroed
  1044.         1   0      8  Stream ID                  [RFC791, RFC1122 (Host Req)]
  1045.         0   0     11  MTU Probe                  [RFC1063, RFC1191 (PMTU)]
  1046.         0   0     12  MTU Reply                  [RFC1063, RFC1191 (PMTU)]
  1047.         1   0     17  Extended Internet Protocol [RFC1385, RFC1883 (IPv6)]
  1048.         0   0     10  Experimental Measurement   [ZSu]
  1049.         1   2     13  Experimental Flow Control  [Finn]
  1050.         1   0     14  Experimental Access Ctl    [Estrin]
  1051.         0   0     15  ???                        [VerSteeg]
  1052.         1   0     16  IMI Traffic Descriptor     [Lee]
  1053.         1   0     19  Address Extension          [Ullmann IPv7]
  1054.  
  1055.  
  1056.    NOTE: Use of the Router Alert option is potentially incompatible with
  1057.    use of IPSEC.  Although the option is immutable, its use implies that
  1058.    each router along a packet's path will "process" the packet and
  1059.    consequently might change the packet.  This would happen on a hop by
  1060.    hop basis as the packet goes from router to router.  Prior to being
  1061.    processed by the application to which the option contents are
  1062.    directed, e.g., RSVP/IGMP, the packet should encounter AH processing.
  1063.  
  1064.  
  1065. Kent, Atkinson                                                 [Page 19]
  1066.  
  1067.  
  1068. Internet Draft          IP Authentication Header          2 October 1997
  1069.  
  1070.  
  1071.    However, AH processing would require that each router along the path
  1072.    is a member of a multicast-SA defined by the SPI.  This might pose
  1073.    problems for packets that are not strictly source routed, and it
  1074.    requires multicast support techniques not currently available.
  1075.  
  1076.    NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by
  1077.    systems along a packet's path conflicts with the classification of
  1078.    these IP Options as immutable and is incompatible with the use of
  1079.    IPSEC.
  1080.  
  1081. A2.  IPv6 Extension Headers
  1082.  
  1083.    This table shows how the IPv6 Extension Headers are classified with
  1084.    regard to "mutability".
  1085.  
  1086.       Option/Extension Name                  Reference
  1087.       -----------------------------------    ---------
  1088.       MUTABLE BUT PREDICTABLE -- included in ICV calculation
  1089.         Routing (Type 0)                    [RFC1883]
  1090.  
  1091.       BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT)
  1092.         Hop by Hop options                  [RFC1883]
  1093.         Destination options                 [RFC1883]
  1094.  
  1095.       NOT APPLICABLE
  1096.         Fragmentation                       [RFC1883]
  1097.  
  1098.       Options -- IPv6 options in the Hop-by-Hop and Destination Extension
  1099.              Headers contain a bit that indicates whether the option might
  1100.              change (unpredictably) during transit.  For any option for which
  1101.              contents may change en-route, the entire "Option Data" field
  1102.              must be treated as zero-valued octets when computing or
  1103.              verifying the ICV.  The Option Type and Opt Data Len are
  1104.              included in the ICV calculation.  All options for which the bit
  1105.              indicates immutability are included in the ICV calculation.  See
  1106.              the IPv6 specification [DH95] for more information.
  1107.  
  1108.       Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange
  1109.              the address fields within the packet during transit from source
  1110.              to destination.  However, the contents of the packet as it will
  1111.              appear at the receiver are known to the sender and to all
  1112.              intermediate hops.  Hence, the IPv6 Routing Header "Type 0" is
  1113.              included in the Authentication Data calculation as mutable but
  1114.              predictable.  The transmitter must order the field so that it
  1115.              appears as it will at the receiver, prior to performing the ICV
  1116.              computation.
  1117.  
  1118.       Fragmentation -- Fragmentation occurs after outbound IPSEC processing
  1119.  
  1120.  
  1121. Kent, Atkinson                                                 [Page 20]
  1122.  
  1123.  
  1124. Internet Draft          IP Authentication Header          2 October 1997
  1125.  
  1126.  
  1127.              (section 3.3) and reassembly occurs before inbound IPSEC
  1128.              processing (section 3.4).  So the Fragmentation Extension
  1129.              Header, if it exists, is not seen by IPSEC.
  1130.  
  1131.              Note that on the receive side, the IP implementation could leave
  1132.              a Fragmentation Extension Header in place when it does
  1133.              re-assembly.  If this happens, then when AH receives the packet,
  1134.              before doing ICV processing, AH MUST "remove" (or skip over)
  1135.              this header and change the previous header's "Next Header" field
  1136.              to be the "Next Header" field in the Fragmentation Extension
  1137.              Header.
  1138.  
  1139.              Note that on the send side, the IP implementation could give the
  1140.              IPSEC code a packet with a Fragmentation Extension Header with
  1141.              Offset of 0 (first fragment) and a More Fragments Flag of 0
  1142.              (last fragment).  If this happens, then before doing ICV
  1143.              processing, AH MUST first "remove" (or skip over) this header
  1144.              and change the previous header's "Next Header" field to be the
  1145.              "Next Header" field in the Fragmentation Extension Header.
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177. Kent, Atkinson                                                 [Page 21]
  1178.  
  1179.  
  1180. Internet Draft          IP Authentication Header          2 October 1997
  1181.  
  1182.  
  1183. References
  1184.  
  1185.    [ATK95]   R. Atkinson, "The IP Authentication Header," RFC 1826,
  1186.              August 1995.
  1187.  
  1188.    [BCCH94]  R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of
  1189.              IAB Workshop on Security in the Internet Architecture",
  1190.              RFC-1636, 9 June 1994, pp. 21-34.
  1191.  
  1192.    [Bel89]   Steven M. Bellovin, "Security Problems in the TCP/IP
  1193.              Protocol Suite", ACM Computer Communications Review, Vol.
  1194.              19, No. 2, March 1989.
  1195.  
  1196.    [CER95]   Computer Emergency Response Team (CERT), "IP Spoofing
  1197.              Attacks and Hijacked Terminal Connections", CA-95:01,
  1198.              January 1995. Available via anonymous ftp from
  1199.              info.cert.org in /pub/cert_advisories.
  1200.  
  1201.    [DH95]    Steve Deering & Bob Hinden, "Internet Protocol version 6
  1202.              (IPv6) Specification", RFC-1883, December 1995.
  1203.  
  1204.    [GM93]    James Galvin & Keith McCloghrie, Security Protocols for
  1205.              version 2 of the Simple Network Management Protocol
  1206.              (SNMPv2), RFC-1446, April 1993.
  1207.  
  1208.    [KA97a]   Steve Kent, Randall Atkinson, "Security Architecture for
  1209.              the Internet Protocol", Internet Draft, ?? 1997.
  1210.  
  1211.    [KA97b]   Steve Kent, Randall Atkinson, "IP Encapsulating Security
  1212.              Payload (ESP)", Internet Draft, ?? 1997.
  1213.  
  1214.    [KA97c]   Steve Kent, Randall Atkinson, "IP Authentication Header",
  1215.              Internet Draft, ?? 1997.
  1216.  
  1217.    [Ken91]   Steve Kent, "US DoD Security Options for the Internet
  1218.              Protocol", RFC-1108, November 1991.
  1219.  
  1220.    [MG97a]   C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP
  1221.              and AH", Internet Draft, 7/2/97.
  1222.  
  1223.    [MG97b]   C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
  1224.              and AH", Internet Draft, 7/2/97.
  1225.  
  1226.    [Riv92]   Ronald Rivest, "The MD5 Message Digest Algorithm," RFC-
  1227.              1321, April 1992.
  1228.  
  1229.    [SHA]     NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995
  1230.  
  1231.  
  1232.  
  1233. Kent, Atkinson                                                 [Page 22]
  1234.  
  1235.  
  1236. Internet Draft          IP Authentication Header          2 October 1997
  1237.  
  1238.  
  1239.    [STD-1]   J. Postel, "Internet Official Protocol Standards", STD-1,
  1240.              March 1996.
  1241.  
  1242.    [STD-2]   J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20
  1243.              October 1994.
  1244.  
  1245.  
  1246. Disclaimer
  1247.  
  1248.    The views and specification here are those of the authors and are not
  1249.    necessarily those of their employers.  The authors and their
  1250.    employers specifically disclaim responsibility for any problems
  1251.    arising from correct or incorrect implementation or use of this
  1252.    specification.
  1253.  
  1254.  
  1255.  
  1256. Author Information
  1257.  
  1258.    Stephen Kent
  1259.    BBN Corporation
  1260.    70 Fawcett Street
  1261.    Cambridge, MA  02140
  1262.    USA
  1263.    E-mail: kent@bbn.com
  1264.    Telephone: +1 (617) 873-3988
  1265.  
  1266.    Randall Atkinson
  1267.    @Home Network
  1268.    425 Broadway,
  1269.    Redwood City, CA  94063
  1270.    USA
  1271.    E-mail: rja@inet.org
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289. Kent, Atkinson                                                 [Page 23]
  1290.