Internet Key Exchange (IKEv2) Protocol
RFC 4306

Note: This ballot was opened for revision 17 and is now closed.

(Steven Bellovin) (was Discuss) Yes

Comment (2004-06-09)
No email
send info
Should there be discussion of requirements for maximum UDP packet size (after fragment reassembly)?  On the number of very closely-spaced packets that the system must be capable of receiving?  (There have been reports of interoperability problems in the past because of this issue.)

(Russ Housley) (was Discuss, Yes, Discuss, Yes) Yes

Comment (2004-06-09)
No email
send info
  Please spell out the acronym "PFS" the first time it is used.

  In the 2nd paragraph of section 3.12, the document says: "... i.e., it MUST
  be non-critical."  It would be more clear, I think, to say: "the critical
  bit MUST be set to 0."  This is discussed elsewhere in the document, but
  stating the value of the bit will make it clearer.

  In section 3.1, the second-to-last entry in the main table should read
  "RESERVED TO IANA" to match the wording in the rest of the tables.

  [IKEv2IANA] and [Ker01] are not referenced in the document.  Please
  delete these references.

(Harald Alvestrand) No Objection

Comment (2004-09-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Margaret Cullen) (was Discuss) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-06-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Scott Hollenbeck) No Objection

(David Kessens) (was Discuss, No Objection) No Objection

(Allison Mankin) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection