[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Summary list -- IPsec Architecture
Folks,
Here's a summary of IPsec architecture issues and what we believe to be
their current resolution/status. This is based on the draft distributed
in 11/97, subsequent email (up until 1/31) including the summaries of
IETF discussions, and feedback received recently on SA lifetimes. It
does not include some minor edits (typos), the addition of the new
copyright text required by the RFC format instructions, etc. The issues
have been divided into 2 groups:
1. NO ACTION -- the draft has been left as is; rationale or a
pointer to the relevant email is included below.
2. CHANGES MADE -- the draft has been changed as described below.
The Architecture draft has been submitted to the IETF secretariat for
distribution. Per direction from the working group chairs, we also sent
the draft to the mailing list to minimize the delay in getting it to the
community.
As with the AH/ESP specs, thank you for the feedback both on the list
and privately.
Karen
NO ACTION
===============================================================================
1. Section 3.0 "System Overview" -- Should support for "discard"
function be MUST (as in current doc)?
* see email from S. Kent 12/7/97 (Subj: "responses to comments
in the Architecture Document") for rationale -- no comments
were received
2. Section 4.4.1 "Security Policy Database" -- Should entries in SPD be
ordered (as currently specified)?
* see email from S. Kent 12/7/97 (Subj: "responses to comments
in the Architecture Document") for rationale -- no comments
were received on this specific issue, but people did bring up
closely related issues which are discussed below.
3. Section 4.4.1 "Security Policy Database" -- How to select which SAD
and/or SPD entries to use if multiple entries match? The
architecture document requires use of the first matching entry
encountered and correspondingly requires use of ordered entries to
achieve the desired security goals.
Some email has interpreted "ordered SPD" to imply the ordering that
exists AFTER the user input has been processed by a vendor-specific
algorithm. The intent of the draft is that "ordered SPD" means the
user specified (e.g., ASCII) ordering of the SPD input. Email
discussions centered on whether one could "use the most restrictive
SA" (and presumably policy) if one followed this approach. Some
folks said that they can specify "most restrictive" SAD entries but
cannot also specify an ordering of the SPD input that results in the
same mapping to SAD entries. To first order, it would appear to be
possible to create a list of entries (SAs or policies) ordered to
enable the first match to be the "most restrictive." This can be
achieved by defining the rules for "restrictiveness" and then
ordering the SPD/SAD entries from most to least restrictive. The
participants in the discussion did not define "most restrictive" nor
how they were "ordering" the SAD/SPD entries.
The basic issue for SPD ordering is that SPD selectors define an
n-space, for n => 5 (Source IP, Dest IP, Protocol, Source Port, Dest
Port, Name). There does not appear to be a way to cannonically order
SPD entries in this space, given that some may be "don't care,"
others may have specific values, and IP addresses can have ranges.
(Mathematically, the set of SPD entries forms a lattice. One could
use set inclusion to induce a partial order, but not a total order.)
So, the editors believe that the SPD must be searched in a linearly
ordered fashion, with the order determined by the system
adminitrator.
4. Section 4.4.1 "Security Policy Database" -- Should support be
provided for sharing of SAs or SA bundles? Currently, the spec
calls for sharing of SAs.
* see email from S. Kent 12/7/97 (Subj: "responses to comments
in the Architecture Document") for rationale -- no comments
were received
5. Section 4.4.1 "Security Policy Database" -- Per email from Gordon
Oliver (12/12/97) -- Should guidance be provided "about what kinds of
policies are allowed and the associations between policies and
bundles."
* The allowable policies are those expressable with the IPsec
selectors and are determined by local administration and
defined in the SPD. No comments were received.
6. Section 4.4.2 "Selectors" -- Should we add "negative" entries, i.e.,
the ability to specify that a selector value NOT be x. This would
support creation of ranges with holes. Currently this is not
supported by the spec.
* see email from S. Kent 12/7/97 (Subj: "responses to comments
in the Architecture Document") which notes that the ability to
have negative entries is "implicit in the SPD, in that DISCARD
is a processing option for traffic." At present, ISAKMP does
not support negotiation of SAs with negative selectors, e.g.,
to create "holes" in address space ranges or exceptions to
"any" matches. So, we can't support negative entries in this
sense. However, using DISCARD as a processing option for an
entry does allow local expression of negative entries. No
comments were received.
7. Section 5.2.1 Selecting and Using an SA or SA bundle -- Need to
verify that ISAKMP and DOI support specification of the ordering of
application of IPsec headers.
* This has become irrelevant since the document calls for only
one case of "nested" IPsec headers, [IP1][AH][ESP][upper], -->
no negotiation of ordering is needed.
8. Section "6. ICMP Processing (relevant to IPsec)" -- Per email from
Gordon Oliver (12/2/97) -- how should we handle "an ICMP packet that
signifies an error that will not necessarily recover [sic] (i.e., not
MTU)..." when "...there isn't enough information to forward the ICMP
packet...? Dropping the ICMP on the floor will cause poor behavior
on the network....(suppose it'd work though)"
* No comments received -- deferred to IPsecond.
9. Section "6. ICMP Processing (relevant to IPsec)" -- Need to discuss
how to avoid the unauthorized disclosure of information that could
occur if decrypted IP packet contents were included in an ICMP error
message. In other words, a packet could be decrypted and then an
error could occur which triggers the transmission of an ICMP error
message containing the decrypted data. The ICMP error message with
its decrypted contents is then not identified as requiring
confidentiality in transiting back to the source. This could happen
for many reasons, e.g., the ICMP error message could take a different
path (with a different security policy) on the return route.
* This is deferred to IPsecond.
10. Section "6.1.2.1 Propagation of PMTU" -- Should propagation of PMTU
by security gateway be a MUST or a SHOULD? The current draft says
MUST to ensure that the host learns, as quickly as possible, that
there is an MTU problem downstream.
11. Section "6.1.2.4 PMTU Aging" -- From Cheryl Madson's email of 11/21
on "IPSEC SA doc comments" -- "16. Page 35, first full paragraph.
What's the general opinion been of using the behavior described in
RFC1191 as opposed to what's been described in RFC2003? [I'm talking
about the issue of whether or not to forward the packet through the
tunnel anyhow if it's too big.].
* Unclear on the [comment] in this context, but the paragraph in
question is the last paragraph of 6.1.2.4 PMTU Aging. It
says:
"Systems SHOULD use the approach described in the Path
MTU Discovery document (RFC 1191, Section 6.3), which
suggests periodically resetting the PMTU to the
first-hop data-link MTU and then letting the normal PMTU
Discovery processes update the PMTU as necessary. The
period SHOULD be configurable."
No comments were received. RFC 1191 talks about how a host or
gateway should do PMTU discovery in general and includes a
discussion of how to age the PMTU, etc. RFC 2003 doesn't talk
about aging the soft state. So it makes sense to use RFC1191
for the model for this section.
CHANGES MADE (* indicates the change made)
===============================================================================
1. Section 4.1 -- Per discussion of "some issues about IPsec" re: tunnel
and transport modes (1/11-28) -- Two topics were raised.
1. Why have both tunnel and transport mode?
2. Which modes are used when (host to host, SG to SG, host to SG
(for gateway management), host to SG (for road warrior)?
* Added the following text at "Section 4.1 "Definition and
Scope" [of SAs]:
In summary:
a) A host MUST support both transport and tunnel mode
(per your message of 1/25)?
b) A security gateway is required to support only tunnel
mode. If it supports transport mode, that should be
used only when the security gateway is acting as a
host, e.g., for network management.
2. Section 4.2 "Security Association Functionality" -- For tunnel-mode
SAs, is clarification needed about SA granularity and vulnerability
to traffic analysis?
* Added the sentence at the end of the last paragraph of this
section, which now reads:
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.
Moreover, ESP payload padding also can be invoked to hide the
size of the packets, further concealing the external
characteristics of the traffic. Similar traffic flow
confidentiality services may be offered when a mobile user is
assigned a dynamic IP address in a dialup context, and
establishes a (tunnel mode) ESP SA to a corporate firewall
(acting as a security gateway). Note that fine granularity SAs
generally are more vulnerable to traffic analysis than coarse
granularity ones that are carrying traffic from many
subscribers.
3. Section 4.3 "Combining Security Associations -- Is clarification
needed on how to handle ISAKMP traffic in the context of iterated
tunneling?
* Section 4.5 page 22 already discusses this, so a pointer to
this section has been added along with some clarifications.
The text for Section 4.3 now reads:
"o Iterated tunneling refers to the application of multiple
layers of security protocols effected through IP tunneling.
This approach allows for multiple levels of nesting, since
each tunnel can originate or terminate at a different IPsec
site along the path. No special treatment is expected for
ISAKMP traffic at intermediate security gateways other than
what can be specified through appropriate SPD entries
(See Case 3 in Section 4.5)
"These two approaches also can be combined, i.e., an SA bundle
could be constructed from one tunnel mode SA and one or two
transport mode SAs, applied in sequence. (See Section 4.5 "Basic
Combinations of Security Associations.") Note that nested
tunnels can also occur where neither the source nor the
destination endpoints of any of the tunnels are the same. In
that case, there would be no host or security gateway with a
bundle corresponding to the nested tunnels.
4. Section "4.3 Combining Security Associations" -- Need clarification
of "iterated tunneling". Need clarification of "These two approaches
can also be combined".
* Added the following diagram after the paragraph on "Transport
adjacency"
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -----Security Association 1 (ESP transport)------- |
| |
-------Security Association 2 (AH transport)----------
* Added the following text and diagrams after the paragraph on
"Iterated tunneling":
There are 3 basic cases of iterated tunneling -- support is
required only for cases 2 and 3.
1. both endpoints for the SAs are the same -- The inner and
outer tunnels could each be either AH or ESP, though it is
unlikely that Host 1 would specify both to be the same,
i.e., AH inside of AH or ESP inside of ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -------Security Association 1 (tunnel)---------- | |
| |
---------Security Association 2 (tunnel)--------------
2. one endpoint of the SAs is the same -- The inner and
outer tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 |
| | | |
| ----Security Association 1 (tunnel)---- |
| |
---------Security Association 2 (tunnel)-------------
3. neither endpoint is the same -- The inner and outer tunnels
could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| Gwy 1 Gwy 2 |
| | | |
| --Security Assoc 1 (tunnel)- |
| |
-----------Security Association 2 (tunnel)-----------
5. Section 4.4.1 "Security Policy Database" (paragraph 5)-- Needs
clarification of the 3 cases of allowable values for each selector
* Changed text from:
The SPD contains an ordered list of policy entries. Each policy
entry is keyed by one or more selectors that define the set of
IP traffic encompassed by this policy entry.... For each
selector, the policy entry specifies which of the following
values should used in the SA: (a) the value in the packet, (b)
the value associated with the policy, or (c) a wildcard.
to:
The SPD contains an ordered list of policy entries. Each policy
entry is keyed by one or more selectors that define the set of
IP traffic encompassed by this policy entry.... For each
selector, the policy entry specifies how to derive the
corresponding values for a new SAD entry from those in the SPD
and the packet (Note that at present, ranges are only supported
for IP addresses; but wildcarding can be expressed for all
selectors):
a. use the value in the packet itself -- This will limit
use of the SA to those packets which have this
packet's value for the selector even if the selector
for the policy entry has a range of allowed values
or a wildcard for this selector.
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)).
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). And suppose that a packet is to be sent that
has a source address of 192.168.2.3. The value to be used for
the SA could be any of the sample values below depending on what
the policy entry for this selector says is the source of the
selector value:
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)
6. Section 4.4.1 "Security Policy Database" What should be done re:
ISAKMP (encrypted) traffic traversing a security gateway that does
not normally allow transit traffic to be encrypted? May need to
mention proxy key exchange as a possible mechanism for enabling
encrypted packet traversal.
* Changed last paragraph from:
The SPD also will be consulted when any IPsec implementation is
the target of an SA establishment request from another IPsec
implementation, e.g., using ISAKMP/Oakley.
to:
The SPD is used to control the flow of ALL traffic through an
IPsec system, including security and key management traffic
(e.g., ISAKMP/Oakley) from/to entities behind a security
gateway. This means that ISAKMP traffic must be explicitly
accounted for in the SPD, else it will be discarded. Note that
a security gateway could prohibit traversal of encrypted packets
in various ways, e.g., having a DISCARD entry in the SPD for ESP
packets or providing proxy key exchange. In the latter case,
the traffic would be internally routed to the key management
module in the security gateway.
7. Section 4.4.2 "Selectors" -- There are discrepancies between the
draft's SPD/SAD values and ISAKMP/Oakley's ability to negotiate
these values for an SA. The DOI does not support value "ranges" for
any selector besides IP addresses. It also does not support
enumerated lists, TOS, IPv6 Flow Label, IPv6 Class.
* Removed enumerated lists from Destination IP Address, Source IP
Address, Transport Layer Protocol, Source and Destination Ports
(and a few other places in the text)
* Removed range from Transport Layer Protocol
* Removed TOS, IPv6 Flow Label, and IPv6 Class
* Updated table on page 19 to reflect above changes
* Added the following text at the end of section 4.4.2
NOTE: In principle, one could have selectors and/or selector
values in the SPD which cannot be negotiated for an SA or SA
bundle. Examples might include selector values used to select
traffic for discarding or enumerated lists which cause a
separate SA to be created for each item on the list. For now,
this is left for future versions of this document and the list
of required selectors and selector values is the same for the
SPD and the SAD. However, it is acceptable to have an
administrative interface that supports use of selector values
which cannot be negotiated provided that it does not mislead the
user into believing it is creating an SA with these selector
values. For example, the interface may allow the user to
specify an enumerated list of values but would result in the
creation of a separate policy and SA for each item on the list.
A vendor might support such an interface to make it easier for
its customers to specify clear and concise policy
specifications.
8. Section 4.4.2 "Selectors" -- Why do we have the Transport Protocol
selector separate from the IPsec protocol selector?
* It had been suggested that administrators might want this for
the SPD. However, it appears that it is not possible to
negotiate IPsec protocol separately from Transport Protocol.
At the last IETF meeting, we agreed to drop this, at least for
now. It can be argued that supporting both provides greater
filtering functionality, but whenever we have such filter
functionality and we cannot negotiate an SA to correspond to
it, we cause potential problems/confusion. (DISCARD and
BYPASS filters are something of an exception in that they
don't result in SAs, but even there we have possible
confusion.)
The paragraphs on IPsec protocol have been removed. This
specific issue and the more general one of having selectors
for the SPD that are not negotiable for the SAD is deferred to
IPsecond.
9. Section 4.4.2 "Selectors" -- Should there be support for the
selector "names"?
* Rationale behind use of "name" as a selector is discussed in
email from S. Kent 12/7/97 (Subj: "responses to comments in
the Architecture Document"). While this will add complexity
to SPD management (as discussed in the 12/7 email), folks said
they wanted this. So, the choice was either to defer this for
now and not support dialup users with dynamically assigned IP
addresses, or to support it and buy into the added complexity.
It was proposed in the 12/7 email that names be added as a
selector -- no comments were received. Therefore the
following text has replaced the section for UserID.
"- Name: There are 2 cases (Note that these name forms are
supported in ISAKMP.)
1. User ID
a. a fully qualified user name string (DNS), e.g.,
mozart@foo.bar.com
b. X.500 distinguished name, e.g., C = US, SP = MA,
O = GTE Internetworking, CN = Stephen T. Kent.
2. System name (host, security gateway, etc.)
a. a fully qualified DNS name, e.g., foo.bar.com
b. X.500 distinguished name
c. X.500 general name
Note that one of the possible values of this selector is
"OPAQUE".
[REQUIRED for
o User ID
- native host implementations
- BITW and BITS implementations acting as HOSTS
with only one user
- security gateway implementations for INBOUND
processing.
o System names -- all implementations]
10. Section 4.4.2 "Selectors" -- Need to clarify "Destination IP
Address" sentence -- the one in the outer IP header is not
necessarily the one in the IP header/packet being protected.
* Changed the text for Destination IP Address from:
- Destination IP Address (IPv4 or IPv6): .... Note that
this selector is conceptually different from the
"Destination IP Address" field in the <Destination IP
Address, IPsec Protocol, SPI> used to uniquely
identify an SA. It could have the same value.
to:
- Destination IP Address (IPv4 or IPv6): .... Note that
this selector is conceptually different from the
"Destination IP Address" field in the <Destination IP
Address, IPsec Protocol, SPI> tuple used to uniquely
identify an SA. When a tunnelled packet arrives at
the tunnel endpoint, its SPI/Destination
address/Protocol are used to look up the SA for this
packet in the SAD. This destination address comes
from the encapsulating IP header. Once the packet has
been processed according to the tunnel SA and has come
out of the tunnel, its selectors are "looked up" in
the Inbound SPD. The Inbound SPD has a selector
called destination address. This IP destination
address is the one in the inner (encapsulated) IP
header. In the case of a transport'd packet, there
will be only one IP header and this ambiguity does not
exist.
11. Section 4.4.2 "Selectors" -- Need to correct required support for
Transport Layer Protocol (MAY --> MUST for IPv4) and Ports (REQUIRED
--> MAY). Need to clarify how fragmentation impacts availability of
Port information.
* Changed the paragraph on "Transport Layer Protocol" from:
[REQUIRED for IPv6 implementations, MAY be supported in
IPv4 implementations]
to:
[REQUIRED for all implementations]
* Changed the paragraph on "Source and Destination (e.g.,
TCP/UDP) Ports" from:
[REQUIRED for all implementations]
to:
[MAY be supported]
* Added text at the end of the paragraph on "Source and
Destination (e.g., TCP/UDP) Ports"
The following table summarizes the relationship between the
"Next Header" value in the packet and SPD and the derived Port
Selector value for the SPD and SAD.
Next Hdr Next Hdr Derived Port Selector Field
in Packet in SPD Value in SPD and SAD
-------- -------- ---------------------------
ESP ESP or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragment
If the packet has been fragmented, then the port information
may not be available in the current fragment. If so, discard
the fragment. An ICMP PMTU should be sent for the first
fragment, which will have the port information.
12. Section 4.4.3 "Security Association Database" -- Per discussion on
the list (email 1/22 to 1/23, Subject: "Security Association
Lifetimes in kbytes") -- Need to add a note about how one might
handle refreshing of keys when SAs expire. The following approach
was described by Dan McDonald (email 1/23).
* Changed the relevant bulleted item in Section 4.4.3 from:
o Lifetime of this Security Association: a time interval
after which an SA must be replaced with a new SA (and
new SPI) or terminated, plus an indication of which of
these actions should occur. This may be expressed as
a time or byte count.
to:
o Lifetime of this Security Association: a time interval
after which an SA must be replaced with a new SA (and
new SPI) or terminated, plus an indication of which of
these actions should occur. This may be expressed as
a time or byte count. If time is employed, and if IKE
employs X.509 certificates for SA establishent, the SA
lifetime must be constrained by the validity intervals
of the certificates, and the NextIssueDate of the CRLs
used in the IKE exchange for the SA. Both initiator
and responder are responsible for constraining SA
lifetime in this fashion.
[REQUIRED for all implementations]
NOTE: The details of how to handle the refreshing of
keys when SAs expire is a local matter. However, one
reasonable approach is:
(a) If byte count is used, then the
implementation SHOULD count the number of
bytes to which the IPsec algorithm is
applied.
(b) There SHOULD be two kinds of lifetime -- a
soft lifetime which warns the implementation
to initiate action such as setting up a
replacement SA and a hard lifetime when the
current SA ends.
(c) If the entire packet does not get delivered
during the SAs lifetime, the packet SHOULD
be discarded.
13. Section 4.5 "Basic Combinations of Security Associations" -- The
working group has agreed that ONLY the 4 cases outlined here are
mandatory. Problems only arise if both the source and destination
endpoints of an SA are the same. In that case, the only "nesting"
case for which support is required is AH followed by ESP in
transport mode i.e., [IP1][AH][ESP][upper].
* Changed 2nd paragraph in Case 4 from:
Only tunnel mode is required between H1 and SG2. So the
headers in a packet between H1 and SG2 would look like
one of the ones in case 2.
to:
Only tunnel mode is required between H1 and SG2. So the
headers for the SA between H1 and SG2 would look like
one of the ones in case 2. The headers for the SA
between H1 and H2 would like one of the ones in case 1,
* Removed the text below that was at the end of the section:
"The following combinations of AH and ESP MUST be
supported in the indicated contexts:
- Cases 1, 3, 4 (between H1 and H2):
a. AH in transport mode
b. ESP in transport mode
b. AH followed by ESP in transport mode
d. any one of a, b, or c above AH or ESP in
tunnel mode
- Cases 1, 2, 3, and 4 (all SAs shown):
e. AH in tunnel mode
f. ESP in tunnel mode"
14. Section 4.5 "Basic Combinations of Security Associations" -- Do we
need to specify support for linking together the multiple ISAKMP
negotiations associated with nested SAs?
* Given the agreed upon set of SA combinations that MUST be
supported, this situation mostly does not arise. There is no
requirement to support general nesting which is therefore
deferred to IPsecond. However, in cases 1 and 4, Outbound
Processing must apply multiple IPsec headers in the "correct"
order. Therefore the following notes have been added.
In Section 4.5 Case 1, the text has been changed from:
Note that either transport or tunnel mode can be
selected by the hosts. Also, in transport mode at the
sender, first ESP, then AH can be applied to the packet.
So the headers in a packet between H1 and H2 could look
like any of the following:
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]
to:
Note that either transport or tunnel mode can be
selected by the hosts. So the headers in a packet
between H1 and H2 could look like any of the following:
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]
Note that there is no requirement to support general
nesting, but in transport mode, both AH and ESP can be
applied to the packet. In this event, the SA
establishment procedure MUST ensure that first ESP, then
AH are applied to the packet.
In section 4.5 Case 4, the following note has been added
after the last paragraph:
Note that in this case, the sender MUST apply the
transport header before the tunnel header. Therefore
the management interface to the IPsec implementation
MUST support configuration of the SPD and SAD to ensure
this ordering of IPsec header application.
15. Section 5. "IPsec Traffic Processing" -- Need to clarify that
Inbound and Outbound processing apply to ALL traffic not just IPsec
traffic.
* Changed section titles from "IPsec Traffic" to "IP Traffic"?
* Added text at the beginning of Section 5 that says:
"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."
16. Section 5 -- Per email from SrinivasRao (1/13) re:"Do we need
host-to-network conversion for ESP header" -- We interpreted this to
refer to the fact that different IPsec platforms will use different
native byte ordering and that therefore we need to point out that
all of the cryptographic algorithms expect their input in canonical
network byte order and generate their output in canonical network
byte order.
* Added the following text at the beginning of "Section 5. IPsec
Traffic Processing" (now changed to "IP Traffic Processing" as
described above) before the Output and Input sections.
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.
17. Section 5 -- Need to clarify the default if no match is found in
SPD. This applies to inbound and outbound traffic processing.
* Added text at the beginning of Section 5 that says: "If no
policy is found in the SPD that matches the packet (for either
inbound or outbound traffic), the packet MUST be discarded."
18. Section "5.1.1. Selecting and Using an SA or SA Bundle" [outbound
processing] -- Several issues have come up.
a) How much searching of the SPD and SAD should be done
before creating a new SA?
* Several approaches to this have been brought up on the list,
e.g., see email from S. Kent 12/7/97 in reply to Ly Loi (Subj:
"Re: IPSEC arch comments"). There is a tradeoff between
spending more time to search the SAD to avoid creating
unnecessary SAs and using more space by creating potentially
redundant SAs by using the first SPD hit (if it does not point
to a matching SA). One possible enhancement would be to note
which policies create overlapping SAs when the SPD is created.
There weren't many comments, but the general feeling seemed to
be in favor of creating an SA for the first policy hit rather
than searching the whole SAD.
b) How does one make sure that an existing SA (initiated by another
system) is used for outgoing traffic that otherwise would be
passed through without IPsec processing because local policy
requires no IPsec processing at all.
* Changed the text to explicitly state that the SPD be linked
to the SAD when an SA is created.
c) How should one handle failure to find local keying entity?
* Add text to address this situation.
To address these 3 issues, the text for step 2 has been changed from:
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, search the SAD for an SA (created by other SPD
entries) that matches. If none exist, create an
appropriate SA bundle.
to:
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.
19. Sections "5.1.2 Header Construction for Tunnel Mode" and "5.1.2.1
IPv4 -- Header Construction for Tunnel Mode" -- Can the source
address of the encapsulating IP header be *any* address of the
originating security gateway, i.e., an IP address of the security
gateway other than the one through which the packet would be
forwarded.
* Changed 5.1.2 "Header Construction for Tunnel Mode" from:
o The outer IP header Source Address and Destination Address
identify the "endpoints" of the tunnel (the encapsulator
and decapsulator). The inner IP header Source Address
and Destination Addresses identify the original sender
and recipient of the datagram, respectively.
to:
o The outer IP header Source Address and Destination Address
identify the "endpoints" of the tunnel (the encapsulator
and decapsulator). The inner IP header Source Address
and Destination Addresses identify the original sender
and recipient of the datagram, respectively. (see
footnote 3 after the table in 5.1.2.1 for more details
on the encapsulating source IP address.)
* Added the following text to footnote 3 of section 5.1.2.1
"IPv4 -- Header Construction for Tunnel Mode".
NOTE: In principle, the encapsulating IP source address
can be any of the encapsulator's interface addresses or
even an address different from any of the
encapsulator's IP addresses, (e.g., if it's acting as a
NAT box) so long as the address is reachable through
the encapsulator from the environment into which the
packet is sent. This does not cause a problem because
IPsec does not currently have any INBOUND processing
requirement that involves the Source Address of the
encapsulating IP header. So while the receiving tunnel
endpoint looks at the Destination Address in the
encapsulating IP header, it only looks at the Source
Address in the inner (encapsulated) IP header.
20. Sections "5.1.2.1 IPv4 -- Header Construction for Tunnel Mode" and
"5.1.2.2 IPv6 -- Header Construction for Tunnel Mode" -- What should
be the "Next Header" field:
* Modified footnote 5 in 5.1.2.1 from
5. If Inner Hdr is IPv4, copy the TOS. If Inner Hdr is
IPv6, map the Class to TOS.
to:
5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS.
If Inner Hdr is IPv6 (Protocol = 41), map the Class
to TOS.
* Modified footnote 6 in 5.1.2.2 from
6. If Inner Hdr is IPv6, copy the Class. If Inner Hdr
IPv4, map the TOS to Class.
to:
6. If Inner Hdr is IPv6 (Next Header = 41), copy the
Class. If Inner Hdr is IPv4 (Next Header = 4), map
the TOS to Class.
21. Section 5.2.1 Selecting and Using an SA or SA bundle (part of 5.2
Processing Inbound IPsec Traffic) -- The question has been raised as
to whether there should be OPTIONAL support for "post IPsec
processing to include forwarding and additional IPsec processing".
* Added the following text at the end of the section:
Note that in the case of a security gateway, if
forwarding causes a packet to exit via an IPsec-enabled
interface, then additional IPsec processing may be
applied.
22. Section 5.2.1 Selecting and Using an SA or SA bundle (part of 5.2
Processing Inbound IPsec Traffic) -- Need to add error handling if
a matching SA is not found.
* Added the following text at the end of step 1.
If the SA lookup fails, drop the packet and log/report
the error.
23. Section "6. ICMP Processing (relevant to IPsec)" -- Need to clarify
that this section applies to ICMP error messages not other ICMP
traffic, e.g., Echo/Reply.
* At the beginning of the section, added:
"The focus of this section is on the handling of ICMP
error messages. Other ICMP traffic, e.g., Echo/Reply,
should be treated like other traffic and can be
protected on an end-to-end basis using SAs in the usual
fashion."
24. Section "6. ICMP Processing (relevant to IPsec)" -- Should a
security gateway that receives a PMTU message not directed to it,
forward that message in an IPsec tunnel? (In the current spec,
router-generated IPsec-protected ICMP (error) messages are not
subjected to source address checks.)
* Modified the first sentence of the section from:
"An ICMP message protected by AH or ESP and generated by
a router SHOULD be processed and forwarded in a tunnel
mode SA, and MUST NOT be subjected to source address
checks."
to:
"An ICMP error message protected by AH or ESP and
generated by a router SHOULD be processed and forwarded
in a tunnel mode SA. Local policy determines whether or
not it is subjected to source address checks by the
router at the destination end of the tunnel. Note that
if the router at the originating end of the tunnel is
forwarding an ICMP error message from another router,
the source address check would fail."
25. Section "6. ICMP Processing (relevant to IPsec)" -- Need to note
that the authenticity of the returned IP header in an ICMP error
message could be invalid even if the source address is OK.
* Added the following text at the end of the first paragraph of
the section:
"Note that even if the source of an ICMP error message
is authenticated, the returned IP header could be
invalid. Accordingly, the selector values in the IP
header SHOULD also be checked to be sure that they are
consistent with the selectors for the SA over which the
ICMP message was received."
26. Section "6.1.2.2 Calculation of PMTU" -- What should happen if "the
PMTU drops below the acceptable limit (e.g., below zero)"?
* Per suggestion from Gordon Oliver (12/2/97), added the
following note at the end of this section.
"Note: In some situations the addition of IPsec headers
could result in an effective PMTU (as seen by the host
or application) that is unacceptably small. To avoid
this problem, the implementation may establish a
threshold below which it will not report a reduced PMTU.
In such cases, the implementation would apply IPsec and
then fragment the resulting packet according to the
PMTU. This would result in a more efficient use of the
available bandwidth."
27. Section "6.1.2.2 Calculation of PMTU" -- How should a socket-based,
host IPsec implementation handle a PMTU message, given that the
socket interface would already be aware of the space devoted to
local use of IPsec (on the socket in question)
* This section has a pointer to the appendix "B.3.2 Calculation
of PMTU", which covers this topic but has an example which
involves nesting beyond what is currently allowed. B.3.2 has
been revised to reflect the simplifications that have been
made to nesting support requirements. The original text has
been changed from:
The calculation of PMTU from an ICMP PMTU has to take
into account the addition of any IPsec header by H1 --
AH and/or ESP transport, or ESP or AH tunnel. Within a
single host, multiple applications may share an SPI and
nesting of security associations may occur. The diagram
below illustrates several possible combinations of
security associations between a pair of hosts (as viewed
from the perspective of one of the hosts.) (ESPt or AHt
= tunnel mode; ESPx or AHx = transport mode)
Socket 1 ----------------------------------------------- I
| n
Socket 2 (ESPt/SPI-A) ------------------------------- | t
| | e
Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r
| n
Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e
t
In order to figure out the PMTU for each socket that
maps to SPI-E, it will be necessary to have backpointers
from SPI-E to each of the four paths that lead to it --
Socket 1, SPI-A, SPI-D, and SPI-H
to:
The calculation of PMTU from an ICMP PMTU has to take
into account the addition of any IPsec header by H1 --
AH and/or ESP transport, or ESP or AH tunnel. Within a
single host, multiple applications may share an SPI and
nesting of security associations may occur. (See
Section 4.5 Basic Combinations of Security Associations
for description of the combinations that MUST be
supported). The diagram below illustrates an example of
security associations between a pair of hosts (as viewed
from the perspective of one of the hosts.) (ESPx or AHx
= transport mode)
Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet
In order to figure out the PMTU for each socket that
maps to SPI-B, it will be necessary to have backpointers
from SPI-B to each of the 2 paths that lead to it --
Socket 1 and Socket 2/SPI-A.
28. Section 8 "Use in Systems Supporting Information Flow Security" --
Need changes to Intro to make it clear that these requirements apply
to a wider range of systems than just "MLS".
* The text in the Intro (the paragraphs before 8.1) has been
slightly re-worded to be more general and cover information
flow security rather than just multi-level security.
29. Section "References" -- Need to update references
* Verified all references are used in the spec
* Put in latest revs of IPsec documents
30. Some minor edits:
* Defined SAD when it's first used
* Indent 5.2.1 and 5.2.2 in table of contents