[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
new versions of IPsec AH and ESP specs
Barbara, Ted,
We have submitted revised drafts for AH & ESP with the changes listed
at the end of this message.
- draft-ietf-ipsec-esp-v3-04.txt
- draft-ietf-ipsec-rfc2402bis-02.txt
We believe these revisions address all comments received to-date. So
we'd like to request that the working group initiate Last Call on
these two drafts.
Thank you,
Karen
In addition to minor edits for clarity and consistency, typo fixes,
and updates to dates and references, the following changes were made
to both AH and ESP (see details below)
1. The MSEC working group has published an ID that makes it
clear that multicast support will require additional changes
beyond the demultiplexing and sequence number management
changes that were made in the previous versions of these
drafts to better accommodate multicast. Therefore, we have
changed the drafts to make whether or not multicast
requirements for SA lookup are mandatory, dependent on
whether the IPsec implementation supports multicast. This
avoids burdening unicast-only implementations with
multicast-related requirements.
2. To clarify SA lookup for multicast traffic, we removed
use of protocol field for SA lookup.
3. We moved references to mandatory algorithms to a separate
document
IP Authentication Header (AH)
=============================
Section 2.4 Security Parameters Index (SPI), Paragraph 2, first 2 sentences
From:
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).
To:
If an IPsec implementation supports multicast, then it MUST
support multicast SAs using the following algorithm for
mapping inbound IPsec datagrams to SAs. (Implementations
that support only unicast traffic need not implement this
demultiplexing algorithm.) 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. (For multicast SAs, the
protocol field is not employed for SA lookups.)
Section 2.4 Security Parameters Index (SPI), Paragraph 2, sentence 7
From:
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.
To:
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 to determine the appropriate SA.
Section 3.2 Integrity Algorithms, Paragraph 1, last 2 sentences
Deleted:
The mandatory-to-implement integrity algorithms are described
in Section 5 "Conformance Requirements". Other algorithms MAY
be supported.
Section 3.4.2 Security Association Lookup, Paragraph 1, sentence 3
From:
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.
To:
If an implementation supports multicast traffic, the
destination address is also employed in the lookup (in
addition to the SPI), and the sender address also may be
employed, as described in Section 2.4.
Section 5. Conformance Requirements, Paragraph 1
From:
Implementations that claim conformance or compliance with this
specification MUST fully implement the AH syntax and processing
described here and MUST comply with all requirements of the
Security Architecture document. If the key used....
To.
Implementations that claim conformance or compliance with this
specification MUST fully implement the AH syntax and processing
described here for unicast traffic, and MUST comply with all
requirements of the Security Architecture document [KA98a].
Additionally, if an implementation claims to support multicast
traffic, it MUST comply with the additional requirements
specified for support of such traffic. If the key used....
Section 5. Conformance Requirements, Paragraph 1, last sentence
From:
A compliant AH implementation MUST support the following
mandatory-to-implement algorithms:
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
To:
The mandatory-to-implement algorithms for use with AH are
described in a separate RFC, to facilitate updating the
algorithm requirements independently from the protocol per
se. Additional algorithms, beyond those mandated for AH, MAY
be supported.
Section 7. Differences from RFC 2402, Bullet 1
From:
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.
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, or may be combined with the protocol,
at the option of the receiver. For multicast SAs, the SPI
is combined with the destination address, and optionally the
source address, to select an SA.
Section 7. Differences from RFC 2402, new bullet
Added bullet 3
o Moved references to mandatory algorithms to a separate document.
IP Encapsulating Security Payload (ESP)
=======================================
2.1 Security Parameters Index (SPI), paragraph 3, sentences 1 and 2.
From:
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).
To:
If an IPsec implementation supports multicast, then it MUST
support multicast SAs using the following algorithm for
mapping inbound IPsec datagrams to SAs. (Implementations that
support only unicast traffic need not implement this
demultiplexing algorithm.) 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. (For multicast SAs, the
protocol field is not employed for SA lookups.)
2.1 Security Parameters Index (SPI), paragraph 3, sentence 7
From:
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.
To:
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 to determine the appropriate SA.
3.2 Algorithms, Paragraph 1, sentences 1 and 2
From:
The mandatory-to-implement algorithms are described in
Section 5, "Conformance Requirements." Other algorithms MAY
be supported.
To:
The mandatory-to-implement algorithms for use with ESP are
described in a separate RFC, to facilitate updating the
algorithm requirements independently from the protocol per
se. Additional algorithms, beyond those mandated for ESP,
MAY be supported.
3.4.2 Security Association Lookup, Paragraph 1, sentence 3
From:
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.
To:
If an implementation supports multicast traffic, the
destination address is also employed in the lookup (in
addition to the SPI), and the sender address also may be
employed, as described in Section 2.1.
Section 5. Conformance Requirements, Paragraph 1, sentence 1
From:
Implementations that claim conformance or compliance with this
specification MUST fully implement the ESP syntax and processing
described here and MUST comply with all additional packet
processing requirements levied by the Security Architecture
document [KA98a]. If the key used....
To.
Implementations that claim conformance or compliance with this
specification MUST fully implement the ESP syntax and processing
described here for unicast traffic, and MUST comply with all
additional packet processing requirements levied by the Security
Architecture document [KA98a]. Additionally, if an
implementation claims to support multicast traffic, it MUST
comply with the additional requirements specified for support
of such traffic. If the key used....
5. Conformance Requirements, Paragraph 1, last sentence
From:
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)
To:
The mandatory-to-implement algorithms for use with ESP are
described in a separate document, to facilitate updating the
algorithm requirements independently from the protocol per
se. Additional algorithms, beyond those mandated for ESP,
MAY be supported.
7. Differences from RFC 2406, bullet 2
From:
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 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.
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, or may be combined with the protocol,
at the option of the receiver. For multicast SAs, the SPI is
combined with the destination address, and optionally the
source address, to select an SA.
7. Differences from RFC 2406, new bullet
Added bullet (This is now the next to last bullet.)
o Moved references to mandatory algorithms to a separate
document.