Subject: [Mobike] Dormant Mode?

From: "James Kempf" <[email-masked]>
Date: Wed, 24 Aug 2005 09:33:49 -0700

So I'd like to raise a possible issue here, namely whether or not Mobike 
should attempt to support dormant mode hosts. I say that it's a "possible" 
issue because, in general, most IETF protocols don't do a very good job 
supporting dormant mode, and it would be entirely consistent to say that 
Mobike doesn't either. But I think the point should at least be raised.

Section 2.4 of draft-ietf-ipsec-ikev2-17.txt (IKEv2 spec) has some guidance 
about connection timers, but there is nothing specific about recommended 
values for timeouts or retransmissions, since, as the document correctly 
notes, this will vary depending on circumstance. Since some mobile hosts can 
actually spend more time in dormant mode than active, for power saving 
purposes, there's a possibility that the IKE SAs will need to be regenerated 
from scratch every time the mobile host comes out of dormant mode, if the 
timeouts are set too short. In addition, if there are any stateful 
middleboxes (proxies, firewalls), the state on them could expire 
prematurely, causing a request incoming through the VPN tunnel gateway to be 
rejected even though the VPN tunnel gateway itself didn't time out the SA.

The basic issue I think that needs addressing is: should Mobike attempt in 
some way to address dormant mode, since, like address changes, it is a 
characteristic of mobile hosts?

Thoughts?

            jak 

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Aug 2005 20:13:48 +0300

Good question.

I think we made a decision earlier on that we will not support
what we called "zero address set" mode, where the client notifies
the other end that its temporarily unreachable. I'd rather not
reopen that discussion.

However, this is not the same as providing a protocol that
is suitable even to peers going dormant. For instance, it might
be an idea to provide specification guidance or even some
informational data over the protocol about the characteristics
of the peer at the other end. This could also be done
as an orthogonal function to the base MOBIKE protocol
exchange.

(Also, we'd probably want to stay away from re-introducing
lifetimes that were removed when going from IKEv1 to IKEv2.)

--Jari

James Kempf wrote:

> So I'd like to raise a possible issue here, namely whether or not 
> Mobike should attempt to support dormant mode hosts. I say that it's a 
> "possible" issue because, in general, most IETF protocols don't do a 
> very good job supporting dormant mode, and it would be entirely 
> consistent to say that Mobike doesn't either. But I think the point 
> should at least be raised.
>
> Section 2.4 of draft-ietf-ipsec-ikev2-17.txt (IKEv2 spec) has some 
> guidance about connection timers, but there is nothing specific about 
> recommended values for timeouts or retransmissions, since, as the 
> document correctly notes, this will vary depending on circumstance. 
> Since some mobile hosts can actually spend more time in dormant mode 
> than active, for power saving purposes, there's a possibility that the 
> IKE SAs will need to be regenerated from scratch every time the mobile 
> host comes out of dormant mode, if the timeouts are set too short. In 
> addition, if there are any stateful middleboxes (proxies, firewalls), 
> the state on them could expire prematurely, causing a request incoming 
> through the VPN tunnel gateway to be rejected even though the VPN 
> tunnel gateway itself didn't time out the SA.
>
> The basic issue I think that needs addressing is: should Mobike 
> attempt in some way to address dormant mode, since, like address 
> changes, it is a characteristic of mobile hosts?
>
> Thoughts?
>
>            jak
>

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 24 Aug 2005 13:17:34 -0400

> Mobike doesn't either. But I think the point should at least be raised.

What, specifically, do you mean by "dormant"?  (I hope we get a generic
definition which covers both the "phone" space and the "laptop" space,
which appear to do power management very differently...)

This could be conceptually similar to/related to the "no active
addresses" mode we discussed early in the life of the WG.  I liked it
but it didn't get much traction at the time for reasons I didn't fully
understand.

					- Bill

---

From: "James Kempf" <[email-masked]>
Date: Wed, 24 Aug 2005 10:29:22 -0700

> which appear to do power management very differently...)

I think for purposes of Mobike, dormant mode could be defined as the mobile 
host will not be originating any packets for some period of time, including 
responses to IKEv2 probes, in order to preserve power but is still reachable 
at one of the addresses should any packets be incoming. Gratiutious packets 
should therefore be avoided.

> but it didn't get much traction at the time for reasons I didn't fully

No, I don't think "no active addresses" would properly characterize it. The 
host is still prepared to take incoming packets at one of the addresses its 
got (like for example an incoming phone call).

A deeper mode might be "no active addresses", in which the host either is 
turned off for the night, or isn't prepared to take any incoming packets, 
for even more power saving.

I think this behavior spans phones and laptops, the difference between the 
two is what happens to packets that come while the mobile host is in dormant 
mode. With laptops (802.11), the AP buffers them then delivers them when the 
laptop periodically wakes up and polls. With phones, the RNC gets on the 
paging channel and pages the mobile, then delivers the packets when the 
mobile wakes up and re-connects.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Aug 2005 20:40:15 +0300

James Kempf wrote:

> No, I don't think "no active addresses" would properly characterize 
> it. The host is still prepared to take incoming packets at one of the 
> addresses its got (like for example an incoming phone call).
>
> A deeper mode might be "no active addresses", in which the host either 
> is turned off for the night, or isn't prepared to take any incoming 
> packets, for even more power saving.
>
> I think this behavior spans phones and laptops, the difference between 
> the two is what happens to packets that come while the mobile host is 
> in dormant mode. With laptops (802.11), the AP buffers them then 
> delivers them when the laptop periodically wakes up and polls. With 
> phones, the RNC gets on the paging channel and pages the mobile, then 
> delivers the packets when the mobile wakes up and re-connects.

Or informs the device on a signaling channel, forcing the device
to wake up.

In any case, its useful to avoid extra packets over wireless. NAT
traversal and its keepalives are btw probably a big contributor
here. Some of us have talked about adaptive keepalive behaviours,
but I'm not sure yet if that is technically possible.

--Jari

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 24 Aug 2005 14:59:58 -0400

> should therefore be avoided.

my (somewhat dated, and admittedly limited) experience with demand-dial
ppp connections leads me to believe that the definition of "gratuitous"
is often highly user-specific and/or application-specific; if we go down
this path, will we end up with nodes exchanging specially-marked
selector sets describing the equivalent of the pppd "active-filter"?

> for even more power saving.

ok, that's what I thought you meant by "dormant" earlier.

In any event, if we create an operating mode in which NAT keepalives are
no longer sent, then that will, IMHO, be more-or-less equivalent to a
no-address-mode scheme --- if you suspend NAT keepalives for longer than
the NAT's idle-session-destruction timer, you'll essentially lose
incoming connectivity to the side which is behind that NAT it reasserts
its presence.

					- Bill

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Aug 2005 22:09:06 +0300

>incoming connectivity to the side which is behind that NAT it reasserts
I'd prefer not to do this. But there may be a way to do
this without losing connectivity. Say, you open up another
UDP-level "connection" through the same pair of addresses,
and start increasing keepalive on that connection; when you
see a port/address change you record the last working keepalive
interval and use half of that as your regular IKE keepalive.
This scheme has a number of drawbacks, including the
assumption that NAT keepalive periods are static and that
it would have to be rerun every time you move. Perhaps
some of the other communities that have a need for NAT
traversal capability have found better solutions. Anyone?

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Aug 2005 11:29:52 -0700

Jari,

> traversal capability have found better solutions. Anyone?

This sounds like an acceptable way to estimate the NAT timeout, but I think 
it should probably be incorporated into STUN or something like that. It 
would be far better if the host could just ask the NAT what its timeout is, 
but we're not there yet.

It won't solve the problem of dormant mode hosts, though. If the keepalive 
originates at the VPN gateway, it will wake the host up. It has to somehow 
originate on the host side.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Aug 2005 11:36:23 -0700

> selector sets describing the equivalent of the pppd "active-filter"?

Well, some kind of filter is a possibility, but I don't think it is 
necessary. The basic requirement, for any kind of Mobike support, is that 
the VPN gateway SA timeout is extended, on host request when it is about to 
go into dormant mode, so that the host isn't getting frequent keepalives.

> incoming connectivity to the side which is behind that NAT it reasserts

I don't see any way to fix the problem with NAT keepalives from the VPN 
side, because any keepalive sent to an address owned by the host will get 
delivered, thus waking it up, which is what you want to avoid. But I think 
it could help in a nonNAT situation.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 22:17:19 +0300

James Kempf wrote:

>
> This sounds like an acceptable way to estimate the NAT timeout, but I 
> think it should probably be incorporated into STUN or something like 
> that. 

Probably.

> It would be far better if the host could just ask the NAT what its 
> timeout is, but we're not there yet.

Yes.

> It won't solve the problem of dormant mode hosts, though. If the 
> keepalive originates at the VPN gateway, it will wake the host up. It 
> has to somehow originate on the host side.

Ah, but surely any improvement in the keepalive processing should ensure
that both peers employ the same timeouts.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Aug 2005 13:23:50 -0700

>> keepalive originates at the VPN gateway, it will wake the host up. It has 
>> to somehow originate on the host side.
>

Right. If they both sync with the NAT timeout, then it doesn't matter. I 
guess the real problem is that the host can't influence the NAT timeout. If 
it's set too short, then the host will have to wake up - or get woken up - 
to keep the NAT and SA state hot. Sigh.

I suppose at this point one must throw up one's hands and say "its up to the 
network operator to configure their NAT timeouts so that dormant mode hosts 
don't need to wake up excessively".

            jak