Subject: [mobile-ip] Update IKE endpoint to home address, not care-of address

From: Koh <[email-masked]>
Date: Sun, 18 May 2003 21:17:59 +0900

Hello,

According to MIPv6 draft21, a MN-HA's IKE endpoint MUST be updated
from previous care-of address to new care-of address, 
when the MN moves.

My question is why the MN and the HA update IKE endpoint
to new care-of address instead of MN's home address.

I like the idea of updating IKE endpoint to the home address
because I believe the idea is in consistency with other IKE situations.
In this case, ISAKMP packets will be sent with HAO/RH2.

  o The reason why the MN has to use care-of address in IKE is
    "Packets addressed to the home address of the mobile node cannot
     be used before the Binding Update has been processed.(11.3.2)",
    so once the Binding Update has been processed, we don't need to
    "use its care-of address as the Source Address of all packets
     it sends as part of the key management protocol.(11.3.2)"

  o If a MN has negotiated IKE at home network before movement,
    the IKE endpoint must be the home address,
    and this endpoint can be kept in the movement.

  o When negotiating with a CN, the MN uses the home address as IKE
    endpoint even if there is a RO.

  o Now that we have the API related to K bit, we can choose
    the endpoint.
    And if the MN or HA doesn't have K=1 ability, the MN may rerun
    IKE upon movement. But once it reruns with the home address,
    the MN doesn't need to rerun IKE at the next movement.

In the draft21 11.3.2, 
>   For the default case of using IKE [9] as the
>   automated key management protocol, such problems can be avoided by
>   the following requirements when communicating with its home agent:
>
>   o  When the mobile node is away from home, it MUST use its care-of
>      address as the Source Address of all packets it sends as part of
>      the key management protocol (without use of Mobile IPv6 for these
>      packets, as suggested in Section 11.3.1).

I think the "MUST" clause should be limited to the no BC situation,
and let MNs use its home address as the Source Address of IKE
when the MN is communicating with its home agent.

Has there been any analysis of this question ?

Best regards,

Koh

---

From: Francis Dupont <[email-masked]>
Date: Sun, 18 May 2003 17:53:13 +0200

=> I already answered in private... Here are some points:

   let MNs use its home address as the Source Address of IKE
   when the MN is communicating with its home agent.
   
=> there are two different reasons for using the Co@:
 - the H@ is not available before the first home registration BU
   (this is a chicken & egg issue for the MN-HA IKE)
 - the MN-HA tunnel is setup with the addresses IKE runs over as the
   outer addresses. If we'd like only one overhead for mobility
   and IPsec then we have to use the Co@.

and

=> there are in fact three things to update:
 - the tunnel endpoints in the SPD (note they are not the selectors)
 - the tunnel endpoints in the SADB (same remark)
 - the IKE endpoints, but only if there is still a running phase 1.
As a running phase 1 is not needed with IKEv1, if we refine the meaning
of the K bit we have better options...

Regards

[email-masked]

---

From: Koh <[email-masked]>
Date: Tue, 20 May 2003 00:22:28 +0900

Thanks for your fast reply.

>    and IPsec then we have to use the Co@.

Hmm...
My understanding of the draft was :

  - the tunnel endpoints in the SPD/SADB are not controled by IKE
    but controled by the MIPv6 stack directly

  - BA's K=1 means "the HA have changed its IKE endpoint",
    not "the HA have changed both IKE endpoint and tunnel endpoint".
    (The draft mentioned the third one only, the IKE endpoint.)

  - The tunnel endpoints in the SPD/SADB should be updated even if K=0.

In our implement IPsec tunnel endpoints will be evaluated
packet by packet refering to BCs, not refering to SPD's tunnel endpoint.
(it can reduce the overhead of mobile-ip tunnel)
Therefore we were able to focus only on the first reason you mentioned.

If this issue depends on the implement,
I'd like the draft to let MNs use its home address as the Source
Address of IKE when the MN is communicating with its home agent.

If our implement are wrong, does the draft need to be clarified
the reasons for using the CoA ?

Best regards,

Koh

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 May 2003 18:43:00 +0200

Hmm...

=> if you can implement this (as it was done in last KAME snapshots *)
then you don't really need to update IKE endpoints...

   
=> so I am not very satisfied by the definition of the K bit because
one can assume some unspecified interactions between mobile and IPsec codes.

=> this is a non standard way to implement IPsec: when IKE has no monopoly
on the management of SPD/SADB, it is supposed to setup correct SAs...

=> I disagree: the interaction between mobility and IPsec codes in
the draft are reduced to movement, i.e., IKE should be able to setup
the proper SA pairs when the MN starts in visit.

=> the first one (bootstrap problem) was (is?) in the mobile IPv6 draft.

Regards

PS: (*) actual KAME snapshots don't work because IKE (racoon) is not
informed of the SPD update (the fix is easy and needs 10~20 lines of
code).
PPS: IMHO to update the SPD/SADB by the mobility code is a good solution
but I don't know whether it is applicable in all implementations...
IKE is another problem because IKEv1 and IKEv2 have very different
requirements, and of course in the real world we are between. We have
the choice between support IKEv1 as it is specified or to wait for IKEv2
and a peer address update mechanism. Today it seems the first solution
(deal with IKEv1) is simpler because we can assume very short IKE session
livetimes.

---

