<span style="font-family: Arial; font-size: 14px; line-height: 150%;"><b><font color="#ff0000">Unsubscribe remove from mail overwhelming</font></b><br><br>On 11/5/2018 at 9:47 PM, "Tobias Brunner" <tobias@strongswan.org> wrote:<blockquote style="border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;">Hi Peter,<br><br>Your description of DPDs and the role strongSwan plays in this is a bit<br>confusing.  I assume you are referring to the Android/libipsec<br>implementation where strongSwan handles IKE as well as ESP (otherwise,<br>ESP is handled by the kernel, not strongSwan).<br><br>> Given that the normal traffic is used for DPD, and the empty DPD packets<br>> are only used when there is a lack of data traffic to inform the other<br>> end that the connection is still active,<br><br>It's more used to check if the peer is still responsive, not to inform<br>the peer.  They are sent if no message has been received from the peer<br>(IKE or ESP) in a certain time span.<br><br>> is it possible to run the DPD<br>> part of the protocol outside of strongswan and still work properly in<br>> conjunction with the normal traffic in strongswan?<br><br>What "DPD part of the protocol" are you referring to exactly?<br><br>> The DPD part of<br>> strongswan will be disabled<br><br>Then strongSwan doesn't care about the connection after it was<br>established until a rekeying is scheduled or a packet is received from<br>the peer.  But every packet sent (e.g. to rekey an SA) will act as DPD,<br>this can't be disabled.  DPD is actually already disabled in the Android<br>app.  Or are you maybe confusing this with NAT-T keep alives?  These are<br>also sent by the Android app to keep NAT mappings alive if there was no<br>outbound traffic (IKE or ESP) for a while.<br><br>> 1) Handling DPD received: Upon receiving a DPD, the software external to<br>> strongswan will send a DPD response.  Strongswan will ignore it.  Will<br>> this work, and will it still be conforming to the protocol standards?<br><br>What is that "DPD" you refer to and that's received outside of<br>strongSwan?  An IKE message?  An ESP message?  An encrypted ICMP<br>message?  If the latter two, how would the external application decrypt<br>the message without strongSwan (if it, in fact, handles ESP).  And how<br>to differentiate between "DPD"-ESP packets and actual traffic.  Also,<br>UDP is used in the Android app, so how would the external app share the<br>UDP socket (or would it use an AF_PACKET/RAW socket)?<br><br>> 2) Transmitting DPD: The software external to strongswan will<br>> periodically send a DPD for strongswan regardless of whether there is<br>> active traffic from strongswan.  <br><br>Basically same questions as above.<br><br>> In either case, the sequence numbers of packets between strongswan and<br>> the external software will likely be out of sync.<br><br>What sequence numbers are you referring to?<br><br>> Will this be ok<br>> still, and achieve the goal of keeping the connection alive?<br><br>Depends on what sequence numbers you refer to, whether replay protection<br>is disabled, how they would be learned and changed by the external<br>software, how/if keys are shared etc.<br><br>> The goal of this is to save power by putting strongswan to sleep when<br>> there is no active traffic.<br><br>As mentioned, DPD is already disabled in the Android app, partly to save<br>power.  But if the responder sends DPDs (actual IKE INFORMATIONAL<br>requests) these have to replied to (keys and IKE sequence numbers have<br>to be synced, otherwise the peer wouldn't accept the response, nor would<br> strongSwan be able to handle other messages from the peer e.g. rekeyings).<br><br>Regards,<br>Tobias</blockquote></span>