[strongSwan] Handling DPD outside of strongswan

[Eduardo Mirahyes]

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