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

Asked by Tobias Heer

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

How does HIPL figure out that a host is inactive?

Question information

English Edit question
HIPL Edit question
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Miika Komu (miika-iki) said :

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
* 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.

Revision history for this message
Miika Komu (miika-iki) said :

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

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


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

Revision history for this message
Tobias Heer (heer) said :

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.
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?

Revision history for this message
Miika Komu (miika-iki) said :

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?

Can you help with this problem?

Provide an answer of your own, or ask Tobias Heer for more information if necessary.

To post a message you must log in.