[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPsec AH and ESP drafts
Folks,
Here's a summary of IPsec AH and ESP edits/questions. This is based on
the drafts distributed in 11/97 and subsequent email (up until 1/31). It
does not include minor edits (typos), the addition of the new copyright
text required by the RFC format instructions, updating of the reference
section, etc. The issues have been divided into 3 groups:
AH-ONLY
ESP-ONLY
AH AND ESP
We have submitted the AH and ESP drafts to the IETF secretariat for
distribution. Per direction from the working group chairs, we are also
sending copies directly to the list to get them into folks' hands as
soon as possible.
Thank you for all the feedback/help both on the list and in private
email.
Karen
AH-ONLY
============================================================================
===
1. Per email from Dave Mason (12/29-30) -- For IPv4, need to discuss how
to handle the bytes of IP header after the last option. RFC 791 (IP)
and RFC 1122 (Host Requirements) specify only that an "End of Options
List" option is placed after the last option. "This might not
coincide with the end of the internet header according to the
internet header length.... and need only be used if the end of the
options would not otherwise coincide with the end of the internet
header." They do not say to insert "End of Options List" options
until the IP header is 4-byte aligned or up to the end of the IP
header.
*Changed AH Appendix A.1 IPv4 Options -- added the following note
at the end of the table.
End of Options List options SHOULD be repeated as
necessary to ensure that the IP header ends on a 4 byte
boundary in order to ensure that there are no
unspecified bytes which could be used for a covert
channel.
ESP-ONLY
============================================================================
===
1. Section 3.1 -- Per summary from IPsec document reading party, "3.1
Say that tunnel mode *MUST* be used."
* Sorry, but could someone provide more context? There are
several places where this statement might apply.
2. Section 3.3.3 Sequence Number Generation -- Add pointer to Section
5 to provide explanation for comment on manual key management.
* Changed last paragraph of this section from:
If anti-replay has been disabled, the sender does not
need to monitor or reset the counter, e.g., in the case
of manual key management.
to:
If anti-replay has been disabled, the sender does not
need to monitor or reset the counter, e.g., in the case
of manual key management (see Section 5).
3. Section 3.3.5 -- Per summary from IPsec document reading party,
"3.3.5 I'm not convinced that the description of how to do
fragmentation is correct. I'm especially concerned that transport
and tunnel modes require different processing. The interaction of
the rules here with IPv6 fragmentation is especially worthy of
attention. (See the discussion of fragmentation in Wagner and
Bellovin's "A Bump in the Stack Encryptor for MS-DOS"....)
* Modified the existing Section "3.3.5 Fragmentation":
If necessary, fragmentation is performed after ESP
processing within an IPsec implementation. Thus,
transport mode ESP is applied only to whole IP datagrams
(not to IP fragments). An IP packet to which ESP has
been applied may itself be fragmented by routers en
route, and such fragments must be reassembled prior to
ESP processing at a receiver. In tunnel mode, ESP is
applied to an IP packet, the payload of which may be a
fragmented IP packet. For example, a security gateway
or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
implementation (as defined in the Security Architecture
document) may apply tunnel mode ESP to such fragments.
by adding the following two notes:
NOTE: For transport mode -- As mentioned at the
beginning of Section 3.1, bump-in-the-stack and
bump-in-the-wire implementations may have to first
reassemble a packet fragmented by the local IP layer,
then apply IPsec, and then fragment the resulting
packet.
NOTE: For IPv6 -- For bump-in-the-stack and
bump-in-the-wire implementations, it will be necessary
to walk through all the extension headers to determine
if there is a fragmentation header and hence that the
packet needs reassembling prior to IPsec processing.
4. Section 3.4.5 -- Per summary from IPsec document reading party, need
to correct the text to indicate additional ways in which decryption
can "fail".
* Changed Section 3.4.5 Packet Decryption, paragraph 4 (counting
the indented steps 1,2,3 taken by the receiver as one
paragraph) from:
Note that there are two ways in which the decryption can
"fail".
o The selected SA may not be correct.
o The encrypted ESP packet could be corrupted.
The latter case would be detected if authentication is
selected for the SA, as would tampering with the SPI.
However, an SA mismatch might still occur due to
tampering with the IP Destination Address. In either
case, the erroneous result of the decryption operation
(an invalid IP datagram or transport-layer frame) will
not necessarily be detected by IPsec, and is the
responsibility of later protocol processing.
to:
Note that there are several ways in which the decryption
can "fail":
a. The selected SA may not be correct -- The SA
may be mis-selected due to tampering with the
SPI, destination address. or IPsec protocol
type fields. Such errors, if they map the
packet to another extant SA, will be
indistinguishable from a corrupted packet,
(case c). Tampering with the SPI can be
detected by use of authentication. However,
an SA mismatch might still occur due to
tampering with the IP Destination Address or
the IPsec protocol type field.
b. The pad length or pad values could be
erroneous -- Bad pad lengths or pad values
can be detected irrespective of the use of
authentication.
c. The encrypted ESP packet could be corrupted
-- This can be detected if authentication is
selected for the SA.,
In case (a) or (c), the erroneous result of the
decryption operation (an invalid IP datagram or
transport-layer frame) will not necessarily be detected
by IPsec, and is the responsibility of later protocol
processing.
AH AND ESP
============================================================================
===
1. Section 2 -- Define "IV" (ESP-only) and "ICV" (AH and ESP)
before/when using these terms.
* In AH -- Changed the text following the header format diagram
from:
The following subsections define the fields that
comprise the AH format. All the fields described here
are mandatory, i.e., they are always present in the AH
format and are included in the ICV computation.
to:
The following subsections define the fields that
comprise the AH format. All the fields described here
are mandatory, i.e., they are always present in the AH
format and are included in the Integrity Check Value
(ICV) computation (see Sections 2.6 and 3.3.3).
* In ESP -- Changed text following header format diagram from:
* 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.
The following subsections define the fields in the header
format. "Optional" means that the field is omitted if the
option is not selected, i.e., it is present in neither the
packet as transmitted nor as formatted for computation of an
ICV....
to:
* If included in the Payload field, cryptographic
synchronization data, e.g., an Initialization Vector (IV,
see Section 2.3), usually is not encrypted per se,
although it often is referred to as being part of the
ciphertext.
The following subsections define the fields in the header
format. "Optional" means that the field is omitted if the
option is not selected, i.e., it is present in neither the
packet as transmitted nor as formatted for computation of an
Integrity Check Value (ICV, see Section 2.7)......
2. Section 3.1 -- Per summary from IPsec document reading party, need to
reconcile AH (Section 3.1) and ESP (Section 3.1) descriptions of
support for combinations of SAs with the Architecture's description
of support for combinations of SAs.
*The Architecture document has been changed to more clearly
reflect the 4 cases that the community agreed needed to be
supported and remove some errors and inconsistencies. The AH
and ESP text has been changed to point to the Architecture
document. We removed the following text from AH and ESP
Sections 3.1:
If more than one IPsec header/extension is required,
then starting with packet [IP1][upper], the following 5
cases plus any combination of one of the Tunnel cases
followed by one of the Transport cases (i.e., 4 then 1,
4 then 2, 4 then 3, 5 then 1, 5 then 2, 5 then 3.) MUST
be supported.
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
Support for additional combinations of AH and ESP is
optional. Use of other, optional combinations may
adversely affect interoperability.
and replaced it with:
ESP and AH headers can be combined in a variety of
modes. The IPsec Architecture document describes the
combinations of security associations that must be
supported.
3. Section 3.3.4 (ESP) and 3.3.3.2.2 (AH) -- Per discussion re:
"implicit padding for authentication" (1/7-25), need to clarify that
the input "block size" for MD5 and SHA-1 is such that no padding is
needed even though their internal algorithms have an internal "block
size" of 64 bytes.
* Changed AH and ESP documents to clarify the above. This
involved changing AH Section "3.3.3.2.2 Implicit Packet
Padding":
For some authentication algorithms, the byte string over
which the ICV computation is performed must be a
multiple of a blocksize specified by the algorithm. If
the IP packet length (including AH) does not match the
blocksize requirements for the algorithm, implicit
padding MUST be appended to the end of the packet, prior
to ICV computation. The padding octets MUST have a
value of zero. The blocksize (and hence the length of
the padding) is specified by the algorithm
specification. This padding is not transmitted with the
packet.
by adding the following sentence at the end:
Note that MD5 and SHA-1 are viewed as having a 1-byte
blocksize because of their internal padding conventions.
and changing ESP Section "3.3.4 Integrity Check Value
Calculation", paragraph 2:
For some authentication algorithms, the byte string over
which the ICV computation is performed must be a
multiple of a blocksize specified by the algorithm. If
the length of this byte string does not match the
blocksize requirements for the algorithm, implicit
padding MUST be appended to the end of the ESP packet,
(after the Next Header field) prior to ICV computation.
The padding octets MUST have a value of zero. The
blocksize (and hence the length of the padding) is
specified by the algorithm specification. This padding
is not transmitted with the packet.
by adding the following sentence at the end:
Note that MD5 and SHA-1 are viewed as having a 1-byte
blocksize because of their internal padding conventions.
4. Section 3.4.1 -- Per summary from IPsec document reading party, need
to clarify that the appearance of a "fragment" for ESP processing can
result not just from a bug in the code but because the current IPv4
spec does NOT require (upon reassembly) the zero'ing of the OFFSET
field or the clearing of the MORE FRAGMENTS flag.
*Modified the following text in AH and ESP:
3.4.1 Reassembly
If required, reassembly is performed prior to AH
processing. If a packet offered to AH for processing
appears to be an IP fragment, i.e., the OFFSET field is
non-zero or the MORE FRAGMENTS flag is set, the receiver
MUST discard the packet; this is an auditable event. The
audit log entry for this event SHOULD include the SPI
value, date/time, Source Address, Destination Address,
and (in IPv6) the Flow ID.
3.4.1 Reassembly
If required, reassembly is performed prior to ESP
processing. If a packet offered to ESP for processing
appears to be an IP fragment, i.e., the OFFSET field is
non-zero or the MORE FRAGMENTS flag is set, the receiver
MUST discard the packet; this is an auditable event. The
audit log entry for this event SHOULD include the SPI
value, date/time, Source Address, Destination Address,
and (in IPv6) the Flow ID.
by the addition of the following text:
NOTE: For packet reassembly, the current IPv4 spec does
NOT require either the zero'ing of the OFFSET field or
the clearing of the MORE FRAGMENTS flag. In order for a
reassembled packet to be processed by IPsec (as opposed
to discarded as an apparent fragment), the IP code must
do these two things after it reassembles a packet.
5. Section 3.4.3 -- Per suggestion from Dan McDonald (1/7), need to
modify the documents to clarify that anti-replay is not supportable
in the case of multiple senders to a single SA, irrespective of
whether the destination address is unicast, broadcast, or multicast.
*Changed AH and ESP documents to clarify the above. This
involved changing AH Section "3.4.3 Sequence Number
Verification" from:
All AH implementations MUST support the anti-replay
service, though its use may be enabled or disabled by
the receiver on a per-SA basis. (Note that there are no
provisions for managing transmitted Sequence Number
values among multiple senders directing traffic to a
single, multicast SA. Thus the anti-replay service
SHOULD NOT be used in a multi-sender multicast
environment that employs a single, multicast SA.)
to:
All AH implementations MUST support the anti-replay
service, though its use may be enabled or disabled by
the receiver on a per-SA basis. (Note that there are no
provisions for managing transmitted Sequence Number
values among multiple senders directing traffic to a
single SA (irrespective of whether the destination
address is unicast, broadcast, or multicast). Thus the
anti-replay service SHOULD NOT be used in a multi-sender
environment that employs a single SA.)
and changing ESP Section "3.4.3 Sequence Number Verification"
from:
All ESP implementations MUST support the anti-replay
service, though its use may be enabled or disabled by
the receiver on a per-SA basis. This service MUST NOT
be enabled unless the authentication service also is
enabled for the SA, since otherwise the Sequence Number
field has not been integrity protected. (Note that
there are no provisions for managing transmitted
Sequence Number values among multiple senders directing
traffic to a single, multicast SA. Thus the anti-replay
service SHOULD NOT be used in a multi-sender multicast
environment that employs a single, multicast SA.)
to:
All ESP implementations MUST support the anti-replay
service, though its use may be enabled or disabled by
the receiver on a per-SA basis. This service MUST NOT
be enabled unless the authentication service also is
enabled for the SA, since otherwise the Sequence Number
field has not been integrity protected. (Note that
there are no provisions for managing transmitted
Sequence Number values among multiple senders directing
traffic to a single SA (irrespective of whether the
destination address is unicast, broadcast, or
multicast). Thus the anti-replay service SHOULD NOT be
used in a multi-sender environment that employs a single
SA.)