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

[Ballot comment]
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.

[Ballot discuss]
My exponential backoff issue was resolved, however I don 't think that my other issue has been fully addressed.

The draft now says:

  IKEv2 implementations SHOULD be aware of the maximum UDP message size
  supported and MAY shorten messages by leaving out some certificates
  or cryptographic suite proposals if that will keep messages below the
  maximum.

How are implementations supposed to know the UDP message size?  Does this mean that IKEv2 nodes SHOULD implement PMTU discovery so that they can know what size packet will reach the other end without fragmentation.

The document states that there can be a DoS risk if fragmentation occurs.  I don't understand why that is the case or how serious of a risk it is, so I am not sure how important it is (or isn't) to avoid fragmentation.  However, there certainly are options available to avoid IP-layer fragmentation if that poses a risk.  Is there a reason why that isn't considered to be worth the trouble?

[Ballot discuss]
My exponential backoff issue was resolved, however I don 't think that my other issue has been fully addressed.

The draft now says:

  IKEv2 implementations SHOULD be aware of the maximum UDP message size
  supported and MAY shorten messages by leaving out some certificates
  or cryptographic suite proposals if that will keep messages below the
  maximum.

How are implementations supposed to know the UDP message size?  Does this mean that IKEv2 nodes SHOULD implement PMTU discovery so that they can know what size packet will reach the other end without fragmentation.

The document states that there can be a DoS risk if fragmentation occurs.  I don't understand why that is the case or how serious of a risk it is, so I am not sure how important it is (or isn't) to avoid fragmentation.  However, there certainly are options available to avoid IP-layer fragmentation if that poses a risk.  Is there a reason why that isn't considered to worth the trouble?

[Ballot discuss]
In 2002, the working group decided not to pursue elliptic curves.  Hilarie Orman made several presentation advocating them; her slides are in the minutes.  However, the IPR concerns associate with elliptic curves lead the working group to classic Diffie-Hellman.  Yet, two elliptic curve groups are still included in the document.  This seems to contradict the working group decision.  I suggest the removal of the elliptic curve groups from Appendix B.

[Ballot discuss]
In general, I think that this is a good piece of work.  However, there are two issues with this document that should be addressed:

(1) This document uses UDP and includes a retransmission mechanism for requests, but it does not indicated that the retransmission timer must back off exponentially.

(3) This specification does not mandate a minimum supported UDP packet size for hosts that
implement IKEv2.  Would the default minimum (556 bytes of UDP payload in IPv4) be sufficient?  Or should this specification mandate that implementations of IKEv2 must support larger UDP packets?

[Ballot discuss]
Comments from the ops directorate:

In reading this draft, I am concerned about whether the IPv6
addressing model that is described in Section 2.19 and 3.15 has been fully
thought through.

The CFG_REQUEST functionality that is described is somewhat in
the style of PPP's IPCPv4, in that a particular address can be assigned,
along with IP-layer parameters such as the DNS and WINS server addresses.

However, for PPP IPCPv6, a different route was taken; only the
Interface-Id is negotiated with mechanisms such as RS/RA used to obtain
the prefix and upper-layer configuration handled by
existing mechanisms such as DHCPv6.  This allows configuration mechanisms
to be leveraged across interface types.

I'm concerned that the implications of the IPv6 configuration mechanisms
defined in IKEv2 haven't been well thought through; the examples seem
mostly focussed on IPv4.

For example, the document contains a  number of oddities -- it defines how
to configure an IPv6 NetBios Name Server, even though NetBIOS is not
supported for IPv6;  yet another mechanism is defined for configuring an
IPv6 DNS server;  the draft allows a host to obtain *both* an address and
a prefix, as well as to obtain the address of a DHCP server, etc.

Note that a number of comments were posted to the IPSEC list about these
issues, but they seem to have been ignored.

[Ballot discuss]
I have three concerns about this document:

(1) This document uses UDP and includes a retransmission mechanism for requests, but I couldn't find anything that indicated that the retransmission timer must back off exponentially.

(2) I'm not sure if this is a real concern or not, but...

