Security Architecture for the Internet Protocol
draft-ietf-ipsec-rfc2401bis-06

[Ballot comment]
The document attempts to cover certain VPN-related issues, but the routing-
related part is not adequate. It would take a lot of time and effort to
improve the document from that perspective. Hence changing to ABSTAIN.

To: kent@bbn.com, kseo@bbn.com
Cc: housley@vigilsec.com, hartmans-ietf@MIT.EDU
Subject: Explaining my RFC 2401bis concerns
From: Sam Hartman
Date: Tue, 08 Feb 2005 15:45:24 -0500
Message-ID:



Hi there and sorry about the protracted delay.

I'm hoping to explain my concerns about 2401bis enough that we can
figure out if there is a problem and if so how hard it would be to
fix.  I'm assuming any changes will be relatively small; if as we get
into this discussion it looks like that's not the case I'll reconsider
the issue.

If you would rather discuss these issues on a conference call I would
be happy to do so.

I'd like to start by explaining my area of concern.  I'm explicitly
not phrasing my concern in the terms of the RFC 2401bis model at
first; I want to make sure we understand the requirements before we
start thinking about how they relate to the model.

Several parts of the IETF seem to be using IPsec to secure
higher-level applications.  OSPF and ISCSI are two examples although I
expect the trend to continue.  In addition, IPsec is also used when
IPsec itself is the application; I'll call this VPN IPsec until you
suggest a better term.  By VPN IPsec I'm including anything from
transport mode SAs configured by system administrators to more
traditional VPN tunnels secured by ESP in tunnel mode.  I think most
of the IPsec working group's time has been focused on what I would
consider VPN IPsec.  I think rfc 2401bis works well for this use of
IPsec.

Internet hosts run multiple applications.  In general I consider it
architecturally unacceptable for the fact that a host is running one
application to prevent it from running another application.  It's
architecturally dubious if adding an application to a host  changes
the other applications. 

I believe it is important that we be able to create generic IPsec
implementations.  I think that generic IPsec implementations should
have the following properties:

1) A single implementation of IPsec supports all the applications the
  IETF has designed today and is sufficiently flexible to support new
  applications for which IPsec is likely to be part of the security
  model.  Naturally implementations of RFC 2401bis will not support
  BTNS, channel bindings, or other enhancements to IPsec until those
  enhancements actually happen and code gets written.

2) Adding the first IPsec application should not suddenly change the
  performance or network interactions of other applications.

3) Adding a new IPsec application should not require reconfiguration
  of existing IPsec applications except in so far as administrative
  policy of those applications is explicitly designed to conflict
  with other applications.  I.E. adding OSPF should not require
  reconfiguring ISCSI.  It may well be that adding OSPF does require
  adjusting security policy for an IPsec VPN application that was
    configured to reject unspecified traffic.


In addition to being able to create generic IPsec implementations the
IETF has an additional requirement.  We need to be able to specify the
use of IPsec to secure applications.  As Steve  saw from reviewing the
OSPF draft  it tends to be necessary to discuss IPsec configuration
when discussing how to secure an application with IPsec.    We need to
be able to do this in a manner that the specification of one
application does not conflict with the specification of another
application.

The above are the requirements/goals I'm trying to make sure we are
achieving.  I'm going to discuss specifics but please keep in mind
that my motivation is to meet the requirements I have previously
described.  If you believe the way I'm thinking about specifics is
wrong or think there is a more efficient or completely different
solution, feel free to propose it.


Question: Have I described my goal sufficiently clearly in order to
discuss whether it is a reasonable goal and in order to discuss
whether rfc2401bis meets this goal?  If not, please let me know where
I need to clarify/expand.

One thing that is obvious to me at this point is that I seem to be
concerned about the case where the application security is tied
reasonably closely to the application.  I understand that it is
perfectly reasonable to use IPsec as a systems administrator to move
an application that has no  security behind a protection barrier.
People seem to want to rely on IPsec in protocol specifications  to
provide security.  That's fine, but that  means the application
implementation, rather than the systems administrator may be
involved in security policy configuration.  Ultimately we need to get
to a point where configuration of applications secured by IPsec can be
as easy as applications secured by TLS.  That can is for implementers;
some implementations will make security easy and some will not.



Where do I see potential conflicts between RFC 2401bis and these
goals?  As I mentioned in my discuss there are two areas: applications
combined with the IPsec VPN application and the fragment reassemble
requirements for bypass traffic.


