Subject: [mobile-ip] rerunning IKE, RR SA endpoint changes, and IPsec NAT-T

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Jan 2003 16:07:52 +0200

We've been discussing what to do with IKE connections after
movements. The issue is similar to what we need to do for
IPsec SAs for RR protection when we move; an API was needed
there to update the gateway address after BU has been
successfully processed.

I chatted with some IKE folks today. They informed me that
there's a very similar situation for IPsec NAT Traversal
(see draft-ietf-ipsec-nat-t-ike-04.txt). This is an IKEv1
extension that is past WG last call, and will also be
incorporated natively in some form to IKEv2. In NAT traversal
they needed to solve several issues, but one of them is of
particular interest to us: it is possible that the NAT device
reboots or loses its mappings while an IPsec-IKE connection is
running through it. The result is that the port numbers and/or
IP addresses may change. In order to avoid problems due to this,
each node will always use the addresses and ports that were
used in the last authenticated packet from the peer.

This will change both the IKE endpoint and the SA gateway
addresses.

I also talked about how tied IKEv1 is to the addresses. It
turns out that the RFC itself does not require tight integration
of connections to addresses, but most implementations have
interpreted the cookie creation rules in a way that ties the
implementations to the address. So your vanilla IKE implementation
can't float its address. But this is now changing as more folks
are implementing NAT traversal; as a part of extending IKE to
do NAT traversal they also have to adopt smarter cookie creation
procedures.

Ok, so that was about IKE in general. What does this imply for
us? Obviously we are not alone in thinking about similar things.
The important thing for us is that if typical IKE implementations
are starting to have these capabilities, then we shouldn't be
shy about requiring APIs to move even IKE endpoints around. My
proposal is that upon accepting a BU, the HA must change both
the IPsec and the IKE endpoints accordingly. This will avoid any
additional cost of running IKE on every movements, and will
ensure that the MN gets the notifications about e.g. SA deletions.

Our situation is slightly different from the NAT traversal case
in that we have an explicit signal about the change of the location.
We should take advantage of this, particularly when the adopt-
latest-used-address -approach has some (minor) vulnerabilities.

Comments?

Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 3 Jan 2003 09:46:20 -0800

Jari,

I like this solution.

            jak

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "Cheryl Madson" <[email-masked]>; "Vijay Devarapalli"
<[email-masked]>; "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 03, 2003 6:07 AM
Subject: rerunning IKE, RR SA endpoint changes, and IPsec NAT-T

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 4 Jan 2003 11:26:15 -0800

Just one observation. Some implementations may choose the SPI unique across
all SAs so that it does not use the destination address to lookup the SA. In
that
case you don't need to update at all.  But if this is not true, then it
really
matters on how often the MN moves. But still updating SAs (it can be
expensive
in some architectures e.g. h/w acceleration card) might be faster than
negotiating
new ones.

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Sun, 05 Jan 2003 00:16:11 +0200

> in some architectures e.g. h/w acceleration card) might be faster than

I agree that in some architectures the updates can be costly.
In theory, SA creation and in particular key set-up is costly
and other updates might be easier. If your crypto chip requires
all of the SA parameters to be updated even if you change just
the gateway address, this may delay you a bit. Or the
chip-main CPU signaling path gives some latency for any updates.

When do we need to update? There seems to be two issues at
play here: one, does the peer recognize our packet if it
comes to a new address? And two, will the packet get to peer in
the first place? Regarding the last issue, note that we are updating
the gateway address in the IPsec SA. That is, the destination address
in the outer tunnel header. Without an update to this address,
the packets would be destined to the old care-of address. While
the first issue can be solved with a relaxation of the SA lookup
rules, the second issue is still relevant.

Of course, we have two ways to make an update: either update
the SA or negotiate a new one through IKE. Do you have a
suggestion on how we could allow both? There needs to be
some interoperability between MNs and HAs from different
vendors, which side will make the decision on what to do?
Also, it isn't clear what the tradeoffs are e.g. MN
sending more packets over wireless vs. home agent saving
some CPU.

Oh well, it seems that in any we must be able to accept
a reneg that the other side proposes. Is it enough to
require a capability to modify SAs but allow implementations
to do a reneg if they want to?

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Jan 2003 18:39:40 +0100

=> "needed" is a bit to strong here.

=> this is the "address and port agility". This is fine but
has some bad security consequences as it is specified
(cf. my transient pseudo-NAT I-D, a new version is in the I-D
editor queue, i.e., submitted last year but has to be published).

=> the SA gateway stuff is not in IKEv2 draft.

   implementations to the address.

=> this can be a problem only inside an exchange.

   So your vanilla IKE implementation can't float its address.

=> some can between exchanges, i.e., between phases 1 and 2 or
between two phases 2. And with IKEv2 this should be the rule.

   But this is now changing as more folks
   are implementing NAT traversal; as a part of extending IKE to
   do NAT traversal they also have to adopt smarter cookie creation
   procedures.
   
=> NAT traversal is in the IPsec WG charter so is a good argument
to get "address agility" but we don't need the security hole
which comes with it.

=> at the Yokohama IETF the IPsec people seemed to be in favor of
this kind of things (at least they didn't scream :-).

=> I agree, we need only a reasonably safe (address guaranteed by
the peer, return routability check, etc) form of address agility.

Regards

[email-masked]