State management in HIP. Does HIPL remove inactive peers and how does it determine that a peer is inactive?

A host inactivity can be detected by several means. I'll describe them below and try to identify current status and key issues:

1. Host does not send any ESP traffic.
* Standards compliant.
* Unimplemented
* Could be implemented in two ways: firewall assisted inspection or IPsec SA timeouts (see id #592115).
* Probably the IPsec SA timeouts are a better way because it does not assume firewall presence. However, this would still require retry with UPDATE before giving up.

2. Echo requests are not being replied.
* Standards compliant.
* Unimplemented (UPDATEs are just used for handovers).
* Used also by the native NAT traversal draft to check for connectivity.

3. ICMPv6 echo responses inside the tunnel fail to arrive.
* Implemented and quite robust. The default behaviour at the moment.
* Not *mandated* by the *HIP* RFCs (we could refer to some IPv6 RFCs). Implemented also by hip for inter.net.
* Not suitable for keepalives for NATs with registration servers (rvs, relay) because they don't necessarily create data channel (in practive, I guess all of the implementations create the data channel anyways).
* A solid way to detect problems with the data channel because it actually tests connectivity inside the tunnel. Also, does not require any special HIP-related processing at the peer as long as it is not filtering ICMPv6 out.
* Does not purge HADB state, just keeps trying to send UPDATEs. Adding a max tries variable would be trivial in the maintenance loop.

>When will HIP remove peers from the hadb in the following states:
>ESTABLISHED

At the moment, it doesn't unless the peer e.g. reboots and sends an I1.

>R2_SENT

Hipd is not inspecting ESP packets because the firewall is an optional component. So, R2_SENT transitions immediately to ESTABLISHED.

The problem is that the states ESTABLISHED and R2_SENT have different handling of I2 messages.

In ESTABLISHED, an R2 is sent AND existing associations will be dropped and new ones will be created while in R2_SENT, only the previous R2 is retransmitted.

Hence, when moving directly to ESTABLISHED, retransmitted I2s (because of lost R2s) might cause a tear-down of the freshly established SAs (etc.). RFC5201 offers a workaround for this based on timers.

Now my question is:

a) What happens in HIPL when the responder receives a retransmitted I2 when it already moved to state ESTABLISHED.
and
b) if the answer to a) is that it tears down/changes/interrupts the SAs or other relevant information - wouldn't it make sense to implement state R2-sent and use the timer-based approach?

Answer to question (a) is that HIPL drops existing SAs and sends a new R2. The answer to question (b) is probably "yes" (*).

We could actually switch from R2_SENT to ESTABLISHED when receiving ICMPv6 keepalives in hipd, but since this feature is not mandated by RFC5201, it would be just an optimization.

(*) Criticism for the timer-based approach: why can't the Initiator check if the SPI number in R2 has changed?