Network Working Group R. Atkinson
Request for Comments: 4822 Extreme Networks
Obsoletes: 2082 M. Fanto
Updates: 2453 NIST
Category: Standards Track February 2007
RIPv2 Cryptographic Authentication
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The IETF Trust (2007).
In the interests of encouraging rapid migration away from Keyed-MD5
and its known weakness, the IESG has approved this document even
though it does not meet the guidelines in BCP 107 (RFC 4107).
However, the IESG stresses that automated key management should be
used to establish session keys and urges that the future work on key
management described in Section 5.6 of this document should be
performed as soon as possible.
This note describes a revision to the RIPv2 Cryptographic
Authentication mechanism originally specified in RFC 2082. This
document obsoletes RFC 2082 and updates RFC 2453. This document adds
details of how the SHA family of hash algorithms can be used with
RIPv2 Cryptographic Authentication, whereas the original document
only specified the use of Keyed-MD5. Also, this document clarifies a
potential issue with an active attack on this mechanism and adds
significant text to the Security Considerations section.
Atkinson & Fanto Standards Track [Page 1]RFC 4822 RIPv2 Cryptographic Authentication February 20071. Introduction
Growth in the Internet has made us aware of the need for improved
authentication of routing information. RIPv2 provides for
unauthenticated service (as in classical RIP), or password
authentication. Both are vulnerable to passive attacks currently
widespread in the Internet. Well-understood security issues exist in
routing protocols [Bell89]. Cleartext passwords, originally
specified for use with RIPv2, are widely understood to be vulnerable
to easily deployed passive attacks [HA94].
The original RIPv2 cryptographic authentication specification, RFC
2082 [AB97], used the Keyed-MD5 cryptographic mechanism. While there
are no openly published attacks on that mechanism, some reports
[Dobb96a, Dobb96b] create concern about the ultimate strength of the
MD5 cryptographic hash function. Further, some end users,
particularly several different governments, require the use of the
SHA hash function family rather than any other such function for
policy reasons. Finally, the original specification uses a hashing
construction widely believed to be weaker than the HMAC construction
used with the algorithms added in this revision of the specification.
This document obsoletes the original specification, RFC 2082 [AB97].
This specification differs from RFC 2082 by adding support for the
SHA family of hash algorithms and the HMAC technique, while retaining
the original Keyed-MD5 algorithm and mode. As the original RIPv2
Cryptographic Authentication mechanism was algorithm-independent,
backwards compatibility is retained. This requirement for backwards
compatibility precludes making significant protocol changes. So,
this document limits changes to the addition of support for an
additional family of cryptographic algorithms. The original
specification has been very widely implemented, is known to be widely
interoperable, and is also widely deployed.
The authors do NOT believe that this specification is the final
answer to RIPv2 authentication and encourage the reader to consult
the Security Considerations section of this document for more
If RIPv2 authentication is disabled, then only simple
misconfigurations are detected. The original RIPv2 authentication
mechanism relied upon reused cleartext passwords. Use of cleartext
password authentication can protect against accidental
misconfigurations if that were the only concern, but is not helpful
from a security perspective. By simply capturing information on the
wire -- straightforward even in a remote environment -- a hostile
Atkinson & Fanto Standards Track [Page 2]RFC 4822 RIPv2 Cryptographic Authentication February 2007