Subject: Re: [mobile-ip] Mipv6 issue #194: More details on how movements are handling wrt IKE

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jan 2003 22:23:32 +0200

> - If the mobile node has used IKE to establish security associations
>   with its home agent and wishes to receive notifications from the
>   home agent, it MUST re-establish IKE Phase 1 connection after
>   movements. It SHOULD do this in parallel with other tasks related to
>   movements, such as sending Binding Updates, as the use of existing
>   IPsec security associations does not require IKE.

James pointed out the performance impacts of this step. While
this step is only needed if you (a) use IKE and (b) want to receive
the notifications, it is indeed pretty bad on the performance.
I added the second condition in order to not force this on all
MNs.

But why would we want to keep the IKE connection up then? Its because
we could be receiving notifications on it, such as the home agent
telling the MN that it is going to delete the IPSec SAs established
earlier.

I don't like running IKE on every movement at all. What alternatives
do we have? We can

- Expect nodes to not want to get the notifications
- Require an API between MIPv6 and IKE so that the IKE SAs can
   also change their endpoints
- Rely on IKEv2 to not be so bound to the IP addresses (what's the
   status on that?)
- Something else, what?

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Jan 2003 11:29:17 +0100

Note that IKE protocol is unable to change its endpoints in this
   manner [is this really true?].

=> this is not true: a rekeying can change endpoints.

   Given that IKE is run using care-of addresses, this renders the current
   IKE security association unusable upon movements.

=> an IKE implementation can use the IKE SA SPI to keep the IKE SA
accross movements, so your next statement is not always true:

   A new IKE Phase 1 is therefore needed for rekeying, if
   movements have occurred.
   
   - If the mobile node has used IKE to establish security associations
      with its home agent, it SHOULD delete all IKE Phase 1 connections
      run on top of the previous care-of address when the previous care-of
      address is no longer usable or is about to become unusable.
   
=> either the HA IKE implementation uses the IKE SA SPI and this is
not necessary, or it doesn't use it and it will drop any attempt
to delete the IKE SA from a new care-of...

=> s/re-establish/& or update endpoint addresses of/

   Home agents:
   
   - If the home agent has used IKE to establish security associations
      with the mobile node, it SHOULD delete all IKE Phase 1 connections
      run on top of the previous care-of address upon making a
      modification to the care-of address in a binding.
   
=> note there is usually no API for IKE SA deletion (only IPsec SAs
are managed by PF_KEY).

   PROCESSING SEQUENCES
   ====================
   
   Step 2. Mobile node runs IKE from care-of address B to the home
   agent, establishing a Phase 1.
   
   Step 5. Mobile node establishes a pair of security associations for
   protecting return routability packets. These security associations are
   in tunnel mode and their endpoint in the mobile node side is care-of
   address B.
   
=> do you implicitely assume the step 5 uses the phase 1 established
in step 2 or IKE can be rerun (i.e., step 2 and 5 are independent)?

   Step 8. Mobile node sends a Binding Update and receives a Binding
   Acknowledgement using the security associations created in Step 3.

=> so step 3 (BU/BA) IPsec SAs should have a long lifetime (and
don't rely on the step 2 phase 1 for their management).

   The home agent modifies the endpoint of the security associations
   created in Step 5 to the care-of address C.

=> this is very different for step 5 SAs, and even more if all traffic
through the MN-HA tunnel is protected.

   The home agent and the
   mobile node will also remove their Phase 1 connection created on
   top of the care-of address B.
   
=> this is not necessary.

   Step 9. Optionally, the mobile node establishes a new IKE Phase 1
   on top of the care-of address C.
   
=> this is a good idea because step 5 SAs can need rekeying independently
of movements.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Jan 2003 11:37:28 +0100

>   IPsec security associations does not require IKE.
   
   James pointed out the performance impacts of this step.

=> but don't forget the "in parallel" (and my comment explaining that
a phase 1 is not necessary with good implementations).

   While this step is only needed if you (a) use IKE and (b) want to receive
   the notifications,

=> unfortunately rekeying is included in your "notifications" so
this step remains useful.

   it is indeed pretty bad on the performance.
   I added the second condition in order to not force this on all
   MNs.

   

