Subject: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Jul 2006 15:04:54 -0700

I was at Wimax Forum last week and I think I now understand why they and 
3GPP2 want to use RFC 4285 auth option rather than IPsec. One issue - lack 
of EAP support for client auth - is solved by IKEv2 and they seem to now be 
moving in the direction of recommending IKEv2 if people want to deploy 
IPsec. But the other issue is a bit more complex. 802.16, like most cellular 
protocols, has extensive support for dormant mode, and Wimax Forum is 
supporting dormant mode in their network design. If IPsec is used, then 
there is a risk when a mobile node goes into dormant mode that the IPsec SA 
may time out. It is unfortunate that this was not brought up when the 
discussion about RFC 4285 was happening, but I think this might be something 
that the WG could work on now as part of the new charter. This would make 
IKEv2/IPsec more attractive as a security option for cellular operators.

Comments?

            jak

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Jul 2006 15:43:42 -0700

the dormant mode extensions sounds good to me. we could do
this extension. one issue to consider - what triggers this
message? how does Mobile IP know the mobile node is going
into a dormant mode. if we have the trigger we should be
okay.

but we have to check if this was the issue. with IKEv1 you
could negotiate a lifetime for the IPsec SA. IKEv2 does not
have the IPsec SA lifetime feature. so keepalives are
needed.

James Kempf wrote:
> 3GPP2 want to use RFC 4285 auth option rather than IPsec. One issue - 
> lack of EAP support for client auth - is solved by IKEv2 and they seem 
> to now be moving in the direction of recommending IKEv2 if people want 
> to deploy IPsec. 

yes this was one of the main issues.

the way I saw it folks in 3GPP2 liked RFC 4285 because it
is very similar to the MIPv4 mechanism and they were
comfortable with it.

Vijay

But the other issue is a bit more complex. 802.16, like
> most cellular protocols, has extensive support for dormant mode, and 
> Wimax Forum is supporting dormant mode in their network design. If IPsec 
> is used, then there is a risk when a mobile node goes into dormant mode 
> that the IPsec SA may time out. It is unfortunate that this was not 
> brought up when the discussion about RFC 4285 was happening, but I think 
> this might be something that the WG could work on now as part of the new 
> charter. This would make IKEv2/IPsec more attractive as a security 
> option for cellular operators.
> 
> Comments?
> 
>            jak
> 
> 
>

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Jul 2006 13:03:48 +0200

Hi,

I didn't follow the works about "Dormant Mode Host" DT in the Seamoby
WG but was there not such a issue debated in this DT?

Best regards.

JMC.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 18 Jul 2006 07:36:30 -0700 (PDT)

Hi Jean-Michel,
  Seamoby WG had the dormant mode "things" in its charter, but after producing an architecture document (now RFC 3154) it got dropped from the charter.

Regards,

--behcet

----- Original Message ----
From: Jean-Michel Combes <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: [email-masked]; James Kempf <[email-masked]>
Sent: Tuesday, July 18, 2006 6:03:48 AM
Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

Hi,

Best regards.

JMC.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jul 2006 09:17:11 -0700

For security, the message would need to be sent within an SA. There is a 
question about which.

One possibility is to do a Mobility Extension (call the messages Sleeping 
and WakingUp) and send it within the IPsec SA between the HA and MN. The MN 
sends the Sleeping message when it is about to go into dormant mode, it 
sends the WakingUp message when it comes out again. The WakingUp message 
isn't needed for the MN to get mobility service, it is just there for 
optimizing the SA timeouts. This would require a special API on the HA 
between the MIP code and IKE code for the HA to extend the IPsec SA 
lifetime, similar to the one for IKEv1 mobility. The solution would only be 
applicable to Mobile IP.

The other possibility is to do an IKEv2 INFORMATIONAL message that is sent 
within the IKE SA. It works similarly, but there would be no need for any 
API on the HA, since the IKE code itself would process it (actually, I 
proposed something like this to the Mobike WG but they didn't see the need 
for it). This would be applicable to both Mobike and Mobile IP (and any 
other security protocol that uses IKEv2, so maybe HIP as well).

One question is, does the HA need to do anything else if the MN goes into 
dormant mode? I think there are lots of things it could do (lengthen the BU 
timeout, apply a filter that is either mobile specified or part of the 
user's service profile with the operator to only allow specific traffic 
through, etc.) but I would really like to keep things simple.

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 17, 2006 3:43 PM
Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

>> lack of EAP support for client auth - is solved by IKEv2 and they seem to 
>> now be moving in the direction of recommending IKEv2 if people want to 
>> deploy IPsec.
>
>> charter. This would make IKEv2/IPsec more attractive as a security option 
>> for cellular operators.
>>
>> Comments?
>>
>>            jak
>>
>>
>>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jul 2006 09:48:27 -0700

Seamboy looked at "IP paging". This was a much more ambitious and far 
reaching proposal, involving a IP level location management system separate 
from Mobile IP specifically for dormant mode hosts. What I'm proposing is 
much, much simpler, just a MIP or IKE message to tell the HA when the MN 
goes into or comes out of dormant mode.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Jul 2006 12:06:01 -0700

> For security, the message would need to be sent within an SA. There is a 

if it is going to be an extension to Mobile IPv6 messages, it
can only be sent within the IPsec SA that was created for
protecting the Mobile IPv6 messages. the MN somehow would need
to indicate to the HA that it wants the IKE SA also be kept
around while it goes dormant

> One possibility is to do a Mobility Extension (call the messages 
> Sleeping and WakingUp) and send it within the IPsec SA between the HA 
> and MN. The MN sends the Sleeping message when it is about to go into 
> dormant mode, it sends the WakingUp message when it comes out again. The 
> WakingUp message isn't needed for the MN to get mobility service, it is 
> just there for optimizing the SA timeouts. This would require a special 
> API on the HA between the MIP code and IKE code for the HA to extend the 
> IPsec SA lifetime, similar to the one for IKEv1 mobility. The solution 
> would only be applicable to Mobile IP.

you probably don't need a "Wakingup" message. just send some
data.

> The other possibility is to do an IKEv2 INFORMATIONAL message that is 
> sent within the IKE SA. It works similarly, but there would be no need 
> for any API on the HA, since the IKE code itself would process it 
> (actually, I proposed something like this to the Mobike WG but they 
> didn't see the need for it). This would be applicable to both Mobike and 
> Mobile IP (and any other security protocol that uses IKEv2, so maybe HIP 
> as well).

I think extending IKE would be better than doing this as a
Mobile IP extension. it is a generic problem of trying to keep
the IPsec SA (negotiated using IKEv2) alive when the MN wants
to go into a dormant mode. one problem is that there is no WG
to do this extension. it would have to be an individual
submission.

> One question is, does the HA need to do anything else if the MN goes 
> into dormant mode? I think there are lots of things it could do 
> (lengthen the BU timeout, apply a filter that is either mobile specified 
> or part of the user's service profile with the operator to only allow 
> specific traffic through, etc.) but I would really like to keep things 
> simple.

agree. lets just do a simple extension. :)

Vijay

> 
>            jak
> 
> ----- Original Message ----- From: "Vijay Devarapalli" 
> <[email-masked]>
>>> I was at Wimax Forum last week and I think I now understand why they 
>>> and 3GPP2 want to use RFC 4285 auth option rather than IPsec. One 
>>> issue - lack of EAP support for client auth - is solved by IKEv2 and 
>>> they seem to now be moving in the direction of recommending IKEv2 if 
>>> people want to deploy IPsec.
>>
>>
>>> Wimax Forum is supporting dormant mode in their network design. If 
>>> IPsec is used, then there is a risk when a mobile node goes into 
>>> dormant mode that the IPsec SA may time out. It is unfortunate that 
>>> this was not brought up when the discussion about RFC 4285 was 
>>> happening, but I think this might be something that the WG could work 
>>> on now as part of the new charter. This would make IKEv2/IPsec more 
>>> attractive as a security option for cellular operators.
>>>
>>> Comments?
>>>
>>>            jak
>>>
>>>
>>>