Re: Concerning the SOURCE-ADDRESS-CHANGED proposal

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

 In your previous mail you wrote:

   >            its IP-address and wants the responder of this
   >            notification to update the IKE SA remote peer address and
   >            port. When this notification is received the host MUST

=> note that this problem (to trust in the peer to give its real address
or to perform a return routability check) was discussed for mobile IPv6
and the conclusion is to trust the peer in some cases (I can send
references if you are interested): I have a concern about this MUST
(in my proposal it is a SHOULD and there is a MAY if the responder
decides to not perform the check).

   >            do the dead peer detection against the address given in
   >            this payload, and if that is successful then the IKE SA
   >            peer address and all the child SA tunnel endpoint
   >            addresses MUST be updated to new address. 
   
   Tero's specification doesn't state what should happen if the dead peer
   detection fails, or how long the responder should hold onto the address
   change notification state information and do the "dead peer detection
   thing" until its peer appears on the new source address.
   
=> you've put the finger on some reasons I don't like the idea to allow
to send an update from the old address (something which is not allowed
too in mobile IP): a lot of problems for a little gain in some cases...

   These are minor issues, which can certainly be worked out.  But in the
   interests of time and closure, and given that both Tero's and
   Francis's proposals are additions to the ikev2 protocol that could be
   easily specified as an addition in a separate document, Barbara and I
   will suggest that this be best handled separately from the ikev2
   specification.
   
=> I have no problem with that. I always wrote or said the update itself
can be postponed (it will be the first critical payload :-) because it
can be simulated by rekeying, i.e., it is only an optimization.
Note this is *not* the case for the peer address protection (which fixes
a security flaw) or for a better text for NAT traversal...

Thanks

Francis.Dupont@enst-bretagne.fr