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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 18 Jul 2006 15:12:06 -0400

James,

OK, I understand the intent (possible solution) better now. Besides
IPsec keepalives which happen periodically, there is Dead Peer Detection
(DPD) in use today. This gets triggered when the IPsec stack does not
detect any bearer traffic for a peer.   

So, there needs to be some additional hooks defined for the MIP6 stack
to manipulate IPsec keepalives and DPD.

-Kuntal

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, July 18, 2006 1:43 PM
> To: Chowdhury, Kuntal
> Cc: [email-masked]
> Subject: Re: [Mip6] New Charter Item:Support for Dormant Mode Alert to
HA?
> 
> 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,
> 
> 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: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 18 Jul 2006 16:26:49 -0400

> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Tuesday, July 18, 2006 2:49 PM
> To: James Kempf; Chowdhury, Kuntal
> Cc: [email-masked]
HA?
> 
> 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.

[KC>] IPsec DPD has nothing to do with IPsec SA lifetime. So, even if
someone sets MIP6 BCE lifetime = IPsec SA lifetime, it won't stop IPsec
stack to send DPD messages to the peer (MN). MN waking up and refreshing
its MIP6 BCE is a basic requirement for MIP6 protocol to work. 

> George
> > Sent: Tuesday, July 18, 2006 3:37 PM
> > To: Tsirtsis, George; Chowdhury, Kuntal
> > Cc: [email-masked]
to
> HA?
> >
> > 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
> >
> > 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
> > 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]
> > > Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode
Alert
> > > Starent Networks, Corp. The information transmitted may not be
used

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 24 Jul 2006 11:54:45 -0700

I am just not seeing a good technical reason why this is needed. 
 
Going in and out of dormancy could happen often and the net idle time is
also unpredictable. Given that, I don't think it is a good idea to have
to send messages and wait for acks before entering dormant mode. 
 
If there is a good reason why WiMAX needs it, then perhaps something can
be defined specifically for WiMAX (even a vendor specific payload should
do) - I don't see a general purpose need for this functionality. I just
verified with some 3gpp2 folks that there has been no discussion related
to this in 3gpp2 and also that they don't see the mobile being required
to send any messages before going dormant. 

Vidya

________________________________

	From: James Kempf [mailto:[email-masked]] 
	Sent: Monday, July 24, 2006 10:12 AM
	To: Narayanan, Vidya; Tsirtsis, George; Vijay Devarapalli
	Cc: [email-masked]
	Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode
Alert to HA?

	Clearly, we disagree about the need for the WG to work on
something here. 
	 
	                   jak

________________________________

	From: Narayanan, Vidya [mailto:[email-masked]]
	Sent: Thu 7/20/2006 3:45 PM
	To: James Kempf; Tsirtsis, George; Vijay Devarapalli
	Cc: [email-masked]
	Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode
Alert to HA?

	>
	> 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):
	>
	>    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.
	>
	
	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.
	
	> 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.
	>
	
	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
	> that this was, indeed, a concern.
	>
	> And finally regarding your point:
	>
	>     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.
	>
	> 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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jul 2006 12:07:40 -0700

Like I said, we disagree. No need to waste any more network bandwidth on 
discussion.

            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: Monday, July 24, 2006 11:51 AM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?

Vidya

                   jak

in this
It is
SA, but

Vidya

> 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
> > 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
>
>
> >             jak
> >
> > 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
> > What would be the motivation for maintaining such mode
> specific timer
> > values?
> >
> > Vidya
> >
> > Sent: Wed 7/19/2006 8:47 AM
> > Subject: Re: [Mip6] New Charter Item:Support for Dormant
Mode
> > Alert to HA?
> >
> >
> >
> > The operator may want to keep active mode timers short, then
> > set them longer
> > only if the mobile goes into dormant mode.
> >
> >             jak
> >
> >
> >
> > 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
> > 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.
> > > Sent: Tuesday, July 18, 2006 3:11 PM
> > > To: Vijay Devarapalli
> > > Cc: [email-masked]; James Kempf
> > > 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.
> > > > From: Vijay Devarapalli
[mailto:[email-masked]]
> > > > Sent: Tuesday, July 18, 2006 6:06 PM
> > > > To: Tsirtsis, George
> > > > Cc: James Kempf; Chowdhury, Kuntal; [email-masked]
> > > > 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
> > > > > it can be configured to a time that makes sense for
MIP
> > > or a given
> > > > > deployment scenario.
> > > >
> > > > 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
> > > >
> > > > > 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]
> > > > >> Subject: Re: [Mip6] New Charter Item:Support for
Dormant
> > > Mode Alert
> > > > >> 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]>
> > > > >>> May I ask, what is the typical lifetime of the SA
and
> > what would
> > > you
> > > > >>>> Subject: Re: [Mip6] New Charter Item:Support for
> Dormant Mode
> > > Alert
> > > > > to
> > > > >>> HA?
> > > > >>>
> > > > >>>> 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
> > > > >>>
> > > > >>>> This is a good discussion. Indeed the need for
IPsec
> > keepalives
> > > (or
> > > > >>>> 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
> > > > >>>>> 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
> > > > >>>
> > > > >>>>> 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.
> > > > >>>>>>
> > > > >>>>>> 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
> > > > >>>>>> 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
> > > > >>>>>>
> > > > >>>>>>> most cellular protocols, has extensive support
> for dormant
> > > > > mode,
> > > > >>>> and
> > > > >>>>>>> Wimax Forum is supporting dormant mode in their
network
> > > > > design.
> > > > >>>>>>> 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
> > > > >>>> "This email message and any attachments are
confidential
> > > > > information
> > > > >>>> 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
> > > > >>>> destroy all copies of this message and any
> > attachments without
> > > > > reading
> > > > >>> or
> > > > >>>