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

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Aug 2006 01:13:07 +0300

Hi Francis, and thanks for this note. Inline:

>I've not so arbitrary pick up one of the messages to answer...
>
>IMHO there are three issues to address: DPD, SA lifetimes, BCE.
>
>About Dead Peer Detection, RFC 4306 is very flexible. I believe there is
>no reason in this case to have each peer polling the other, i.e., one sends
>polls and says its peer is dead when it doesn't receive a small number of
>acks in a row, the other says its peer is dead when it doesn't receive a
>small (perhaps a bit larger) number of polls in a row.
>We have already in practice the HA in a passive mode, i.e., it is *never*
>the IKE initiator. To make the MN the active polling side and the HA the
>passive one seems the right way to go (but I'll come back about DPD).
>
>Security Association lifetimes: IKEv1 can negociate them but this is a
>major operational issue to get this right. IKEv2 relies on the config
>so the idea should be to have a good config. BTW at least the IKE SA
>lifetime should be in the PAD so there is no issue to put a large value
>(i.e., almost infinite) on a HA for MNs but not for other HAs.
>Again we need only rekeys initiated by one side, of course this side
>should be the MN, i.e., HAs should use almost infinite lifetimes.
>
>What is the real limit? The only thing which really requires a rekey
>is the sequence number exhaution but smaller sequence numbers are on
>32 bits: I can't see an issue for low traffic SAs, i.e., the IKE SA,
>the BU/BA transport SA, the HOTI/HOT SA, etc. The only problem can
>be with a payload SA when the MN should actively rekey in time, so
>IMHO the only case we can be in trouble (but in fact independtly of IPsec)
>is a dormant node receiving a lot of protected traffic...
>  
>
I agree with all of the above.

>BCE: even very unreasonable BCE lifetimes are a bit small (a few days,
>16 bit value in 4 second unit). If we add something IMHO this is the first
>place as the MIPv6 code can really take benefit to know the node is dormant.
>
>Come back to DPD: a passive DPD should have a good way to distinguish
>between a dormant and a dead node so I propose to add a new "private
>status" notification in DPD poll with in the data the delay to the next
>poll in second. So the passive DPD code becomes very easy to implement,
>and a MN going to the dormant node has only to send a poll with a large
>delay and wait for the ack. BTW this needs only a document, and an
>experimental RFC if we prefer a "IANA status" type.
>  
>
The key question is why we are doing the periodic traffic to
begin with. In some cases, like the NAT keepalive, we have
to do it. New protocol mechanisms wouldn't change that,
nor does the dormant status of the node.

Detecting a dead node is another reason. But in this application
it will not change the fact that packets will be dropped on the
floor. The packets are dropped both when the home agent knows
the mobile node is no longer there, and when it doesn't know.
The home agent may be able to send better ICMPs to the other side
or generate more accurate accounting records, however, but
I wonder if this is worth the extra effort.

In any case, it seems to me that most of this issue relates
to finding the right configuration parameters to suit this
particular application. If someone wants to write a document
explaining how to best configure the different protocol layers
so that battery usage and network traffic is minimized, this
would be welcome. But lets not jump into designing new protocol
mechanisms until we have documented how the current
ones should be used to avoid (most/all) of the problems.

And the dormant mode problem is not specific to Mobile IPv6
or even mobility; wireless nodes that do not move can have
exactly the same issue. This suggests a general solution
rather than a Mobile IPv6 specific one. (And I think you
were implying a general solution, for all IPsec use.)

--Jari

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