[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AH/ESP loose ends



Folks,

Here are some additional issues/edits based on feedback from the
community since our June 6 email on "AH/ESP edits".  Please let us know
your opinions on the open issues below by Friday the 20th (6/20/97).

Thank you,
Karen


OPEN ISSUES
-----------
1. In a private message, someone raised the concern that some routers
   may move and/or insert IP options, e.g., for 4-byte alignment.  If
   so, this would conflict with the use of AH.  Can anyone confirm or
   deny this rumor?

2. Re: defining how to handle mutable/immutable IPv4 and IPv6 fields for
   the purpose of AH ICV calculation... We received feedback requesting
   clarification on how to handle IPv4 options that aren't explicitly
   listed in the text.  We were thinking of including the table below
   (along with similar information for IPv6 options and extension
   headers) in an Appendix to the AH document.  We view creating a
   separate document as the cleanest approach, as it best accommodates
   the creating of new options/extension headers, but realize that it
   might further delay the process and so we offer the appendix solution
   as a compromise.  In any case we believe that an explicit listing of
   options (and extensions for IPv6) is needed to avoid confusion.
  
   We've included below the rewritten section 3.2.3, "Integrity Check
   Value Calculation", which explicitly categorizes the IP base header
   fields into immutable, mutable but predictable, and mutable.  We have
   then included the Appendix proposed above under "Open Issues" that
   lists the IPv4 Options and IPv6 Options and Extension Headers.


ESP
---
1. In section 2.4, "Padding (for Encryption)" -- some concerns were
   expressed about whether this section clearly describes how to
   determine the padding values (a default that can be overridden by the
   algorithm in its RFC) and that this field can be used for traffic
   flow confidentiality padding even when the algorithm does not impose
   a padding requirement.  This section now reads:

   2.4  Padding (for Encryption)

   If an encryption algorithm is employed that requires the plaintext to
   be a multiple of some number of bytes, e.g., the block size of a
   block cipher, the Padding field is used to fill the plaintext
   (consisting of the Payload Data, Pad Length and Next Header fields,
   as well as the Padding) to the size required by the algorithm.

   As a default, the Padding bytes SHOULD be initialized with random
   data and they are transmitted.  The transmitter can add 0-255 bytes
   of padding.  Any encryption algorithm used with ESP that requires a
   padding value other than the default value MUST define its padding
   requirements in an RFC specifying how the algorithm is used with ESP.
   The content of the Padding field will thus be determined by the
   encryption algorithm and mode selected and defined in the
   corresponding algorithm RFC.

   Padding also may be required, irrespective of algorithm requirements,
   to ensure that the resulting ciphertext terminates on a 4-byte
   boundary, i.e., the Pad Length and Next Header fields must be right
   aligned within a 4-byte word, as illustrated in the ESP packet format
   figure.

   Finally, padding beyond that required for the algorithm or alignment
   reasons cited above, may be used to conceal the actual length of the
   payload, in support of (partial) traffic flow confidentiality.
   However, inclusion of such additional padding has adverse bandwidth
   implications and thus its use should be undertaken with care.  The
   Padding field is optional, but all implementations MUST support
   generation and consumption of padding.

2. In section 2.3, "Payload Data", changed the sentence "If the
   algorithm used to encrypt the payload requires cryptographic
   synchronization data, e.g., an IV..." to "If the algorithm used to
   encrypt the payload requires cryptographic synchronization data,
   e.g., an Initialization Vector (IV)..."

3. In section 2, "Encapsulating Security Payload Packet Format", added a
   footnote to the diagram that says, "If included in the Payload field,
   cryptographic synchronization data, e.g., an IV, usually is not
   encrypted per se, although it often is referred to as being part of
   the ciphertext."


AH
--
1. In section 3.2.3, "Integrity Check Value Calculation", clarified that
   for Loose and Strict Source Routing (IPv4 and IPv6), the destination
   address is mutable but predictable.  

2. Re: router alert option -- It should be noted that if this option is
   used, the option is immutable, but it means that each router will
   "process" the packet, i.e., might change the packet.  This would
   happen on a hop by hop basis as the packet goes from router to
   router.  But in order to reach the higher layer that's doing the
   processing, e.g., RSVP/IGMP, the packet has to go through IPSEC
   processing first.  But the routers along the way won't have an SA
   with an SPI for this packet (just the endpoint of the SA will have
   this information).  So IPSEC might not be appropriate for users of
   this option.  We propose to call the option immutable, insert a note
   to the reader warning about this problem.

3. In section 3.2.3, Integrity Check Value Calculation, we've rewritten
   this text to explicitly categorize the IP header fields into
   immutable, mutable but predictable, and mutable (see below).  We have
   then included the Appendix proposed above under "Open Issues".

4. In section 3.2.3.1, we've clarified that "...the zero-fill approach
   ensures that the length of the fields that are so handled cannot be
   changed during transit, even though their contents are not explicitly
   covered by the ICV."


----------------------------------------------------------------------------
   As mentioned under "Open Issues" above, we've appended below the
   rewritten section 3.2.3, "Integrity Check Value Calculation", which
   explicitly categorizes the IP base header fields into immutable,
   mutable but predictable, and mutable.  We have then included the
   Appendix proposed above under "Open Issues" that lists the IPv4
   Options and IPv6 Options and Extension Headers.

3.2.3  Integrity Check Value Calculation

3.2.3.1  Handling Mutable Fields

The AH ICV is computed over IP header fields that are either immutable
in transit or that are predictable in value upon arrival at the endpoint
for the AH SA.  The ICV also encompasses the upper level protocol data,
which is assumed to be immutable in transit.  If a field is modified
during transit, the value of the field is set to zero for purposes of
the ICV computation.  If a field is mutable, but its value at the
(IPsec) receiver is predictable, then that value is inserted into the
field for purposes of the ICV calculation.  The Authentication Data
field also is set to zero in preparation for this computation.  Note
that by replacing each field's value with zero, rather than omitting the
field, alignment is preserved for the ICV calculation.  Also, the
zero-fill approach ensures that the length of the fields that are so
handled cannot be changed during transit, even though their contents are
not explicitly covered by the ICV.

3.2.3.1.1  ICV Computation for IPv4

3.2.3.1.1.1 Base Header Fields

The IPv4 base header fields are classified as follows:
	
Immutable
	Version				
	Internet Header Length 
	Total Length
	Identification
	Protocol
	Source Address		
	Destination Address (without loose or strict source routing)

Mutable but predictable 
	Destination Address (with loose or strict source routing)

Mutable (zeroed prior to ICV calculation)
	Type of Service (TOS)
	Flags
	Fragment Offset
	Time to Live (TTL)
	Header Checksum

   TOS -- This field is excluded because some routers are known to
	change the value of this field, even though the IP specification
	does not consider TOS to be a mutable header field.

   Flags -- This field is excluded since an intermediate router might
	set the DF bit, even if the source did not select it.

   Fragment Offset -- Since AH is applied only to non-fragmented IP
	packets, the Offset Field must always be zero, and thus it is
	excluded (even though it is predictable).  

   TTL -- This is changed en-route as a normal course of processing by
	routers, and thus its value at the receiver is not predictable
	by the sender.

   Header Checksum -- This will change if any of these other fields
	changes, and thus its value upon reception cannot be predicted
	by the sender.

3.2.3.1.1.2 Options

For IPv4 (unlike IPv6), there is no mechanism for tagging options as
mutable in transit.  Hence the IPv4 options are explicitly listed in
Appendix A and classified as immutable, mutable but predictable, or
mutable.  For IPv4, the entire option is viewed as a unit; so even
though the type and length fields within most options are immutable in
transit, if an option is classified as mutable, the entire option is
zeroed for ICV computation purposes.

3.2.3.1.2  ICV Computation for IPv6

3.2.3.1.2.1 Base Header Fields

The IPv6 base header fields are classified as follows:
	
Immutable
	Version				
	Payload Length
	Next Header
	Source Address		
	Destination Address (without Routing Extension Header)

Mutable but predictable
	Destination Address (with Routing Extension Header)

Mutable (zeroed prior to ICV calculation)
	Priority
	Flow Label
	Hop Limit

3.2.3.1.2.2 Extension Headers -- Options

The IPv6 extension headers (that are options) are explicitly listed in
Appendix A and classified as immutable, mutable but predictable, or
mutable.  

IPv6 options in the Hop-by-Hop and Destination Extension Headers contain
a bit that indicates whether the option might change (unpredictably)
during transit.  For any option for which contents may change en-route,
the entire "Option Data" field must be treated as zero-valued octets
when computing or verifying the ICV.  The Option Type and Opt Data Len
are included in the ICV calculation.  All options for which the bit
indicates immutability are included in the ICV calculation.  See the
IPv6 specification [DH95] for more information.


3.2.3.1.2.3 Extension Headers -- non-Options

The IPv6 extension headers (that are not options) are explicitly listed
in Appendix A and classified as immutable, mutable but predictable, or
mutable.


----------------------------------------------------------------------------

Appendix A

1. IPv4 Options

   This table shows how the IPv4 options are classified with regard to
   "mutability".  Where two references are provided, the second one
   supercedes the first.  This table is based in part on information
   provided in RFC1700, "ASSIGNED NUMBERS", (October 1994).

              Option
   Copy Class Number Name                        Reference
   ---- ----- ------ ----------------------      ---------
   IMMUTABLE -- included in ICV calculation
     0     0      0  End of Options List         [RFC791]
     0     0      1  No Operation                [RFC791]
     1     0      2  Security                    [RFC1108(historic but in use)]
     1     0      5  Extended Security           [RFC1108(historic but in use)]
     1     0      6  Commercial Security         [expired I-D, now US MIL STD]
     1     0     20  Router Alert                [RFC2113]
     1     0     21  Sender Directed Multi-      [RFC1770]
                     Destination Delivery
   MUTABLE -- zeroed
     1     0      3  Loose Source Route          [RFC791]
     0     2      4  Time Stamp                  [RFC791]
     0     0      7  Record Route                [RFC791]
     1     0      9  Strict Source Route         [RFC791]
     0     2     18  Traceroute                  [RFC1393]

   EXPERIMENTAL, SUPERCEDED -- zeroed
     1     0      8  Stream ID                   [RFC791, RFC1122 (Host Req)]
     0     0     11  MTU Probe                   [RFC1063, RFC1191 (PMTU)]
     0     0     12  MTU Reply                   [RFC1063, RFC1191 (PMTU)]
     1     0     17  Extended Internet Protocol  [RFC1385, RFC1883 (IPv6)]
     0     0     10  Experimental Measurement    [ZSu]
     1     2     13  Experimental Flow Control   [Finn]
     1     0     14  Experimental Access Control [Estrin]
     0     0     15  ???                         [VerSteeg]
     1     0     16  IMI Traffic Descriptor      [Lee]
     1     0     19  Address Extension           [Ullmann IPv7]


2. IPv6 Extension Headers

	     Option/Extension Name	Reference
             ---------------------	---------
   MUTABLE BUT PREDICTABLE
	     Routing (Type 0)		 [RFC1883]

   BIT INDICATING IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT)
	     Hop by Hop options		 [RFC1883]
	     Destination options	 [RFC1883]

   NOT APPLICABLE		   
	     Fragmentation		 [RFC1883]


   Options -- IPv6 options in the Hop-by-Hop and Destination Extension
	Headers contain a bit that indicates whether the option might
	change (unpredictably) during transit.  For any option for which
	contents may change en-route, the entire "Option Data" field
	must be treated as zero-valued octets when computing or
	verifying the ICV.  The Option Type and Opt Data Len are
	included in the ICV calculation.  All options for which the bit
	indicates immutability are included in the ICV calculation.  See
	the IPv6 specification [DH95] for more information.

   Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange
	the address fields within the packet during transit from source
	to destination.  However, the contents of the packet as it will
	appear at the receiver are known to the sender and to all
	intermediate hops.  Hence, the IPv6 Routing Header "Type 0" is
	included in the Authentication Data calculation as mutable but
	predictable.  The transmitter must order the field so that it
	appears as it will at the receiver, prior to performing the ICV
	computation.

   Fragmentation -- Fragmentation occurs after outbound IPSEC processing
	(section 3.2.4) and reassembly occurs before inbound IPSEC
	processing (section 3.3.1).  So the Fragmentation Extension
	Header, if it exists, is not seen by IPSEC.



Follow-Ups: