[strongSwan] Handling DPD outside of strongswan

Eduardo Mirahyes em at ebear.co
Mon Feb 18 11:00:58 CET 2019

Unsubscribe remove from mail overwhelming

On 11/5/2018 at 9:47 PM, "Tobias Brunner"  wrote:Hi Peter,

Your description of DPDs and the role strongSwan plays in this is a
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
> are only used when there is a lack of data traffic to inform the
> 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
> 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
this can't be disabled.  DPD is actually already disabled in the
app.  Or are you maybe confusing this with NAT-T keep alives?  These
also sent by the Android app to keep NAT mappings alive if there was
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. 
> this work, and will it still be conforming to the protocol

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
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
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
> active traffic from strongswan.  

Basically same questions as above.

> In either case, the sequence numbers of packets between strongswan
> 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
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
> there is no active traffic.

As mentioned, DPD is already disabled in the Android app, partly to
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
 strongSwan be able to handle other messages from the peer e.g.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190218/f635df70/attachment.html>

More information about the Users mailing list