RIPv2 Cryptographic Authentication
RFC 4822

Document Type RFC - Proposed Standard (February 2007; No errata)
Obsoletes RFC 2082
Updates RFC 2453
Was draft-rja-ripv2-auth (individual in sec area)
Authors Randall Atkinson  , M Fanto 
Last updated 2015-10-14
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4822 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Russ Housley
Send notices to (None)
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 Notice

   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 2007

1.  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

   entity can read the cleartext RIPv2 password and use that knowledge
   to inject false information into the routing system via the RIPv2
   routing protocol.
Show full document text