comments/concerns about ikev2-05

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 - question - section 1.2: why the SA2 stuff is mandatory, i.e., why
   the IKE_AUTH has to build an IPsec SA pair? The answer seems to be
   this is simpler but I don't know if a paranoid guy should not prefer
   to get PFS also for the first IPsec SA pair...

 - comment - section 1.5: this section (and the 2.21 one) uses to hidden
   and incorrect assumption that an address identifies only one node.
   Of course with NAT traversal many nodes can share the same address
   (but not the same port), and a node can use many addresses.
   I'd like to see more care in the wording.

 - comment - section 2.1: the text is not enough accurate about what is
   retransmitted. IMHO it is the IKE message itself only. For instance
   if a responder receives for the second time a request but from a different
   address, it should send the same reply but to the new address.
   To solve this kind of issues I propose:
    * to make very clear that replies are sent with the reversed addresses
      and ports (i.e., source becomes destination and destination source,
      both for the IP header addresses and the UDP ports).
      Note this rule is very strict and suffers no exception.
    * to specify that what is restransmitted/cached/etc is the IKE message
      itself and not the whole IP packet.

  - comment - section 2.19: the term IRAC and IRAS must be introduced
    (there is no acronym section).

  - comment - section 2.21: read the comment about section 1.5 and the
    "UDP port 500" should be changed in "UDP port 500 or 4500".

  - concern - section 2.23: "responses SHOULD be sent to the port from
    whence they came" has to be changed in "responses MUST be sent to the
    address and port from whence they came and from the address and port
    to whence they came". Read the comment about section 2.1.
    Note that I have a concern about to perform NAT detection in the
    IKE_SA_INIT exchange, cf my comment about section 3.10.1.

  - question - section 3.6: this section defines certificate encoding
    values without the corresponding layout, i.e., some defined types
    are not usable because underspecified. It is the case of the DNS
    signed key. Is it the KEY RRset with its SIG RRs in wire format
    (cf RFC 1035 and 2535)?

  - question - section 3.6: hash and URL of PKIX stuff doesn't require
    HTTP URLs. This is fine but HTTP-CERT-LOOKUP-SUPPORTED seems to
    be more restricting. LDAP at least should be allowed.
    (IMHO the "HTTP-based URL" idea (?) is the source of this issue)
    Note: I'd like to be able to get certificates or public keys through
    the DNS in a standardized way.

  - typo - section 3.10.1: INVALID-SPI is defined twice. At least one
    should be specialized, i.e., value 4 for INVALID-IKE-SPI or
    value 11 for INVALID-IPSEC-SPI.

  - typo - section 3.10.1: where is the COOKIE-REQUIRED notification?
    (proposal: either define or delete it)

  - concern - section 3.10.1: I signaled that NAT-DETECTION-*-IPs were
    buggy. Unfortunately they are still wrong. If we look at
    the Tero's draft about NAT traversal (draft-ietf-ipsec-nat-t-ike-05.txt):
     - the detection can be done in the second exchange (IKE_AUTH).
     - the SHA-1 of SPIs (why?), addresses and ports can be easily
       faked by an attacker. As the NAT traversal is less secure,
       the current spec opens the door to a bidding down attack.
    I tried both to fix the NAT traversal support and to introduce
    mobility/multihoming support in my draft about address management.
    A new version should be available soon, the name of my I-D is:
    draft-dupont-ikev2-addrmgmt-01.txt
    Everything in it should be considered at the exception of the explicit
    peer address mechanism (same effect can be got with rekeying, of course
    not at the same price).

  - typo - section 3.14: s/Encrpted/Encrypted/

  - typo - appendix A: two 12)

  - typo - history H.4: s/from IKEv2-05/from IKEv2-04/

  - comment: there is nothing about IKE keepalives... If it is added one
    day (IMHO it should be), with NAT traversal the peer behind a NAT
    SHOULD send requests.

Regards

Francis.Dupont@enst-bretagne.fr

PS: of course detailed concerns with proposals can be found in my draft.
I submitted it two days ago but I can send it to impatients...