Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   For this reason, what we propose is that we pick an approach, and be
   done with it.  The question then before the working group is whether or
   not there is another way to accomplish the task, but whether there are
   either (a) fatal flaws in the proposal presented, (b) clear,
   overwhelming advantages to do things a different way (and no handwaving;
   it must be a complete proposal), or (c) minor enhancements that all can
   agree are worthwhile to include in the protocol and worthwhile to
   implement.  Otherwise we will be arguing until the cows come home
   (and/or when the IESG shuts us down, or the mob from problem-statement
   mailing list show up with the pitchforks, tar, and feathers :-).
   
   (SEMI-)CLOSED ISSUES
   =====================
   
   The following issues have been burbling on the list, although in the
   opinion of the IPSEC Working group chairs, there isn't consensus in the
   IPSEC working group to act on them.
   
   If you feel otherwise, please speak now.
   
   A)  Revised identity 
   --------------------
   
=> I am afraid that either we have to include a large part of
draft-ietf-ipsec-pki-profile-xx.txt draft, or to adopt this
revised identity proposal. IMHO this is between (a) and (b).

   B) DHCP-based vs. MODECFG style remote access configuration
   -----------------------------------------------------------
   
=> IMHO IKE should not be involved directly into address
allocation... I propose to ask the IPSRA WG to remove if they'd like
any relevant part from IKEv2 (they should already have strong opinions
and they should like the idea to remove something from an IPsec WG
proposal :-). This is between (b) and (c).

   If there are those who feel otherwise, or who see fatal problems with
   the current approach, please speak now.
   
=> the NAT-DETECTION-*-IP notifications were cut&paste from a draft
for IKEv1 and should be fixed. Fortunately this is easy and we can
extend the fix to a proper address management in IKEv2.
I'd like that the proposal of draft-dupont-ikev2-addrmgmt-00.txt is
included in the next IKEv2: all the section 3 at the exception of
the subsection 3.5 which is a real change and perhaps needs more
discussion.
BTW I have a minor point: my proposed "peer address update" notification
relies on a strong sequencing of IKE messages. The current draft has
only a weak sequencing (weak because the message ID, aka the sequence
number, is not protected), I don't know if this is a global problem,
i.e., if the replay of old messages with a fresh message ID can be
used for real attacks...

Regards

[e-mail]