Re: Working Group Last Call IKEv2

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

 In your previous mail you wrote:

   I have some concerns about the current draft (08), here are
   the minor concerns:

    - in section 2.1 (retransmission) we should stress the "messages"
      are IKE messages, i.e., for instance one can restransmit a request
      using a different address in the transport header. I propose a
      very simple improvement, change:

     For every pair of messages, the Initiator is responsible for

      to

     For every pair of IKE messages, the Initiator is responsible for

     so the reader can refer to section 3 where IKE messages are defined.

    - nowhere the rule for sending response (reverse the transport stuff)
      is fully explained. I propose to complete section 2.11 (agility):

     ... An implementation MUST
     accept incoming connection requests even if not received from UDP
     port 500 or 4500, and MUST respond to the address and port from which
     the request was received.

      becomes:

     ... An implementation MUST
     accept incoming requests even if not received from UDP port 500 or
     4500, and MUST respond to the address and port from which the request
     was received, and from the address and port to which the request was
     received.

      note that I suppressed the word "connection" as this stands for
      every requests.

    - when CHILD_SAs rekeyed with a CREATE_CHILD_SA using PFS are usable?
      In IKEv1 these synchro issues are handled by the infamous commit bit
      and the third message of quick mode... IMHO the companion draft
      (draft-ietf-ipsec-ikev2-tutorial-xx.txt) should give some hints.
      BTW I'd like to get the opinion from other implementors because
      the simplest solution (wait for an initiator->responder packet)
      is not always available... This can be an occasion to explain
      what SA to use in rekeying, the new one or the old one until it
      expires?

Regards

Francis.Dupont@enst-bretagne.fr