Sie sind auf Seite 1von 6

DPD

Dead Peer Detection


Introducción

Cuando dos peers se comunican con IKE [1] e IPSec [2], puede ocurrir que la
conectividad entre los dos se cae de forma inesperada. Esta situación puede
producirse a causa de problemas de enrutamiento, un reinicio del peer, etc, y en
tales casos, a menudo no hay manera que IKE y IPSec puedan identificar la pérdida
de la conectividad entre dichos pares. En este escenario de fallo, los SA puede
permanecer hasta que expire su vida, lo que resulta en un "agujero negro",
situación en la que los paquetes son un enviados por el túnel hacia “la nada”. A
menudo es deseable reconocer estos “agujeros negros”, tan pronto posible, para
que un router pueda conmutar el trafico encriptado a un peer diferente
rápidamente. Del mismo modo, es necesario para estos problemas para acelerar la
recuperación de los recursos de red.

Este problema de la detección de un peers IKE “muertos” ha sido abordado por propuestas que
requieren el envío periódico de mensajes HELLO/ACK para probar el estado del túnel. Este sistema de
comprobación del estado del túnel pueden ser unidireccionales (sólo se envían HELLO) o bidireccionales
(en envían HELLO y se responden estos Hello con ACK). A los efectos de documento (redactado en
base al DRAFT de IETF), el término "Heartbeat" se refiere a un mensaje unidireccional y el término
"Keepalive" se referirán a un mensaje bidireccional.

Keepalives

Los dos peers deben estar de acuerdo en el intervalo en el que se envían los keepalives, esto significa
que algún tipo de negociación se requiere durante la Fase 1.

Para que cualquier conmutación de túneles, por algún fallo entre los peers, sea posible, los keepalives
deben ser enviados a intervalos bastante frecuentes - alrededor de 10 segundos o menos.

En este hipotético escenario de keepalives, los pares A y B acuerdan intercambiar keepalives cada 10
segundos. Esencialmente, cada 10 segundos, un peer debe enviar un HELLO al otro. Este HELLO sirve
como prueba “de vida” de la entidad de origen. A su vez, el otro peer debe reconocer cada HELLO con
un ACK. Si transcurre el lapso de 10 segundos, y uno de los peers no ha recibido un HELLO, enviará su
propio mensaje HELLO, usando el ACK del peer como prueba de la vitalidad. La recepción de ya sea un
HELLO o un ACK causa que se reinicie el temporizador de keepalives.

Si no se recibe un ACK en un periodo de tiempo determinado, esto puede estar indicando un escenario
de fallo.
Veamos algunos ejemplos, a continuación:

Escenario 1:

El Peer A tiene un contador de tiempo de 10 segundos (keepalive cada 10 segundos) que finaliza antes
que el contador del peer B. Por lo que A, envía un HELLO a B en primer lugar y B responde con un ACK.

Peer A: Peer B:
El timer de 10 segundos expira;
Quiere saber si B está vivo, envía un
HELLO. 
Recibe el HELLO, por lo que verifica el
estado de A  envía un ACK y reinicia el
timer de keepalives
Recibe el ACK de B lo cual prueba el
Estado de B y reinicia el timer de
keepalives

Escenario 2:

El Peer A tiene un contador de tiempo de 10 segundos (keepalive cada 10 segundos) que finaliza antes
que el contador del peer B. B no responde. A puede retransmitir, en el caso de que su HELLO inicial se
ha perdido. Esta situación se describe cómo el peer A detecta que su par B está muerto.

Peer A: Peer B:
El timer de 10 segundos expira; X
Quiere saber si B está vivo, envía un
HELLO. 
El timer de retrasmisión expira, el mensaje inicial X
podría haberse perdido en tránsito hacia B.
A incrementa el contador de error y envía otro
HELLO

Después de algunas retrasmisiones sin tener estas éxito A asume que B está muerto, borra las SA y
inicia el método de failover configurado (en caso de que este exista).

Protocolo DPD

DPD aborda las deficiencias en cuanto a la ausencia de keepalives en IKE mediante la introducción de
un sistema que está basado en intercambios de mensajes.
Con DPD, cada peer es en gran medida independiente de los demás. Un peer es libre de solicitar una
prueba de vitalidad cuando lo necesite. Esta propiedad de los intercambios asincrónicos de DPD permite
que se envíen menos mensajes, y es así como consigue una mayor escalabilidad.
Por ejemplo, consideremos dos peers DPD A y B. Si hay tráfico IPSec entre los dos, no existe la
necesidad de obtener una prueba de vitalidad. El tráfico de IPSec en sí, sirve como prueba de la
vitalidad. Si, por otra parte, existe un período de tiempo durante el cual no se produce el intercambio de
paquetes, la vitalidad de cada peer es cuestionable.

El conocimiento de la vivacidad del peer, sin embargo, es sólo urgente y necesario si hay tráfico para ser
enviado. Por ejemplo, si A tiene paquetes IPSec para enviar a su peer (B) después del período de
inactividad, necesitara saber si el peer B todavía está vivo. En este punto, A puede iniciar el intercambio
de DPD’s con B.

Con este fin, cada uno de los compañeros puede tener requisitos diferentes para la detección de la vida
de su peer. Peer A, por ejemplo, puede requerir una rápida de conmutación peer en una situación de
fallo, mientras que los requisitos del peer B los requerimientos para la limpieza de los recursos se menos
urgente. En el DPD, cada uno de los peers puede definir su propia "métrica de preocupación" -- un
intervalo que define la urgencia del intercambio de DPD.
Continuando con el ejemplo, Peer A podría definir su intervalo de DPD para 10 segundos. Entonces, si el
peer A envía tráfico IPSec de salida, pero no a recibir el tráfico de entrada por 10 segundos, puede iniciar
un intercambio de DPD con B.
El peer B, por otra parte, define su intervalo de DPD menos urgente, a 5 minutos. Si la sesión de IPSec
está inactiva durante 5 minutos, peer B puede iniciar un intercambio de DPD la próxima vez que envíe
paquetes de IPSec para A.

Es importante señalar que la decisión sobre cuándo iniciar un intercambio de DPD es específica de cada
implementación que se haga (generalmente varía en cada fabricante). Una implementación podría
incluso, definir los mensajes DPD para ser enviados a intervalos regulares, después de períodos de
inactividad.

Intercambio de Mensajes DPD

El intercambio de mensajes DPD es bidireccional (HELLO/ACK)

Sender Responder

HDR, NOTIFY (R-U-THERE), Hash 

 HDR, NOTIFY(R-U-THERES-ACK), HASH

EL mensaje R-U-THERE se corresponde con un HELLO y el R-U-THERE-ACK se corresponde con el


ACK.
DPD en equipos Cisco

La funcionalidad de DPD está presente en los VPN 3000, los ASA, en los clientes VPN
Cisco y en el IOS desde las versiones: 12.3(7)T , 12.2(33)SRA y 12.2(33)SXH.

DPD funciona de varias maneras, la más “rápida” es la funcionalidad de Periodic,


pero consume recursos, cuando los peers de IKE sean demasiados, lo más
aconsejable es usar la opción On-Demand. Ambos métodos serán explicados más
adelante.

Como funciona la funcionalidad de keepalives DPD, implementada


en el IOS

DPD funciona en base a timers.

La ventaja de utilizar los mensajes DPD periódicamente (Periodic), es


fundamentalmente, detectar de manera rápida y dinámica, la caída de los peers
“muertos”. De esta manera se “fuerza” al router a enviar los mensajes DPD a
intervalos regulares, exista o no exista trafico que transmitir.

Con la opción On-Demand, los mensajes DPD son enviados de acuerdo al patrón del
tráfico enviado por el túnel. Por ejemplo, si un router tiene trafico que enviar a su
peer y no conoce el estado del túnel, lo que hace es enviar un mensaje DPD al peer,
realizando un query, verificando de este modo el estado del túnel. Si el router no
tiene trafico que enviar, nunca enviara un mensaje DPD a su peer.

Si quieres configurar la opción de enviar mensajes DPD de forma periódica el


comando a utilizar es

crypto isakmp keepalive [tiempo en segundos] periodic

Si la opción “periodic” no está configurada, es utilizado el método On-Demand


por defecto.

Ejemplo de configuración con la opción Periodic

IKE Fase 1 Policy


crypto isakmp policy 1
encryption 3des
authentication pre-share
group 2
!
IKE Preshared Key
crypto isakmp key kd94j1ksldz address 10.2.80.209 255.255.255.0
crypto isakmp keepalive 10 periodic
crypto ipsec transform-set esp-3des-sha esp-3des esp-sha-hmac
crypto map test 1 ipsec-isakmp
set peer 10.2.80.209
set transform-set esp-3des-sha
match address 101
!
!
interface FastEthernet0
ip address 10.1.32.14 255.255.255.0
speed auto
crypto map test

Donde

crypto isakmp keepalive segundos [reenvio] [periodic| on-demand]

• segundos— Intervalo en segundos del envío de mensajes DPD.

• reenvios—(Opcional) Intervalo en segundos del reenvío de los mensajes DPD, si falla la recepción del ACK
del mensaje enviado.

• periodic—(Opcional) Envío de mensajes DPD a intervalos regulares.

• on-demand—(Opcional) Envío de mensajes DPD bajo demanda . Este es el comportamiento por defecto.

Ejemplo de reenvíos
crypto isakmp keepalive 30 20 periodic

Con esta configuración le indicamos al router que envié un mensaje DPD cada 30 segundos de forma
periódica. Si el peer no responde al mensaje DPD, el router volverá a enviar el mensaje cada 20
segundos (cuatro transmisiones en total).

Uso de DPD con Múltiples peers en un mismo Crypto MAP

Si se utiliza DPD con múltiples peer y el router detecta uno de los peers no está
activo, es decir que no responde los DPD, el router conmutara al siguiente peer
declarado en el crypto map.

Ejemplo
crypto map green 1 ipsec-isakmp
set peer 10.0.0.1
set peer 10.0.0.2
set peer 10.0.0.3
set transform-set txfm
match address 101

Verificar el Funcionamiento de DPD


Comandos debug

La siguiente captura corresponde a la recepción de un mensaje DPD ( R_U_THERE).


*Mar 25 15:18:52.123: ISAKMP (0:268435457): received packet from 10.2.80.209
dport 500 sport 500 Global (I) QM_IDLE
*Mar 25 15:18:52.123: ISAKMP: set new node -443923643 to QM_IDLE *Mar 25 15:18:52.131:
ISAKMP:(0:1:HW:2): processing HASH payload. message ID =
-443923643
*Mar 25 15:18:52.131: ISAKMP:(0:1:HW:2): processing NOTIFY R_U_THERE_ACK protocol 1
spi 0, message ID = -443923643, sa = 81BA4DD4
*Mar 25 15:18:52.135: ISAKMP:(0:1:HW:2): DPD/R_U_THERE_ACK received from peer
10.2.80.209, sequence 0x9
*Mar 25 15:18:52.135: ISAKMP:(0:1:HW:2):deleting node -443923643 error FALSE
reason "informational (in) state 1"
*Mar 25 15:18:52.135: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY *Mar
25 15:18:52.135: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE New State =
IKE_P1_COMPLETE