Re: [IPsec] IPsec Digest, Vol 123, Issue 21

[Tero Kivinen <[e-mail]>]

Les Leposo writes:
> have you overlooked the issue of nat mappings?

Nope.

> ipsec nat keepalives are very useful for keeping nat mappings alive,
> and in a world full of all sorts of nat devices (some behaving
> reliably and others not), one would have to use low keepalive
> interval... like 10-60s. 

IPsec NAT-T keepalives are completely different thing than DPD.

IPsec NAT-T keepalives are packets sent by the device behind the NAT
as specified in the RFC3948 section 2.3. The responder SHOULD ignore
the received NAT-keepalive packet, and MUST NOT be used to detect
whether a connection is live (RFC 3948 section 4). Only device behind
the NAT sends them and other end does not respond to them, or send its
own keepalives (unless it is also behind NAT).

The dead peer detection (DPD) or liveness check is a procedure
specified in the RFC5996 section 2.4 where it says that:

	... If there has only been outgoing traffic on all of
   the SAs associated with an IKE SA, it is essential to confirm
   liveness of the other endpoint to avoid black holes.  If no
   cryptographically protected messages have been received on an IKE SA
   or any of its Child SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer.
   (This is sometimes called "dead peer detection" or "DPD", although it
   is really detecting live peers, not dead ones.)  Receipt of a fresh
   cryptographically protected message on an IKE SA or any of its Child
   SAs ensures liveness of the IKE SA and all of its Child SAs.

This is done by sending empty INFORMATIONAL message to the other end,
and if there is response to it then other end is up and running. You
are supposed to do this only when you suspect something is wrong, i.e.
the traffic changed to be one way (i.e. no packets coming back), or
you get ICMP or unauthenticated notify payload or similar.

> Now, today's client devices need to be energy efficient - so the
> device sleeps/hibernates to save battery. Sleeping past the nat
> keepalives is bound to happen (either by design or error). At some
> point the device will wake from sleep and need to test reachability
> using dpd.

Yes, if the device sleeps a long time, it should check whether the IKE
SA is still up by using DPD. This has nothing to do with the NAT
keepalives. 

> And in some cases (if the sleep was more than a certain threshold),
> rather than wait for dpd to failover, the choice is to go for rekey.

Rekey is not an option, as that would require the IKE SA to still be
up. I think you mean startting the IKE SA from the beginning. If the
device has been sleeping for long time, and it suspects the IKE SA is
gone, it might try shorter period for the DPD, i.e. send few retries
for the empty INFORMATIONAL message and if no response is received,
then fall back to start the IKE SA from the beginning.

The device of course needs to first wait that the network is up again
before doing this test, as when you wake up from the sleep, the device
most likely needs to find the wifi network again, do DHCP, perhaps
even do hotel login page etc before it can actually send any packets
to network, and doing DPD during that time, would certainly fail, even
when the other end would still be there. 

It is important to remember what are the fundamental restrictions set
by the protocol, and which issues are just caused by bad
implementations. Quite a lot of the problems we are seeing are caused
by bad implementations... 
-- 
[e-mail]