From: Koh <[email-masked]>
Date: Tue, 20 May 2003 23:25:07 +0900

Hi,

> one can assume some unspecified interactions between mobile and IPsec codes.

Neither am I, if our implement didn't comply with the draft.

> => the first one (bootstrap problem) was (is?) in the mobile IPv6 draft.

Don't we need the second one ?

Anyway,
Thanks for clarification.

Now another question floated through my idea.

When a MN, which doesn't have K=1 ability and has a binding
with a HA, moves to another network,
the fastest handover method for the MN is not to send BU,
but to re-negotiate IKE on the new care-of address. 
And even if the binding remains the old care-of address,
user-packets will flow back and forth in new IPsec tunnel.
(I don't know if the reverse-tunnel check in 10.4.5 works well
in the IPsec tunnel.)
And the MN can move with IKE as long as the binding exists.

Isn't it little bit weird behavior ?

> informed of the SPD update (the fix is easy and needs 10~20 lines of

I'll try it, thanks.

> the choice between support IKEv1 as it is specified or to wait for IKEv2

I haven't read IKEv2 yet. Maybe I should...

> (deal with IKEv1) is simpler because we can assume very short IKE session

Maybe I'm dense, but why can we assume very short IKE session
lifetimes ? (If the reason depends heavily on IKEv2, forget it.)

Best regards,

Koh

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 May 2003 17:20:33 +0200

> => the first one (bootstrap problem) was (is?) in the mobile IPv6 draft.
   
=> BTW it is.

=> the second reason (built an IPsec tunnel with the Co@) is from
an optimization, i.e., the IPsec tunnel works with a double overhead
if IPsec uses the H@ as the MN external address. I.e., this is a SHOULD
when the first reason is from a MUST.

=> this is not really true because:
 - the IPsec tunnel may protect only packets with a mobility header,
   i.e., to protect all the packets between the MN and the HA is
   only an option.
 - the HA is a CN too, for instance genuine packets sent by the HA
   to the MN using the HA address (the == not a) are not put in the
   tunnel but are handled by the mobility code, i.e., a RH2 is added.
   Note this is the only visible difference between a mobile IPsec VPN
   where the HA is the SG and mobile IPv6 without routing optimization
   and with the protect everything between MN and HA option.

=> the 10.4.5 check is for packets not protected by IPsec (not protected ==
can't be authenticated). The wording is a bit poor because the MUST for
the check is not clearly bound to the MAY for the action when the check
fails.

=> in fact IMHO the binding is even not needed...

=> no and if we add a peer address update mechanism to IKE(v2) then
a mobile IPsec VPN is at least equivalent to a mobile IPv6 mode.
IMHO this is a good news because mobile IPsec VPNs are already
available in the real world.

   I'll try it, thanks.
   
=> I can put the fix in the racoon mailing-list if you read it.

=> you should read both the last IKEv2 draft and its tutorial (companion
Internet draft).

   
=> because in its version 1, IKE is used only to setup IPsec SA pairs
after you can close the session. In its version 2, this is no more true
because IKE is used to manage IPsec SAs: when the session (aka the phase 1
aka the IKE SA) is closed, all the IPsec SAs it has setup are closed.

Thanks

PS: if the discussion becomes too IPsec specific, we should move to the
IPsec WG list.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 May 2003 01:26:11 +0300

> Neither am I, if our implement didn't comply with the draft.

Hmm... actually I think what you had in terms of everything else than
the address for IKE was ok. According to ha-ipsec Section 4.3 home
agents are required to update the outer destination of the packets
that eventually go out on the wire to the current care-of address.
This is independent of the K bit.

The K bit on the other hand is optional. If you can't do it, fine.
If you can, it should cause the IKE endpoints to change too. That
is, the movement causes the SADB/SPD to change, and if the K bit
is on, it also causes the IKE endpoint change. But K bit is not
needed for the SADB/SPD change. In conclusion I think we haven't
left this unspecified.

As far as the IKE address being the home address, I can see that
in some cases that might work. However, I'd rather keep a very
strict rule in the current specification -- if there's interest
later perhaps this can be pursued separately. (But I would actually
group a number of things under the same work item and take a look
at IKEv2 enhancements for address update at the same time etc.)

Finally, Francis you wrote:

 > the 10.4.5 check is for packets not protected by IPsec (not protected ==

Yes. I modified the text slightly to make this clearer:

   "o  ...

    o  Depending on the security policies used by the home
       agent, reverse tunneled packets MAY be discarded
       unless accompanied by a valid ESP header. The support
       for authenticated reverse tunneling allows the home
       agent to protect the home network and correspondent nodes
       from malicious nodes masquerading as a mobile node.

    o  Otherwise, when a home agent decapsulates a tunneled
       packet from the mobile node, the home agent MUST verify
       that the Source Address in the tunnel IP header is the
       mobile node's primary care-of address. Otherwise any
       node in the Internet could send traffic through the home
       agent and escape ingress filtering limitations. This
       simple check forces the attacker to at least know the
       current location of the real mobile node and be able
       to defeat ingress filtering."

--Jari

---

From: Koh <[email-masked]>
Date: Thu, 22 May 2003 00:00:16 +0900

> at IKEv2 enhancements for address update at the same time etc.)

I understand the standpoint of the draft
and appreciate the conclusion.

> Yes. I modified the text slightly to make this clearer:

Thanks,

Koh