The bypass traffic concern is simple.  As I understand it section 7.4
means that adding a bypass rule for some application forces stateful
fragment inspection.  The critical problem comes with applications
like OSPF where a small fraction of the total traffic for the system
will be protected by IPsec.  Router manufacturers will probably not
consider it acceptable to do fragment inspection for all traffic
passing through a router simply because OSPF is used and something
includes a non-trivial port range.  It seems that the requirement is
over-broad.  For example I don't understand why stateful fragment
inspection is required if the set of IP addresses requiring protection
does not overlap with the set of IP addresses for bypass traffic.
Similarly as I pointed out in my discuss text it seems like you can
avoid the problem for locally destined traffic on some implementations
if you mark sockets that are expecting protected traffic.  Am I
missing something from a security standpoint, or do we just need to
find text that liberalizes the requirement and fits within the model?


The other concern--conflicts between IPsec VPN and other applications
seems to be more complicated; my hope is that once the solution is
found it will end up being simple.  I want to make sure it is possible
to have a single implementation model--arrangement of interfaces, SPD
selection function, set of SPDs that meet the criteria I outlined for
a generic implementation.

I'm particularly concerned by the tendency to need to decide which
interfaces are protected and which interfaces are not protected for
each application and the need to specify SPD rules that would not work
together for each application.  I think Steve's review comments for
the OSPF draft and responses to my ISCSI example both illustrate the
concern.  Any time you find yourself saying things like "for this
protocol, consider these interfaces protected," you are not being
generic.  I don't want to require that we be generic all the time; I
simply want to check and make sure it is possible to be generic.--


Question: Is this concern sufficiently well stated that you understand
what I'm trying to say?  If not, where should I focus on clarifying?

[Ballot comment]
Section 6.1.2 creates requirements for incoming ICMP packets on the
protected side of the IPsec boundary.  As best I can tell the attacks
described in that section are potential problems for any Internet
gateway and have nothing to do with IPsec.  If so, why should the
IPsec architecture add requirements for additional administrative
controls to mitigate these attacks?  (I think the administrative
controls are a good idea; I'm just unsure why this specification is
the right place for them.)

[Ballot discuss]
I'm updating this discuss based on discussions with Steve Kent and on
the IESG telechat.  My words have changed significantly but the issues
have not.  Mostly I've changed to reflect a better understanding based
on Steve's comments.

A lot of good work has gone into this document.  I find it easier to
follow than RFC 2401 and believe it would be useful in implementing
IPsec.


[issue 1, based on my iSCSI example]

I am beginning to believe that I have a somewhat general problem with
the balances and tradeoffs that the IPsec working group has chosen and
how those interact with the rest of the IETF.  The IPsec working group
is focusing on IPsec as its own application; system administrators and
users who configure IPsec because they want specific traffic
protected.  That's clearly an important use of IPsec.  However the
rest of the IETF continues to view IPsec as an appropriate tool for
providing security for other applications, protocols, etc.  In these
situations, IPsec (especially in native implementations) may need to
provide appropriate interfaces to these uses.  I'm concerned that the
2401bis model favors the first use too much.  Revisiting that issue
this late in the process would be inappropriate.  However I'd like to
focus on two cases where 2401bis seems to be problematic for the use
of IPsec as a security tool by higher layers.

The first issue is one I noticed late yesterday.  Section 7.4 mandates
stateful fragment handling for bypass and discard traffic if any of
the SPD selectors specify a specific port.    This means that when  I
start protecting traffic for one application, I end up having to
significantly complicate the packet processing for all my traffic.
Especially for native implementations, this seems unnecessary.  It
seems like  the real requirement is that I should not be able to
manipulate fragments to generate or receive unprotected traffic when
I'm expecting protected traffic.  It seems like keeping track of
whether a particular socket requires protected traffic would be
sufficient.  I'm not sure you can do better than 7.4 for other types
of implementations.

The second case is the case I described  eearlier where a host is
using IPsec both to provide security services for a higher layer and
to enforce specific policy as a security gateway etc.  Again, it
seems like you can do better than the current document  for native
implementations.    Virtual interfaces  based on MAC address seem like
the wrong solution; it only works if the protected traffic doesn't
share a router with unprotected traffic. 

I understand not all implementations need to support this sort of
functionality.  I'm concerned that it is not clear from the current
draft  that you might want to do this.  Also, I'm concerned that you
might end up choosing an implementation of this feature with hidden
implications.   

I suspect I need to be more concrete in what I want here.  I think
that all I'm asking for is clarifying text, but I haven't yet figured
out how I'd do what I want in the model so I'm having a hard time
determining if it is clear.

There are probably one or two rounds of discussion that need to happen
on this; I will try to be responsive so this does not bog down.

[issue 2; Steve proposed two solutions both  of which are acceptable
to me.]


In 4.4.4.1, the two uses of the name pseudo-selector do not seem to be
comparable and so I don't understand why they are overloaded.  In the
first use, the name is an IKE identity used to contact a responder.
In the second use, the name is a local OS user for whom protection
services will be used or bypassed (or data discarded).  The local OS
is unlikely to use IKE identities; local naming is more likely to be
unix UIDs, Windows security IDs or something similar.  Why are these
two different things both called name; why should they be in the same
place in the SPD?

[issue 3; I think we have rough agreement]

The example for X.500 distinguished names seems in the wrong order.
Shouldn't the country come last, not first?  In any event, a reference
to the string encoding of DNs that is being used should probably be
given; I'm assuming the example is relative to RFC 2253 or at this
point its successor.  If you are using a different string
encoding--particularly one with different ordering--it is even more
critical to cite.

[issue 4; one outstanding question; probably the answer will be
sufficient for me to drop the issue.]


There doesn't in general seem to be a way to create an SPD policy that
uses IPsec if a SA is available  but is not used otherwise.  If the
peer is using an IKE identity other than an IP address the name
selector is adequate for this task.  However I don't understand how to
create an SPD entry of this type if the peer will assert an IP address
for its identity. 

[issue 5; open question/clarification]

In section 5, the document claims that both outbound and inbound
packets must be checked against the SPD (or a cache).  This doesn't
actually appear to be what's described for inbound packets that use
IPsec protection.  The procedure for handling packets only checks them
against the SAD, not against the SPD.  The text claims that the SAD is
a cache of the SPD for inbound packets.  If this were true, everything
would be consistent.  However, earlier in section 4.4.1, the document
says that a system administrator should be given the opportunity to
decide what happens when the SPD is changed.  One of the options is to
allow extant SAs to continue.  If this option is taken, the SAD can
contain SAs that correspond to no SPD entry.  I believe the simplest
fix is to revise section 5 to claim that the SPD is consulted for
outbound packets and the SPD-I and SAD are consulted for inbound
packets.

[issue 6; Steve proposed acceptable solution]

The text after rule 4 of 5.2 is confusing; Steve proposes making a
rule 5.

[issue 7; agreed solution]



Section 7.4 should gain the same text about stateful fragment checking
not working in case of multiple paths as found in section 7.3.

