Internet Key Exchange (IKEv2) Protocol
draft-ietf-ipsec-ikev2-17

Reviewed by Scott Brim, Gen-ART.

Only minor issues found.
This round's review (on version 15):

I'm no IKE expert, but it looks ready to go except for two presentation
issues that could be fixed.  I don't think they should hold it back --
Harald gets to decide.  I suggest "no objection".  I'm CCing Charlie
Kaufman.

First, as said before on previous versions, I think the "Bob and Alice"
stuff is not clearer than simply using "initiator" and "responder"
everywhere, and in fact gets in the way.  The document is still
readable, but one has to translate Bob and Alice into initiator and
responder, so they are not helpful.

Second, a nit -- this text:

                                     Transform    Used In
                                        Type
          RESERVED                        0
          Encryption Algorithm (ENCR)     1  (IKE and ESP)
          Pseudo-random Function (PRF)    2  (IKE)
          Integrity Algorithm (INTEG)     3  (IKE, AH, and optional in
          ESP)
          Diffie-Hellman Group (D-H)      4  (IKE and optional in AH and
          ESP)
          Extended Sequence Numbers (ESN) 5  (Optional in AH and ESP)
          RESERVED TO IANA                6-240
          PRIVATE USE                     241-255


could use better formatting.

In Section 2.23:
  
     If the NAT_DETECTION_DESTINATION_IP payload received does not
      match the hash of the destination IP and port found from the IP
      header of the packet containing the payload, it means that this
      end is behind NAT (i.e., the original sender sent the packet to
      address of the NAT box, which then changed the destination address
      to this host). In this case the this end should start sending
      keepalive packets as explained in [Hutt04].

Two nits:  "the this end should" should probably be "this end"; the parenthetical
section seems confusing and should probably be re-worded or perhaps
dropped (as what to do is clear without it).

Just below, NAT-T is used without explanation in the text; expansion may be useful.

In 3.3.4 (Mandatory transform IDs), the draft says:

   
   It is likely that IANA will add additional transforms in the future,
   and some users may want to use private suites, especially for IKE
   where implementations should be capable of supporting different
   parameters, up to certain size limits. In support of this goal, all
   implementations of IKEv2 SHOULD include a management facility that
   allows specification (by a user or system administrator) of Diffie-
   Hellman parameters (the generator, modulus, and exponent lengths and
   values) for new DH groups. Implementations SHOULD provide a
   management interface via which these parameters and the associated
   transform IDs may be entered (by a user or system administrator), to
   enable negotiating such groups.

   All implementations of IKEv2 MUST include a management facility that
   enables a user or system administrator to specify the suites that are
   acceptable for use with IKE. Upon receipt of a payload with a set of
   transform IDs, the implementation MUST compare the transmitted
   transform IDs against those locally configured via the management
   controls, to verify that the proposed suite is acceptable based on
   local policy.  The implementation MUST reject SA proposals that are
   not authorized by these IKE suite controls.

reading these together, it was not clear to me whether it was considered
acceptable for an implementation to be configured such that there
were none of the mandatory transforms in its permitted set.  I eventually
came to the conclusion that this was permitted (i.e., only private suites
in use), but I feel the document might benefit from making the point explcit
here, one way or the other.

The IANA considerations seem sparse, and I hope the wg is prepared
to work with IANA and the designated expert on this, especially in
setting up the process for creating a new registry when a new transform
type is registered.