[strongSwan] Handling DPD outside of strongswan

[Tobias Brunner]

Hi Peter,

Your description of DPDs and the role strongSwan plays in this is a bit
confusing.  I assume you are referring to the Android/libipsec
implementation where strongSwan handles IKE as well as ESP (otherwise,
ESP is handled by the kernel, not strongSwan).

> Given that the normal traffic is used for DPD, and the empty DPD packets
> are only used when there is a lack of data traffic to inform the other
> end that the connection is still active,

It's more used to check if the peer is still responsive, not to inform
the peer.  They are sent if no message has been received from the peer
(IKE or ESP) in a certain time span.

> is it possible to run the DPD
> part of the protocol outside of strongswan and still work properly in
> conjunction with the normal traffic in strongswan?

What "DPD part of the protocol" are you referring to exactly?

> The DPD part of
> strongswan will be disabled

Then strongSwan doesn't care about the connection after it was
established until a rekeying is scheduled or a packet is received from
the peer.  But every packet sent (e.g. to rekey an SA) will act as DPD,
this can't be disabled.  DPD is actually already disabled in the Android
app.  Or are you maybe confusing this with NAT-T keep alives?  These are
also sent by the Android app to keep NAT mappings alive if there was no
outbound traffic (IKE or ESP) for a while.

> 1) Handling DPD received: Upon receiving a DPD, the software external to
> strongswan will send a DPD response.  Strongswan will ignore it.  Will
> this work, and will it still be conforming to the protocol standards?

What is that "DPD" you refer to and that's received outside of
strongSwan?  An IKE message?  An ESP message?  An encrypted ICMP
message?  If the latter two, how would the external application decrypt
the message without strongSwan (if it, in fact, handles ESP).  And how
to differentiate between "DPD"-ESP packets and actual traffic.  Also,
UDP is used in the Android app, so how would the external app share the
UDP socket (or would it use an AF_PACKET/RAW socket)?

> 2) Transmitting DPD: The software external to strongswan will
> periodically send a DPD for strongswan regardless of whether there is
> active traffic from strongswan.  

Basically same questions as above.

> In either case, the sequence numbers of packets between strongswan and
> the external software will likely be out of sync.

What sequence numbers are you referring to?

> Will this be ok
> still, and achieve the goal of keeping the connection alive?

Depends on what sequence numbers you refer to, whether replay protection
is disabled, how they would be learned and changed by the external
software, how/if keys are shared etc.

> The goal of this is to save power by putting strongswan to sleep when
> there is no active traffic.

As mentioned, DPD is already disabled in the Android app, partly to save
power.  But if the responder sends DPDs (actual IKE INFORMATIONAL
requests) these have to replied to (keys and IKE sequence numbers have
to be synced, otherwise the peer wouldn't accept the response, nor would
 strongSwan be able to handle other messages from the peer e.g. rekeyings).

Regards,
Tobias