[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPsec -- new versions of AH and ESP
My apologies for the previous line-noise version of this email. It
looked fine on my screen but the intervening mail forwarding systems
mangled it. Hopefully, this version will be more readable.
Folks,
We just submitted new versions of the AH and ESP IDs to the IETF secretariat.
This email describes the changes that were made and one as yet unresolved
issue.
A. multicast
+ how should one demux inbound multicast traffic?
+ how should sequence numbering/anti-replay be
handled
B. tunnel vs transport mode -- when should each mode be used?
C. mandatory algorithms -- should these be removed from the
AH and ESP drafts in a manner analogous to their removal
from IKE?
D. miscellaneous other changes, e.g.,:
AH
- correction to table describing header fields
- changed text re: use of 51 in Protocol or Next
Header field from "will" to "SHALL"
ESP
- correction to tunnel mode processing in Section
3.4.4.1
AH & ESP
- added text to ESP to define byte order within cypher
block. This is already stated in 2401, but someone
requested that it also be put in ESP.
Some edits to the two IDs are not included in this email, e.g., correcting
typos, simplifying/clarifying text, updating references, etc.
Thank you,
Karen
****************************************************************************
A. Multicast: Based on discussion with the multicast security working
group, we have made the following changes:
Authentication Header (AH)
==========================
2.4 Security Parameters Index (SPI) -- paragraph 1, last sentence
From:
The SPI field is mandatory.
To:
The SPI field is mandatory and the mechanism for mapping inbound
traffic to unicast SAs described above MUST be supported by all
AH implementations.
2.4 Security Parameters Index (SPI) -- paragraph 2
From:
For multicast SAs, the SPI (and optionally the protocol ID) in
combination with the destination address is used to select an SA.
This is because multicast SAs are defined by a multicast
controller, not by each IPsec receiver. (See the Security
Architecture document for more details.)
To:
IPsec implementations SHOULD be prepared to support both unicast
and multicast SAs using the following algorithm for mapping inbound
IPsec datagrams to SAs. Each entry in the Security Association
Database (SAD) [KA97a] must indicate whether the SA lookup makes
use of the source and destination IP addresses, in addition to the
SPI (and, optionally, the protocol field). Nominally, this
indication can be represented by two bits, one associated with the
source IP address and the other for the destination IP address. A
"1" value for each bit indicates the need to match against the
corresponding address field as part of the SA lookup process. Thus,
for example, unicast SAs would have both bits set to zero, since
neither the source nor destination IP address is used for SA
matching. (Only the SPI, and, optionally, the protocol field are
employed.) For multicast methods that rely only on the destination
address to specify a multicast group, only the second bit would be
set to "1," implying the need to use the destination address plus
the SPI (and, optionally the protocol) to determine the appropriate
SA. For multicast methods (e.g., SSM [HCO3]) that also require the
source address to identify a multicast group, both bits would be
set to "1." (There is no current requirement to support SA mapping
based on the source address but not the destination address, thus
one of the possible four values is not meaningful.) The indication
whether source and destination address matching is required to map
inbound IPsec traffic to SAs MUST be set either as a side effect
of manual SA configuration or via negotiation using an SA
management protocol, e.g., IKE.
2.5.1 Extended (64-bit) Sequence Number -- paragraph 1, added
sentence at end of paragraph
Added:
(The ESN feature is applicable to multicast as well as unicast
SAs.)
3.2 Integrity Algorithms -- paragraph 1
From:
The authentication algorithm employed for the ICV computation is
specified by the SA. For point-to-point communication, suitable
integrity algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., AES [AES]
or on one-way hash functions (e.g., MD5 or SHA-1). For multicast
communication, one-way hash algorithms combined with asymmetric
signature algorithms are appropriate, though performance and space
considerations currently preclude use of such algorithms.....
To:
The integrity algorithm employed for the ICV computation is
specified by the SA. For point-to-point communication, suitable
integrity algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., AES [AES]
or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.).
For multicast communication, a variety of cryptographic strategies
for providing integrity have been developed and research continues
in this area.....
3.3.2 Sequence Number Generation -- paragraph 4, added sentence
From:
If anti-replay is disabled (as noted above), the sender does not
need to monitor or reset the counter, e.g., in the case of manual
key management (see Section 5). However, the sender still
increments the counter and when it reaches the maximum value, the
counter rolls over back to zero.
To:
If anti-replay is disabled (as noted above), the sender does not
need to monitor or reset the counter, e.g., in the case of manual
key management (see Section 5). However, the sender still
increments the counter and when it reaches the maximum value, the
counter rolls over back to zero. (This behavior is recommended for
multi-sender, multicast SAs, unless anti-replay mechanisms outside
the scope of this standard are negotiated between the sender and
receiver.)
3.4.2 Security Association Lookup -- paragraph 1
From:
Upon receipt of a packet containing an IP Authentication
Header, the receiver determines the appropriate (unidirectional)
SA, based on the destination IP address, security protocol (AH),
and the SPI.....
To:
Upon receipt of a packet containing an IP Authentication Header,
the receiver determines the appropriate (unidirectional) SA via
lookup in the SAD. For a unicast SA, this determination is based
on the SPI or the SPI plus protocol field, as described in
Section 2.4. For multicast SAs, the destination address is also
employed in the lookup (in addition to the SPI and, optionally
the protocol), and the sender address also may be employed, as
described in Section 2.4....
3.4.3 Sequence Number Verification -- paragraph 1
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 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.)
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. Anti-replay is applicable to unicast as well as
multicast SAs. However, this standard specifies no mechanisms
for providing anti-replay for a multi-sender SA (unicast or
multicast). In the absence of negotiation (or manual
configuration) of an anti-replay mechanism for such an SA, it is
recommended that sender and receiver checking of the sequence
number for the SA be disabled (via negotiation or manual
configuration), as noted below.
7. Differences from RFC 2402 -- first bullet
From:
o SPI -- modified to better reflect the differences between
unicast and multicast SA lookups. For unicast, the SPI may be
used alone to select an SA; for multicast, the SPI is combined
with destination address to select an SA.
To:
o SPI -- modified to specify a uniform algorithm for SAD lookup
for unicast and multicast SAs, covering a wider range of multicast
technologies. For unicast, the SPI may be used alone to select an
SA; for multicast, the SPI is combined with the destination
address, and optionally the source address, to select an SA. If
the receiver (unicast) or the multicast controller (multicast)
opted to use the security protocol (AH) in selecting the SPI,
then the security protocol is also used in the lookup.
(I had the security protocol as (ESP) -- am I correct to
assume that was a boo-boo?)
7. Differences from RFC 2402 -- second bullet
From:
o Sequence number -- added a new option for a 64-bit sequence
number for very high-speed communications.
To:
o Sequence number -- added a new option for a 64-bit sequence
number for very high-speed communications. Clarified sender and
receiver processing requirements for multicast SAs and
multi-sender SAs.
Encapsulating Security Payload (ESP)
====================================
2.1 Security Parameters Index -- 1 and 2
From:
The SPI is an arbitrary 32-bit value that is used by a receiver to
identify the SA to which an incoming packet is bound. The SPI field
is mandatory.
For a unicast SA, the SPI can be used by itself to specify an SA,
or it may be used in conjunction with the IPsec protocol type (in
this case ESP). Since the SPI value is generated by the receiver,
whether the value is sufficient to identify an SA by itself, or
whether it must be used in conjunction with the IPsec protocol
value is a local matter.
To:
The SPI is an arbitrary 32-bit value that is used by a receiver to
identify the SA to which an incoming packet is bound. For a unicast
SA, the SPI can be used by itself to specify an SA, or it may be
used in conjunction with the IPsec protocol type (in this case ESP).
Since, for unicast SAs, the SPI value is generated by the receiver,
whether the value is sufficient to identify an SA by itself, or
whether it must be used in conjunction with the IPsec protocol
value is a local matter. The SPI field is mandatory and the
mechanism for mapping inbound traffic to unicast SAs described
above MUST be supported by all ESP implementations.
2.1 Security Parameters Index (SPI) -- paragraph 3
From:
For multicast SAs, the SPI (and optionally the protocol ID) in
combination with the destination address is used to select an SA.
This is because multicast SAs are defined by a multicast
controller, not by each IPsec receiver. (See the Security
Architecture document for more details.)
To:
IPsec implementations SHOULD be prepared to support both unicast
and multicast SAs using the following algorithm for mapping inbound
IPsec datagrams to SAs. Each entry in the Security Association
Database (SAD) [KA97a] must indicate whether the SA lookup makes
use of the source and destination IP addresses, in addition to the
SPI (and, optionally, the protocol field). Nominally, this
indication can be represented by two bits, one associated with the
source IP address and the other for the destination IP address. A
"1" value for each bit indicates the need to match against the
corresponding address field as part of the SA lookup process. Thus,
for example, unicast SAs would have both bits set to zero, since
neither the source nor destination IP address is used for SA
matching. (Only the SPI, and, optionally, the protocol field are
employed.) For multicast methods that rely only on the destination
address to specify a multicast group, only the second bit would be
set to "1," implying the need to use the destination address plus
the SPI (and, optionally the protocol) to determine the appropriate
SA. For multicast methods (e.g., SSM [cite]) that also require the
source address to identify a multicast group, both bits would be
set to "1." (There is no current requirement to support SA mapping
based on the source address but not the destination address, thus
one of the possible four values is not meaningful.) The indication
whether source and destination address matching is required to map
inbound IPsec traffic to SAs MUST be set either as a side effect
of manual SA configuration or via negotiation using an SA
management protocol, e.g., IKE.
2.2.1 Extended (64-bit) Sequence Number -- paragraph 1, added
sentence at end of paragraph
Added:
(The ESN feature is applicable to multicast as well as unicast
SAs.)
3.3.3 Sequence Number Generation -- paragraph 4, added sentence
From:
If anti-replay is disabled (as noted above), the sender does not
need to monitor or reset the counter, e.g., in the case of manual
key management (see Section 5). However, the sender still
increments the counter and when it reaches the maximum value, the
counter rolls over back to zero.
To:
If anti-replay is disabled (as noted above), the sender does not
need to monitor or reset the counter, e.g., in the case of manual
key management (see Section 5). However, the sender still
increments the counter and when it reaches the maximum value, the
counter rolls over back to zero. (This behavior is recommended for
multi-sender, multicast SAs, unless anti-replay mechanisms outside
the scope of this standard are negotiated between the sender and
receiver.)
3.4.2 Security Association Lookup -- paragraph 1
From:
Upon receipt of a packet containing an ESP Header, the
receiver determines the appropriate (unidirectional) SA, based
on the SPI alone (unicast) or SPI combined with destination IP
address (multicast)....
To:
Upon receipt of a packet containing an ESP Header, the receiver
determines the appropriate (unidirectional) SA via lookup in the
SAD. For a unicast SA, this determination is based on the SPI or
the SPI plus protocol field, as described in Section 2.1. For
multicast SAs, the destination address is also employed in the
lookup (in addition to the SPI and, optionally the protocol),
and the sender address also may be employed, as described in
Section 2.1.....
3.4.3 Sequence Number Verification -- paragraph 1
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. (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.)
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 ESP
integrity service also is enabled for the SA, since otherwise
the Sequence Number field has not been integrity protected.
Anti-replay is applicable to unicast as well as multicast SAs.
However, this standard specifies no mechanisms for providing
anti-replay for a multi-sender SA (unicast or multicast). In the
absence of negotiation (or manual configuration) of an anti-replay
mechanism for such an SA, it is recommended that sender and
receiver checking of the sequence number for the SA be disabled
(via negotiation or manual configuration), as noted below.
7. Differences from RFC 2402 -- second bullet
From:
o SPI -- modified to better reflect the differences between
unicast and multicast SA lookups. For unicast, the SPI may be
used alone to select an SA; for multicast, the SPI is combined
with destination address to select an SA.
To:
o SPI -- modified to specify a uniform algorithm for SAD lookup
for unicast and multicast SAs, covering a wider range of multicast
technologies. For unicast, the SPI may be used alone to select an
SA; for multicast, the SPI is combined with the destination
address, and optionally the source address, to select an SA. If
the receiver (unicast) or the multicast controller (multicast)
opted to use the security protocol (ESP) in selecting the SPI,
then the security protocol is also used in the lookup.
7. Differences from RFC 2402 -- third bullet
From:
o Sequence number -- added a new option for a 64-bit sequence
number for very high-speed communications.
To:
o Sequence number -- added a new option for a 64-bit sequence
number for very high-speed communications. Clarified sender and
receiver processing requirements for multicast SAs and
multi-sender SAs.
****************************************************************************
B. Tunnel vs Transport mode -- A design team is still discussing how
IPsec should deal with tunneling in various contexts. It seems
likely that we will change the current processing flow in 2401,
and redefine the rules on when to use tunnel mode vs. transport
mode, e.g., to better accommodate overlay nets, PPVPN
applications, etc. However, to facilitate moving the AH and ESP
specs to Last Call, we have:
a. changed "upper layer protocol" to "next layer protocol"
throughout these 2 specs
b. removed the text in these two specs that says WHEN to use
these modes and deferred that to the Architecture spec
(2401bis). The AH and ESP specs will continue to discuss
the transport and tunnel mechanisms and the Architecture
spec will describe when to use them.
Authentication Header (AH)
==========================
1. Introduction -- paragraph 3
From:
AH may be applied alone, in combination with the IP Encapsulating
Security Payload (ESP) [KA97b], or in a nested fashion through the
use of tunnel mode (see "Security Architecture for the Internet
Protocol" [KA97a], hereafter referred to as the Security
Architecture document).
To:
AH may be applied alone, in combination with the IP Encapsulating
Security Payload (ESP) [KA97b], or in a nested fashion (see
"Security Architecture for the Internet Protocol" [KA97a],
hereafter referred to as the Security Architecture document).
3.1 Authentication Header Location -- paragraph 1
From (some of this text was moved to Section 3.1.1 -- see below)
Like ESP, AH may be employed in two ways: transport mode or tunnel
mode. The former mode is applicable only to host implementations
and provides protection for upper layer protocols, in addition to
selected IP header fields. (In this mode, note that for "bump-in-
the-stack" or "bump-in-the-wire" implementations, as defined in the
Security Architecture document, inbound and outbound IP fragments
may require an IPsec implementation to perform extra IP
reassembly/fragmentation in order to both conform to this
specification and provide transparent IPsec support. Special care
is required to perform such operations within these implementations
when multiple interfaces are in use.)
To:
Like ESP, AH may be employed in two ways: transport mode or tunnel
mode. (See the Security Architecture document for a description of
when each should be used.)
3.1 Authentication Header Location -- paragraph 2, sentence 1
From:
AH provides authentication for as much of the IP header as
possible, as well as for upper level protocol data....
To:
AH provides authentication for as much of the IP header as
possible, as well as for next level protocol data....
3.1.1 Transport Mode -- paragraph 1, sentences 1 and 2
From:
In transport mode, AH is inserted after the IP header and before
an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any
other IPsec headers that have already been inserted. In the
context of IPv4, this calls for placing AH after the IP header
(and any options that it contains), but before the upper layer
protocol.....
To:
In transport mode, AH is inserted after the IP header and before
a next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any
other IPsec headers that have already been inserted. In the
context of IPv4, this calls for placing AH after the IP header
(and any options that it contains), but before the next layer
protocol.....
3.1.1 Transport Mode -- paragraph 1, deleted sentence 5
From:
(Note that the term "transport" mode should not be misconstrued
as restricting its use to TCP and UDP. For example, an ICMP
message MAY be sent using either "transport" mode or "tunnel"
mode.)
To:
(Note that the term "transport" mode should not be misconstrued
as restricting its use to TCP and UDP.)
3.1.1 Transport Mode -- added at the end of this section some of
the text removed from 3.1 (see above)
Note that in transport mode, for "bump-in-the-stack" or
"bump-in-the-wire" implementations, as defined in the Security
Architecture document, inbound and outbound IP fragments may
require an IPsec implementation to perform extra IP
reassembly/fragmentation in order to both conform to this
specification and provide transparent IPsec support. Special care
is required to perform such operations within these implementations
when multiple interfaces are in use.
3.1.2 Tunnel Mode
From:
Tunnel mode AH may be employed in either hosts or security gateways
(or in so-called "bump-in-the-stack" or "bump-in-the-wire"
implementations, as defined in the Security Architecture document).
When AH is implemented in a security gateway (to protect transit
traffic), tunnel mode MUST be used. In tunnel mode, the "inner" IP
header carries the ultimate source and destination addresses, while
an "outer" IP header may contain distinct IP addresses, e.g.,
addresses of security gateways. In tunnel mode, AH protects the
entire inner IP packet, including the entire inner IP header. The
position of AH in tunnel mode, relative to the outer IP header, is
the same as for AH in transport mode. The following diagram
illustrates AH tunnel mode positioning for typical IPv4 and IPv6
packets.
To:
In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header
contains the addresses of the IPsec "peers," e.g., addresses of
security gateways. In tunnel mode, AH protects the entire inner
IP packet, including the entire inner IP header. The position
of AH in tunnel mode, relative to the outer IP header, is the
same as for AH in transport mode. The following diagram
illustrates AH tunnel mode positioning for typical IPv4 and IPv6
packets.
3.3 Outbound Packet Processing -- paragraph 1, sentence 1
From:
In transport mode, the sender inserts the AH header after the IP
header and before an upper layer protocol header, as described
above.....
To:
In transport mode, the sender inserts the AH header after the IP
header and before a next layer protocol header, as described
above.....
3.3 Outbound Packet Processing -- paragraph 2
Deleted (To be addressed in Architecture document):
If there is more than one IPsec header/extension required, the
order of the application of the security headers MUST be defined
by security policy. For simplicity of processing, each IPsec
header SHOULD ignore the existence (i.e., not zero the contents or
try to predict the contents) of IPsec headers to be applied later.
(While a native IP or bump-in-the-stack implementation could
predict the contents of later IPsec headers that it applies
itself, it won't be possible for it to predict any IPsec headers
added by a bump-in-the-wire implementation between the host and
the network.)
3.3.3 Integrity Check Value Calculation -- paragraph 1, bullet 3
From:
The AH ICV is computed over:
o....
o....
o the upper level protocol data, which is assumed to be
immutable in transit
To:
The AH ICV is computed over:
o....
o....
o the next level protocol data, which is assumed to be
immutable in transit
3.3.4 Fragmentation -- paragraph 2
From:
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.
To:
NOTE: For transport mode -- As mentioned at the end of Section
3.1.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.
Encapsulating Security Payload (ESP)
====================================
1. Introduction -- paragraph 1, sentence 2
From:
ESP may be applied alone, in combination with the IP
Authentication Header (AH) [KA98b], or in a nested fashion, e.g.,
through the use of tunnel mode (see "Security Architecture for
the Internet Protocol" [KA98a], hereafter referred to as the
Security Architecture document).
To:
ESP may be applied alone, in combination with the IP
Authentication Header (AH) [KA98b], or in a nested fashion,
(see "Security Architecture for the Internet Protocol" [KA98a],
hereafter referred to as the Security Architecture document).
1. Introduction -- paragraph 2, sentence 1
From:
The ESP header is inserted after the IP header and before the
upper layer protocol header (transport mode) or before an
encapsulated IP header (tunnel mode).
To:
The ESP header is inserted after the IP header and before the
next layer protocol header (transport mode) or before an
encapsulated IP header (tunnel mode).
1. Introduction -- paragraph 8
From:
The traffic flow confidentiality (TFC) service generally is
effective only if ESP is employed in tunnel mode between
security gateways, and only if sufficient traffic flows between
these gateways to conceal the characteristics of specific,
individual subscriber traffic flows.
To:
The traffic flow confidentiality (TFC) service generally is
effective only if ESP is employed in a fashion that conceals
the ultimate source and destination addresses of correspondents,
e.g., in tunnel mode between security gateways, and only if
sufficient traffic flows between IPsec peers (either naturally
or as a result of generation of masking traffic) to conceal the
characteristics of specific, individual subscriber traffic flows.
2.3 Payload Data -- paragraph 2
From:
Note that the beginning of the transport header (transport mode)
or the beginning of the encapsulated IP datagram (tunnel mode)
MUST be aligned relative to the beginning of the ESP header as
follows. For IPv4, this alignment is a multiple of 4 bytes. For
IPv6, the alignment is a multiple of 8 bytes.
To:
Note that the beginning of next layer protocol header MUST be
aligned relative to the beginning of the ESP header as follows.
For IPv4, this alignment is a multiple of 4 bytes. For IPv6,
the alignment is a multiple of 8 bytes.
2.4 Padding (for Encryption) -- paragraph 1, 3rd bullet has been
modified and changed to be a regular paragraph, not a bullet.
From:
Three factors require or motivate use of the Padding field.
o .....
o .....
o 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 TFC. The padding field
described here offers limited opportunity for concealing the
length of the plaintext and thus a new, separate mechanism
is described below for use when TFC is required (see Section
2.7).
To:
Two factors require or motivate use of the Padding field.
o .....
o .....
Padding beyond that required for the algorithm or alignment
reasons cited above, could be used to conceal the actual length
of the payload, in support of TFC. However, the Padding field
described is too limited to be effective for TFC and thus should
not be used for that purpose. Instead, the new, separate mechanism
described below (see Section 2.7) should be used when TFC is
required.
2.6 Next Header -- paragraph 1
From:
The Next Header is a mandatory, 8-bit field that identifies the
type of data contained in the Payload Data field, e.g., an IPv4
or IPv6 packet, or an upper layer header and data.
To:
The Next Header is a mandatory, 8-bit field that identifies the
type of data contained in the Payload Data field, e.g., an IPv4
or IPv6 packet, or a next layer header and data.
2.7 Traffic Flow Confidentiality (TFC) Padding -- paragraph 4
Deleted:
In transport mode, this facility generally will not be available,
consistent with the earlier admonition that effective TFC service
in IPsec generally requires use of tunnel mode between security
gateways.
3.1 ESP Header Location
From:
ESP may be employed in two ways: transport mode or tunnel mode.
The former mode is applicable to host implementations and provides
protection for upper layer protocols, but not the IP header. (In
this mode, note that for "bump-in- the-stack" or "bump-in-the-wire"
implementations, as defined in the Security Architecture document,
inbound and outbound IP fragments may require an IPsec implementation
to perform extra IP reassembly/fragmentation in order to both conform
to this specification and provide transparent IPsec support. Special
care is required to perform such operations within these
implementations when multiple interfaces are in use.)
To:
ESP may be employed in two ways: transport mode or tunnel mode. (See
the Security Architecture document for description of when each should
be used.)
3.1.1 Transport Mode Processing -- paragraph 1, sentence 1 and 2
From:
In transport mode, ESP is inserted after the IP header and before
an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context
of IPv4, this translates to placing ESP after the IP header (and
any options that it contains), but before the upper layer
protocol.....
To:
In transport mode, ESP is inserted after the IP header and before
a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context
of IPv4, this translates to placing ESP after the IP header (and
any options that it contains), but before the next layer
protocol.....
3.1.1 Transport Mode -- paragraph 1, deleted sentence 5
From:
(Note that the term "transport" mode should not be misconstrued
as restricting its use to TCP and UDP. For example, an ICMP
message MAY be sent using either "transport" mode or "tunnel"
mode.)
To:
(Note that the term "transport" mode should not be misconstrued
as restricting its use to TCP and UDP.)
3.1.1 Transport Mode -- added text
Added at the end of this section some of the text removed from 3.1
Note that in transport mode, for "bump-in- the-stack" or
"bump-in-the-wire" implementations, as defined in the Security
Architecture document, inbound and outbound IP fragments may
require an IPsec implementation to perform extra IP
reassembly/fragmentation in order to both conform to this
specification and provide transparent IPsec support. Special
care is required to perform such operations within these
implementations when multiple interfaces are in use.
3.1.2 Tunnel Mode Processing
From:
Tunnel mode ESP may be employed in either hosts or security gateways.
When ESP is implemented in a security gateway to protect subscriber
transit traffic, tunnel mode MUST be used. (Transport mode MAY be used
to protect management or similar traffic terminating at a security
gateway.) In tunnel mode, the "inner" IP header carries the ultimate
source and destination addresses, while an "outer" IP header contains
the addresses of the IPsec peers. In tunnel mode, ESP protects the
entire inner IP packet, including the entire inner IP header. The
position of ESP in tunnel mode, relative to the outer IP header, is
the same as for ESP in transport mode. The following diagram
illustrates ESP tunnel mode positioning for typical IPv4 and IPv6
packets.
To:
In tunnel mode, the "inner" IP header carries the ultimate
source and destination addresses, while an "outer" IP header contains
the addresses of the IPsec peers. In tunnel mode, ESP protects the
entire inner IP packet, including the entire inner IP header. The
position of ESP in tunnel mode, relative to the outer IP header, is
the same as for ESP in transport mode. The following diagram
illustrates ESP tunnel mode positioning for typical IPv4 and IPv6
packets.
In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header
contains the addresses of the IPsec "peers", e.g., addresses of
security gateways. In tunnel mode, ESP protects the entire inner
IP packet, including the entire inner IP header. The position
of ESP in tunnel mode, relative to the outer IP header, is the
same as for ESP in transport mode. The following diagram
illustrates ESP tunnel mode positioning for typical IPv4 and IPv6
packets.
3.3 Outbound Packet Processing -- paragraph 1, sentence 1
From:
In transport mode, the sender encapsulates the upper layer
protocol information between the ESP header and the ESP trailer
fields, and retains the specified IP header (and any IP extension
headers in the IPv6 context).
To:
In transport mode, the sender encapsulates the next layer
protocol information between the ESP header and the ESP trailer
fields, and retains the specified IP header (and any IP extension
headers in the IPv6 context).
3.3 Outbound Packet Processing -- paragraph 1
Deleted last sentence (to be addressed in Architecture document)
If more than one IPsec header/extension is required by security
policy, the order of the application of the security headers MUST
be defined by security policy.
3.3.2.1 Separate Confidentiality and Integrity Algorithms --
paragraph 1, step 1
From:
If separate confidentiality and integrity algorithms are employed,
the sender:
1. encapsulates (into the ESP Payload field):
- for transport mode -- just the original upper layer
protocol information.
To:
If separate confidentiality and integrity algorithms are employed,
the sender:
1. encapsulates (into the ESP Payload field):
- for transport mode -- just the original next layer
protocol information.
3.3.2.2 Combined Confidentiality and Integrity Algorithms --
paragraph 1, step 1
From:
If a combined confidentiality/integrity algorithm is employed,
the sender:
1. encapsulates into the ESP Payload Data field:
- for transport mode -- just the original upper layer
protocol information.
To:
If a combined confidentiality/integrity algorithm is employed,
the sender:
1. encapsulates into the ESP Payload Data field:
- for transport mode -- just the original next layer
protocol information.
3.3.4 Fragmentation -- paragraph 2
From:
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.
To:
NOTE: For transport mode -- As mentioned at the end of Section
3.1.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.
3.4.4.1 Separate Confidentiality and Integrity Algorithms --
paragraph 1, step 5
From:
5. the receiver reconstructs the original IP datagram from:
- for transport mode -- original IP header plus the
original upper layer protocol information in the ESP
Payload field
To:
5. the receiver reconstructs the original IP datagram from:
- for transport mode -- original IP header plus the
original next layer protocol information in the ESP
Payload field
****************************************************************************
C. Mandatory Algorithms -- Does the working group want to remove the
text that describes the mandatory algorithms and move them to
another document? If yes, then the following sections would be
removed/edited.
Authentication Header (AH)
==========================
3.2 Integrity Algorithms -- paragraph one, sentence 4
.... The mandatory-to-implement integrity algorithms are
described in Section 5 "Conformance Requirements". Other
algorithms MAY be supported.
5. Conformance Requirements -- paragraph one, sentence 4
.... A compliant AH implementation MUST support the following
mandatory-to-implement algorithms:
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
Encapsulating Security Payload (ESP)
====================================
3.2 Algorithms -- first 2 sentences
The mandatory-to-implement algorithms are described in Section 5,
"Conformance Requirements." Other algorithms MAY be supported....
5. Conformance Requirements -- paragraph one, sentence 4
.... A compliant ESP implementation MUST support the following
mandatory-to-implement algorithms:
- AES (with 128-bit keys) in CBC mode
- HMAC with MD5 [MG98a]
- HMAC with SHA-1 [MG98b]
- NULL Encryption algorithm (RFC 2410)
****************************************************************************
D. Other Changes
Authentication Header (AH)
==========================
2. Authentication Header Format -- paragraph 1
From:
The protocol header (IPv4, IPv6, or IPv6 Extension) immediately
preceding the AH header will contain the value 51 in its
Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2].
To:
The protocol header (IPv4, IPv6, or IPv6 Extension) immediately
preceding the AH header SHALL contain the value 51 in its Protocol
(IPv4) or Next Header (IPv6, Extension) field [STD-2]. Figure 1
illustrates the format for AH.
2. Authentication Header Format -- table
From: (removed "D" = dummy from Requ'd column for "IP datagram".
There is a "dummy" value in ESP, but not in AH.)
What What
# of Requ'd Integ is
bytes [1] Covers Xmtd
------ ------ ------ ------
IP Header variable M [2] plain
Next Header 1 M Y plain
Payload Len 1 M Y plain
RESERVED 2 M Y plain
SPI 4 M Y plain
Seq# (low order 32-bits) 4 M Y plain
ICV variable M Y[3] plain
IP datagram [4] variable M or D Y plain
Seq# (high order 32-bits) 4 if ESN Y not xmtd
ICV Padding variable if need Y not xmtd
[1] - M = mandatory; D = dummy
To:
What What
# of Requ'd Integ is
bytes [1] Covers Xmtd
------ ------ ------ ------
IP Header variable M [2] plain
Next Header 1 M Y plain
Payload Len 1 M Y plain
RESERVED 2 M Y plain
SPI 4 M Y plain
Seq# (low order 32-bits) 4 M Y plain
ICV variable M Y[3] plain
IP datagram [4] variable M Y plain
Seq# (high order 32-bits) 4 if ESN Y not xmtd
ICV Padding variable if need Y not xmtd
[1] - M = mandatory
2. Authentication Header Format -- added the following text at
the end of this section.
"Note: All of the cryptographic algorithms used in IPsec
expect their input in canonical network byte order (see
Appendix in RFC 791) and generate their output in canonical
network byte order. IP packets are also transmitted in
network byte order."
3.3.4 Fragmentation -- paragraph 1, sentence 3 (and added a
parenthetical sentence after sentence 3.)
From:
.....An IP packet to which AH has been applied may itself be
fragmented by routers en route, and such fragments must be
reassembled prior to AH processing at a receiver....
To:
.....An IPv4 packet to which AH has been applied may itself
be fragmented by routers en route, and such fragments must be
reassembled prior to AH processing at a receiver. (This does
not apply to IPv6, where there is no router-initiated fragmentation.)
3.4.2 Security Association Lookup -- added paragraph at end
(Note that SA management traffic, e.g., IKE packets, does not
need to be processed based on SPI, i.e., one can demultiplex
this traffic separately, e.g., based on Next Protocol and Port
fields.)
Encapsulating Security Payload (ESP)
====================================
2. Encapsulating Security Payload Packet Format -- added the
following text at the end of this section.
"Note: All of the cryptographic algorithms used in IPsec
expect their input in canonical network byte order (see
Appendix in RFC 791) and generate their output in canonical
network byte order. IP packets are also transmitted in
network byte order."
3.4.4.1 Separate Confidentiality and Integrity Algorithms,
paragraph 1, step 5 -- corrected tunnel mode processing
From:
5. the receiver reconstructs the original IP datagram from:
- for transport mode -- original IP header plus the
original next layer protocol information in the ESP
Payload field
- for tunnel mode -- tunnel IP header + the entire IP
datagram in the ESP Payload field.
To:
5. the receiver reconstructs the original IP datagram from:
- for transport mode -- outer IP header plus the
original next layer protocol information in the ESP
Payload field
- for tunnel mode -- the entire IP datagram in the
ESP Payload field.