Re: New Charter Item:Support for Dormant Mode Alert to HA?

Hi Francis and all.

First of all, i think the dormant mode is useful in some scenario.

And, I agree with Francis here. The experimental RFC sounds reasonable.
This is easiest way to achieve the dormant mode on MN, IMO.

BTW, we should not define new method to lengthen the BC lifetime, other
than BU.
It is hard to predict how much time MN needs for the dormant mode.
Re-sending BU or freezing lifetime value is better.

regards,
ryuji

Francis Dupont wrote:
> 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...
>
> 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.
>
> Regards
>
> Francis.Dupont@xxxxxxxxxx
>
> PS: about RFC 4285, the whole story was laziness vs. security
> (or if you prefer cost vs. security)...
>
> _______________________________________________
> Mip6 mailing list
> Mip6@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/mip6
>
>