exchanges are authenticated by a simple clear text password.   This type of authentication is useful to protect against accidental   misconfiguration of routers on a LAN.  It protects against routers   inadvertently backing up another router.  A new router must first be   configured with the correct password before it can run VRRP with   another router.  This type of authentication does not protect against   hostile attacks where the password can be learned by a node snooping   VRRP packets on the LAN.  The Simple Text Authentication combined   with the TTL check makes it difficult for a VRRP packet to be sent   from another LAN to disrupt VRRP operation.   This type of authentication is RECOMMENDED when there is minimal risk   of nodes on a LAN actively disrupting VRRP operation.  If this type   of authentication is used the user should be aware that this clear   text password is sent frequently, and therefore should not be thedraft-ietf-vrrp-spec-v2-05.txt                                 [Page 26]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000   same as any security significant password.10.3 IP Authentication Header   The use of this authentication type means the VRRP protocol exchanges   are authenticated using the mechanisms defined by the IP   Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP   and AH", [HMAC].  This provides strong protection against   configuration errors, replay attacks, and packet   corruption/modification.   This type of authentication is RECOMMENDED when there is limited   control over the administration of nodes on a LAN.  While this type   of authentication does protect the operation of VRRP, there are other   types of attacks that may be employed on shared media links (e.g.,   generation of bogus ARP replies) that are independent from VRRP and   are not protected.   Specifically, although securing VRRP prevents unauthorized machines   from taking part in the election protocol, it does not protect hosts   on the network from being deceived.  For example, a gratuitous ARP   reply from what purports to be the virtual router's IP address can   redirect traffic to an unauthorized machine.  Similarly, individual   connections can be diverted by means of forged ICMP Redirect   messages.draft-ietf-vrrp-spec-v2-05.txt                                 [Page 27]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 200011. Intellectual Property   The IETF takes no position regarding the validity or scope of any   intellectual property 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; neither does it represent that it   has made any effort to identify any such rights.  Information on the   IETF's procedures with respect to rights in standards-track and   standards-related documentation can be found in BCP-11.  Copies of   claims of rights made available for publication 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 implementors or users of this specification can   be obtained from the IETF Secretariat.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights which may cover technology that may be required to practice   this standard.  Please address the information to the IETF Executive   Director.   The IETF has been notified of intellectual property rights claimed in   regard to some or all of the specification contained in this   document.  For more information consult the online list of claimed   rights.12. Acknowledgments   The authors would like to thank Glen Zorn, and Michael Lane, Clark   Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve   Bellovin, Thomas Narten, Rob Montgomery, and Rob Coltun for their   comments and suggestions.13.  References   [802.1D]  International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std             802.1D, 1993 edition.   [AUTH]    Kent, S., R. Atkinson, "IP Authentication Header", RFC2402,             November 1998.   [CKSM]    Braden, R., D. Borman, C. Partridge, "Computing the             Internet Checksum", RFC1071, September 1988.draft-ietf-vrrp-spec-v2-05.txt                                 [Page 28]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000   [DISC]    Deering, S., "ICMP Router Discovery Messages", RFC1256,             September 1991.   [DHCP]    Droms, R., "Dynamic Host Configuration Protocol", RFC2131,             March 1997.   [HMAC]    Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP             and AH", RFC2403, November 1998.   [HSRP]    Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby             Router Protocol (HSRP)", RFC2281, March 1998.   [IPSTB]   Higginson, P., M. Shand, "Development of Router Clusters to             Provide Fast Failover in IP Networks", Digital Technical             Journal, Volume 9 Number 3, Winter 1997.   [IPX]     Novell Incorporated., "IPX Router Specification", Version             1.10, October 1992.   [OSPF]    Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998.   [RIP]     Malkin, G., "RIP Version 2", RFC2453, STD0056, November             1998.   [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area             Networks", RFC1469, June 1993.   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision             3", RFC2026, BCP00009, October 1996.   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate             Requirement Levels", RFC2119, BCP0014, March 1997.   [TKARCH]  IBM Token-Ring Network, Architecture Reference, Publication             SC30-3374-02, Third Edition, (September, 1989).14. Author's Addresses   Steven Knight                           Phone: +1 612 943-8990   Ascend Communications                   EMail: Steven.Knight@ascend.com   High Performance Network Division   10250 Valley View Road, Suite 113   Eden Prairie, MN USA 55344   USAdraft-ietf-vrrp-spec-v2-05.txt                                 [Page 29]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000   Douglas Weaver                          Phone: +1 612 943-8990   Ascend Communications                   EMail: Doug.Weaver@ascend.com   High Performance Network Division   10250 Valley View Road, Suite 113   Eden Prairie, MN USA 55344   USA   David Whipple                           Phone: +1 206 703-3876   Microsoft Corporation                   EMail: dwhipple@microsoft.com   One Microsoft Way   Redmond, WA 98052-6399   USA   Robert Hinden                           Phone: +1 650 625-2004   Nokia                                   EMail: hinden@iprg.nokia.com   313 Fairchild Drive   Mountain View, CA 94043   USA   Danny Mitzel                            Phone: +1 650 625-2037   Nokia                                   EMail: mitzel@iprg.nokia.com   313 Fairchild Drive   Mountain View, CA 94043   USA   Peter Hunt                              Phone: +1 650 625-2093   Nokia                                   EMail: hunt@iprg.nokia.com   313 Fairchild Drive   Mountain View, CA 94043   USA   P. Higginson                            Phone: +44 118 920 6293   Digital Equipment Corp.                 EMail: higginson@mail.dec.com   Digital Park   Imperial Way   Reading   Berkshire   RG2 0TE   UK   M. Shand                                Phone: +44 118 920 4424   Digital Equipment Corp.                 EMail: shand@mail.dec.com   Digital Park   Imperial Way   Reading   Berkshire   RG2 0TE   UKdraft-ietf-vrrp-spec-v2-05.txt                                 [Page 30]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000   Acee Lindem                             Phone: 1-919-254-1805   IBM Corporation                         E-Mail: acee@raleigh.ibm.com   P.O. Box 12195   Research Triangle Park, NC  27709   USAdraft-ietf-vrrp-spec-v2-05.txt                                 [Page 31]INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 200014. Changes from RFC2338    - Revised the section 4 examples text with a clearer description of      mapping of IP address owner, priorities, etc.    - Clarify the section 7.1 text describing address list validation.    - Corrected text in Preempt_Mode definition.    - Changed authentication to be per Virtual Router instead of per      Interface.    - Added new subsection (9.3) stating that VRRP over ATM LANE is      beyond the scope of this document.    - Clarified text describing received packet length check.    - Clarified text describing received authentication check.    - Clarified text describing VRID verification check.    - Added new subsection (8.4) describing need to not forward packets      for adopted IP addresses.    - Added clarification to the security considerations section.    - Added reference for computing the internet checksum.    - Updated references and author information.draft-ietf-vrrp-spec-v2-05.txt