Subject: [Mip6] MOBIKE and MIP

From: "James Kempf" <[email-masked]>
Date: Mon, 3 Apr 2006 09:43:57 -0700

There is some discussion going on in the MIP4 group about running MOBIKE and 
MIP together. The following drafts have been written on the topic:

- draft-ietf-mip4-vpn-problem-solution-02 (this one is pre-MOBIKE)
- draft-ietf-mip4-mobike-connectivity-00
- draft-meghana-mip4-mobike-optimizations-00

I haven't read the drafts, but I'm told that their recommendation is not to 
avoid using MIP and MOBIKE together, which seemed to be the conclusion of 
the discussion during the WG meeting at IETF 65. I don't know whether that 
conclusion would apply to MIP6, since IKE/IPsec is more tightly integrated 
with MIP6 and MOBIKE might have a larger effect on interoperation.

            jak

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 3 Apr 2006 14:00:22 -0700

James, Vijay,
There are two cases with respect to MOBIKE and MIP6: 

1. MOBIKE and MIP6 have different endpoints - i.e., MOBIKE between MN
and VPN GW, MIP6 between MN and HA

This is a valid model and has applicability in some markets (where data
needs to be protected using IPsec in a VPN-over-MIP model). This would
be a reason to write a draft similar to the MIP4-MOBIKE one. 

2. MOBIKE and MIP6 endpoints are the same - i.e., both run between the
MN and HA

This is the model that may not make sense, depending on the
applicability. From an architectural purity point of view, I could be
convinced that this should replace the 'K' bit concept - since, MIP6
should not really be doing key management for IKE/IKEv2 in any shape or
form. However, since the 'K' bit exists *and* the IKEv2 SA that it is
updating is *solely* for the purpose of MIP6, I'm inclined to leave it
in (gets the job done without additional signaling). However, when the
IKEv2 SA does more than just MIP6 (i.e., the MIP6 IPsec SA is only one
of the child SAs derived from it and the IKEv2 SA has broader scope,
allowing other child SAs to be derived), I would like to see MOBIKE
doing the address update to IKEv2 rather than MIP6. This is why I was
saying in some earlier responses on this topic that we should not
consciously disallow the co-existence of MIP6 and MOBIKE. 

Regards,
Vidya

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, April 03, 2006 11:26 AM
> To: James Kempf; [email-masked]
> Subject: RE: [Mip6] MOBIKE and MIP
> 
> hi Jim,
> 
> draft-ietf-mip4-vpn-problem-solution-02 assumes legacy VPNs. 
> this would mean, the VPN GW cannot be touched while running 
> Mobile IPv4. the solution requires a external HA and an 
> internal HA so that the VPN gateways can be traversed without 
> touching them and at the same time provide mobility while 
> crossing trust boundaries.
> 
> draft-ietf-mip4-mobike-connectivity-00 addresses the same problem as
> draft-ietf-mip4-vpn-problem-solution-02 but assumes that the 
> VPN GW on the path is actually a VPN GW that uses IKEv2 and 
> supports MOBIKE. 
> not a legacy VPN GW. then it is possible to setup a Mobile 
> IPv4 tunnel inside the MOBIKE tunnel.
> 
> both the above drafts assume the VPN GW and the home agent 
> are two separate boxes.
> 
> draft-meghana-mip4-mobike-optimizations-00 takes the concept 
> further and reduces the overhead by having FA functionality 
> or HA functionality on the VPN GW in addition to IKEv2 and 
> MOBIKE functionality.
> 
> MIPv4 and MIPv6 are very different protocols.
> with MIPv6 you set up an IPsec protected Mobile IP tunnel 
> between the mobile node and the HA.
> so you already have the VPN functionality. the 'K' bit also 
> allows you to update the IKE SA associated with the tunnel. 
> this is what MOBIKE tries to do too. so that's why I don't 
> expect someone to use MOBIKE and MIP6 at the same time to the 
> same box (or gateway).
> 
> there was an email on this list from Jouni Korhonen asking if 
> we can write up something for MIP6 and MOBIKE along the lines 
> of draft-ietf-mip4-mobike-connectivity-00. I had told him 
> yes. but this assumes the VPN GW and the home agent as two 
> separate boxes, with a MIP6 tunnel to the home agent inside 
> the IPsec tunnel to the VPN gateway. I have already written 
> up a draft on this, but didn't submit it because I didn't see 
> a need for it. 
> it is a very obvious solution.
> 
> Vijay
> 
> > -----Original Message-----
> > From: James Kempf [mailto:[email-masked]]
> > Sent: Monday, April 03, 2006 9:44 AM
> > To: [email-masked]
> > Subject: [Mip6] MOBIKE and MIP
> > 
> > There is some discussion going on in the MIP4 group about running 
> > MOBIKE and MIP together. The following drafts have been 
> written on the 
> > topic:
> > 
> > I haven't read the drafts, but I'm told that their 
> recommendation is 
> > not to avoid using MIP and MOBIKE together, which seemed to be the 
> > conclusion of the discussion during the WG meeting at IETF 
> 65. I don't 
> > know whether that conclusion would apply to MIP6, since 
> IKE/IPsec is 
> > more tightly integrated with MIP6 and MOBIKE might have a larger 
> > effect on interoperation.
> > 
> >             jak
> > 
> > 
> >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 3 Apr 2006 14:13:27 -0700

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Monday, April 03, 2006 2:00 PM
> To: Vijay Devarapalli; James Kempf; [email-masked]

I have the draft ready to go. there was a discussion
on this on the MIP6 mailing list about a year ago.
there wasn't much interest at that point. so it wasn't
submitted.

> 2. MOBIKE and MIP6 endpoints are the same - i.e., both run between the

this is what was discussed at the last IETF meeting.
the conclusion was that it would be redundant.

> in (gets the job done without additional signaling). 

yes.

> However, when the
> allowing other child SAs to be derived), 

its the other way around. sending a binding update
triggers the IKEv2 stack to setup a transport mode
SA for the BU. sending a HoTi message triggers the
IKEv2 stack to setup a tunnel mode SA for the HoTi
message. when MIP6 is used, MIP6 would be your
mobility management protocol.

> I would like to see MOBIKE

nobody is disallowing anything.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 3 Apr 2006 18:00:03 -0700

> its the other way around. sending a binding update triggers 
> the IKEv2 stack to setup a transport mode SA for the BU. 
> sending a HoTi message triggers the
> IKEv2 stack to setup a tunnel mode SA for the HoTi message. 
> when MIP6 is used, MIP6 would be your mobility management protocol.
> 

I'm not sure how it is the other way around :) The IKEv2 SA can lead to
an IPsec transport mode SA for the BU and an IPsec tunnel mode SA for
the HoTi message. If that is all the IKEv2 SA is doing, it makes sense
for the 'K' bit to control the address change on that. However, the
IKEv2 SA may be deriving other IPsec SAs - say, a tunnel mode IPsec SA
for data traffic protection between the MN and HA. In such cases, MOBIKE
should be in control of updating the IKEv2 SA. 

> nobody is disallowing anything.

Well, current definitions are insufficient to allow this behavior. If
MOBIKE needs to be used to update the IKEv2 SA, the 'K' bit must be
ignored in MIP6 signaling (or always set to 0) - this isn't specified
anywhere right now. 

Vidya

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 3 Apr 2006 18:05:35 -0700

> However, the
> for data traffic protection between the MN and HA. 

why would you do this? and if you want to do this,
use the MIP tunnel, which is already setup. better
use the IPsec protected MIP tunnel. why would there
be a separate IPsec tunnel?

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 3 Apr 2006 18:56:37 -0700

> why would you do this? and if you want to do this, use the 
> MIP tunnel, which is already setup. better use the IPsec 
> protected MIP tunnel. why would there be a separate IPsec tunnel?
> 

That was an example. Key separation is one reason I can think of as a
motivation to do a separate IPsec SA for data protection. I'm not saying
all implementations will/need to do this. The goal of the IPsec SA
derived for MIP6 is really to protect MIP6 signaling and its lifetime,
etc. may be governed by that use. It is a matter of policy whether that
does or does not fit the requirements for data protection. 

Also, other examples exist. If the MIP6 HA is also, say a SIP server and
you want to use IPsec to protect the SIP signaling between the SIP
client and server, that can be another child SA from IKEv2. Of course,
this holds true for any other applications running over IP. All I'm
saying is that IKEv2 potentially has broader applicability and the MIP6
IPsec SA may only be *one* of the child SAs that is being derived. 

Also note that the same IPsec SA could be protecting a bunch of
applications (MIP6, SIP, whatever signaling)- in this case, the IKEv2 SA
may only lead to one IPsec SA. Even so, the fact that the IKEv2 and
IPsec SAs have an applicability that is broader than MIP6 in this case
says that MIP6 should not be updating those SAs. It would be an
architectural limitation that could hurt us later, even if we can't come
up with a good reason now. 