This document defines a UDP-based prototol that includes at least one mechanism (hash based encoding of certificates) to avoid the need for IP fragmentation.  However, there are many other
IKEv2 payloads defined that are variable length and could be quite long.  Furthermore, there is
the possibility of IKEv2 packets containing multiple payloads.

Given the statement that the use of IP fragmentation opens up the possibility of DoS attacks, did
the authors consider any IKE-level mechanisms to avoid fragmentation, such as limiting the
overall packet size?  Or compressing the payloads in some way?

(3) Should this specification mandate a minimum supported UDP packet size for hosts that
implement IKEv2? 

These last two are really just questions, so if they have already been discussed in the WG or don't apply
for some reason, I'll remove my discuss.

[Ballot discuss]
I'm not sure if this is a real concern or not, but...

This document defines a UDP-based prototol that includes at least one mechanism (hash based encoding of certificates) to avoid the need for IP fragmentation.  However, there are many other
IKEv2 payloads defined that are variable length and could be quite long.  Furthermore, there is
the possibility of IKEv2 packets containing multiple payloads.

Given the statement that the use of IP fragmentation opens up the possibility of DoS attacks, did
the authors consider any IKE-level mechanisms to avoid fragmentation, such as limiting the
overall packet size?  Or compressing the payloads in some way?

Also, should this specification mandate a minimum supported UDP packet size for hosts that
implement IKEv2?

These are really just questions, so if they have already been discussed in the WG or don't apply
for some reason, I'll remove my discuss.

[Ballot discuss]
I'm not sure if this is a real concern of not, but...

This document defines a UDP-based prototol that includes at least one mechanism (hash based encoding of certificates) to avoid the need for IP fragmentation.  However, there are many other
IKEv2 payloads defined that are variable length and could be quite long.  Furthermore, there is
the possibility of IKEv2 packets containing multiple payloads.

Given the statement that the use of IP fragmentation opens up the possibility of DoS attacks, did
the authors consider any IKE-level mechanisms to avoid fragmentation, such as limiting the
overall packet size?  Or compressing the payloads in some way?

Also, should this specification mandate a minimum supported UDP packet size for hosts that
implement IKEv2?

These are really just questions, so if they have already been discussed in the WG or don't apply
for some reason, I'll remove my discuss.

[Ballot comment]
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.

[Ballot discuss]
In section 1.5, the last sentence says: "... it MAY send an Informational
  message without cryptographic protection to the source IP address and port
  to alert it to a possible problem."  However, section 1.4 says that
  informational messages "MAY ONLY occur after the initial exchanges and are
  cryptographically protected with the negotiated keys."  These are in
  conflict, and one of them needs to be changed to resolve the conflict.
  Also, "MAY ONLY" ought to be changed to "MUST ONLY."

  In section 2.23, the text says: "IKEv2 can negotiate UDP encapsulation of
  IKE, ESP, and AH packets."  Then, in the middle of page 38, the conventions
  for tunneling IKE and ESP over UDP are described.  The conventions for AH
  ought to be described too.  Further, the IANA registry for port 4500 ought
  to be updated to point to this document.  It currently says:
 
    ipsec-msft      4500/tcp  Microsoft IPsec NAT-T
    ipsec-msft      4500/udp  Microsoft IPsec NAT-T
    #              Christian Huitema  March 2002

  In the 3rd paragraph of section 2.21, the document says: "If the message is
  marked as a response, the node MAY audit the suspicious event but MUST NOT
  respond."  How would an implementation respond to a response message?

  In section 3.3.2, the table for transform type values needs an entry for
  zero, making it RESERVED.

  Also in Section 3.3.2, the table for encryption algorithms has some missing
  references.  ENCR_AES_CBC ought to refer to RFC 3602, and ENCR_AES_CTR ought
  to refer to RFC 3686.

  Also in Section 3.3.2, the table of PRFs should replace "PRF_AES_CBC" with
  "PRF_AES128_CBC" in order to match the companion algorithms document.
  Further, it ought to refer to RFC 3664.

  Also in Section 3.3.2, the last entry in the integrity algorithms table is
  ought to be AUTH_AES_XCBC_96, and it ought to refer to RFC 3566.

  Also in Section 3.3.2, the Diffie-Hellman groups table should not constrain
  the kinds of groups that might be registered in the future.  It ought to
  say: "values 6-13 and 19-1023 are reserved to IANA."

  In section 3.3, I do not understand the context where ESP or AH would make
  use of D-H.  Why is D-H an optional type for ESP or AH?

  In section 3.5, the table needs to say something about values 4, 6, 7,
  and 8.  I assume that they are also reserved to IANA.

  In section 3.10.1, the first table needs an entry for zero, making it
  RESERVED.  Further, at the end of the first table, the document ought to
  reserve values 40-1891 (not 39-8191).

  In section 6, please change the title of the Diffie-Hellman registry
  to "IKEv2 Diffie-Hellman Transform IDs."  Again, the point is to avoid
  unduly constraining the kinds of groups that might be registered in
  the future.

  Also in section 6, the last paragraph would be more clear if is said:
  "Changes and additions to any of these registries are by expert review."

  Appendix A refers to two Internet Drafts that will never be published.
  These references need to be replaced with a brief summary of the issue.

