Subject: [Mip6] Regarding the charter revision w.r.t the IPsec SA and IKEv2

From: Basavaraj Patil <[email-masked]>
Date: Mon, 24 Jul 2006 14:19:51 -0500

In discussions with Pasi Eronen, I believe there is really nothing specific
that needs to be done w.r.t MIP6 and IKEv2 as far as dead-peer-detection is
concerned. 

Pasi's comment was:
"
When using IPsec for MIP6, there is no need to send any keepalives.
IKE may do Dead Peer Detection (DPD) occasionally, but this is a
configurable parameter (just like binding lifetime) and doing DPD,
say, once every 8 hours does not seem unacceptable to me. And doing
DPD (and Binding Updates) every N hours is IMHO *MUCH* better solution
than introducing hard state (as someone already pointed out on the
list).

(In the NAT case, we typically need keepalives every 30 seconds, and
the endpoints can't choose any other internal since it depends on the
NAT, not the endpoints.)
"

Hence I believe that there is not really any concern as far as IPsec/IKEv2
is concerned in the context of MIP6.

-Raj

P.s: I had to forward Pasi's note since he is not registered on the MIP6
list 

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 24 Jul 2006 13:20:55 -0700

This was my understanding as well. It is a matter of policy and timer
configuration. 

Vidya

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 12:20 PM
> To: [email-masked]
> Cc: Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: [Mip6] Regarding the charter revision w.r.t the 
> IPsec SA and IKEv2
> 
> 
> In discussions with Pasi Eronen, I believe there is really 
> nothing specific that needs to be done w.r.t MIP6 and IKEv2 
> as far as dead-peer-detection is concerned. 
> 
> Pasi's comment was:
> "
> IKE may do Dead Peer Detection (DPD) occasionally, but this 
> is a configurable parameter (just like binding lifetime) and 
> doing DPD, say, once every 8 hours does not seem unacceptable 
> to me. And doing DPD (and Binding Updates) every N hours is 
> IMHO *MUCH* better solution than introducing hard state (as 
> someone already pointed out on the list).
> 
> (In the NAT case, we typically need keepalives every 30 
> seconds, and the endpoints can't choose any other internal 
> since it depends on the NAT, not the endpoints.) "
> 
> Hence I believe that there is not really any concern as far 
> as IPsec/IKEv2 is concerned in the context of MIP6.
> 
> -Raj
> 
> P.s: I had to forward Pasi's note since he is not registered 
> on the MIP6 list 
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Jul 2006 13:22:15 -0700

> than introducing hard state (as someone already pointed out on the

yes, the DPD timer is configurable, but it does not change
dynamically based on whether the mobile node is dormant or
not. the proposed extension lets you change the DPD timer
on the responder dynamically. currently you are stuck with
a fixed DPD timer.

take the mobile IP binding cache state for example. the
binding cache lifetime can be changed at any time by sending
a BU with a different lifetime.

Vijay

---

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

Raj,

Perhaps you could convey this message to NWG?

            jak

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 24 Jul 2006 13:53:02 -0700

> 
> Basavaraj Patil wrote:
> > In discussions with Pasi Eronen, I believe there is really nothing 
> > specific that needs to be done w.r.t MIP6 and IKEv2 as far as 
> > dead-peer-detection is concerned.
> > 
> > Pasi's comment was:
> > "
> not. the proposed extension lets you change the DPD timer on 
> the responder dynamically. currently you are stuck with a 
> fixed DPD timer.
> 

But, do you really see a mobile that is about to enter dormant mode
sending these messages to change the lifetime? 

Vidya

> seconds, and 
> > NAT, not the endpoints.) "
> > 
> > Hence I believe that there is not really any concern as far as 
> > IPsec/IKEv2 is concerned in the context of MIP6.
> > 
> > -Raj
> > 
> > P.s: I had to forward Pasi's note since he is not registered on the 
> > MIP6 list
> > 
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Jul 2006 14:25:32 -0700

> sending these messages to change the lifetime? 

why is it hard?

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 24 Jul 2006 14:39:59 -0700