=> the problem is for exchanges at the initiative of the HA
(for the other case, the MN can "refresh" the IKE SA on demand).

=> not require... but such an API will make things easy.

=> IKEv2 is explicitely not so bound so any IKEv2 implementation should
be good for this point.

   - Something else, what?
   
=> today we should rely on good implementations and rekeying but
a re-address exchange or better a direct API between IKE and MIPv6
will be more easy/efficient.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Jan 2003 14:17:45 +0200

> => not require... but such an API will make things easy.

We have already concluded that we will have to accept a reneg
request at any time, potentially with INITIAL_CONTACT notif
which would delete all previous connections.

We have also concluded that new IKE implementations will be
able to move to different addresses due to NAT traversal.

I think most people dislike the idea of rerunning IKE
on movements, except in special cases perhaps.

I agree that not all implementations have an IKE API available
at the moment.

What alternatives do we have then?

1) Use the reneg approach only. This is very undesireable.
2) Allow an optional API approach, fallback to reneg.
3) Require an API approach always.
4) Allow NAT-traversal style non-signaled endpoint changes.
5) Require NAT-traversal style end-point changes.

Between the API vs. NAT-traversal style, I'd prefer the former,
since we have the information available.

Francis, what is your preferred approach from above?

I'd be willing to go for approach #2, but I'm not sure how
interoperability is achieved. How does my MN know that your
HA supports or does not support the API? Or will I change my
endpoint through the API, and if you dont' support this you
will send me a reneg?

Jari

---

From: "Jayant Shukla" <[email-masked]>
Date: Mon, 6 Jan 2003 09:21:10 -0800

There is one more alternative. Decouple NAT traversal from IKE! 
Then you don't have to worry about reneg or modifying SAs.

It does not seem optimal that IKE helps in NAT traversal and them mobile
IP has to account for problems created due to NAT traversal relying on
IKE.

Additional advantage of this approach would be that mobile IP and IP
networks can have exactly the same mechanism for NAT traversal. 

Regards,
Jayant
www.trlokom.com 

Free VPN & Firewall: http://www.tucows.com/preview/295100.html 
http://www.tucows.com/cream.html 

> -----Original Message-----
> From: [email-masked] [mailto:owner-mobile-
> [email-masked]] On Behalf Of Jari Arkko
> Sent: Monday, January 06, 2003 4:18 AM
> To: Francis Dupont
> Cc: Cheryl Madson; Vijay Devarapalli; James Kempf; 'mobile-
> [email-masked]'
> Subject: Re: [mobile-ip] Mipv6 issue #194: More details on how
movements
> are handling wrt IKE

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Jan 2003 19:11:30 +0100

=> 2. (1 is not acceptable on the long term, 3 is not acceptable
on the short term, 4-5 are too unsafe).

   I'd be willing to go for approach #2, but I'm not sure how
   interoperability is achieved.

=> IKE has a mechanism for "vendor" extensions. Send the question to
the IPsec WG?

   How does my MN know that your HA supports or does not support the API?

=> the IKE style solution is to reverse the API, i.e., to make the BU/BA
stuff a new IKE exchange. When it fails the MN knows it is not supported.

   Or will I change my endpoint through the API, and if you dont'
   support this you will send me a reneg?
   
=> this is harder to detect (the traffic to the previous care-of is lost).

Thanks

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Jan 2003 10:41:23 -0800

Jari,

> endpoint through the API, and if you dont' support this you

How about that renegotiation happens as a fallback if the attempt to ue the old
SA fails?

            jak

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Jan 2003 23:06:35 +0200

James Kempf wrote:

> How about that renegotiation happens as a fallback if the attempt to use the old
> SA fails?

Do you mean failure = it realizes that it doesn't have an API to IKE, or
failure = next time it sends something over the SA it doesn't get a
reply?

The first approach might be OK, though we have to be careful in
using INITIAL_CONTACT notification to get rid of the old SAs.

But I'm not so sure about the second approach. One reason why we
have the IKE SAs around is that we might be getting a delete
notification from the other side. However, I don't know if you
will be sending such notification to me. Also, these notifications
have no ACK in IKEv1 so even you don't know if they got through.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Jan 2003 13:58:51 -0800

