[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: