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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 18 Jul 2006 14:20:11 -0400

James,

This is a good discussion. Indeed the need for IPsec keepalives (or DPD)
over the air when the MN is dormant (or idle) is an issue in the
cellular networks. The issue is Not that there are no mip6 messages
defined or the HA is not aware of dormancy. It is more of a paging
channel capacity issue, MN's battery life issue and the signaling
overhead to transport the keepalives for a dormant MN issue.

So, any new message however small won't solve the problem, IMHO.

-Kuntal

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, July 18, 2006 11:17 AM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode Alert to
HA?
> 
> 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?
> 
> 
> > 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:
> >> 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.
> >
> > 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
> >>
> >>
> >>
> >> _______________________________________________
> >> Mip6 mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

---

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

Kuntal,

The intent is not to introduce something that the MN would send during 
dormant mode. Indeed, as you have described, this would negatively impact 
battery life.

The intent is to provide a way for the MN to say that it is about to go into 
dormant mode, so please lengthen the IPsec SA timeout to avoid having it 
expire for some longer period of time.

            jak

----- Original Message ----- 
From: "Chowdhury, Kuntal" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 18, 2006 11:20 AM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

James,

-Kuntal

HA?
a
Sleeping
The
it
message
only
sent
any
need
any
into
the
traffic
HA?
they
-
seem
to
and
mode
the
> >> charter. This would make IKEv2/IPsec more attractive as a security

"This email message and any attachments are confidential information of 
Starent Networks, Corp. The information transmitted may not be used to 
create or change any contractual obligations of Starent Networks, Corp.  Any 
review, retransmission, dissemination or other use of, or taking of any 
action in reliance upon this e-mail and its attachments by persons or 
entities other than the intended recipient is prohibited. If you are not the 
intended recipient, please notify the sender immediately -- by replying to 
this message or by sending an email to [email-masked] -- and 
destroy all copies of this message and any attachments without reading or 
disclosing their contents. Thank you."

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jul 2006 12:36:31 -0700

I don't know. What do operators typically set the SA lifetime to? Though 
perhaps this is an unanswerable question because, as yet, has anybody 
deployed MIPv6?

My only observation is that this seems to be an issue with Wimax Forum, and 
one of the primary motivators for wanting to use the RFC 4285 Auth Option. 
If IETF and the MIP6 WG would like to encourage them to use IKE (as seemed 
to be the sentiment when RFC 4285 was discussed, and one of the reasons why 
it is not PS), it might be worthwhile to try to address their concerns.

            jak

----- Original Message ----- 
From: "Tsirtsis, George" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Chowdhury, Kuntal" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 18, 2006 12:10 PM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

May I ask, what is the typical lifetime of the SA and what would you
lengthen it to?
George

> Sent: Tuesday, July 18, 2006 2:43 PM
> To: Chowdhury, Kuntal
> Cc: [email-masked]
HA?
> The intent is to provide a way for the MN to say that it is about to
go
> create or change any contractual obligations of Starent Networks,
Corp.
> Any
> entities other than the intended recipient is prohibited. If you are
not
> this message or by sending an email to [email-masked]
--

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 18 Jul 2006 12:10:56 -0700

HA?
go
Corp.
not
--

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 18 Jul 2006 12:49:12 -0700

I guess the important thing is to understand how the typical SA lifetime
relates to the typical MIP6 Binding Lifetime. The MN will have to at
least wake up to refresh its binding.

George

> Sent: Tuesday, July 18, 2006 3:37 PM
> To: Tsirtsis, George; Chowdhury, Kuntal
> Cc: [email-masked]
HA?
> My only observation is that this seems to be an issue with Wimax
Forum,
> to be the sentiment when RFC 4285 was discussed, and one of the
reasons
> why
> > dormant mode, so please lengthen the IPsec SA timeout to avoid
having
> > Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert
to
> > > Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode
Alert
> to
> > HA?
> > >
> > > For security, the message would need to be sent within an SA.
There
> is
> > > optimizing the SA timeouts. This would require a special API on
the
> HA
> > > API on the HA, since the IKE code itself would process it
(actually,
> I
> > > Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode
Alert
> > > >> brought up when the discussion about RFC 4285 was happening,
but
> I
> > destroy all copies of this message and any attachments without
reading
> or

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jul 2006 13:08:16 -0700

Yes, that's true. The two are not coupled as in MIPv4.

Do you have any idea what the typical 3GPP2 operator practice is for MIPv4?

            jak

----- Original Message ----- 
From: "Tsirtsis, George" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Chowdhury, Kuntal" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 18, 2006 12:49 PM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

George

HA?
Forum,
reasons
having
to
Alert
There
the
(actually,
Alert
but
reading

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Jul 2006 14:36:35 -0700

> May I ask, what is the typical lifetime of the SA and what would you

with IKEv2 there is no ability to negotiate a lifetime for
the IPsec SA. it is purely local policy. the initiator and
the responder decide independently on how to set the SA
lifetimes.

many IPsec implementations implement two timers. 1) idle
timer 2) DPD timer. the idle timer gets reset everytime there
is some traffic received over the IPsec SA. DPD is triggered
once in a while. as long as the other end responds to the
DPD message, the IPsec SA is not deleted. some implementations
combine these two timers and trigger DPD whenever the idle
timer expires.

I never understood why IKEv2 does not have the ability to
negotiate a lifetime for the IPsec SA (and not worry about
having to send keepalives/data traffic for that duration).

Vijay

>>dormant mode. Indeed, as you have described, this would negatively
> 
> impact
> 
>>battery life.
>>
>>dormant mode, so please lengthen the IPsec SA timeout to avoid having
> 
> it
> 
>>Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to
> 
> HA?
> 
>>
>>James,
>>
>>This is a good discussion. Indeed the need for IPsec keepalives (or
> 
> DPD)
> 
>>>Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode Alert
> 
> to
> 
>>HA?
>>
>>>For security, the message would need to be sent within an SA. There
> 
> is
> 
>>a
>>
>>>question about which.
>>>
>>>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
> 
>>>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
>>
>>>timeout, apply a filter that is either mobile specified or part of
> 
> the
> 
>>>Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode Alert
> 
> to
> 
>>HA?
>>
>>>
>>>>>3GPP2 want to use RFC 4285 auth option rather than IPsec. One
> 
> issue
> 
>>-
>>
>>>>>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
>>>
>>>>>charter. This would make IKEv2/IPsec more attractive as a
> 
> security
> 
>>>option
>>>
>>>>>for cellular operators.
>>>>>
>>>>>Comments?
>>>>>
>>>>>           jak
>>>>>
>>>>>
>>>>>
>>"This email message and any attachments are confidential information
> 
> of
> 
>>review, retransmission, dissemination or other use of, or taking of
> 
> any
> 
>>intended recipient, please notify the sender immediately -- by
> 
> replying to
> 
>>destroy all copies of this message and any attachments without reading
> 
> or
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Jul 2006 14:42:22 -0700

> perhaps this is an unanswerable question because, as yet, has anybody 

this is more of an IPsec issue. it depends on the local policy
on the initiator and responder. however, as long as there is
traffic and there are responses to DPD messages, the IPsec SA
is not deleted.

Vijay

> 
> My only observation is that this seems to be an issue with Wimax Forum, 
> and one of the primary motivators for wanting to use the RFC 4285 Auth 
> Option. If IETF and the MIP6 WG would like to encourage them to use IKE 
> (as seemed to be the sentiment when RFC 4285 was discussed, and one of 
> the reasons why it is not PS), it might be worthwhile to try to address 
> their concerns.
> 
>            jak
> 
> ----- Original Message ----- From: "Tsirtsis, George" 
> <[email-masked]>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 18 Jul 2006 14:47:27 -0700

So how often PDP messages are sent is also local policy? In which case
it can be configured to a time that makes sense for MIP or a given
deployment scenario.
George

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Tuesday, July 18, 2006 5:42 PM
> To: James Kempf
> Cc: Tsirtsis, George; Chowdhury, Kuntal; [email-masked]
HA?
Forum,
to
to
having
to
Alert
There
the
(actually,
Alert
but
reading

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Jul 2006 15:05:50 -0700

Tsirtsis, George wrote:
> So how often PDP messages are sent is also local policy? 

I guess you meant DPD. yes it is local policy. the initiator
and responder configure this independently.

> In which case

Yes. however, the IPsec implementation should allow for
sufficiently large values for DPD timer. but then again
DPD exists so that unwanted IPsec state is removed if
the other end goes down or if there is no traffic for a
long time.

Vijay

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 18 Jul 2006 15:10:43 -0700

Yes, I meant DPD. 

There is a fate sharing here between MIP6 state and IPSEC state. I guess
the SA lifetime and DPD timer was introduced to catch the general case
but they do not make sense to be much different than the MIP lifetime
when that is used.

It is indeed strange, however, that IPSEC does not allow for negotiation
of these parameters. I guess people will have to use reasonable values
in each deployment depending what they are doing.

George

> Sent: Tuesday, July 18, 2006 6:06 PM
> To: Tsirtsis, George
> Cc: James Kempf; Chowdhury, Kuntal; [email-masked]
HA?
to
> >>> Option. If IETF and the MIP6 WG would like to encourage them to
use
> > IKE
> >>> (as seemed to be the sentiment when RFC 4285 was discussed, and
one
Alert
> >>>> Starent Networks, Corp. The information transmitted may not be
used
> >>>> action in reliance upon this e-mail and its attachments by
persons

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 18 Jul 2006 16:26:31 -0700

I'm just catching up with this discussion. 

If the IPsec idle timer is at least equal to the BU lifetime, why is
there a need for any other signaling related to dormant mode? Given that
the timer values are a matter of policy, this should be do-able. 

Vidya

> From: Tsirtsis, George [mailto:[email-masked]] 
> Sent: Tuesday, July 18, 2006 3:11 PM
> To: Vijay Devarapalli
> Cc: [email-masked]; James Kempf
> There is a fate sharing here between MIP6 state and IPSEC 
> state. I guess the SA lifetime and DPD timer was introduced 
> to catch the general case but they do not make sense to be 
> much different than the MIP lifetime when that is used.
> 
> It is indeed strange, however, that IPSEC does not allow for 
> negotiation of these parameters. I guess people will have to 
> use reasonable values in each deployment depending what they 
> are doing.
> 
> George
> 
> > I guess you meant DPD. yes it is local policy. the initiator and 
> > responder configure this independently.
> > 
> > > In which case
> sufficiently 
> > large values for DPD timer. but then again DPD exists so 
> that unwanted 
> > IPsec state is removed if the other end goes down or if there is no 
> > traffic for a long time.
> > 
> > Vijay
> > 
> > > George
> > >
> > >>> I don't know. What do operators typically set the SA 
> lifetime to?
> > > Though
> > >> this is more of an IPsec issue. it depends on the local 
> policy on 
> > >> the initiator and responder. however, as long as there 
> is traffic 
> > >> and there are responses to DPD messages, the IPsec SA is not 
> > >> deleted.
> > >>
> > >> Vijay
> > >>
> > >>> and one of the primary motivators for wanting to use 
> the RFC 4285
> > > Auth
> > >>>> The intent is to provide a way for the MN to say that 
> it is about
> > > to
> > >>> go
> > >>>
> > >>>> into
> > >>>>> and WakingUp) and send it within the IPsec SA between 
> the HA and
> > > MN.
> > >>>> The
> > >>>>> MN
> > >>>>> between the MIP code and IKE code for the HA to 
> extend the IPsec
> > > SA
> > >>>>> One question is, does the HA need to do anything else 
> if the MN
> > > goes
> > >>>> into
> > >>>>> timeout, apply a filter that is either mobile 
> specified or part
> > > of
> > >>> the
> > >>>
> > >>>>>> 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.
> > >>>>>>
> > >>>>>> have the IPsec SA lifetime feature. so keepalives are needed.
> > >>>>>>
> > >>>>>> James Kempf wrote:
> > >>>>>> 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
> > >>>>>>
> > >>>>>>> this might be something that the WG could work on 
> now as part
> > > of
> > >>>> the
> > >>>>> new
> > >>>> review, retransmission, dissemination or other use of, 
> or taking
> of
> > >>> any
> > >>>
> > >>>> entities other than the intended recipient is 
> prohibited. If you
> > > are
> > >>> not
> > >>>
> > >>>> the

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Wed, 19 Jul 2006 10:38:55 +0200

This problem applies also to the 3GPP I-WLAN in case the access
network (that may be any non-3GPP access network and not only WLAN,
despite of the name) supports dormant mode. I agree it is an important
issue to study.

I think there are two issues here:

- one is the SA lifetime. This is really an IKE/IPsec issue and should
be handled in IPsec (concluded) WG. As mentioned, this issue does not
apply only to MIP6; in 3GPP I-WLAN the MN has an IPsec tunnel with the
PDG and if the access network supports dormant mode, the MN cannot go
into dormant mode state in order to keep the SA up. I guess it may
apply also to MOBIKE.

- another issue is the lifetime of the BCE. It seems not acceptable
that the MN needs to go back to active state in order to send a
refresh BU to the HA. For this issue, an extension to MIP6, similar to
the one proposed by James, may make sense.

--Gerardo

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 19 Jul 2006 06:27:35 -0700

IMHO It would be a mistake to introduce a mechanism that allows the MN
to stop sending BUs. This would essentially result in "hard state" which
is bad. 

Everyone repeat after me "hard state is bad"! ok, just joking :-)

Seriously though, all we are talking about here is manipulating a set of
timers we have for all these processes so that the maintenance of the
soft state associated with MIP and IPSEC does not affect the mobile's
battery life. Set these timers to values in the order of many minutes or
even better hours and the power consumption becomes negligible since the
MN can be in dormant mode for most of the time. One should also
time-align such timers when possible so that the MN can wake up once,
refresh all its timers and then go back to sleep.

Regards
George

> From: Gerardo Giaretta [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 4:39 AM
> To: Tsirtsis, George; James Kempf
> Cc: Chowdhury, Kuntal; [email-masked]
HA?
> > > Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode
Alert to
> > > If IETF and the MIP6 WG would like to encourage them to use IKE
(as
> > seemed
Alert
> > > > > and WakingUp) and send it within the IPsec SA between the HA
and
> > > > > between the MIP code and IKE code for the HA to extend the
IPsec
> > > > > One question is, does the HA need to do anything else if the
MN
> > > > > >> lack of EAP support for client auth - is solved by IKEv2
and
> > > > > >> this might be something that the WG could work on now as
part
used
persons

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 08:47:56 -0700

The operator may want to keep active mode timers short, then set them longer 
only if the mobile goes into dormant mode.

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "Tsirtsis, George" <[email-masked]>; "Vijay Devarapalli" 
<[email-masked]>
Cc: <[email-masked]>; "James Kempf" <[email-masked]>
Sent: Tuesday, July 18, 2006 4:26 PM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

Vidya

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 09:10:49 -0700

Gerardo,

----- Original Message ----- 
From: "Gerardo Giaretta" <[email-masked]>
To:> - one is the SA lifetime. This is really an IKE/IPsec issue and should
> into dormant mode state in order to keep the SA up. I guess it may

The IPsec WG doesn't exist anymore and neither does MOBIKE. MOBIKE was 
closed recently. If the MIP WG decides that this is a problem that needs to 
be solved, it cannot simply hand the problem off to another WG. Either a new 
WG would need to be formed or the MIP WG would need to do the work itself.

> the one proposed by James, may make sense.

As George brought up, the two are linked. Unfortunately, given the way IETF 
designs protocols (as "piece parts"), its difficult to optimize if two 
independently designed protocols have in softstate dependences when used 
together.

Perhaps we would solve the problem by defining an IKEv2 INFORMATIONAL 
message to negotiate the timeout, then let the MN include a Mobility Header 
Option to lengthen the BCE lifetime into that. This would limit the message 
exchange to one roundtrip (presuming no retransmission), which I believe is 
important because an MN that wants to go into dormant mode probably doesn't 
want to conduct a lot of messaging with the HA.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 09:28:47 -0700

----- Original Message ----- 
From: "Tsirtsis, George" <[email-masked]>
To: "Gerardo Giaretta" <[email-masked]>; "James Kempf" 
<[email-masked]>
Cc: "Chowdhury, Kuntal" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 19, 2006 6:27 AM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

jak>> No, it isn't a joke. You're right.

jak>> I think the issue is that some operators may want to have a policy 
that has different timer values for dormant and active mode hosts. And what 
if the timer values are set differently for different kinds of mobile 
devices? A timer for an iPac might be different from a Toyota Prius, 
because the amount of power available would be quite different.

jak>> Anyway, there's still an issue with IKEv2 not allowing the timer value 
to be negotiated.

            jak

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 19 Jul 2006 09:30:46 -0700

> > refresh BU to the HA. 

=> I think this is too radical. It's perfectly acceptable to do that if
it only happens once an hour or once every two hours ...etc. If it
happens once a minute then of course it's a problem. I don't think you
can make a blanket statement that disregards the frequency of the
updates. 

 > MIP6, similar to

=> Too premature IMO. 

Hesham

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 19 Jul 2006 09:41:34 -0700

James,

Yes, as Vijay also indicated it would be good if IKEv2 had a way to
negotiate timers.

WRT MIP, however, lengthening the lifetime could simply be a matter for
sending another BU before going to dormant mode, rather than introducing
a whole new message.

My point is that it is not clear to me that MIP/IPSEC and other
protocols need to understand "dormancy" as a mode of operation, as long
as the soft state timers can be negotiated at will (within policy limits
of course).

George

> Sent: Wednesday, July 19, 2006 12:29 PM
> To: Tsirtsis, George; Gerardo Giaretta
HA?
HA?

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Jul 2006 10:58:04 -0700

James Kempf wrote:
> Gerardo,
> 
> ----- Original Message ----- From: "Gerardo Giaretta" 
> <[email-masked]>
> closed recently. If the MIP WG decides that this is a problem that needs 
> to be solved, it cannot simply hand the problem off to another WG. 
> Either a new WG would need to be formed or the MIP WG would need to do 
> the work itself.

the work is too minor to form a WG. another option is an
individual submission with reviews from MIP6 WG and the
IPsec and MOBIKE mailing lists (which are still around).

> As George brought up, the two are linked. Unfortunately, given the way 
> IETF designs protocols (as "piece parts"), its difficult to optimize if 
> two independently designed protocols have in softstate dependences when 
> used together.
> 
> message to negotiate the timeout, then let the MN include a Mobility 
> Header Option to lengthen the BCE lifetime into that. 

oh no... these have to be two separate messages. mobility
options can be sent only in mobility header messages which
in turn can't be combined with any other protocol payload.
(piggybacking was removed. :)).

Vijay

This would limit
> the message exchange to one roundtrip (presuming no retransmission), 
> which I believe is important because an MN that wants to go into dormant 
> mode probably doesn't want to conduct a lot of messaging with the HA.
> 
>            jak
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Jul 2006 10:59:20 -0700

> sending another BU before going to dormant mode, rather than introducing

agree.

Vijay

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Wed, 19 Jul 2006 20:02:46 +0200

> (piggybacking was removed. :)).

I still see the IPsec/MOBIKE problem as separate from the MIP6 one.
Again it applies also to other scenarios than MIP6 mobility.

This was also discussed in WiMAX Forum for WiMAX and 3GPP
interworking. And IKEv2 does not allow to negotiate lifetimes.

Do people think that everybody can be fine just setting proper timers
administratively?

--Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Jul 2006 11:06:32 -0700

> Do people think that everybody can be fine just setting proper timers

IMO, an extension to IKEv2 to signal going to dormant mode,
which will avoid the mobile node having to send
keepalives/active traffic or respond to DPD messages, will
be useful.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 12:56:19 -0700

> Do people think that everybody can be fine just setting proper timers

No, I don't think so. I think the mobile node needs the ability to negotiate 
the timer values.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 12:52:24 -0700

jak>> OK.

jak>> Sure, that would work.

jak>> Yes, I agree. I am not arguing that we need to introduce any 
additional concept of "dormancy", despite the provisional names I gave to 
the proposed messages. I'd like to get the minimum set of functionality that 
will support Wimax Forum and other customers of MIP6, to encourage them to 
use IPsec and the rest of the MIP6 design, rather than coming up with their 
own solutions.

jak>> It sounds to me like that minimal set of functionality may be some way 
to negotiate the IKEv2 timers.

                 jak

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 19 Jul 2006 14:55:49 -0700

What would be the motivation for maintaining such mode specific timer values? 
 
Vidya

________________________________

From: James Kempf [mailto:[email-masked]]
Sent: Wed 7/19/2006 8:47 AM
To: Narayanan, Vidya; Tsirtsis, George; Vijay Devarapalli
Cc: [email-masked]
Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

            jak

----- Original Message -----
From: "Narayanan, Vidya" <[email-masked]>
To: "Tsirtsis, George" <[email-masked]>; "Vijay Devarapalli"

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 19 Jul 2006 15:01:13 -0700

I agree. I'm surprised this is seen as a big problem. 
 
Vidya

From: Soliman, Hesham [mailto:[email-masked]]
Sent: Wed 7/19/2006 9:30 AM
To: Tsirtsis, George; Gerardo Giaretta; James Kempf
Cc: [email-masked]
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

=> Too premature IMO.

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 15:10:24 -0700

Maybe the incidence of mobiles dropping out is higher for active than 
dormant mode mobiles?

Also, another reason for not having the timers have policy fixed values is 
so that the timers can be set depending on the kind of device. I mentioned 
this in a response to George.

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Tsirtsis, George" 
<[email-masked]>; "Vijay Devarapalli" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 19, 2006 2:55 PM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

What would be the motivation for maintaining such mode specific timer 
values?

Vidya

            jak

----- Original Message -----
From: "Narayanan, Vidya" <[email-masked]>
To: "Tsirtsis, George" <[email-masked]>; "Vijay Devarapalli"

Vidya

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 15:12:51 -0700

It seems to be an issue with Wimax Forum, and one of the motivating reasons 
why they and 3GPP2 insisted upon the RFC 4285 Auth option.

To turn this around, do you or anyone have an idea why IKEv2 doesn't allow 
the timer values to be negotiated? Was this just a matter of simplification 
or was there some security issue?

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "Soliman, Hesham" <[email-masked]>; "Tsirtsis, George" 
<[email-masked]>; "Gerardo Giaretta" <[email-masked]>; 
"James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 19, 2006 3:01 PM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

Vidya

=> Too premature IMO.

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 19 Jul 2006 16:32:03 -0700

> 
> Maybe the incidence of mobiles dropping out is higher for 
> active than dormant mode mobiles?
> 

Hmmm.. I'm not so sure. Given that the IPsec SA under discussion is
really for MIP6, I can see why the BU lifetime and the IPsec idle timer
can be in sync without a problem. So, I am surprised that there are
independent requirements here. 

> Also, another reason for not having the timers have policy 
> fixed values is so that the timers can be set depending on 
> the kind of device. I mentioned this in a response to George.
> 

Yes, I recall that. But, whatever considerations are given to the type
of device would, I'd think, apply to the BU lifetime as well. 

Vidya

> Alert to HA?
> > > >>> the reasons why it is not PS), it might be worthwhile 
> to try to
> > > > address
> > > >>> their concerns.
> > > >>>
> > > >>>            jak
> > > >>>
> > > >>> May I ask, what is the typical lifetime of the SA and 
> what would
> > you
> > > >>> lengthen it to?
> > > >>> George
> > > >>>
> > > >>>> The intent is not to introduce something that the MN 
> would send
> > > > during
> > > >>>> This is a good discussion. Indeed the need for IPsec 
> keepalives
> > (or
> > > >>> DPD)
> > > >>>
> > > >>>>> sends the Sleeping message when it is about to go 
> into dormant
> > > > mode,
> > > >>>> it
> > > >>>>> 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
> > > >>>>> 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
> > > >>>>>>> I was at Wimax Forum last week and I think I now 
> understand
> > > > why
> > > >>>> they
> > > >>>>> and
> > > >>>>>>> lack of EAP support for client auth - is solved 
> by IKEv2 and
> > > > they
> > > >>>> seem
> > > >>>>> to
> > > >>>>>>> that the IPsec SA may time out. It is unfortunate 
> that this
> > > > was
> > > >>> not
> > > >>>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 19 Jul 2006 16:59:09 -0700

Yes, I was actually coming to that :) Before I wrote about that, I
wanted to understand the motivation better and hence my questions. 

Now, before we go down the path of concluding that IKEv2 needs to
support timer/lifetime negotiation, we should take a look at why this
functionality didn't make it into IKEv2 (since IKE supported it). 

Supporting lifetime or timer negotiation in a key management protocol is
really seen as a wasteful feature for the following reasons: 

1. The key management protocol itself really has no control over the
enforcement of these lifetimes or timers. 

2. Even with negotiated lifetimes, IKEv2 and IPsec allow either party to
re-key at any time. 

3. Either party may reboot or lose state and lifetime or timers don't
have any value then. 

For all these reasons, it was felt that there is no real reason for
IKEv2 to do this functionality. Independent management of lifetimes and
timers by the initiator and responder is really the most flexible way of
handling this. 

As I said in my earlier emails, all the concerns tied to the IPsec timer
values seem to equally apply to the BU lifetime as well - hence, I am
not yet seeing a need for adding this functionality to IKEv2 per say. 

I'm not sure about WiMAX, but at least in 3gpp2, this was not one of the
reasons for using the AUTH protocol as far as I know. Two reasons why
AUTH protocol was originally chosen as opposed to IPsec - before IKEv2,
there wasn't a way to utilize AAA-based credentials with IPsec (IKE
didn't support EAP). Also, even with EAP/IKEv2, the number of messages
seemed to be a concern (e.g., in a failure/recovery scenario, all
mobiles try to do EAP/IKEv2 with the HA, which could be a problem). And,
currently, 3gpp2 is already revisiting the option of requiring IPsec for
MIP6 in place of the AUTH protocol. 

Vidya

> Sent: Wednesday, July 19, 2006 3:13 PM
> To: Narayanan, Vidya; Soliman, Hesham; Tsirtsis, George; 
> Gerardo Giaretta
> Cc: [email-masked]
> It seems to be an issue with Wimax Forum, and one of the 
> motivating reasons why they and 3GPP2 insisted upon the RFC 
> 4285 Auth option.
> 
> To turn this around, do you or anyone have an idea why IKEv2 
> doesn't allow the timer values to be negotiated? Was this 
> just a matter of simplification or was there some security issue?
> 
>             jak
> 
> <[email-masked]>; "Gerardo Giaretta" 
> <[email-masked]>; "James Kempf" <[email-masked]>
> Cc: <[email-masked]>
>  > > - another issue is the lifetime of the BCE. It seems not 
> acceptable  > > that the MN needs to go back to active state 
> in order to send a  > > refresh BU to the HA.
> 
> => I think this is too radical. It's perfectly acceptable to 
> do that if it only happens once an hour or once every two 
> hours ...etc. If it happens once a minute then of course it's 
> a problem. I don't think you can make a blanket statement 
> that disregards the frequency of the updates.
> 
>  > MIP6, similar to

---

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 20 Jul 2006 09:49:45 -0500

Hi Vidya,

The reason 3gpp2 adopted AUTH protocol because it is simple and easy to
manage. Regarding your statement "requiring IPsec for MIP6 in place of
the AUTH", I don't think that 3gpp2 precluded the usage of IPSec since
they are supporting 3775.

Vidya

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 20 Jul 2006 08:28:08 -0700

> motivating reasons 

=> Honestly, if that's what motivated them to do 4285 then I'm worried
about the rest
of their system! I *think* 4285 was done to avoid implementing IKE/IPsec
primarily. That makes more sense to me than doing it to avoid confusion
about timers which can be set properly by an admin. 

 > doesn't allow 

=> Sounds like a strange design choice to me, the old one allowed for
timer negotiation. 

Hesham

 > do that if

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Jul 2006 08:54:14 -0700 (PDT)

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: James Kempf <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, July 19, 2006 12:58:04 PM
Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

the work is too minor to form a WG. another option is an
individual submission with reviews from MIP6 WG and the
IPsec and MOBIKE mailing lists (which are still around).
==> I agree with James. There are more and more issues coming up with IP aspects of the dormant mode from SDOs (a new one just popped up today in WiMAX) and an issue was mentioned in one of mobopts presentations in IETF 66.
I do not think that an individual submission is going to do it. Maybe a PS might help.

Regards,

Behcet
-- the rest is snipped.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Jul 2006 09:21:54 -0700

Vidya,

The fact is that MIP and IKE are managed by two completely different 
protocols. RFC 4301 does not specify anything about timeouts in the SPD or 
SAD, which would allow some kind of per host or per application timeout 
customization. Your proposal means that the operator would have to manage 
its HA with the same timeouts for the HA to mobile node MIP traffic as for, 
say, signaling traffic between two HAs doing the HA reliability protocol or 
some other IPsec application, because the basic IPsec architecture provides 
no way to differentiate between the timing requirements of the two. I think 
this is unreasonable, as the ability of the two to respond to keepalives 
could be quite different. Furthermore, RFC 4306 says this about why any 
timeouts were left out of IKEv2 (Section 2.4):

   Numbers of retries and lengths of timeouts are not covered in this
   specification because they do not affect interoperability.  It is
   suggested that messages be retransmitted at least a dozen times over
   a period of at least several minutes before giving up on an SA, but
   different environments may require different rules.

As with other cases involving mobile nodes and IKEv2 (whence came MOBIKE), 
this does not address the needs of wireless. An implementation on a laptop 
with 802.11, which doesn't have proper dormant mode support, doesn't need 
the ability to lengthen the timeout for dormant mode because it will be 
woken up by the AP when a keepalive arrives. An implementation on a 
cellphone which does have proper dormant mode support won't, or, at least, 
it shouldn't if we want to provide proper support for dormant mode. Should 
the combined BU/SA timeout be the same for both? If so and it is set to the 
802.11 timeout, having no way for the cellphone to lengthen its timeout when 
it goes into dormant mode means drastically reduced cellphone battery 
lifetime and unhappy customers. If it is set to the expected cellphone 
dormant mode lifetime then the SAD has a bunch of entries for laptops, whose 
owners have closed the lids and jumped on a plane, hanging around when they 
aren't needed. The effect won't be to prohibit interoperability, but it will 
result in a considerable amount of unnecessary traffic and reduced customer 
satisfaction.

Furthermore, IKEv1 had a way to do lifetime negotiation (Section 4.5 in RFC 
2407) via the SA lifetime in the ISAKMP messaging. So I don't quite 
understand why you are opposed to adding an IKEv2 INFORMATIONAL exchange for 
this purpose.

Your point about 3GPP2 needing EAP support is also a concern to Wimax Forum, 
as I mentioned in the original email that started this thread, but, in 
addition, I was hearing that they were concerned about IPsec SA timeout 
during dormant mode. I sent email to the Wimax Forum list, and Raj confirmed 
that this was, indeed, a concern.

And finally regarding your point:

The problem is that it is possible to extend the binding lifetime by sending 
a BU just before the mobile node goes into dormant mode, but there is no 
support in IKEv2 for extending the SA lifetime.

        jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Tsirtsis, George" 
<[email-masked]>; "Vijay Devarapalli" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 19, 2006 4:32 PM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

Vidya

---

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Jul 2006 09:37:38 -0700

jak>> They now also specify IKEv2, but default is 4285. The other reason 
originally for not wanting to use IKE was lack of EAP support, same as for 
pp2, but that has now changed with IKEv2.

jak>> See my response to Vidya on this, it's mentioned in RFC 4306. I think 
it was primarily for simplification. IKEv1 had timers as part of ISAKMP. 
ISAKMP was stripped out in IKEv2, largely for the better, but in the process 
I think they dropped a couple of things that might have been useful in some 
cases.

jak>> Anyway, do you have any objection to putting an IKEv2 INFORMATIONAL 
message into the charter? Or do you think it should be done elsewhere (and 
if so, any suggestions about where)?

            jak

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 20 Jul 2006 10:08:28 -0700

> if so, any suggestions about where)?

=> Well, I don't think it's a serious issue to begin with, because a
reasonable admin will set the timers to a reasonable time. But, to
answer your question, I don't mind having an additional IKEv2 message
provided that it is not sent with the BU and doesn't require MIP6 and
IPsec implementations to cooperate. So if the new message basically sets
the lifetime for the SA, regardless of who's using the SA (MIP or some
other app) then I'm ok with it.

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 20 Jul 2006 15:45:02 -0700

> 
> The fact is that MIP and IKE are managed by two completely 
> different protocols. RFC 4301 does not specify anything about 
> timeouts in the SPD or SAD, which would allow some kind of 
> per host or per application timeout customization. Your 
> proposal means that the operator would have to manage its HA 
> with the same timeouts for the HA to mobile node MIP traffic 
> as for, say, signaling traffic between two HAs doing the HA 
> reliability protocol or some other IPsec application, because 
> the basic IPsec architecture provides no way to differentiate 
> between the timing requirements of the two. 

I don't see why this is the case. The timers are managed per IPsec
session - so, why would the timer values be the same for HA to MN and HA
to HA or other entity IPsec sessions? 

> I think this is 
> unreasonable, as the ability of the two to respond to 
> keepalives could be quite different. Furthermore, RFC 4306 
> says this about why any timeouts were left out of IKEv2 (Section 2.4):
> 

I had stated some of the reasons in one of my earlier emails - timer
and/or lifetime negotiation in a key management protocol is typically
not very useful. 

> As with other cases involving mobile nodes and IKEv2 (whence 
> came MOBIKE), this does not address the needs of wireless. An 
> implementation on a laptop with 802.11, which doesn't have 
> proper dormant mode support, doesn't need the ability to 
> lengthen the timeout for dormant mode because it will be 
> woken up by the AP when a keepalive arrives. An 
> implementation on a cellphone which does have proper dormant 
> mode support won't, or, at least, it shouldn't if we want to 
> provide proper support for dormant mode. Should the combined 
> BU/SA timeout be the same for both? If so and it is set to the
> 802.11 timeout, having no way for the cellphone to lengthen 
> its timeout when it goes into dormant mode means drastically 
> reduced cellphone battery lifetime and unhappy customers. If 
> it is set to the expected cellphone dormant mode lifetime 
> then the SAD has a bunch of entries for laptops, whose owners 
> have closed the lids and jumped on a plane, hanging around 
> when they aren't needed. The effect won't be to prohibit 
> interoperability, but it will result in a considerable amount 
> of unnecessary traffic and reduced customer satisfaction.
> 

There are two sides to this problem - one is the capability for MNs to
request a certain lifetime/timer value - here, when a mobile is entering
dormant mode, it doesn't always know how long it is going to be in
dormant mode. So, what is the timer value being requested? The second
side of the problem is that the server can, at any time, get rid of the
SA depending on resources it has. So, the fact that a mobile requested
an extension of lifetime doesn't particularly matter. 

> 2407) via the SA lifetime in the ISAKMP messaging. So I don't 
> quite understand why you are opposed to adding an IKEv2 
> INFORMATIONAL exchange for this purpose.
> 

IKEv2 acknowledged the lack of this feature and decided it is not
needed. So, a careful scrutiny of whether we need it is quite important.

> Your point about 3GPP2 needing EAP support is also a concern 
> to Wimax Forum, as I mentioned in the original email that 
> started this thread, but, in addition, I was hearing that 
> they were concerned about IPsec SA timeout during dormant 
> mode. I sent email to the Wimax Forum list, and Raj confirmed 
> The problem is that it is possible to extend the binding 
> lifetime by sending a BU just before the mobile node goes 
> into dormant mode, but there is no support in IKEv2 for 
> extending the SA lifetime.
> 

But, is a mobile that is about to go into dormant really sending a BU
and waiting for a BA before going dormant? If all upper layer protocols
took that approach, the mobile will potentially have to send a lot of
messages prior to entering dormant mode - that doesn't seem to be a good
design, IMHO. If we consider the fact that a mobile, at any time, may be
dealing with lifetimes in various protocols (say, MIP, IKEv2, SIP, TLS,
etc.), I would think it would be much more expensive to send all these
messages prior to going dormant. 

Vidya

> > > > >>> perhaps this is an unanswerable question because, 
> as yet, has
> > > > > anybody
> > > > >>> deployed MIPv6?
> > > > >>> Subject: RE: [Mip6] New Charter Item:Support for 
> Dormant Mode
> > > Alert
> > > > > to
> > > > >> HA?
> > > > >>>
> > > > >>>> Subject: RE: [Mip6] New Charter Item:Support for 
> Dormant Mode
> > > Alert
> > > > > to
> > > > >>> HA?
> > > > >>>
> > > > >>>>
> > > > >>>> James,
> > > > >>>>
> > > > >>>>> isn't needed for the MN to get mobility service, 
> it is just
> > > there
> > > > >>> for
> > > > >>>
> > > > >>>>> within the IKE SA. It works similarly, but there 
> would be no
> > > need
> > > > >>> for
> > > > >>>
> > > > >>>> any
> > > > >>>>>>> most cellular protocols, has extensive support 
> for dormant
> > > > > mode,
> > > > >>>> and

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Jul 2006 15:57:01 +0200

I've not so arbitrary pick up one of the messages to answer...

IMHO there are three issues to address: DPD, SA lifetimes, BCE.

About Dead Peer Detection, RFC 4306 is very flexible. I believe there is
no reason in this case to have each peer polling the other, i.e., one sends
polls and says its peer is dead when it doesn't receive a small number of
acks in a row, the other says its peer is dead when it doesn't receive a
small (perhaps a bit larger) number of polls in a row.
We have already in practice the HA in a passive mode, i.e., it is *never*
the IKE initiator. To make the MN the active polling side and the HA the
passive one seems the right way to go (but I'll come back about DPD).

Security Association lifetimes: IKEv1 can negociate them but this is a
major operational issue to get this right. IKEv2 relies on the config
so the idea should be to have a good config. BTW at least the IKE SA
lifetime should be in the PAD so there is no issue to put a large value
(i.e., almost infinite) on a HA for MNs but not for other HAs.
Again we need only rekeys initiated by one side, of course this side
should be the MN, i.e., HAs should use almost infinite lifetimes.

What is the real limit? The only thing which really requires a rekey
is the sequence number exhaution but smaller sequence numbers are on
32 bits: I can't see an issue for low traffic SAs, i.e., the IKE SA,
the BU/BA transport SA, the HOTI/HOT SA, etc. The only problem can
be with a payload SA when the MN should actively rekey in time, so
IMHO the only case we can be in trouble (but in fact independtly of IPsec)
is a dormant node receiving a lot of protected traffic...

BCE: even very unreasonable BCE lifetimes are a bit small (a few days,
16 bit value in 4 second unit). If we add something IMHO this is the first
place as the MIPv6 code can really take benefit to know the node is dormant.

Come back to DPD: a passive DPD should have a good way to distinguish
between a dormant and a dead node so I propose to add a new "private
status" notification in DPD poll with in the data the delay to the next
poll in second. So the passive DPD code becomes very easy to implement,
and a MN going to the dormant node has only to send a poll with a large
delay and wait for the ack. BTW this needs only a document, and an
experimental RFC if we prefer a "IANA status" type.

Regards

[email-masked]

PS: about RFC 4285, the whole story was laziness vs. security
(or if you prefer cost vs. security)...

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 27 Jul 2006 21:00:16 +0900

Hi Francis and all.

First of all, i think the dormant mode is useful in some scenario.

And, I agree with Francis here. The experimental RFC sounds reasonable.
This is easiest way to achieve the dormant mode on MN, IMO.

BTW, we should not define new method to lengthen the BC lifetime, other
than BU.
It is hard to predict how much time MN needs for the dormant mode.
Re-sending BU or freezing lifetime value is better.

regards,
ryuji