> have no ACK in IKEv1 so even you don't know if they got through.

Actually, I had thought something like the second approach, but if there is no
ACK then it can't be done.

I'm not quite sure what you mean by "it realizes that it doesn't have an API".
Is "it" the MN or HA?

In any case, it sounds like there needs to be some initial negotiation if the
API isn't there. Unless we could specify as part of the MIP IPsec usage spec
that it must be.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Jan 2003 00:22:56 +0200

> on the short term, 4-5 are too unsafe).

I agree, except I'd also be willing to accept 3.

> => IKE has a mechanism for "vendor" extensions. Send the question to

Ok, so let's define "interoperability" first in this context so that
everyone is on the same page with the requirement. With "interoperability",
I mean that an MN that supports the API can successfully communicate with
a HA that only supports re-negotiation. Or MN with only reneg can communicate
with a HA that supports API. And "can communicate" means that they will
eventually use the same SAs. Preferrably, the switch is done in a manner
which prevents losing any packets.

So how can we achieve this?

   2a) Assume API exists, and move the endpoints. If a reneg request
       comes in after this, accept it and delete the old SAs. No
       communication is needed about the capabilities over the wire.
       There's a window where the two sides don't agree about the
       current SA endpoints, but they will eventually converge.
       Notifications sent during the window may be lost.

   2b) Negotiate the API capability up-front, e.g. as a part of the
       first Phase 1 exchange. Or send it as a part of the BU.
       If the capability exists, proceeds as in approach 3. If it
       does not, renegotiate on every movement.

    3) Require API support. No communication is needed over the wire.
       The switch can be done in e.g. on receiving the BU on the HA
       side and the BA on the MN side. There's a window where the
       two sides don't agree about the current SA endpoints, but
       they will eventually converge. Notifications
       sent during the window may be lost.

    5) Require NAT Traversal style endpoint changes. No communication
       is needed over the wire, and the switch is performed every time
       traffic on the SA is received from a new address. There is no
       window for disagreement, and notifications will not be lost.

Hmm... interesting results. It seems the require-api-support and
optional-api-support approaches are the same in terms of the potentially
lost notifications. Only the NAT traversal style would give us protection
against that.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Tue, 07 Jan 2003 10:26:40 +0100

In your previous mail you wrote:

   James Kempf wrote:
   
   > How about that renegotiation happens as a fallback if the attempt
   > to use the old SA fails?

   
=> this is not the real purpose of INITIAL_CONTACT. IMHO there are
better ways to get the same result... We should switch to the IPsec
mailing list too.

   But I'm not so sure about the second approach. One reason why we
   have the IKE SAs around is that we might be getting a delete
   notification from the other side.

=> not only deletes. Don't forget rekeying. And this avoids to
rerun a phase 1, i.e., is more efficient.

   However, I don't know if you
   will be sending such notification to me. Also, these notifications
   have no ACK in IKEv1 so even you don't know if they got through.
   
=> this and the keepalive issue are supposed to be fixed in IKEv2.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 07 Jan 2003 10:51:36 +0100

> => ... 3 is not acceptable on the short term

=> what I meant is #3 defers the deployment of MIPv6 until the
API is widely implemented...

   
   
=> first, is reneg == rekeying?

=> this window is between the BU and the BA, and we have this window
in any case!

=> or the notification is acked so it will be resent, or it is not
and can be lost independently.

          first Phase 1 exchange.

=> IMHO this is the best solution.

          Or send it as a part of the BU.
          If the capability exists, proceeds as in approach 3. If it
          does not, renegotiate on every movement.

   
=> I still stronly object to #5 because of its security problems.

   lost notifications.

=> yes, we have the sending BU-receiving BA window.

   Only the NAT traversal style would give us protection against that.
   
=> if we follow this path, we'll switch from the actual explicit BU/BA
to an implicit scheme. Faster but unsafe... Don't forget the external
header is not protected at all in ESP tunnels. IMHO bad things can
happen even without an attacker as the care-of will be only the source
address of the last received packet.

Thanks

PS: I vote for 2b