Subject: [Mobike] Zero Address Set

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 6 Dec 2004 10:16:18 +0100

hi all, 

i thought about the functionality of the "zero address set". one important
question is: what is this functionality good for? 

draft <draft-kivinen-mobike-protocol-00.txt> says:
"
seconds how long the peer assumes to be disconnected
"

pasi calls this functionality (in draft <draft-eronen-mobike-mopo-01.txt>):

"
 temporarily forwarding the traffic of some SA to /dev/null
"

draft <draft-ietf-mobike-design-00.txt> is more verbose on this issue:

"
   One of the features which might be useful would be for the peer to
   announce the other end that it will now disconnect for some time,
   i.e. it will not be reachable at all. For instance, a laptop might go
   to suspend mode. In this case the peer could send address
   notification with zero new addresses, which means that it will not
   have any valid addresses anymore. The responder of that kind of
   notification would then acknowledge that, and could then temporarily
   disable all SAs. If any of the SAs gets any packets they are simply
   dropped. This could also include some kind of ACK spoofing to keep
   the TCP/IP sessions alive (or simply set the TCP/IP keepalives and
   timeouts large enough not to cause problems), or it could simply be
   left to the applications, i.e. allow TCP/IP sessions to notice the
   link is broken.

   The local policy could then decide how long the peer would allow
   other peers to be disconnected, i.e. whether this is only allowed for
   few minutes, or do they allow users to disconnect Friday evening and
   reconnect Monday morning (consuming resources during weekend too, but
   on the other hand not more than is normally used during week days,
   but we do not need lots of extra resources on the Monday morning to
   support all those people connecting back to network).
"

i see this issue from a different point of view.
we have a dead peer detection to provide a mechanism to delete the ike sa
(and ipsec sas) if the other does not respond anymore. 

if a laptop has establish an ike sa with a gateway, uses dead peer detection
and goes into the suspend mode then (even after a short amount of time) the
ike sa will be gone. 

the 'zero address set' functionality could possibly be seen as temporarily
suspending the dead peer protection on a specific address (or path). 

is this totally bogus? 

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 06 Dec 2004 11:56:56 -0500

> question is: what is this functionality good for? 

temporary tunnel suspension when the endpoint knows it will be unreachable  for a while.

> (and ipsec sas) if the other does not respond anymore. 

well, let's distinguish two cases:
 1) we haven't heard from the peer in a while.
 2) the peer has crashed and forgot about the connection

For some applications, tearing down state because of (1) may rightly viewed  as a bug, not a feature -- but you may want fast recovery from (2) without 
tearing down connections merely because of inactivity.

> suspending the dead peer protection on a specific address (or path). 

Sorta.

						- Bill

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 6 Dec 2004 10:48:36 -0800

Bill,

> temporary tunnel suspension when the endpoint knows it will be unreachable  for a while.
Ok. I can see some use for it. But is zero address set alone sufficient or you also
need to tell the other end how long you are not reachable ?  Your peer may not
want to keep the inactive SAs open for a long time. If you don't specify the time, your
peer will delete it anyway after some time. Even if you specify the time, your peer will delete
it anyway based on its local configuration (assuming we are not negotiating it). If you don't
know how long the SAs will be kept around by your peer, would it still be useful ?

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2004 23:00:24 +0200

I guess the key question here is whether there's
enough "bang for the buck" in this function for it
to be included in MOBIKE. Earlier we didn't see that
many people interested, but now we have some. In any
case, we need to consider the following:

- The benefit this feature offers is about "being
   a good citizen" (as you Bill put it) and not send
   unnecessary packets when we know the other end
   is down. Nevertheless, this is not a functional
   benefit in the sense that nothing breaks if we
   don't have it; just that extra packets are sent.

- We know we can not use this feature in all cases
   when the other end is down. We don't always know
   we are going outside coverage.

- We know there's some practical limits to how long
   this condition can be held and still be considered
   useful, such as applications on top starting to
   get timeouts.

- There may be some additional complexity for MOBIKE.
   For instance, assume A and B are talking to each other
   and that A now informs B that its offline. Now,
   normally in MOBIKE if B moves it can tell A immediately.
   But if zero-address set is supported then B must
   be able to queue this notification. And if all of
   B's addresses got changed, the situation is not
   recoverable.

--Jari