Subject: [mobile-ip] key exchange between MN and MAP in HMIPv6

From: Fumio Teraoka <[email-masked]>
Date: Fri, 31 Jan 2003 02:11:08 +0900

Hi,

I have a question about key exchange between MN and MAP in HMIPv6
(draft-ietf-mobileip-hmipv6-07.txt).

In Section 12.1, there is the following paragraph:

   The MAP needs to set the SA for the RCoA (not the LCoA). This can be 
   performed with IKE [6]. The mobile node  uses its LCoA as source 
   address but specifies that the RCoA should be used in the SA. This is 
   achieved by using the RCoA as the client identity in IKE Phase 2 
   negotiation (Quick mode).  

In my understanding, ISAKMP-SA must be established in IKE Phase 1
before IKE Phase 2 is executed. The draft does not mention ISAKMP-SA establishment. How is ISAKMP-SA established between MN and MAP in HMIPv6?

Best regards,

Fumio Teraoka, Ph.D
Keio University

---

From: Francis Dupont <[email-masked]>
Date: Fri, 31 Jan 2003 09:49:15 +0100

In my understanding, ISAKMP-SA must be established in IKE Phase 1
   before IKE Phase 2 is executed. The draft does not mention
   ISAKMP-SA establishment. How is ISAKMP-SA established between MN and
   MAP in HMIPv6?
   
=> you should double check with HMIPv6 gurus but it seems very similar
to the standard MIPv6 stuff: the ISAKMP-SA is built in the IKE phase 1
with the MN using its LCoA as its peer source address (it can use the
RCoA at this time, in MIPv6 the MN can't use its HoA). But the IPsec SAs
use the other address, the RCoA (the HoA for MIPv6), so the traffic
selector (aka the phase 2 identity IDci) specifies the RCoA.
At this point, there are two cases:
 - either your IKE implementation(s) supports the "proxy mode" and
   you have a proper authorization: you build an IPsec SA pair
   in transport mode with the RCoA
 - or you can not do that and you build an IPsec SA pair in tunnel
   mode with the LCoA as the outer address and the RCoA as the inner
   address. This is suboptimal and you'll have to rebuild or update
   the SAs at each LCoA change.

Regards

[email-masked]

PS: the RFC 2409 terrible text about the "proxy mode":

   The identities of the SAs negotiated in Quick Mode are implicitly
   assumed to be the IP addresses of the ISAKMP peers, without any
   implied constraints on the protocol or port numbers allowed, unless
   client identifiers are specified in Quick Mode.  If ISAKMP is acting
   as a client negotiator on behalf of another party, the identities of
   the parties MUST be passed as IDci and then IDcr.  Local policy will
   dictate whether the proposals are acceptable for the identities
   specified.  If the client identities are not acceptable to the Quick
   Mode responder (due to policy or other reasons), a Notify payload
   with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.