> > sending these messages to change the lifetime?

Nothing is hard in software :) It seems impractical though - as I said
in one of my earlier emails, mobiles may frequently go in and out of
dormant mode and the duration of dormancy is often unpredictable. If all
timers and lifetimes relating to upper layer protocols need to be
refreshed with messages prior to entering dormant mode, it seems
unnecessarily complicated. The mobile will then have to wait for acks
and if those fail, do retransmissions, etc. Seems more of a battery
power issue to do this every time it enters dormant mode than to say
that something must be refreshed every 8 hours or so. That too, note
that there is a problem only if the mobile happens to be in dormant mode
after 8 hours when the DPD kicks in. 

Keeping it simple seems to be sufficient - talking to some lower layer
folks, it seems to cost more to have to send a message prior to dormancy
periodically than even have to, say, redo IKEv2 every 8 hours. 

Vidya

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 24 Jul 2006 16:45:51 -0500

> on the responder dynamically. currently you are stuck with

Sure... But the point is that as long as you do not have an issue of MNs
having to transition from dormant to active to do a keep-alive then you do
not need anything else. If the static timer is set to a fairly large value
then the MN can go into dormant mode and stay in such for maybe several
hours even. So I think configurable timers are sufficient.

> a BU with a different lifetime.

True. But I don't think the two are analogous.

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Jul 2006 14:46:12 -0700

hi Vidya,

lets address Pasi's comments first. what you bring up
is a different issue.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 24 Jul 2006 16:46:09 -0500

Will do..

-Raj

On 7/24/06 3:45 PM, "ext James Kempf" <[email-masked]> wrote:

>> specific

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 24 Jul 2006 16:52:36 -0500

I agree with Vidya. There is not an explicit reason to change the timer just
before the MN decides that it is going to transition to dormant mode. The
concern here is primarily about battery usage and I think that as long as
the IKEv2 timer is configured to a fairly high value, it will not be an
issue.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 24 Jul 2006 16:58:54 -0500

On 7/24/06 4:49 PM, "ext Vijay Devarapalli"
<[email-masked]> wrote:

.
> they are. the lifetime for a binding cache entry at the HA
> can dynamically change based on signaling messages from the
> MN. the lifetime for IPsec SA state does not today because
> there is no message from the MN negotiating the lifetime.
> 

So in what instances would an MN update the binding lifetime at the HA? Do
you believe that an MN would do this on a random basis. Or more so when the
MN triggers some threshold associated with the lifetime.
The MN can send BUs to the HA and change the lifetime at any time. But I
don't think an MN would do this just because for example it is going into a
dormant mode. So what would be the benefit of having the ability to change
the IPsec SA lifetime on a dynamic basis? An MN does not really know as to
how long it is going to be dormant. So if the lifetime is configured to a
large enough value, that is good enough.

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Jul 2006 14:49:00 -0700

> hours even. So I think configurable timers are sufficient.

having a large DPD timer has its negatives. we don't want
to do that. its better if DPD is done more frequently.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 24 Jul 2006 15:36:51 -0700

<snip>

> > 
> > Sure... But the point is that as long as you do not have an 
> issue of 
> > MNs having to transition from dormant to active to do a keep-alive 
> > then you do not need anything else. If the static timer is set to a 
> > fairly large value then the MN can go into dormant mode and stay in 
> > such for maybe several hours even. So I think configurable 
> timers are sufficient.
> 
> having a large DPD timer has its negatives. we don't want to 
> do that. its better if DPD is done more frequently.
> 

Sure, it is a tradeoff. However, I still see this as a policy issue. 

> binding cache 
> >> lifetime can be changed at any time by sending a BU with a 
> different 
> >> lifetime.
> > 

When would you imagine the MN sending such messages to change the
lifetime? Sending these messages triggered by events such as dormant
mode have other significant problems. Also, what does it really mean
that an MN requested a certain lifetime in IKEv2? If the HA is short in
resources, it is going to purge that SA, period. Alternately, you can
have a policy to say that as long as the HA has resources, the lifetime
of the SA is fairly large. 

Vidya