Vidya

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 4 Apr 2006 00:48:35 -0700

> That was an example. 

I would love to see a realistic scenario. I 
haven't seen one so far. if there is an issue,
don't worry, I would be the first one to jump
on it and start working on a solution.

> Also, other examples exist. If the MIP6 HA is also, say a SIP 

a P-CSCF? or a media gateway?

> client and server, that can be another child SA from IKEv2. 

now why would there be a tunnel mode IPsec SA
for SIP signaling between the MN and the HA?

> Of course,
> this holds true for any other applications running over IP. 

again, please come up with a realistic scenario.
this is my last email on this thread until 
someone comes with an issue that needs to be 
fixed.

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 4 Apr 2006 10:16:13 -0700

> a P-CSCF? or a media gateway?

=> I don't think the nature of the application is an important
factor here. On a conceptual level, it's limiting to assume that
the node handling mobility management (e.g. HA) is the same 
one that will handle the IPsec termination point. 
One possible scenario is a case where my HA and my VPN GW are 
administered by 2 different entities. For instance, I might have 
an IPsec tunnel to a corporate network, while being offered mobility
by a telco. In this case there is a clear separation between
the two SAs. Whether this requires MOBIKE or not is a different 
story. My HoA might be the address used to setup the IPsec SA 
with the corporate GW and that never changes. Alternatively, I might
use my RCoA to setup the SA with the corporate GW, when my RCoA
changes (rare event) I could then use MOBIKE or re-establish the 
SA. 

Personally, I do think the K bit works for the collocated case 
(IPsec and HA in the same node). At the same time, there are realistic
scenarios where the two termination points are separated, but even then
I believe the current specs work today as long as the traffic passes 
through the HA first, which should always be the case. 

Hesham

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 4 Apr 2006 10:25:38 -0700

> changes (rare event) I could then use MOBIKE or re-establish the 

when the MIP6 HA and the VPN GW are separated
with the IPsec tunnel terminating on the VPN
GW and the MIP tunnel terminating on the HA,
then we have a scenario/use case. something
along the lines of 
draft-ietf-mip4-mobike-connectivity-00.txt
should work for this scenario. we are in 
agreement here.

> scenarios where the two termination points are separated....

agreed.

Vidya and Jim are trying to show us a scenario
where the IPsec tunnel and MIP tunnel terminate 
on the same box and MOBIKE is used along with 
MIPv6 signaling messages. 

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 4 Apr 2006 10:56:23 -0700

This approach is taking the view that in the presence of MIP6, it
supercedes everything else and has control over key management for
applications beyond MIP6. I don't think this is the right view at all.
It is quite practical to envision other applications having the same
endpoints (MN and HA) wanting to use the IKEv2 SA for protecting other
signaling. Avoiding that just makes us short-sighted. 

Vidya

> Sent: Tuesday, April 04, 2006 10:44 AM
> To: Soliman, Hesham; Vijay Devarapalli; Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [Mip6] MOBIKE and MIP
> 
> Then maybe that's what the document needs to say.
> 
>             jak
> 
> ----- Original Message -----
> From: "Soliman, Hesham" <[email-masked]>
> To: "Vijay Devarapalli" <[email-masked]>; 
> "Narayanan, Vidya" <[email-masked]>; "James Kempf" 
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, April 04, 2006 10:30 AM
>  > Vidya and Jim are trying to show us a scenario  > where 
> the IPsec tunnel and MIP tunnel terminate  > on the same box 
> and MOBIKE is used along with  > MIPv6 signaling messages.
> 
> => I think this is a scenario that should be avoided.
> 
> Hesham
> 
> 
>  >
>  > Vijay
>  >
> 
> 
>

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 4 Apr 2006 11:51:14 -0700

> This approach is taking the view that in the presence of 
 > MIP6, it supercedes everything else and has control over key 
 > management for applications beyond MIP6. 

=> Could you translate that into a more detailed scenario?
I don't see how this conclusion can be made based on this discussion.
Controlling key management was never the issue here.

   I don't think this 
 > is the right view at all. It is quite practical to envision 
 > other applications having the same endpoints (MN and HA) 
 > wanting to use the IKEv2 SA for protecting other signaling. 

=> I still don't see how that leads to using MOBIKE. No one 
excluded this scenario, but it does *not* imply using MOBIKE. 

Hesham

 > Avoiding that just makes us short-sighted. 
 > 
 > Vidya
 >