[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
responses to comments in the Architecture Document
<fontfamily><param>Times</param><bigger><bigger>Folks,
Ted asked me to review the comments that have arrived over the
last two weeks, re the IPsec Architecture Document. I apologize for
not having responded to each of these as they arrived, but the
Thanksgiving holidays and other job-related matters have fully
occupied my time.
The approach I have taken is to provide responses to comments
in an integrated fashion, not on a per-commenter basis, proceeding
serially through the document. Karen Seo scanned all of the messages
and keyed them to the document in this fashion, in hopes of
integrating related comments from various sources. However, a few
comments
that I've received privately were not forwarded to Karen and thus were
not addressed
in this response. I'll get to those soon.
I'd like to extend a special thanks to Cheryl Madson who wins the
prize
for the greatest range and number of comments on the current draft.
Steve
---------------
Section 3.0
We now require any IPsec implementation to incorporate an explicit
discard function, at the same (selector) granularity as any other
IPsec processing. It has been noted that this may be redundant if a
firewall is "behind" the IPsec implementation, prepared to effect
discarding for traffic. I assume the suggested change would be to
bypass any traffic for which no IPsec processing was specified, and
make provision of an explicit discard function a "MAY" feature.
The argument in favor of the status quo is that inclusion of this
facility makes for a complete security implementation re packet
filtering, whereas omission of the facility implies reliance on some
other components of possibly unknown security quality. I think this
is largely an issue of implementation complexity. In practice, if one
has a firewall behind an IPsec device and wants the firewall to
perform
the discard function, then one can arrange to bypass all non IPsec
traffic. I'm not sure that there is a performance penalty if discard
is not turned on for any traffic, e.g., under such circumstances.
We've heard one or two suggestions to remove this requirement, and a
similar number to retain it, so we currently plan to make no change
here.
Section 4.2
It was suggested that the discussion of traffic flow confidentiality
here may be misleading in that fine granularity SAs tend to allow more
traffic analysis that coarse granularity ones. This is a valid point
and we will reword this section to better express that notion.
Section 4.3
The question was raised what sort of treatment is afforded ISAKMP
packets in the context of iterated tunneling. Cheryl's example
involved a host with a tunnel to a security gateway, and that tunnel
was itself encapsulated in a tunnel between two security gateways. We
did not anticipate any special treatment for ISAKMP traffic at
intermediate security gateways, other than what can be specified
through appropriate SPD entries. A coarse granularity tunnel between
two security gateways would have no trouble carrying ISAKMP traffic
along with all other traffic. If multiple, fine-grained tunnels are
constructed, then one might have to make explicit provision for ISAKMP
traffic, depending on the sets of selectors employed.
Section 4.4.1
The discussion of the requirement for ordering of SPD entries arises
here, on page 14. There has been some question about whether the SPD
entries need to be ordered. The motivation for ordering arises from
several concerns. First, it seem critical that an administrator be
able to express his security policy, not constrained by any artifacts.
Second, the results of applying the policy must be consistent, not
affected such things as the order in which traffic arrives, so that
the effects of the policy are predictable. Third, we support a
variety of selectors, several of which allow for wildcarding. Given
this set of selectors, it didn't seem possible to specify a useful,
canonical ordering that would free an administrator from the need to
explicitly order entries. In fact, the previous version of the
document tried to optimize the lookup process and in doing so it
violated the second goal, as Ly Loi (3COM) pointed out to me in a
series of private messages. So, the ordering requirement is a
response to these goals/constraints. If the WG changes these goals or
any of the constraints, we could revisit this derived requirement for
SPD entry ordering.
---
In this section on page 14, the following text appears:
"For each selector, the policy entry specifies which of the
following values should be used in the SA: (a) the value in
the packet, (b) the value associated with the policy, or (c) a
wildcard."
Someone expressed confusion about case (a). On further reading, I
agree that this is confusing and we'll clarify this and add better
examples in the paragraphs that follow, onto the top of page 15. In
fact, I no longer recall why we call out the last two cases
separately. What I think this is referring to is the issue of how a
SAD entry is constructed from the SPD. In case (a), the SAD has an
entry with values taken from the packet as it was looked up in the
SPD. In case (b), the value from the SAD is used, and in case (c),
that value is a wildcard. This is an important feature because it
allows an administrator to distinguish between a wildcard selector
that is intended to create exactly one SA for all traffic matching
that selector, vs. a wildcard selector that is intended to be
shorthand for creating one SA for EACH different traffic stream that
matches the selector.
Also in this page, immediately below the text above, is a discussion
of how SA bundles may be shared, and why case (c) is important to
that. The notion of an SA bundle was introduced in the architecture
document back in the July draft, after some discussion on the WG list
earlier in the year. The goal is to allow reuse of an SA when there
is SA nesting. People have express concern over possible creation of
unnecessary SAs because of nesting and this is the proposed approach
to dealing with that potential problem. We mention that motivation
near the bottom of page 15
When we had the SAM as an intermediate database, bundles were easy to
manage. Now, without the SAM (which created problems alluded to
earlier), the management of bundles is getting harder, but we have
assumed that folks still want them as a means of avoiding redundant SA
creation. (See the discussion of inbound processing in section 5.2.1,
for example.) Charlie Lynn has done most of the analysis on this
topic, so I'll point you to Charlie for good examples. maybe we have
to change terminology if there is a conflict with the use of this term
in the IPsec DOI document.
Finally, at the end of this section, someone raised the issue
mentioned in 4.3, i.e., what about ISAKMP traffic traversing a
security gateway that normally does not allow transit traffic to be
encrypted. The answer is that the SPD must have a suitable entry to
allow such traversal, if the administrator want to permit IPsec
connections from systems "behind" the security gateway. We can look
at rewording this last paragraph to better convey that notion, i.e.,
that the SPD is used to control the flow of ALL traffic through an
IPsec system, including ISAKMP traffic from entities behind a security
gateway.
Section 4.4.2
This is the section that has the most items that need revision, based
on comment to date. There are mismatches between the ISAKMP
documents, e.g., the DOI, and what is called for here. We noted these
discrepancies back in Munich, but unfortunately none of the authors of
the relevant documents managed to get together since then to resolve
these problems. As Cheryl Madson points out, the big mismatch here is
in terms of what can be negotiated for an SA, vs. what one might use
in the SPD. However, the general model of the SPD does allow for 1-1
maps to SAs, in which case this distinction becomes moot and the
problem is with us again. If the WG wants to move ahead as quickly as
possible, and not require DOI (and implementation) changes, then
we'll just have to remove these selector requirements for SAs and
defer them to IPsecond.
Specifically, Cheryl notes that the DOI does not support value ranges
for
any selector value other than IP addresses. So, we'll have to remove
this facility from the rest of the selectors. Also, enumerated lists
of values are not supported at all, and so these too need to be
removed as selector values. Cheryl also notes that TOS is not
supported in the DOI, and I wonder if IPv6 Class and Flow Label are
included? These can be removed entirely if the goal is to get the
spec out the door, as I suspect that few folks will miss these last
three selector types (at least for a while).
Cheryl also asked why we had separated out IPsec protocol type vs.
Transport Protocol, a change from the July version. Let me see if I
can recall the rationale here. Imagine a security gateway that
examines an inbound packet and determines that it appears to have had
AH applied to it. It might also examine the next protocol field
inside the AH header and make use of it in the access control
decision. Here too, Charlie is probably a better source for examples.
Cheryl also noted her belief that negative entries would be important
as selectors. We do have that facility implicit in the SPD, in that
DISCARD is a processing option for traffic.
Other folks have pointed out that the current definition of SPD entry
types omits an important class of selector, i.e., names. The obvious
case where this is necessary is when a mobile user is dynamically
assigned an address and thus no static IP address entry in the SPD can
be appropriate for this type of user. If the user has a certificate
with a name in it, e.g., a DNS name, then he (his computer) can be
authenticated during SA establishment and we should be able to make
use of an appropriate SPD entry to accommodate such users. This
scenario is a bit trickier in that lookups for outbound traffic must
be matched against this dynamic address, instead of the DNS name, at
least if the SA terminates as a security gateway.
Another motivation for using names (vs. IP addresses) was suggested,
i.e., ease of management for larger communities. Here too, use of DNS
names, with wildcarding, could ease the management burden. However,
we have to be careful to not become dependent on DNS names here unless
we are using authenticated names, .e.g., in conjunction with the
secure DNS technology. Also, security gateways will usually not have
access to the names (vs. IP addresses) associated with traffic
traversing them. So, unless we have secure inverse DNS lookups
available, use of names in SPD entries poses problems in this context.
So, I propose that we add (DNS?) names as another selector type for
use in the SPD. Should this be a mandatory selector, like the others,
and if so, is it mandatory for both hosts and security gateways?
Section 4.5
Cheryl notes that nested SAs of the sort described here may require
multiple ISAKMP negotiations, though she didn't see that as a show
stopper. However, we should make sure that the results of multiple
negotiations can be linked in a consistent fashion, to support the
checks called for in Section 5.2.
Section 5
We'll change the wording of section titles here to reflect the fact
that all traffic is subjected to this processing, whether it's IPsec
traffic or not.
Section 5.1
The question is raised as to what is the default processing if no
matching rule is found in the SPD. Good point. The safe default is
to
discard the traffic, and this applies to both inbound and outbound
traffic. We'll make that explicit and maybe more it to the beginning
of section 5.
Section 5.2
In response to a suggestion that we make explicit mention of the need
to consult the SPD for inbound, non-IPsec traffic, we'll make it clear
that inbound processing check apply to all traffic, not just IPsec,
and note this at the beginning of Section 5.
Section 5.2.1
Cheryl reiterated the importance of checking that all the prescribed
IPsec headers are applied to a received packet and that they were
applied in order, which is consistent with the text. Our only
residual concern is the ability of ISAKMP and the IPsec DOI to specify
the ordering constraints. We need someone to verify this.
Another commenter asked if post-IPsec processing could include
forwarding and additional IPsec processing. In the case of a security
gateway, that could happen, e.g., if the gateway supports concatenated
SAs for linking to internal IPsec-capable hosts. We currently do not
require such support, but it could be an optional feature.
Section 6.
Cheryl asked what set of ICMP messages were being addressed here,
e.g., error messages vs. Echo/Reply messages. The latter, if IPsec
protected, should be treated like other traffic and can be protected
on an end-to-end basis using SAs in the usual fashion. So, yes, the
focus of this section is on error messages and we will revise the text
to reflect that distinction.
Cheryl's next question was why router-generated, IPsec-protected ICMP
(error) messages were not subjected to source address checks. Well,
if the message comes directly from that router, the address check
would be appropriate. However, if the router is forwarding an ICMP
message from another router, the check would fail. This gets to a
point raised by Mike Richardson, and reiterated by Cheryl, i.e.,
should a security gateway that receives a PMTU message not directed to
it forward that message in an IPsec tunnel. The concern is that such
forwarding lends the imprimatur of the IPsec-capable gateway to this
message. So, the resolution to this issue depends in large part on
the answer to this latter question. We could make the checking a
local
policy matter and merely warn folks of the problem for now, in an
effort to reach closure on this.
Another issue raised here is that of the authenticity of the returned
IP header in an ICMP error message. Even if the source is
authenticated, we can't be certain that the returned traffic is valid.
It was suggested that additional checks be added, e.g., ensure that
the returned header info is consistent with the SA over which an
authenticated ICMP is received. We can add text to that effect, and
we will add a warning about the residual vulnerabilities associated
with processing ICMP error messages in general.
Section 6.1.2.1
Cheryl raised the question of why propagation of the PMTU by the
security gateway was a MUST, as it seems beyond what would normally be
required for a router implementing a tunnel. I don't recall whether
this is required by RFC 1191, but the motivation here is to ensure
that the host learns, as quickly as possible, that there is an MTU
problem downstream, so that the host can respond appropriately. Is
there a strong desire to have this be a SHOULD vs. a MUST? if so, we
can change the requirement level.
Section 6.1.2.2
The question was raised as to how a socket-based, host IPsec
implementation should deal with a PMTU message, given that the socket
interface would already be cognizant of the space devoted to local use
of IPsec (on the socket in question). The answer is that the
notification provided by IPsec to the upper layers (in response to
receipt of an ICMP PMTU) ought to be consistent with whatever IPsec
overhead is being applied and with the MTU size reelected to the upper
layers. (Whew, that's a mouthful.)
Section 6.1.2.4
Cheryl's comment here was really a question for the list, i.e., should
we be following the RFC 1191 vs. 2003 behavior re forwarding of a too
big packet. She observed that the WG list didn't seem to come to
closure on that. However, her comment makes we want to check to see
why we're citing 1191 vs. 2003 here. We'll look into that and get
back with a response, but I think the WG chairs have to weigh in on
this too.
Section 8
I'll chime in here. Dan MacDonald worked with several other folks to
provide this section which would otherwise have been deferred to
IPsecond. The intro to this section still needs some work, as the
goal is that these requirements are applicable to a wider range of
systems than those characterized as "MLS." So, expect a few
changes here as well.
References
Cheryl noted that we seem to have a lot of them, many out of date.
We'll clean up this list, paring it down substantially, getting rid of
historically interesting but not currently relevant citations.
</bigger></bigger></fontfamily>