DPD and Keepalive??

abhi-adte — Mon, 11 Mar 2019 19:30:30 GMT

Hi Friends,

I am confused between DPD and Keepalive??

How is working of PFS?

Please help to share..

Re: DPD and Keepalive??

padatta — Wed, 05 Jan 2011 13:12:45 GMT

Hi Abhinay,

PFS = Perfect forward secrecy

PFS enables generation of new D-H keys when SA is periodically re-negotiated. PFS also ensures that the newly derived keys is unrelated to previously obtained keys.

DPD = Dead peer detection.

DPD enables the device to periodically poll the reachability of it's peer.

Keepalives help in keeping the tunnel up during times of inactivity.

HTH

Paps

Re: DPD and Keepalive??

ajhaldiy — Wed, 05 Jan 2011 13:14:19 GMT

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

topic Re: DPD and Keepalive?? in Network Security

DPD and Keepalive??

Re: DPD and Keepalive??

Re: DPD and Keepalive??