Subject: Concerning the SOURCE-ADDRESS-CHANGED proposal

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 11 Apr 2003 16:22:55 -0400

Hmm... after looking at Tero's proposal, Barbara and I have found some
places where it requires some polishing and attention to corner cases as
well:

>            This notification is sent when the other end has changed
                                                ^^^^^^^^^ 
We assume this should be "sender", or the rest of the sentence
doesn't make any sense.

>            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
>            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.

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.

							- Ted

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Apr 2003 01:25:10 +0200

>            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).

   
=> 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...

=> 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

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Sat, 12 Apr 2003 07:29:03 +0300

> will suggest that this be best handled separately from the ikev2

I would actually like to see Tero's scheme in the base IKEv2 document.
An ability to cope with changing addresses is becoming essential
in today's networks. Roaming around, being mobile, multi-homing,
... all of these call for an ability to change addresses. While
it is true that rekeying can help here as well, its really
undesireable solution for many people.

Jari

P.S. I can also promise to contribute in solving the issues you
identified.