Hi Abhinav
Hope you are doing good
Below is the explanation of DPD and Keepalive, As per RFC 3706
Keepalives:
Consider a keepalives scheme in which peer A and peer B require
regular acknowledgements of each other's liveliness. The messages
are exchanged by means of an authenticated notify payload. The two
peers must agree upon the interval at which keepalives are sent,
meaning that some negotiation is required during Phase 1. For any
prompt failover to be possible, the keepalives must also be sent at
rather frequent intervals -- around 10 seconds or so. In this
hypothetical keepalives scenario, peers A and B agree to exchange
keepalives every 10 seconds. Essentially, every 10 seconds, one peer
must send a HELLO to the other. This HELLO serves as proof of
liveliness for the sending entity. In turn, the other peer must
acknowledge each keepalive HELLO. If the 10 seconds elapse, and one
side has not received a HELLO, it will send the HELLO message itself,
using the peer's ACK as proof of liveliness. Receipt of either a
HELLO or ACK causes an entity's keepalive timer to reset. Failure to
receive an ACK in a certain period of time signals an error. A
clarification is presented below:
Scenario 1:
Peer A's 10-second timer elapses first, and it sends a HELLO to B.
B responds with an ACK.
Peer A: Peer B:
10 second timer fires; ------>
wants to know that B is alive;
sends HELLO.
Receives HELLO; acknowledges
A's liveliness;
<------ resets keepalive timer, sends
ACK.
Receives ACK as proof of
B's liveliness; resets timer.
Scenario 2:
Peer A's 10-second timer elapses first, and it sends a HELLO to B.
B fails to respond. A can retransmit, in case its initial HELLO is
lost. This situation describes how peer A detects its peer is dead.
Peer A: Peer B (dead):
10 second timer fires; ------X
wants to know that B is
alive; sends HELLO.
Retransmission timer ------X
expires; initial message
could have been lost in
transit; A increments
error counter and
sends another HELLO.
---
After some number of errors, A assumes B is dead; deletes SAs and
possibly initiates failover.
An advantage of this scheme is that the party interested in the other
peer's liveliness begins the message exchange. In Scenario 1, peer A
is interested in peer B's liveliness, and peer A consequently sends
the HELLO. It is conceivable in such a scheme that peer B would
never be interested in peer A's liveliness. In such a case, the onus
would always lie on peer A to initiate the exchange.
DPD Protocol
DPD addresses the shortcomings of IKE keepalives- and heartbeats-
schemes by introducing a more reasonable logic governing message
exchange. Essentially, keepalives and heartbeats mandate exchange of
HELLOs at regular intervals. By contrast, with DPD, each peer's DPD
state is largely independent of the other's. A peer is free to
request proof of liveliness when it needs it -- not at mandated
intervals. This asynchronous property of DPD exchanges allows fewer
messages to be sent, and this is how DPD achieves greater
scalability.
As an elaboration, consider two DPD peers A and B. If there is
ongoing valid IPSec traffic between the two, there is little need for
proof of liveliness. The IPSec traffic itself serves as the proof of
liveliness. If, on the other hand, a period of time lapses during
which no packet exchange occurs, the liveliness of each peer is
questionable. Knowledge of the peer's liveliness, however, is only
urgently necessary if there is traffic to be sent. For example, if
peer A has some IPSec packets to send after the period of idleness,
it will need to know if peer B is still alive. At this point, peer A
can initiate the DPD exchange.
To this end, each peer may have different requirements for detecting
proof of liveliness. Peer A, for example, may require rapid
failover, whereas peer B's requirements for resource cleanup are less
urgent. In DPD, each peer can define its own "worry metric" - an
interval that defines the urgency of the DPD exchange. Continuing the
example, peer A might define its DPD interval to be 10 seconds.
Then, if peer A sends outbound IPSec traffic, but fails to receive
any inbound traffic for 10 seconds, it can initiate a DPD exchange
Peer B, on the other hand, defines its less urgent DPD interval to be
5 minutes. If the IPSec session is idle for 5 minutes, peer B can
initiate a DPD exchange the next time it sends IPSec packets to A.
It is important to note that the decision about when to initiate a
DPD exchange is implementation specific. An implementation might
even define the DPD messages to be at regular intervals following
idle periods.
PFS (Perfect Forward Secrecy)
PFS provides one more level of security in phase 2. After the exchange of public keys between both the peers in message 3 and 4 , Both sides calculates three keys for encryption and authentication of the data.But if PFS is supported by both the peers, they will be forced to calculate the same keys again in phase 2 just to make sure that data is not compromised.
Let me know if you have any other queries
Regards
Ashish
