draft-ietf-vrrp-spec-v2-05.txt

VRRP双机热备份协议源吗

   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 the



draft-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, 2000


11. 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: [phone]
   Ascend Communications                   EMail: [e-mail]
   High Performance Network Division
   10250 Valley View Road, Suite 113
   Eden Prairie, MN USA 55344
   USA






draft-ietf-vrrp-spec-v2-05.txt                                 [Page 29]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


   Douglas Weaver                          Phone: [phone]
   Ascend Communications                   EMail: [e-mail]
   High Performance Network Division
   10250 Valley View Road, Suite 113
   Eden Prairie, MN USA 55344
   USA

   David Whipple                           Phone: [phone]
   Microsoft Corporation                   EMail: [e-mail]
   One Microsoft Way
   Redmond, WA 98052-6399
   USA

   Robert Hinden                           Phone: [phone]
   Nokia                                   EMail: [e-mail]
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Danny Mitzel                            Phone: [phone]
   Nokia                                   EMail: [e-mail]
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Peter Hunt                              Phone: [phone]
   Nokia                                   EMail: [e-mail]
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   P. Higginson                            Phone: [phone]
   Digital Equipment Corp.                 EMail: [e-mail]
   Digital Park
   Imperial Way
   Reading
   Berkshire
   RG2 0TE
   UK

   M. Shand                                Phone: [phone]
   Digital Equipment Corp.                 EMail: [e-mail]
   Digital Park
   Imperial Way
   Reading
   Berkshire
   RG2 0TE
   UK



draft-ietf-vrrp-spec-v2-05.txt                                 [Page 30]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


   Acee Lindem                             Phone: [phone]
   IBM Corporation                         E-Mail: [e-mail]
   P.O. Box 12195
   Research Triangle Park, NC  27709
   USA














































draft-ietf-vrrp-spec-v2-05.txt                                 [Page 31]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


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