Guidelines for Specifying the Use of IPsec Version 2
RFC 5406

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?

Carrying forward Ted's no objection vote.

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.

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?

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."

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.

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.