[Ballot discuss]
Define SA.  Define -- not just expand -- "IKE SA".  What is one?

2.7: The acronym SA is overloaded -- it's being used to refer to a concept as well as to a payload containing proposals for the concept.

2.15: This section denounces passwords, but the only mandatory input mechanism for shared secrets is an ASCII string.  It MUST support hex input

2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 addresses.

3.1: The text about ignoring things from the UDP header beyond the ports and addresses is a bit odd, since that's about all there is in it....

3.3.3: What are ESN and INTEG?

3.3.5: RC4 also requires a key length

3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems.  Support for ID_IPV4_ADDR is only required for IPv4-capable systems

3.6: What URL types must be supported?  HTTP?  HTTPS?  FTP?  MAILTO?

5: A discussion of fragmentation attacks needs to be here.  The bare mention of [KPS03] earlier is insufficient.

Appendix B doesn't list DH Group 5, but it's mentioned in Section 5.

[Ballot comment]
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.)

[Ballot discuss]
Define SA.  Define -- not just expand -- "IKE SA".  What is one?

2.7: The acronym SA is overloaded -- it's being used to refer to a concept as well as to a payload containing proposals for the concept.

2.15: This section denounces password, but the only mandatory input mechanism for shared secrets is an ASCII string.  It MUST support hex input

2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 addresses.

3.1: The text about ignoring things from the UDP header beyond the ports and addresses is a bit odd, since that's about all there is in it....

3.3.3: What are ESN and INTEG?

3.3.5: RC4 also requires a key length

3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems.  Support for ID_IPV4_ADDR is only required for IPv4-capable systems

3.6: What URL types must be supported?  HTTP?  HTTPS?  FTP?  MAILTO?

5: A discussion of fragmentation attacks needs to be here.  The bare mention of [KPS03] earlier is insufficient.

Appendix B doesn't list DH Group 5, but it's mentioned in Section 5.

[Ballot comment]
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.)

Should the techniques in [KPS03] be mandatory?

[Ballot discuss]
Define SA.  Define -- not just expand -- "IKE SA".  What is one?

2.7: The acronym SA is overloaded -- it's being used to refer to a concept as well as to a payload containing proposals for the concept.

2.15: This section denounces password, but the only mandatory input mechanism for shared secrets is an ASCII string.  It MUST support hex input

2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 addresses.

3.1: The text about ignoring things from the UDP header beyond the ports and addresses is a bit odd, since that's about all there is in it....

3.3.3: What are ESN and INTEG?

3.3.5: RC4 also requires a key length

3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems.  Support for ID_IPV4_ADDR is only required for IPv4-capable systems

3.6: What URL types must be supported?  HTTP?  HTTPS?  FTP?  MAILTO?

Appendix B doesn't list DH Group 5, but it's mentioned in Section 5.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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).