[issue 8; need to post Steve's text to tracker]

Steve Kent has new PAD text (4.4.3) which clarifies and extends the
PAD.  Russ has asked me to hold a discuss on this text.  I'm
discussing some comments about that text with Steve and Russ and
expect to amend my discuss once those discussions complete.

[issue 9]
Appendix C:

There's text at the top of the appendix claiming that the module does
not compile because of a duplicate tag.  Could you please explain this
in more detail.

Review from Brian Carpenter, Gen-ART

I think this is basically ready to go, but I have a few minor comments
and there are some nits.



Slightly substantive:
=====================


> 4.1 Definition and Scope
...
>    If different classes of traffic (distinguished by Differentiated
>    Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
> the
>    same SA, and if the receiver is employing the optional anti-replay
>    feature available in both AH and ESP, this could result in
>    inappropriate discarding of lower priority packets due to the
>    windowing mechanism used by this feature.  Therefore a sender SHOULD
>    put traffic of different classes, but with the same selector values,
>    on different SAs to support QoS appropriately.  To permit this, the
>    IPsec implementation MUST permit establishment and maintenance of
>    multiple SAs between a given sender and receiver, with the same
>    selectors.  Distribution of traffic among these parallel SAs to
>    support QoS is locally determined by the sender and is not
> negotiated
>    by IKE. The receiver MUST process the packets from the different SAs
>    without prejudice.

I think it would be helpful to remind readers that (as indicated
in RFC 2983) we are talking here about the "inner" DSCP in a tunnel,
which will not be changed en route (since in general, the DSCP
value may be changed en route and that destroys the model described,
since there would be no fixed relationship between DSCP value and SA).

I also note that there is no reference to the IPv6 Flow Label. Since
this
is an e2e field (RFC 3697) it would actually be easier to handle than
the
DSCP, if there was any need to do so.

> 4.4.2.1 Data Items in the SAD
...
>    o Bypass DF bit (T/F) - applicable to tunnel mode SAs

Note that this only applies to IPv4 (ditto section 8.1).

>    o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
>      needed to restrict bypass of DSCP values - applicable to tunnel
>      mode SAs

This is unclear to me and needs some explanation. Actually, it's
unclear how the earlier suggested treatment of DSCPs works,
since the DSCP value(s) corresponding to an SA aren't stored anywhere
that I noticed, so the model does not allow for demultiplexing on
DSCP values in any case.



Nits:
=====

> 4.4.1 The Security Policy Database (SPD)
...
> Decorrelation
...
> (unordered) state.  ppendix B provides an algorithm that can be

s/Appendix/ppendix/


Then idnits has complaints:

idnits 1.58

tmp/draft-ietf-ipsec-rfc2401bis-05.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3667/3668 boilerplate...
  * The document seems to lack an RFC 3667 Section 5.4 Copyright Notice
--
    however, there's a paragraph with a matching beginning. Boilerplate
error?
    ( - It does however have an RFC 2026 Section 10.4(C) Copyright
Notice.)
  * The document seems to lack an RFC 3667 Section 5.5 Disclaimer --
    however, there's a paragraph with a matching beginning. Boilerplate
error?
  * The document seems to lack an RFC 3668 Section 5, para 3 IPR
Disclosure
    Invitation -- however, there's a paragraph with a matching
beginning.
    Boilerplate error?
  * There are 105 instances of too long lines in the document, the
longest
    one being 7 characters in excess of 72.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about
    Internet-Drafts being working documents.
  * The document seems to lack a 1id_guidelines paragraph about 6 months
    document validity.
  * The document seems to lack a 1id_guidelines paragraph about the
list of
    current Internet-Drafts.
  * The document seems to lack a 1id_guidelines paragraph about the
list of
    Shadow Directories.

  Miscellaneous warnings:

  - There are 28 instances of lines with hyphenated line breaks in the
    document.
  - Line 512 has weird spacing: '...support  multi...'
  - Line 1029 has weird spacing: '...g value  examp...'
  - Line 1031 has weird spacing: '...elector  selec...'
  - Line 1610 has weird spacing: '...oc addr  list ...'
  - Line 1615 has weird spacing: '...em addr  list ...'
  - (18 more instances...)

    Run idnits with the --verbose option for more detailed information.

[Ballot discuss]
How does the in/out-bound processing model defined in section 5 work in the case
of a VPN gateway? In particular, how does presence of multiple routing realms
and a two-stage forwarding process affect it (imagine a gw that uses dynamic
routing over the VPN tunnels protected by IPsec transport mode as encapsulated
packets leave the box)? What about locally-originated messages, such as routing
messages in this case. I know how to make it work, the question is how the
described model addresses these scenarios.

Section 4.4 Major IPsec Databases:

>    Forwarding vs Security Decisions
>
>      The IPsec model described here embodies a clear separation between
>      forwarding (routing) and security decisions, to accommodate a wide
>      range of contexts where IPsec may be employed. Forwarding may be
>      trivial, in the case where there are only two interfaces, or it
>      may be complex, e.g., if there are multiple protected or
>      unprotected interfaces or if the context in which IPsec is
>      implemented employs a sophisticated forwarding function.

minor note: complexity of forwarding doesn't depend directly on the number of
local interfaces.

>                                                                IPsec
>      assumes only that outbound and inbound traffic that has passed
>      through IPsec processing is forwarded in a fashion consistent with
>      the context in which IPsec is implemented.

What does the above statement really mean?

Though Appendix E is not normative, I should note that it is rather confusing.
Specifically, though the document states that no changes to the forwarding
function are introduced, the appendix mentions two different forwarding
tables--one for protected, and one for unprotected side. Also, the
representation of the forwarding tables themselves creates an impression that
routes usually include both source and destination prefixes, which clearly isn't
true (unless we're talking about a special case of policy-based routing). Again,
I know how to make it work, but I don't think the doc is very good at explaining
this.

[Ballot comment]
This seems to have a mix of RFC 2026 and RFC 3668 boilerplates.

In Section 4.1, the draft says:

In many secure multicast (or anycast) architectures, e.g., [RFC3740],
a central Group Controller/Key Server unilaterally assigns the Group
Security Association's (GSA's) SPI. 

3740 does not seem to mention anycast.  Is there a similar reference
for anycast?

Section 4.4.1 uses 192.168 addresses, rather than the example prefix
192.0.2.x/24

I found the use of "road warrior" in section 4.5.2 distracting.

[Ballot discuss]
A lot of good work has gone into this document.  I find it easier to
follow than RFC 2401 and believe it would be useful in implementing
IPsec.


Several of my comments may end up being addressed by explanations and
no textual changes.

One area where the document appears vague is the IPsec protection
barrier and its interaction with forwarding.  As best I can understand
the architecture, some parts of the system are on the protected side
of IPsec while others are on the unprotected side of IPsec.  It seems
like there is only one protected side of IPsec.  I was running through
usage situations and ran across one for which I'm not sure how this
model works.  Consider a security gateway with two network interfaces,
i0 and i1.  The i0 interface is red; the gateway typically receives
plaintext on this interface.  The i1 interface is black; it is
"closer" to the public Internet.  In addition (or perhaps as part of)
to providing gateway services, the security gateway needs to access an
ISCSI disk via i0.  The gateway wishes to use IPsec for accessing this
disk in order to avoid other systems on i0 from being able to obtain
confidential data.  How would the IPsec implementation look on this
gateway?  It's clearly not as simple as i0 is a protected interface
and i1 is an unprotected interface.  I want to make sure the
architecture (possibly using optional features) is rich enough to
cover this sort of situation and that the explanation of the model is
clear enough that most readers will understand that some IPsec
implementations will support this style of configuration.  I suspect
the first is true, although the ways I've ended up looking at this
problem all involve multiple SPDs and multiple IPsec transitions for
each packet only one of which is necessary.  Hopefully that's not the
correct way of looking at this example.


In 4.4.4.1, the two uses of the name pseudo-selector do not seem to be
comparable and so I don't understand why they are overloaded.  In the
first use, the name is an IKE identity used to contact a responder.
In the second use, the name is a local OS user for whom protection
services will be used or bypassed (or data discarded).  The local OS
is unlikely to use IKE identities; local naming is more likely to be
unix UIDs, Windows security IDs or something similar.  Why are these
two different things both called name; why should they be in the same
place in the SPD?

The example for X.500 distinguished names seems in the wrong order.
Shouldn't the country come last, not first?  In any event, a reference
to the string encoding of DNs that is being used should probably be
given; I'm assuming the example is relative to RFC 2253 or at this
point its successor.  If you are using a different string
encoding--particularly one with different ordering--it is even more
critical to cite.


There doesn't in general seem to be a way to create an SPD policy that
uses IPsec if a SA is available  but is not used otherwise.  If the
peer is using an IKE identity other than an IP address the name
selector is adequate for this task.  However I don't understand how to
create an SPD entry of this type if the peer will assert an IP address
for its identity. 

In section 5, the document claims that both outbound and inbound
packets must be checked against the SPD (or a cache).  This doesn't
actually appear to be what's described for inbound packets that use
IPsec protection.  The procedure for handling packets only checks them
against the SAD, not against the SPD.  The text claims that the SAD is
a cache of the SPD for inbound packets.  If this were true, everything
would be consistent.  However, earlier in section 4.4.1, the document
says that a system administrator should be given the opportunity to
decide what happens when the SPD is changed.  One of the options is to
allow extant SAs to continue.  If this option is taken, the SAD can
contain SAs that correspond to no SPD entry.  I believe the simplest
fix is to revise section 5 to claim that the SPD is consulted for
outbound packets and the SPD-I and SAD are consulted for inbound
packets.

In rule 4 of section 5.2  the text assumes that a packet being passed
outbound again across the IPsec boundary will be bypassed.  This
ignores the case where the packet is being protected.  I don't see any
reason why that case should not be permitted.

Section 6.1.2 creates requirements for incoming ICMP packets on the
protected side of the IPsec boundary.  As best I can tell the attacks
described in that section are potential problems for any Internet
gateway and have nothing to do with IPsec.  If so, why should the
IPsec architecture add requirements for additional administrative
controls to mitigate these attacks?  (I think the administrative
controls are a good idea; I'm just unsure why this specification is
the right place for them.)



Section 7.4 should gain the same text about stateful fragment checking
not working in case of multiple paths as found in section 7.3.

Steve Kent has new PAD text (4.4.3) which clarifies and extends the
PAD.  Russ has asked me to hold a discuss on this text.  I'm
discussing some comments about that text with Steve and Russ and
expect to amend my discuss once those discussions complete.

Appendix C:

1) An OID  needs to be assigned; the module is not yet syntactically
valid.

2) Please explain the duplicate tagging issue.

[Ballot comment]
Section 4.1:
  s/Memory (TCAM0 features/Memory (TCAM) features/

  Section 4.4.1:
  s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/
  s/The SPD-SPD-S/The SPD-S/

  Section 4.4.2:
  s/Database(SAD),/Database (SAD),/

  Section 8.2.1:
  s/SAD entry When/SAD entry. When/

[Ballot discuss]
When will the module identifier be assigned for Appendix C?
  If you want IANA to do it, then it needs to be called out in
  the IANA Considerations section.