Guidelines for Specifying the Use of IPsec Version 2
draft-bellovin-useipsec-10

[Ballot discuss]
The introductions says:

  This document offers some guidance on when IPsec should and should not
  be specified.

However, I didn't see any guidance regarding the types of problems that IPsec doesn't protect against (which needs to be an input to "...when IPsec should and should not be specified"). As one example, I understand that IPsec could be used in routing protocols to protect against attacks that in theory could possibly occur. However, the vast majority of attacks that I have heard have actually occurred against routers fall into three categories: (i) DDOS against the control plane; (ii) Bad password selection; (iii) Accidental mis-configuration by well-intended and properly authorized network operators. IPsec doesn't protect against any of these. In fact, in order to protect against (i), it is at least desirable to set things up so that hackers can't send any packet *to* the router's control plane at all, which reduces the value that results from authentication of packets to the router's control plane. Also, use of IPsec on packets to the router's control plane can greatly magnify the effect of any DDOS attack against the control plane.

If we are going to be talking about *mandating* security mechanisms for use in routing protocols (BGP is used as an example in this document -- a good example since IPsec is in fact currently used in this way in some cases), and if IPsec is the only security mechanism discussed in the document, then I think that we need a more balanced discussion of what can, and what cannot, be accomplished by IPsec.

In addition, the document talks about automated key management. My understanding is that there is no standards track method currently defined that would allow automated key management between multiple systems interconnected via an underlying multicast or point to multipoint service. Thus we can't mandate, or even use, AKM for some of the routing area protocols (such as OSPF and IS-IS) since they transmit packets in some cases directly between multiple systems in this manner.

This leads to the question: Who is the intended audience for this document? It seems clear that it is not security experts, since in general security experts (and even many non-security experts) will already fully understand the entirely reasonable main point that "Just Use IPsec" is very much *not* a valid "security considerations" section for any protocol specification. Thus I am inclined to think that the document audience must be people who are experts in other areas, but who are not security experts, who are trying to figure out how to write the security considerations section of a protocol specification. After reading this document they might have an improved understanding of why writing "just use IPsec" is not sufficient, but they are not going to have any clue what they actually need to write into their document.

It is likely that another impediment to authors who are experts in other areas (NOT security experts) writing the security considerations section of their document is that they might not fully understand how security protocols could or might be used (for example, whether IPsec and associated key management protocols can operate using *only* packet exchange between directly attached systems, or if there needs to be packets exchanged with other not-directly-attached systems). Significantly more guidance is needed.

I see this document clearly making the case that "just use IPsec" is not sufficient. However, I don't see it as being sufficient in the more important point of helping authors understand what they need to write instead.

[Ballot discuss]
The introductions says:

  This document offers some guidance on when IPsec should and should not
  be specified.

However, I didn't see any guidance regarding the types of problems that IPsec doesn't protect against (which needs to be an input to "...when IPsec should and should not be specified"). As one example, I understand that IPsec could be used in routing protocols to protect against attacks that in theory could possibly occur. However, the vast majority of attacks that I have heard have actually occurred against routers fall into three categories: (i) DDOS against the control plane; (ii) Bad password selection; (iii) Accidental mis-configuration by well-intended and properly authorized network operators. IPsec doesn't protect against any of these. In fact, in order to protect against (i), it is at least desirable to set things up so that hackers can't send any packet *to* the router's control plane at all, which reduces the value that results from authentication of packets to the router's control plane. Also, use of IPsec on packets to the router's control plane can greatly magnify the effect of any DDOS attack against the control plane.

If we are going to be talking about *mandating* security mechanisms for use in routing protocols (BGP is used as an example in this document -- a good example since IPsec is in fact currently used in this way in some cases), and if IPsec is the only security mechanism discussed in the document, then I think that we need a more balanced discussion of what can, and what cannot, be accomplished by IPsec.

In addition, the document talks about automated key management. My understanding is that there is no standards track method currently defined that would allow automated key management between multiple systems interconnected via an underlying multicast or point to multipoint service. Thus we can't mandate, or even use, AKM for some of the routing area protocols (such as OSPF and IS-IS) since they transmit packets in some cases directly between multiple systems in this manner.

