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:
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.
jak
----- Original Message -----
From: "Narayanan, Vidya" <vidyan@xxxxxxxxxxxx>
To: "James Kempf" <kempf@xxxxxxxxxxxxxxxxxx>; "Tsirtsis, George"
<tsirtsis@xxxxxxxxxxxx>; "Vijay Devarapalli"
<vijay.devarapalli@xxxxxxxxxxxxx>
Cc: <mip6@xxxxxxxx>
Sent: Wednesday, July 19, 2006 4:32 PM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode Alert to HA?
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
----- Original Message -----
From: "Narayanan, Vidya" <vidyan@xxxxxxxxxxxx>
To: "James Kempf" <kempf@xxxxxxxxxxxxxxxxxx>; "Tsirtsis, George"
<tsirtsis@xxxxxxxxxxxx>; "Vijay Devarapalli"
<vijay.devarapalli@xxxxxxxxxxxxx>
Cc: <mip6@xxxxxxxx>
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
________________________________
From: James Kempf [mailto:kempf@xxxxxxxxxxxxxxxxxx]
Sent: Wed 7/19/2006 8:47 AM
To: Narayanan, Vidya; Tsirtsis, George; Vijay Devarapalli
Cc: mip6@xxxxxxxx
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
----- Original Message -----
From: "Narayanan, Vidya" <vidyan@xxxxxxxxxxxx>
To: "Tsirtsis, George" <tsirtsis@xxxxxxxxxxxx>; "Vijay Devarapalli"
<vijay.devarapalli@xxxxxxxxxxxxx>
Cc: <mip6@xxxxxxxx>; "James Kempf" <kempf@xxxxxxxxxxxxxxxxxx>
Sent: Tuesday, July 18, 2006 4:26 PM
Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode
Alert to HA?
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
> -----Original Message-----
> From: Tsirtsis, George [mailto:tsirtsis@xxxxxxxxxxxx]
> Sent: Tuesday, July 18, 2006 3:11 PM
> To: Vijay Devarapalli
> Cc: mip6@xxxxxxxx; James Kempf
> Subject: RE: [Mip6] New Charter Item:Support for Dormant Mode
> Alert to HA?
>
> 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
>
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:vijay.devarapalli@xxxxxxxxxxxxx]
> > Sent: Tuesday, July 18, 2006 6:06 PM
> > To: Tsirtsis, George
> > Cc: James Kempf; Chowdhury, Kuntal; mip6@xxxxxxxx
> > Subject: Re: [Mip6] New Charter Item:Support for Dormant
> Mode Alert to
> HA?
> >
> > 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
> > >
> > >> -----Original Message-----
> > >> From: Vijay Devarapalli
[mailto:vijay.devarapalli@xxxxxxxxxxxxx]
> > >> Sent: Tuesday, July 18, 2006 5:42 PM
> > >> To: James Kempf
> > >> Cc: Tsirtsis, George; Chowdhury, Kuntal; mip6@xxxxxxxx
> > >> Subject: Re: [Mip6] New Charter Item:Support for Dormant
> Mode Alert
> to
> > > HA?
> > >> James Kempf wrote:
> > >>> 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?
> > >> 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"
> > >>> <tsirtsis@xxxxxxxxxxxx>
> > >>> To: "James Kempf" <kempf@xxxxxxxxxxxxxxxxxx>;
> "Chowdhury, Kuntal"
> > >>> <kchowdhury@xxxxxxxxxxxxxxxxxxx>
> > >>> Cc: <mip6@xxxxxxxx>
> > >>> 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
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: James Kempf [mailto:kempf@xxxxxxxxxxxxxxxxxx]
> > >>>> Sent: Tuesday, July 18, 2006 2:43 PM
> > >>>> To: Chowdhury, Kuntal
> > >>>> Cc: mip6@xxxxxxxx
> > >>>> 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" <kchowdhury@xxxxxxxxxxxxxxxxxxx>
> > >>>> To: "James Kempf" <kempf@xxxxxxxxxxxxxxxxxx>
> > >>>> Cc: <mip6@xxxxxxxx>
> > >>>> 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:kempf@xxxxxxxxxxxxxxxxxx]
> > >>>>> Sent: Tuesday, July 18, 2006 11:17 AM
> > >>>>> To: Vijay Devarapalli
> > >>>>> Cc: mip6@xxxxxxxx
> > >>>>> 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" <vijay.devarapalli@xxxxxxxxxxxxx>
> > >>>>> To: "James Kempf" <kempf@xxxxxxxxxxxxxxxxxx>
> > >>>>> Cc: <mip6@xxxxxxxx>
> > >>>>> 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
> > >>>>>>> Mip6@xxxxxxxx
> > >>>>>>> https://www1.ietf.org/mailman/listinfo/mip6
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Mip6 mailing list
> > >>>>> Mip6@xxxxxxxx
> > >>>>> 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
> > > postmaster@xxxxxxxxxxxxxxxxxxx
> > >>> --
> > >>>
> > >>>> and
> > >>>> destroy all copies of this message and any
attachments without
> > > reading
> > >>> or
> > >>>
> > >>>> disclosing their contents. Thank you."
> > >>>>
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> Mip6 mailing list
> > >>>> Mip6@xxxxxxxx
> > >>>> https://www1.ietf.org/mailman/listinfo/mip6
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Mip6 mailing list
> > >>> Mip6@xxxxxxxx
> > >>> https://www1.ietf.org/mailman/listinfo/mip6
> > >
>
>
> _______________________________________________
> Mip6 mailing list
> Mip6@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/mip6
>
