Hi all:
DPD(RFC 3706) provide a mechanism to detect dead IKEv1 peer.
In draft-ietf-ipsecme-roadmap-07,
4.2.3.1, it tell us
<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-roadmap/>"This RFC
defines an optional extension to IKEv1; dead peer detection (DPD) is an
integral part of IKEv2, which refers to this feature as a "liveness check"
or "liveness test"." So we can learn DPD can be used in IKEv2. However,
some issues need to discuss when used in IKEv2.
#1: Sequence Number in DPD Message
In rfc3706, sequence number in DPD message can prove liveliness and
guard against message replay attack, it is presented in the notification
data field in the Notify Payload format. However, Message ID in the IKEv2
can provide the same function(see WG draft
draft-ietf-ipsecme-ikev2bis<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2bis/>2.2).
If DPD is used in IKEv2, DPD notify message can use Message ID in the
IKEv2 message header other than define the other redundancy sequence number
in the notification data field. Furthermore, another WG draft
draft-ietf-ipsecme-ipsec-ha<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsec-ha/>
define SADB information to be synchronized in the clusters. If DPD use its
unique sequence number , the number should also be synched as IKE SA
counters.
#2: Message Type
RFC3706 define DPD Message as below:
Notify Message Value
R-U-THERE 36136
R-U-THERE-ACK 36137
But I do not see these definition in draft-ietf-ipsecme-ikev2bis
<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2bis/> or
http://www.iana.org/assignments/ikev2-parameters.
So, should we udpate RFC 3706 or make a detailed description in
draft-ietf-ipsecme-ikev2bis
<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2bis/>?
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