This leads to the question: Who is the intended audience for this document? It seems clear that it is not security experts, since in general security experts (and even many non-security experts) will already fully understand the entirely reasonable main point that "Just Use IPsec" is very much *not* a valid "security considerations" section for any protocol specification. Thus I am inclined to think that the document audience must be people who are experts in other areas, but who are not security experts, who are trying to figure out how to write the security considerations section of a protocol specification. After reading this document they might have an improved understanding of why writing "just use IPsec" is not sufficient, but they are not going to have any clue what they actually need to write into their document.

It is likely that another impediment to authors who are experts in other areas (NOT security experts) writing the security considerations section of their document is that they might not fully understand how security protocols could or might be used (for example, whether IPsec and associated key management protocols can operate using *only* packet exchange between directly attached systems, or if there needs to be packets exchanged with other not-directly-attached systems. Significantly more guidance is needed.

I see this document clearly making the case that "just use IPsec" is not sufficient. However, I don't see it as being sufficient in the more important point of helping authors understand what they need to write instead.

[Ballot discuss]
[As part of the AD transition, I am assuming Sam Hartman's discuss.]

Also, please note that section 8 of this specification only coversn
IKEV1.  There are additional requirements for what needs to be
specified for IKEV2 not covered in your spec.  You need to make it
clear that this only covers 2401-based IPsec.  The current text
implies that applications could simply say to use IKEV2.  If they do
that they are outside the scope of this BCP.  That needs to be made
clear.

In particular, the reference to EAP for IKEV2 and the claim that you
need to specify what version of IKE is inappropriate in this document.

[Ballot discuss]
Also, please note that section 8 of this specification only coversn
IKEV1.  There are additional requirements for what needs to be
specified for IKEV2 not covered in your spec.  You need to make it
clear that this only covers 2401-based IPsec.  The current text
implies that applications could simply say to use IKEV2.  If they do
that they are outside the scope of this BCP.  That needs to be made
clear.

In particular, the reference to EAP for IKEV2 and the claim that you
need to specify what version of IKE is inappropriate in this document.

[Ballot discuss]
Also, please note that section 8 of this specification only coversn
IKEV1.  There are additional requirements for what needs to be
specified for IKEV2 not covered in your spec.  You need to make it
clear that this only covers 2401-based IPsec.  The current text
implies that applications could simply say to use IKEV2.  If they do
that they are outside the scope of this BCP.  That needs to be made
clear.

[Ballot discuss]
If this document is changed to state that it is the thought process that a protocol designer needs to go through if they want to secure their protocol with IPsec, it would be more appropriate. It is unclear in the intro or example sections that what is written is illustrative or prescriptive.

It needs to be clear via changing the title and text in the draft that this is for illustrative purposes only.

[Ballot comment]
Only partially tongue-in-cheek, perhaps the
document should be clearer in making a recommendation on
the use of IPsec for applications. For instance, "The
use of IPsec as a security mechanism for any other purpose
than VPNs is NOT RECOMMENDED, and should only be attempted
after careful analysis that such usage is indeed the best
option."

[Ballot comment]
Comment copied from Ted Hardie as he is leaving soon, this is related to my Discuss.

[2007-03-07] I have a small concern that the tone of the document may turn off the intended audience, by appearing to talk down to them.  Two examples, along with concrete suggestions, are given
below, but the problem is fairly general and other approaches might have the same result.  This
comment is, of course, non-blocking and the document can go forward without any change if
the author and IESG are not concerned with this issue.

OLD:

2.  WARNING

  The design of security protocols is a subtle and difficult art.  The
  cautions here about specifying use of IPsec should NOT be taken to
  mean that that you should invent your own new security protocol for
  each new application.  If IPsec is a bad choice, use another
  standardized, well-understood security protocol.  Don't roll your
  own.

NEW:

2.  WARNING

  The cautions here about specifying use of IPsec should NOT be taken to
  mean that that you should invent your own new security protocol for
  each new application.  If IPsec is a bad choice, using another
  standardized, well-understood security protocol will generally give the
  best results for both implementation and deployment.  The design of security
  protocols is a difficult art; rolling out a new protocol will require
  extensive work to confirm its security properties and will incur both
  delay and uncertainty.

OLD:

Selectors        The issue of selectors is easy.  BGP already runs
                    between manually-configured pairs of hosts on TCP
                    port 179.  The appropriate selector would be the
                    pair of BGP speakers, for that port only.  Note that
                    the router's "loopback address" is almost certainly
                    the address to use.

  Mode            Clearly, transport mode is the proper choice.  The
                    information being communicated is generally not
                    confidential, so encryption need not be used.
                    Either AH or ESP can be used; if ESP is used, the
                    sender's IP address would need to be checked against
                    the IP address asserted in the key management
                    exchange.  (This check is mandated by [RFC2401].)
                    For the sake of interoperability, the RFC author
                    should pick one.
NEW:

Selectors      BGP runs between manually-configured pairs of hosts on TCP
                    port 179.  The appropriate selector would be the
                    pair of BGP speakers, for that port only.  Note that
                    the router's "loopback address" is almost certainly
                    the address to use.

  Mode          Transport mode would likely be the proper choice if IPSec
                      were used.  The information being communicated is generally not
                    confidential, so encryption need not be used.
                    Either AH or ESP could be used; if ESP were used, the
                    sender's IP address would need to be checked against
                    the IP address asserted in the key management
                    exchange.  (This check is mandated by [RFC2401].)
                    For the sake of interoperability, either AH or ESP
                    would need to be mandatory to implement.

[Ballot comment]
> A new, simpler version of IKE has been
> approved, but there are few if any deployments [RFC4306].

Is this still true at the time this is being approved?

And finally, only partially tongue-in-cheek, perhaps the
document should be clearer in making a recommendation on
the use of IPsec for applications. For instance, "The
use of IPsec as a security mechanism for any other purpose
than VPNs is NOT RECOMMENDED, and should only be attempted
after careful analysis that such usage is indeed the best
option."

[Ballot discuss]
This is a great and much needed document. However, with my (mostly
negative) experience of a dozen or so attempts to use IPsec for
specific applications, I felt that it made rather weak assertions
where much stronger language should have been used.

Specific points below:

> All variants of IPsec have problems with NAT boxes -- see [RFC3715]
> for details -- but AH is considerably more troublesome.  In
> environments where there is substantial likelihood that the two end-
> points will be separated by a NAT box, AH should be avoided.  Note
> that [RFC3948] is for ESP only, and cannot be used for AH.

I would suggest that this be written in a slightly different way that
emphasizes the need to use IPsec NAT traversal unless it can be
shown that no NATs are involved. In addition, you should point
to remaining problems (if any) for running ESP with NAT-T,
along with the inability to use AH.

> It is, in some sense, a misnomer to speak of the API as a part of
> IPsec, since that piece is missing on many systems.  To the extent
> that it does exist, it isn't standardized.  The problem is simple: it
> is difficult or impossible to request IPsec protection, or to tell if
> was used for given inbound packets or connections.

This is a bit weak. A suggested reformulation:

Applications have rarely access to an API that they could use to
interact with the IPsec security services. To the extent that APIs do
exist, they have not been standardized. This is problematic in
a number of ways:

o  Applications programmers are unable to "turn on" IPsec
  protection automatically, and have to rely on external
  measures, such as manual administration. It becomes
  impossible to produce an appliation that is by default
  secure.

o  Applications are unable to verify that IPsec services
  are being used underneath.

o  Applications are unaware of the specific identities and
  properties of the protected channel provided by IPsec.
  For instance, the IPsec key management mechanisms may
  be aware of the identity and authorization of the peer,
  but this information cannot be used by the application,
  nor linked to application-level decisions, such as access
  to resources reserved to the entity identified by this
  identity.

In contrast, security services such as TLS that operate on higher
layers are often able to provide these functions.

> Even for host-to-host use, IPsec availability (and experience, and
> ease of use) has generally been for VPNs.  Hosts that support IPsec
> for VPN use do not always support it on a point-to-point basis,
> especially via a stable, well-defined API or user interface.

s/do not always/rarely/

> Section 4.4 of [RFC2401] describes the Security Policy Database (SPD)
> and "selectors" used to decide what traffic should be protected by
> IPsec.  Choices include source and destination addresses (or address
> ranges), protocol numbers (i.e., 6 for TCP and 17 for UDP), and port
> numbers for TCP and UDP.  Protocols whose protection requirements
> cannot be described in such terms are poorer candidates for IPsec in
> particular, it becomes impossible to apply protection at any finer
> grain than "destination host".

In a world that runs to a large extent on dynamically assigned
addresses and often uses dynamically assigned port numbers as well, an
all-or-nothing policy for VPNs works well but other policies can be
difficult to create.

> 3.3.  Key Management

This does not discuss situations where key management
cannot easily be accomplished using the standard IPsec
key management mechanisms. For instance, there are
chicken-and-egg problems in applying IKE to low-level
communication tools that attempt to establish a contact
or discover peers. RFC 2461 specified "just use IPsec"
for Neighbor Discovery. Among the many limitations of
that specification was that you couldn't possibly use
IKE for setting up the security assocations for ND
communication, because to use IKE you would have
had to be able to send packets, which in turn would
have required that ND had already run.


> f.  What form of authentication should be used?  Choices include pre-
>    shared secrets, certificates, and (for IKEv2) an EAP exchange
>    [RFC3748].

Shouldn't we talk about authorization here as well? The fact
that my device has a company certificate does not mean that
it can use any application or any resource.

As an example, Mobile IPv6 has had to deal with authorizing
the use of a specific home address, to avoid other, also
certified, users from hijacking that address.

Suggested addition:

f2.  How are the participants authorized to perform the
    operations that they request? For instance, are all
    devices with a certificate from a particular source
    allowed to use any application with with IPsec or
    access any resource?

>  Security Policy  Connections should be accepted only from the
>                  designated peer.

Question. What if the router has many functions, e.g., BGP,
management, VPN gateway, statistics collection? Would you need RFC
4301 PAD to distinguish the different credentials needed for different
tasks? Its unclear to me how this is done in RFC 2401 space.

[Ballot discuss]
I share Ted's concern in his Comment, but consider the mandate of "Don't roll your own" too strong for a BCP and worthy of a DISCUSS. There are times when building in security into a protocol is a Good Thing. As Steven indicates, security is a difficult art, and as such I think that even this type of warning is not so black and white as he states here.

Ted's suggested text on this would satisfy my discuss.

[Ballot discuss]
The introductions says:

  This document offers some guidance on when IPsec should and should not
  be specified.

However, I didn't see any guidance regarding the types of problems that IPsec doesn't protect against. As one example, I understand that IPsec could be used in routing protocols to protect against attacks that in theory could possibly occur. However, the vast majority of attacks that I have heard about against routers fall into three categories: (i) DDOS against the control plane; (ii) Bad password selection; (iii) Accidental mis-configuration by well-intended and properly authorized network operators. IPsec doesn't protect against any of these. In fact, in order to protect against (i), it is at least desirable to set things up so that hackers can't send any packet *to* the router's control plane at all, which reduces the value that results from authentication of packets to the router's control plane. Also, use of IPsec on packets to the router's control plane will magnify the effect of any DDOS attack against the control plane.

If we are going to be talking about *mandating* security mechanisms for use in routing protocols (BGP is used as an example in this document), and if IPsec is the only security mechanism discussed in the document, then I think that we need a more balanced discussion of what can, and what cannot, be accomplished by IPsec.

[Ballot discuss]
The introductions says:

  This document offers some guidance on when IPsec should and should not
  be specified.

However, I didn't see any guidance regarding the types of problems that IPsec doesn't protect against. As one example, I understand that IPsec could be used in routing protocols to protect against attacks that in theory could possibly occur. However, the vast majority of attacks that I have heard about against routers fall into three categories: (i) DDOS against the control plane; (ii) Bad password selection; (iii) Accidental mis-configuration by well-intended and properly authorized network operators. IPsec doesn't protect against any of these. In fact, in order to protect against (i), it is at least desirable to set things up so that hackers can't send any packet *to* the router's control plane at all, which reduces the value that results from authentication of packets to the router's control plane. Also, use of IPsec on packets to the router's control plane will magnify the effect of any DDOS attack against the control plane.

If we are going to be talking about *mandating* security mechanisms for use in routing protocols (BGP is used as an example in this document), and if IPsec is the only security mechanism discussed in the document, then I think that we need a more balanced discussion of what can, and what cannot, be accomplished by IPsec.

[Ballot comment]
I realize this has been in the works for some time now, but it seems a little odd that it only talks about "ipsec v2" when we are seeing security reviews criticizing documents for not having adapted the "ipsec v3" model.  It's excellent to have a guidance document, but will this document guide authors towards something that will cause problems at secdir review time?

[Ballot comment]
The Introduction Section says:

'This document describes how to specify the use of IPsec Version 2
  [RFC2401], including ESPv2 [RFC2406], AHv2 [RFC2402], and IKEv1
  [RFC2409].  A separate document will describe the IPsec Version3
  suite [RFC4301] [RFC4302] [RFC4303] [RFC4306].'

Should not the title reflect this and be 'Guidelines for Mandating the Use of IPsec Version 2', while the future separate document will refer to IPsec Version 3?

[Ballot comment]
I have a small concern that the tone of the document may turn off the intended audience, by appearing to talk down to them.  Two examples, along with concrete suggestions, are given
below, but the problem is fairly general and other approaches might have the same result.  This
comment is, of course, non-blocking and the document can go forward without any change if
the author and IESG are not concerned with this issue.

OLD:

2.  WARNING

  The design of security protocols is a subtle and difficult art.  The
  cautions here about specifying use of IPsec should NOT be taken to
  mean that that you should invent your own new security protocol for
  each new application.  If IPsec is a bad choice, use another
  standardized, well-understood security protocol.  Don't roll your
  own.

NEW:

2.  WARNING

  The cautions here about specifying use of IPsec should NOT be taken to
  mean that that you should invent your own new security protocol for
  each new application.  If IPsec is a bad choice, using another
  standardized, well-understood security protocol will generally give the
  best results for both implementation and deployment.  The design of security
  protocols is a difficult art; rolling out a new protocol will require
  extensive work to confirm its security properties and will incur both
  delay and uncertainty.

OLD:

Selectors        The issue of selectors is easy.  BGP already runs
                    between manually-configured pairs of hosts on TCP
                    port 179.  The appropriate selector would be the
                    pair of BGP speakers, for that port only.  Note that
                    the router's "loopback address" is almost certainly
                    the address to use.

  Mode            Clearly, transport mode is the proper choice.  The
                    information being communicated is generally not
                    confidential, so encryption need not be used.
                    Either AH or ESP can be used; if ESP is used, the
                    sender's IP address would need to be checked against
                    the IP address asserted in the key management
                    exchange.  (This check is mandated by [RFC2401].)
                    For the sake of interoperability, the RFC author
                    should pick one.
NEW:

Selectors      BGP runs between manually-configured pairs of hosts on TCP
                    port 179.  The appropriate selector would be the
                    pair of BGP speakers, for that port only.  Note that
                    the router's "loopback address" is almost certainly
                    the address to use.

  Mode          Transport mode would likely be the proper choice if IPSec
                      were used.  The information being communicated is generally not
                    confidential, so encryption need not be used.
                    Either AH or ESP could be used; if ESP were used, the
                    sender's IP address would need to be checked against
                    the IP address asserted in the key management
                    exchange.  (This check is mandated by [RFC2401].)
                    For the sake of interoperability, either AH or ESP
                    would need to be mandatory to implement.

[Ballot comment]
I liked this document and think it will be very useful but one line made me wonder if it really was true.

The document says "Furthermore, there is no global PKI for the Internet and probably never will be one." I would venture a wild guess that 100's of millions of people covering every country in the world regularly use HTTPS with approximately the root CA list Internet Explorer provides to achieve some security goals. I can understand the argument that this is not a good PKI, but I have a very hard time imagining why it is not a global PKI. Perhaps there is some special meaning in the terms of art that I do not understand but if that is the case, I suspect that the target audience for this document would not understand them either.

That said, I don't think changing this line one way or the other changes the value of this document.

[Ballot comment]
Kink has been defined and implementations are available; please update the text.

One requirement of IPsec is that a server must define policy entries
that determine whether traffic will be protected ahead of time.  This
for example typically means that you cannot run a server that supports
both secure and insecure traffic without using multiple ports.  You
should point this out.

[Ballot discuss]
I don't understand what  the following text means:
>  d.  What security policy database entry types should be used by the
>      responder (i.e., the server) when deciding whether or not to
>      accept the IPsec connection request?


Also, please note that section 8 of this specification only covers
IKEV1.  There are additional requirements for what needs to be
specified for IKEV2 not covered in your spec.

[Ballot discuss]
Section 12.1., paragraph 8:
>    [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
>              (NAT) Compatibility Requirements", RFC 3715, March 2004.

  DISCUSS: Is a DOWNREF. But from the way it is cited ("all variants of
  IPsec have problems with NAT boxes -- see [RFC3715]"), this can
  probably safely become an informational reference.