[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Latest AH/ESP/Arch drafts and changes
Folks,
In follow-up to the IESG vote/feedback and recent email...
1. Per direction from Ted Ts'o, we are sending to the IETF secretariat
and the mailing list, revised versions of the following drafts:
o AH -- draft-ietf-ipsec-auth-header-06.txt
o ESP -- draft-ietf-ipsec-esp-v2-05.txt
o Architecture -- draft-ietf-ipsec-arch-sec-05.txt
These drafts contain the changes listed below in part 1 and part 2.
2. Part 1 below contains edits that have been made since Ted's 4/28
email "IPSEC standardization status". If you've already read the
changes that Ted posted to the Web on 4/28, then you only need to
look at these new changes.
3. Part 2 below contains the changes made to the 3/13 Internet Drafts up
until Ted's 4/28 email on "IPSEC standardization status". He posted
these changes (and corresponding drafts, which were not sent to the
IETF secretariat) to the Web. They are included here for those who
haven't yet had a chance to pull them over from the Web site.
Please let us know if you have any questions, etc. Thank you,
Karen
*******************************************************************************
Part 1 -- Changes made to the drafts since Ted's 4/28 email "IPSEC
standardization status"
*******************************************************************************
AH
1. Section 3.3.3.1 "Handling Mutable Fields" -- Amended to match IP (v4
and v6) handling of unrecognized extension headers and to clarify the
distinction between IPv6 options and extension headers -- per (IPng
and IPsec) mailing list discussion.
Changed 3.3.3.1, second paragraph, from:
... If the IPsec implementation encounters an extension
header that it does not recognize, it MUST zero the whole
header except for the Next Header and Hdr Ext Len fields.
The length of the extension header MUST be computed by 8 *
Hdr Ext Len value + 8. If the IPsec implementation
encounters an IPv4 option that it does not recognize, it
should zero the whole option, using the second byte of the
option as the length. (IPv6 options contain a flag
indicating mutability, which determines appropriate
processing for such options.)
to:
... If the IP (v4 or v6) implementation encounters an
extension header that it does not recognize, it will discard
the packet and send an ICMP message. IPsec will never see
the packet. If the IPsec implementation encounters an IPv4
option that it does not recognize, it should zero the whole
option, using the second byte of the option as the length.
IPv6 options (in Destination extension headers or Hop by Hop
extension header) contain a flag indicating mutability, which
determines appropriate processing for such options.
2. Section 3.3.3.1.2.2 "Extension Headers -- Options" -- changed wording
to clarify the distinction between IPv6 options and extension headers
-- per email from Ted Ts'o on 5/5/98
Changed title from:
3.3.3.1.2.2 Extension Headers -- Options
to:
3.3.3.1.2.2 Extension Headers Containing Options
Deleted the first sentence of section:
The IPv6 extension headers (that are options) are explicitly
listed in Appendix A and classified as immutable, mutable but
predictable, or mutable.
3. Section 3.3.3.1.2.3 "Extension Headers -- non-Options" -- changed
wording to clarify that IPv6 options are contained in extension
headers (Hop by Hop and Destination) -- per email from Ted Ts'o on
5/5/98
Changed title from:
3.3.3.1.2.3 Extension Headers -- non-Options
to:
3.3.3.1.2.3 Extension Headers Not Containing Options
===========================================================================
ESP
1. Section 3.4.3 "Sequence Number Verification" -- fixed incorrect
reference -- per email from Marc Hasson on 4/30/98.
Changed 3.4.3, second paragraph from:
If the receiver does not enable anti-replay for an SA....To
avoid having the sender do unnecessary sequence number
monitoring and SA setup (see section 3.3.2).....
to:
If the receiver does not enable anti-replay for an SA....To
avoid having the sender do unnecessary sequence number
monitoring and SA setup (see section 3.3.3).....
2. Section 3.4.5 "Packet Decryption" -- changed this section to be
consistent with Section 2.4 "Padding (for Encryption)" paragraph on
default padding scheme which says, "When this [the default] padding
scheme is employed, the receiver SHOULD inspect the Padding field."
-- per email from Marc Hasson on 4/30/98.
Changed 3.4.5, step 2 from:
2. processes any padding as specified in the encryption
algorithm specification. The default action is to
remove/ignore any padding.
to:
2. processes any padding as specified in the encryption
algorithm specification. If the default padding scheme
(see Section 2.4) has been employed, the receiver SHOULD
inspect the Padding field before removing the padding
prior to passing the decrypted data to the next layer.
===========================================================================
Architecture:
1. Section 4.1 "Definition and Scope" -- changed to clarify the
distinction between IPv6 options and extension headers -- per email
from Ted Ts'o on 5/5/98
NOTE: Because an extension header can be used with IPv4 as well as
with IPv6, we did not say that extension headers are IPv6.
Changed third paragraph from:
... In the case of AH, the protection is also extended to
selected portions of the IP header (and options). For more
details on the coverage afforded by AH, see the AH
specification [KA98a]...
to:
... In the case of AH, the protection is also extended to
selected portions of the IP header, selected portions of
extension headers, and selected options (contained in the
IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6
Destination extension headers). For more details on the
coverage afforded by AH, see the AH specification [KA98a]
2. Section 4.4.2 "Selectors" paragraphs on Destination IP Address and
Source IP Address -- corrected to reflect the fact that IPv6 does not
have broadcast addresses -- per email from Marc Hasson on 4/30/98.
RFC 1884 says "IPv6 addresses are 128-bit identifiers for interfaces
and sets of interfaces. There are three types of addresses:
Unicast: ....
Anycast: ....
Multicast: ....
So we also changed these paragraphs to include "anycast", even though
anycast addresses are not syntactically distinguishable from unicast
addresses.
Changed paragraph on Destination Addresses from:
- Destination IP Address (IPv4 or IPv6): this may be a single
IP address (unicast, broadcast, or multicast group), a range
of addresses (high and low values (inclusive), address +
mask, or a wildcard address....
- Source IP Address(es) (IPv4 or IPv6): this may be a single
IP address (unicast, broadcast, or multicast group), range of
addresses (high and low values inclusive), address + mask, or
a wildcard address....
to:
- Destination IP Address (IPv4 or IPv6): this may be a single
IP address (unicast, anycast, broadcast (IPv4 only), or
multicast group), a range of addresses (high and low values
(inclusive), address + mask, or a wildcard address....
- Source IP Address(es) (IPv4 or IPv6): this may be a single
IP address (unicast, anycast,, broadcast (IPv4 only), or
multicast group), range of addresses (high and low values
inclusive), address + mask, or a wildcard address....
3. Section 4.4.2 "Selectors" paragraph on Source IP Address -- The
current text says:
- Source IP Address(es) (IPv4 or IPv6): this may be a single
IP address (unicast, broadcast, or multicast group), range of
addresses (high and low values inclusive), address + mask, or
a wildcard address.
In his 4/30 email, Marc Hasson asked,
"Can a source address really be a broadcast or multicast? This
seems like we're having IPSEC condone illegal IP[v6] packet
behavior...."
Since a packet's source address FIELD may not contain a broadcast or
multicast address, at first glance, it doesn't make sense for a
source address SELECTOR to be a broadcast or multicast address. But
this raises the question of what happens during IKE's SA negotiation
-- what does the receiving end of an SA setup request do when the
destination address is broadcast or multicast and it tries to set up
the return half of the SA pair? In particular, what does the
(outbound) SPD use for the Source IP Address selector value (as
opposed to what would be in a packet)? This seems like a case where
the selector values would need to be different from the packet values
and hence the current text is correct, provided we change "broadcast"
to "broadcast (IPv4 only). Note also that if a multicast receiver
initiates an ISAKMP exchange, e.g., to obtain a key from (each)
sender to the group, the "destination address selector" would be the
multicast sender's address (a unicast address) while the "source
address selector" would contain the multicast group address.
For now, we are leaving the text as is to cover the possibility that
broadcast/multicast might be useful in the future, e.g., to enable
one to use a multicast address when doing secure multicasting
operations. Since the multicast problem has been deferred to
IPsecond (or later?), this issue is similarly deferred..
4. Appendix B.2 "Fragmentation" -- very last paragraph
The last paragraph currently says:
c. Security gateways -- integrate IPsec into the IP stack
NOTE: The IPsec module will have access to the following
selectors .... Unlike Bump-in-the-stack implementations,
security gateways may be able to look up the Source Address in
the DNS to provide a System Name, e.g., in situations involving
use of dynamically assigned IP addresses in conjunction with
dynamically updated DNS entries....
From email from Marc Hasson on 4/30/98...[referring to the sentence
above, "Unlike Bump-in-the-stack...."]
"I'm not sure why this statement is here. Having done both an
IPSEC stack for Mentat as well as having worked on a BITS
implementation (involving both user and kernel pieces) I don't
see any reason why a BITS implementation can't do a DNS lookup
for its System name just as well as a "pure" IPSEC host or SG.
In fact, part of the dynamic IP assignment (via DHCP perhaps)
and DNS update may already have provided a BITS host with what
it needs to do a DNS lookup.
Our impression was that the community viewed the phrase
"bump-in-the-stack" (BITS) as describing an implementation that
typically would not have access to various system calls to higher
portions of the protocol stack, e.g., DNS lookup. Nonetheless,
Marc's comment is still reasonable, and whether or not to remove the
sentence seems to depend on the connotations of the phrase
"bump-in-the-stack". For now, we've added the word "some" in front
of the phrase "Bump-in-the-stack implementations" so that the text
now reads:
"c. Security gateways -- integrate IPsec into the IP stack
NOTE: The IPsec module will have access to the following
selectors .... Unlike some Bump-in-the-stack implementations,
security gateways may be able to look up the Source Address in
the DNS to provide a System Name, e.g., in situations involving
use of dynamically assigned IP addresses in conjunction with
dynamically updated DNS entries....
*******************************************************************************
Part 2 -- Changes made to 3/13 drafts (as of 4/23). These are the
changes Ted announced in his email of 4/28 "IPSEC standardization
status" and posted to the Web.
*******************************************************************************
ESP ONLY
1. Clarified when the padding computation takes into account the IV --
per private email of 3/24.
Changed the text in 2.4 "Padding (for Encryption)", first
paragraph after the 3 bullets (which explain the motivation for
padding) from:
The sender MAY add 0-255 bytes of padding. Inclusion of
the Padding field in an ESP packet is optional, but all
implementations MUST support generation and consumption
of padding. The padding computation applies to the
plaintext portion of the Payload Data, exclusive of the
IV (if present).
to:
The sender MAY add 0-255 bytes of padding. Inclusion of
the Padding field in an ESP packet is optional, but all
implementations MUST support generation and consumption
of padding.
a. For the purpose of ensuring that the bits to be
encrypted are a multiple of the algorithm's
blocksize (first bullet above), the padding
computation applies to the Payload Data
exclusive of the IV, the Pad Length, and Next
Header fields.
b. For the purposes of ensuring that the
Authentication Data is aligned on a 4-byte
boundary (second bullet above), the padding
computation applies to the Payload Data
inclusive of the IV, the Pad Length, and Next
Header fields.
2. Corrected and clarified the Outbound and Inbound processing sections
-- per private email on 3/20. We now speak in terms of encryption
always being applied (where no confidentiality is offered by using
the NULL encryption algorithm) so as to avoid confusion about the
following issues:
o encapsulation and padding are always performed whether or not
confidentiality is selected in order to preserve alignment and
put the next protocol field in the right place.
o encryption is always done before authentication
Also corrected decryption to encryption in the Outbound section.
Changed the beginning of (Outbound Processing) Section 3.3.2
"Packet Encryption" from:
If confidentiality is selected, then the sender:
1. encapsulates....
2. adds any necessary padding.
3. encrypts the result ....
- If explicit cryptographic synchronization
data, e.g., an IV, is indicated, it is input
to the decryption algorithm per the algorithm
specification and placed in the Payload field.
- If implicit cryptographic synchronication
data, e.g., an IV, is indicated, it is
constructed and input to the decryption
algorithm as per the algorithm specification.
to:
In this section, we speak in terms of encryption always
being applied because of the formatting implications.
This is done with the understanding that "no
confidentiality" is offered by using the NULL encryption
algorithm. Accordingly, the sender:
1. encapsulates...
2. adds any necessary padding.
3. encrypts the result....
- If explicit cryptographic synchronization
data, e.g., an IV, is indicated, it is input
to the encryption algorithm per the algorithm
specification and placed in the Payload field.
- If implicit cryptographic synchronication
data, e.g., an IV, is indicated, it is
constructed and input to the encryption
algorithm as per the algorithm specification.
Changed the beginning of (Inbound Processing) Section 3.4.5
"Packet Decryption" from:
If confidentiality has been selected, then the receiver:
to:
As in section 3.3.2, "Packet Encryption", we speak here in
terms of encryption always being applied because of the
formatting implications. This is done with the
understanding that "no confidentiality" is offered by
using the NULL encryption algorithm. Accordingly, the
receiver:
===============================================================================
AH and ESP
1. Updated to use IKE instead of ISAKMP/Oakley. Added IKE to Reference
section.
2. Clarified the text explaining the reason for having the receiver notify
the sender if anti-replay is disabled -- per private email
In both AH and ESP, changed Section 3.4.3 "Sequence Number
Verification", paragraph 2
If the receiver does not enable anti-replay for an SA,
no inbound checks are performed on the Sequence Number.
The default for the sender is that the Sequence Number
will be checked at the sender. Hence, if an SA
establishment protocol such as ISAKMP/Oakley is
employed, the receiver SHOULD notify the sender, during
SA establishment, if the receiver will not provide
anti-replay protection.
to:
If the receiver does not enable anti-replay for an SA,
no inbound checks are performed on the Sequence Number.
However, from the perspective of the sender, the default
is to assume that anti-replay is enabled at the
receiver. To avoid having the sender do unnecessary
sequence number monitoring and SA setup (see section
3.3.2), if an SA establishment protocol such as IKE is
employed, the receiver SHOULD notify the sender, during
SA establishment, if the receiver will not provide
anti-replay protection.
Also, changed section 3.3.3 "Sequence Number Generation" to
coordinate with the above change. Inserted the following text
between paragraph 2 and paragraph 3.
The sender assumes anti-replay is enabled as a default,
unless otherwise notified by the receiver (see 3.4.3).
Thus, if the counter has cycled, the sender will set up
a new SA and key (unless the SA was configured with
manual key management).
===============================================================================
ARCHITECTURE
1. Section 4.2 "Security Association Functionality" -- clarified wording of
per email from Bill Sommerfeld on 3/16:
Changed "below" to "outside" in 5th sentence of 3rd paragraph
which now reads:
The scope of the authentication offered by ESP is
narrower than for AH, i.e., the IP header(s) "outside"
the ESP header is(are) not protected.
2. Section 4.2 "Security Association Functionality", paragraph 4 --
clarified Section to reflect the fact that encryption service in ESP
is now optional -- per private email on 3/16.
Changed:
An ESP (tunnel mode) SA between two security gateways can
offer partial traffic flow confidentiality. The use of
tunnel mode allows the inner IP headers to be encrypted,
concealing the identities of the (ultimate) traffic source
and destination.....
to:
If confidentiality service is selected, then an ESP (tunnel
mode) SA between two security gateways can offer partial
traffic flow confidentiality. The use of tunnel mode allows
the inner IP headers to be encrypted, concealing the
identities of the (ultimate) traffic source and
destination....
3. Section 4.4 "Security Association Databases" -- clarified
inbound/outbound terminology and model -- per various private and
public email.
Added the following paragraph at the end of Section 4.4
before 4.4.1:
Each interface for which IPsec is enabled requires
nominally separate inbound vs. outbound databases (SAD
and SPD), because of the directionality of many of the
fields that are used as selectors. Typically there is
just one such interface, for a host or security gateway
(SG). Note that an SG would always have at least 2
interfaces, but the "internal" one to the corporate net,
usually would not have IPsec enabled and so only one
pair of SADs and one pair of SPDs would be needed. On
the other hand, if a host had multiple interfaces or an
SG had multiple external interfaces, it might be
necessary to have separate SAD and SPD pairs for each
interface.
4. Sections 4.4 and 5 -- modified so that mention of the SPD having
entries for inbound traffic, outbound traffic, and for each interface
are brought up in the SPD section (4.4.1) rather than later on in
Section 5 -- per email from Henry Spencer on 3/17
In Section 4.4.1 "The Security Policy Database (SPD)", added the
following paragraph after the first paragraph:
The SPD must be consulted during the processing of all
traffic (INBOUND and OUTBOUND), including non-IPsec
traffic. In order to support this, the SPD requires
distinct entries for inbound and outbound traffic. One
can think of this as separate SPDs (inbound vs.
outbound). In addition, a nominally separate SPD must
be provided for each IPsec-enabled interface.
In Section 5. "IP Traffic Processing", first 2 paragraphs --
removed the text that is now redundant with Section 4.4.1 and
combined them. So that the text changed from:
The SPD must be consulted during the processing of all
traffic (INBOUND and OUTBOUND), including non-IPsec
traffic. Note that the SPD requires distinct entries
for inbound and outbound traffic. One can think of this
as separate SPDs (inbound vs. outbound). Note also that
a nominally separate SPD must be provided for each
IPsec-enabled interface.
If no policy is found in the SPD that matches the packet
(for either inbound or outbound traffic), the packet
MUST be discarded.
into the following text:
As mentioned in Section 4.4.1 "The Security Policy
Database (SPD)", the SPD must be consulted during the
processing of all traffic (INBOUND and OUTBOUND),
including non-IPsec traffic. If no policy is found in
the SPD that matches the packet (for either inbound or
outbound traffic), the packet MUST be discarded.
5. Section 4.4.1, "The Security Policy Database (SPD)" -- modified to
reflect the reduced requirements for reuse of SAs (This was changed
in the last draft in the Outbound Processing Section 5.1.1 "Selecting
and Using and SA or SA Bundle" but not here) -- per email from Henry
Spencer on 3/17 on private email on 4/13
Changed 2nd to last paragraph of Section 4.4.1 "The Security
Policy Database (SPD)" from:
Because a security policy may require that more than one
SA be applied to a specified set of traffic, in a
specific order, the policy entry in the SPD must
preserve these ordering requirements.....For an inbound
IPsec packet for which multiple IPsec SAs are to be
applied, the lookup based on destination address, IPsec
protocol, and SPI should identify a single SA. To allow
minimization of the number of SAs, the linkage between
the SPD and the SAD (at both the sender and the
receiver) MUST allow an SA to be used in more than one
bundle.
to:
Because a security policy may require that more than one
SA be applied to a specified set of traffic, in a
specific order, the policy entry in the SPD must
preserve these ordering requirements.....For an inbound
IPsec packet for which multiple IPsec SAs are to be
applied, the lookup based on destination address, IPsec
protocol, and SPI should identify a single SA. To allow
minimization of the number of SAs, the linkage between
the SPD and the SAD (at both the sender and the
receiver) SHOULD allow an SA to be used in more than one
bundle.
Modified paragraph 5, last 2 bullets from:
b. use the value associated with the policy entry -- if
this were to be just a single value, then there would
be no difference between (b) and (a). However, if
the allowed values for the selector were a range,
then (b) would enable use of the SA by any packet
with a selector value within the range not just by
packets with the selector value of the packet that
triggered the creation of the SA.
c. use a wildcard value -- this can be used to create an
SA that can be shared by a broader set of SPD entries
(vs (b)).
to:
b. use the value associated with the policy entry -- If
this were to be just a single value, then there would
be no difference between (b) and (a). However, if
the allowed values for the selector are a range (for
IP addresses) or a wildcard, then in the case of a
range,(b) would enable use of the SA by any packet
with a selector value within the range not just by
packets with the selector value of the packet that
triggered the creation of the SA. In the case of a
wildcard, (b) would allow use of the SA by packets
with any value for this selector.
Changed paragraphs 6 and 7, from:
For example, suppose there is an SPD entry where the
allowed value for source address is any of a range of
hosts (192.168.2.1 to 192.168.2.10)....
source for the example of
value to be new SAD
used in the SA selector value
--------------- ------------
a. packet 192.168.2.3 (one host)
b. SPD entry 192.168.2.1 to 192.168.2.10
(range of hosts)
c. wildcard * (any host)
Case (c) permits the sharing of an SA (or SA bundle) by
multiple SPD entries. Case (a) can be used to prohibit
sharing, even among packets that match the same SPD
entry.
to:
For example, suppose there is an SPD entry where the
allowed value for source address is any of a range of
hosts (192.168.2.1 to 192.168.2.10)....
source for the example of
value to be new SAD
used in the SA selector value
--------------- ------------
a. packet 192.168.2.3 (one host)
b. SPD entry 192.168.2.1 to 192.168.2.10
(range of hosts)
Note that if the SPD entry had an allowed value of
wildcard for the source address, then the SAD selector
value could be wildcard (any host). Case (a) can be
used to prohibit sharing, even among packets that match
the same SPD entry.
Deleted the last sentence of next to last paragraph. It read:
To allow minimization of the number of SAs, the linkage
between the SPD and the SAD (at both the sender and the
receiver) SHOULD allow an SA to be used in more than one
bundle.
6. Section 4.4.2 "Selectors" -- defined term "opaque" -- per email from
Bill Sommerfeld on 3/16 and Henry Spencer 3/17
Added definition of "opaque" to last sentence of Section 4.4.2
(also changed UserID to "Name")
Note that in the case of receipt of a packet with an ESP
header, e.g., at an encapsulating security gateway or
BITW implementation, the transport layer protocol,
source/destination ports, and UserID (if present) may be
opaque.
to:
Note that in the case of receipt of a packet with an ESP
header, e.g., at an encapsulating security gateway or
BITW implementation, the transport layer protocol,
source/destination ports, and Name (if present) may be
"OPAQUE", i.e., inaccessible because of encryption or
fragmentation.
7. Section 4.4.2 "Selectors", paragraphs on Source IP Address and
Destination IP Address -- corrected text per email from Bill
Sommerfeld on 3/16.
o Changed text for "Source IP Address" to match "Destination IP
Address"
o Corrected text to list "address + mask", clarify what a range
is, match DOI etc.
o Added a note re: not specifying a mix of IPv4 and IPv6
IP addresses
Changed paragraphs on Source and Destination IP Addresses from:
- Source IP Address(es) (IPv4 or IPv6): this may be a
single IP address, range of addresses, or a wildcard
(mask) address. The latter two are required to support
more than one source system sharing the same SA (e.g.,
behind a security gateway or in a multihomed host)....
- Destination IP Address (IPv4 or IPv6): this may be a
single IP address (unicast, broadcast, or multicast
group), a range of addresses, or a wildcard (mask)
address. The latter two are required to support more
than one source system sharing the same SA (e.g., behind
a security gateway or in a multihomed host).....
to:
- Source IP Address(es) (IPv4 or IPv6): this may be a
single IP address (unicast, broadcast, or multicast
group), range of addresses (high and low values
inclusive), address + mask, or a wildcard address. The
last three are required to support more than one source
system sharing the same SA (e.g., behind a security
gateway or in a multihomed host)....
- Destination IP Address (IPv4 or IPv6): this may be a
single IP address (unicast, broadcast, or multicast
group), a range of addresses (high and low values
(inclusive), address + mask, or a wildcard address. The
last three are used to support more than one destination
system sharing the same SA (e.g., behind a security
gateway)....
Added the following text at the end of the first paragraph
in Section 4.4.2 Selectors:
Note also that both Source and Destination addresses
should either be IPv4 or IPv6.
8. Section 4.4.2 Selectors, paragraph on "Source and Destination (e.g.,
TCP/UDP) Ports" -- Amend table to show that "Next Hdr" in SPD is the
"Transport Layer Protocol" selector -- per private email of 3/18.
Changed:
Next Hdr Next Hdr Derived Port Selector Field
in Packet in SPD Value in SPD and SAD
-------- -------- ---------------------------
to:
Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
9. Section 4.4.2 "Selectors" -- correct table near the end of the
section to say that the destination address selector can have a
value of a single address, a range, or a wildcard in the SAD -- per
email from Padma Goli on 4/6/98.
Changed the table near the end of Section 4.4.2 "Selectors"
from:
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
--> dst addr single IP addr single IP addr single,range,wildcard
....
to:
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
--> dst addr single IP addr single,range,wild single,range,wildcard
.....
10. Section 4.4.2 Selectors -- amended text for "Name" to note that
support for name forms other than addresses is not required if
manual keying is used -- per private email on 4/8.
Changed the [REQUIRED section of the part on "Name" from:
[REQUIRED for the following cases.....
to:
[REQUIRED for the following cases. Note that support
for name forms other than addresses is not required for
manually keyed SAs....
11. Sections 4.4.3 "Security Association Database (SAD)" and 5.1.1
"Selecting and Using an SA or SA Bundle" -- corrected inconsistency
between these sections on how to handle failure to find an SA that
matches a given packet (for outbound processing) -- per mail from K.
SrinivasRao on 3/16.
Changed first paragraph from:
In each IPsec implementation there is a nominal Security
Association Database, in which each entry defines the
parameters associated with one SA. Each SA has an entry in
the SAD. For outbound processing, entries are pointed to by
entries in the SPD. Note that if an SPD entry does not
currently point to an SA that is appropriate for the packet,
before it creates an SA, the implementation should check to
see if the SAD already has an appropriate SA (created by some
other SPD entry).
to:
In each IPsec implementation there is a nominal Security
Association Database, in which each entry defines the
parameters associated with one SA. Each SA has an entry in
the SAD. For outbound processing, entries are pointed to by
entries in the SPD. Note that if an SPD entry does not
currently point to an SA that is appropriate for the packet,
the implementation creates an appropriate SA (or SA Bundle)
and links the SPD entry to the SAD entry (see Section 5.1.1).
so that 4.4.3 matches the outbound processing steps in Section
5.1.1, step 2:
2. Match the packet's selector fields against those in the SA
bundles found in (1) to locate the first SA bundle that
matches. If no SAs were found or none match, create an
appropriate SA bundle and link the SPD entry to the SAD
entry. If no key management entity is found, drop the
packet.
12. Section 4.4.3 "Security Association Database (SAD)" -- clarified to
explain how wildcard might be used for IPsec protocol mode -- per
private email in 3/98
Changed Section 4.4.3, paragraph on IPsec Protocol Mode from:
o IPsec protocol mode: tunnel, transport or wildcard.
Indicates which mode of AH or ESP is applied to traffic
on this SA. [REQUIRED for all implementations, unless
implicitly defined by context]
to:
o IPsec protocol mode: tunnel, transport or wildcard.
Indicates which mode of AH or ESP is applied to traffic
on this SA. Note that if this field is "wildcard" at
the sending end of the SA, then the application has to
specify the mode to the IPsec implementation. This use
of wildcard allows the same SA to be used for either
tunnel or transport mode traffic on a per packet basis,
e.g., by different sockets. The receiver does not need
to know the mode in order to properly process the
packet's IPsec headers.
[REQUIRED as follows, unless implicitly defined by context:
- host implementations must support all modes
- gateway implementations must support
tunnel mode]
NOTE: The use of wildcard for the protocol mode of an
inbound SA may add complexity to the situation in the
receiver (host only). Since the packets on such an SA
could be delivered in either tunnel or transport mode,
the security of an incoming packet could depend on which
mode had been used to deliver it. If, as a result, an
application cared about the SA mode of a given packet,
then the application would need a mechanism to obtain
this mode information.
13. Section 4.4.3 "Security Association Database (SAD)" -- clarified
that the Anti-Replay Window is not used when anti-replay is
disabled, e.g., for a manually keyed SA. -- per private email on
4/8.
Changed the "REQUIRED" part of the paragraph on "Anti-Replay
Window" from:
[REQUIRED for all implementations but used only for
inbound traffic.]
to:
[REQUIRED for all implementations but used only for
inbound traffic. NOTE: If anti-replay has been disabled
by the receiver, e.g., in the case of a manually keyed
SA, then the Anti-Replay Window is not used.]
14. [Outbound] Section 5.1.1 "Selecting and Using an SA or SA Bundle" --
clarified that an attempt to create an ESP SA with both a NULL
encryption and NULL authentication algorithm -- per private email
discussion on 3/17.
Added the following text at the end of the section:
NOTE: A compliant implementation MUST not allow instantiation
of an ESP SA that employs both a NULL encryption and a NULL
authentication algorithm. An attempt to negotiate such an SA
is an auditable event.
15. Section 5.1.2.2 "IPv6 -- Header Construction for Tunnel Mode" --
corrected "hop count" to "hop limit" -- per email from Peter Curran
on 4/21.
16. [Inbound] Section 5.2.1 "Selecting and Using an SA or SA Bundle" --
clarified how/when to match packet selectors to the SA selectors --
per private email on 3/18
Changed step 2 from:
....Local policy determines the specificity of the SA
selectors (single value, list, range, wildcard). In
general, a packet's source address SHOULD match the SA
selector value. (However, an AH or ESP-protected ICMP
packet from a gateway may legitimately appear in a
tunnel mode SA with a source IP address other than that
bound to the SA, and thus such packets should be
permitted as exceptions to this check. See Section 6.)
Other packet fields MAY match the SA selector values as
required by local policy.
to:
....Local policy determines the specificity of the SA
selectors (single value, list, range, wildcard). In
general, a packet's source address MUST match the SA
selector value. However, an ICMP packet received on a
tunnel mode SA MAY have a source address other than that
bound to the SA and thus such packets should be
permitted as exceptions to this check. For an ICMP
packet, the selectors from the enclosed problem packet
(the source and destination addresses and ports should
be swapped) should be checked against the selectors for
the SA. Note that some or all of these selectors may be
inaccessible because of limitations on how many bits of
the problem packet the ICMP packet is allowed to carry
or due to encryption. See Section 6.
17. Section 6.1.2 Path MTU Discovery (PMTU) -- Fixed parenthetical
definition of IPv6 "Code 0" -- per private email of 3/18.
Changed from:
IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed and DF set)
- Next-Hop MTU in the 32 bit MTU field of the
ICMP6 message
to:
IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed)
- Next-Hop MTU in the 32 bit MTU field of the
ICMP6 message
18. Appendix B.2 "Fragmentation" -- corrected number of cases from 24 to
20, fixed a couple of minor wording problems.
19. Appendix B.2 "Fragmentation" -- modified text to reflect changes
previously made in the main body of the text:
- remove TOS/Class from list of selectors (per comment in a
private email)
- add lookup of SPD entry in addition to look up of SA (caught
as part of editing process).
Changed the 5th paragraph, item (b) from:
b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer
and network drivers...
.....
At the network layer, the IPsec module will have access to
the following selectors from the packet -- SRC address, DST
address, TOS, Next Protocol, and if there's a transport layer
header --> SRC port and DST port. One cannot assume IPsec
has access to the User ID. It is assumed that the available
selector information is sufficient to figure out the relevant
Security Association(s).
to:
At the network layer, the IPsec module will have access to
the following selectors from the packet -- SRC address, DST
address, Next Protocol, and if there's a transport layer
header --> SRC port and DST port. One cannot assume IPsec
has access to the User ID. It is assumed that the available
selector information is sufficient to figure out the relevant
Security Policy entry and Security Association(s).
Changed the 5th paragraph, item (c) from:
c. Security gateways -- integrate IPsec into the IP stack
NOTE: The IPsec module will have access to the following
selectors from the packet -- SRC address, DST address,
TOS/Class, Next Protocol, and if there's a transport layer
header --> SRC port and DST port. It won't have access to
the User ID (only Hosts have access to User ID information.)
It also won't have access to the transport layer information
if there is an ESP header, or if it's not the first fragment
of a fragmented message. It is assumed that the available
selector information is sufficient to figure out the relevant
Security Association(s).
to:
NOTE: The IPsec module will have access to the following
selectors from the packet -- SRC address, DST address, Next
Protocol, and if there's a transport layer header --> SRC
port and DST port. It won't have access to the User ID (only
Hosts have access to User ID information.) Unlike
Bump-in-the-stack implementations, security gateways may be
able to look up the Source Address in the DNS to provide a
System Name, e.g., in situations involving use of dynamically
assigned IP addresses in conjunction with dynamically updated
DNS entries. It also won't have access to the transport
layer information if there is an ESP header, or if it's not
the first fragment of a fragmented message. It is assumed
that the available selector information is sufficient to
figure out the relevant Security Policy entry and Security
Association(s).
20. Corrected references in Section B.3.4 "Per Socket Maintenance of
PMTU Data" -- per email from Rohit Aradhya on 3/21.
Changed from:
Implementation of the calculation of PMTU (Section
B.2.2) and support for PMTUs at the granularity of
individual "communication associations" (Section B.2.3)
is a local
matter.
to:
Implementation of the calculation of PMTU (Section
B.3.2) and support for PMTUs at the granularity of
individual "communication associations" (Section B.3.3)
is a local matter.
Follow-Ups: