scalability of DPD is much better than keepalives and heartbeats.
DPD maintains the HELLO/ACK model presented by keepalives, as it
follows that an exchange is initiated only by an entity interested in
the liveliness of its peer.
6. Resistance to Replay Attack and False Proof of Liveliness
6.1. Sequence Number in DPD Messages
To guard against message replay attacks and false proof of
liveliness, a 32-bit sequence number MUST be presented with each R-
U-THERE message. A responder to an R-U-THERE message MUST send an
R-U-THERE-ACK with the same sequence number. Upon receipt of the R-
U-THERE-ACK message, the initial sender SHOULD check the validity of
the sequence number. The initial sender SHOULD reject the R-U-
THERE-ACK if the sequence number fails to match the one sent with the
R-U-THERE message.
Additionally, both the receiver of the R-U-THERE and the R-U-THERE-
ACK message SHOULD check the validity of the Initiator and Responder
cookies presented in the SPI field of the payload.
6.2. Selection and Maintenance of Sequence Numbers
As both DPD peers can initiate a DPD exchange (i.e., both peers can
send R-U-THERE messages), each peer MUST maintain its own sequence
number for R-U-THERE messages. The first R-U-THERE message sent in a
session MUST be a randomly chosen number. To prevent rolling past
overflowing the 32-bit boundary, the high-bit of the sequence number
initially SHOULD be set to zero. Subsequent R-U-THERE messages MUST
increment the sequence number by one. Sequence numbers MAY reset at
the expiry of the IKE SA, moving to a newly chosen random number.
Each entity SHOULD also maintain its peer’s R-U-THERE sequence
number, and an entity SHOULD reject the R-U-THERE message if it fails
to match the expected sequence number.
Implementations MAY maintain a window of acceptable sequence numbers,
but this specification makes no assumptions about how this is done.
Again, it is an implementation specific detail.
7. Security Considerations
As the previous section highlighted, DPD uses sequence numbers to
ensure liveliness. This section describes the advantages of using
sequence numbers over random nonces to ensure liveliness.
While sequence numbers do require entities to keep per-peer state,
they also provide an added method of protection in certain replay
attacks. Consider a case where peer A sends peer B a valid DPD R-U-
THERE message. An attacker C can intercept this message and flood B
with multiple copies of the messages. B will have to decrypt and
process each packet (regardless of whether sequence numbers or nonces
are in use). With sequence numbers B can detect that the packets are
replayed: the sequence numbers in these replayed packets will not
match the incremented sequence number that B expects to receive from
A. This prevents B from needing to build, encrypt, and send ACKs.
By contrast, if the DPD protocol used nonces, it would provide no way
for B to detect that the messages are replayed (unless B maintained a
list of recently received nonces).
Another benefit of sequence numbers is that it adds an extra
assurance of the peer’s liveliness. As long as a receiver verifies
the validity of a DPD R-U-THERE message (by verifying its incremented
sequence number), then the receiver can be assured of the peer’s
liveliness by the very fact that the sender initiated the query.
Nonces, by contrast, cannot provide this assurance.
8. IANA Considerations
There is no IANA action required for this document. DPD uses notify
numbers from the private range.
9. References
9.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
10. Editors’ Addresses
Geoffrey Huang
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: (408) 525-5354
EMail: ghuang@cisco.com
Stephane Beaulieu
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, ON
Canada, K2K 3E8
Phone: (613) 254-3678
EMail: stephane@cisco.com
Dany Rochefort
Cisco Systems, Inc.
124 Grove Street, Suite 205
Franklin, MA 02038
Phone: (508) 553-8644
EMail: danyr@cisco.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.