--- 1/draft-ietf-vrrp-spec-v2-09.txt 2006-02-05 02:09:58.000000000 +0100 +++ 2/draft-ietf-vrrp-spec-v2-10.txt 2006-02-05 02:09:58.000000000 +0100 @@ -1,91 +1,90 @@ INTERNET-DRAFT R. Hinden, Editor -August 13, 2003 Nokia +February 4, 2004 Nokia Virtual Router Redundancy Protocol - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. - This internet draft expires on February 17, 2004. + This internet draft expires on August 9, 2004. Abstract This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. This document replaces RFC2338 "Virtual Router Redundancy Protocol". - RFC2338 will become historic. Table of Contents 1. Introduction...............................................3 2. Required Features..........................................5 - 3. VRRP Overview..............................................7 - 4. Sample Configurations......................................9 - 5. Protocol..................................................12 - 5.1 VRRP Packet Format....................................12 - 5.2 IP Field Descriptions.................................12 - 5.3 VRRP Field Descriptions...............................13 - 6. Protocol State Machine....................................16 - 6.1 Parameters per Virtual Router.........................16 - 6.2 Timers................................................17 - 6.3 State Transition Diagram..............................17 - 6.4 State Descriptions....................................17 - 7. Sending and Receiving VRRP Packets........................21 - 7.1 Receiving VRRP Packets................................21 - 7.2 Transmitting Packets..................................21 - 7.3 Virtual MAC Address...................................22 - 8. Operational Issues........................................23 - 8.1 ICMP Redirects........................................23 - 8.2 Host ARP Requests.....................................23 - 8.3 Proxy ARP.............................................23 - 8.4 Potential Forwarding Loop.............................24 - 9. Operation over FDDI, Token Ring, and ATM LANE.............24 - 9.1 Operation over FDDI...................................24 - 9.2 Operation over Token Ring.............................24 - 9.3 Operation over ATM LANE...............................26 - 10. Security Considerations...................................27 - 11. Intellectual Property.....................................27 - 12. Acknowledgments...........................................28 - 13. Normative References......................................28 - 14. Informative References....................................29 - 15. Editors' Address..........................................29 - 16. Changes from RFC2338......................................30 + 3. VRRP Overview..............................................6 + 4. Sample Configurations......................................8 + 5. Protocol..................................................11 + 5.1 VRRP Packet Format....................................11 + 5.2 IP Field Descriptions.................................11 + 5.3 VRRP Field Descriptions...............................12 + 6. Protocol State Machine....................................15 + 6.1 Parameters per Virtual Router.........................15 + 6.2 Timers................................................16 + 6.3 State Transition Diagram..............................16 + 6.4 State Descriptions....................................16 + 7. Sending and Receiving VRRP Packets........................20 + 7.1 Receiving VRRP Packets................................20 + 7.2 Transmitting Packets..................................20 + 7.3 Virtual MAC Address...................................21 + 8. Operational Issues........................................22 + 8.1 ICMP Redirects........................................22 + 8.2 Host ARP Requests.....................................22 + 8.3 Proxy ARP.............................................22 + 8.4 Potential Forwarding Loop.............................23 + 9. Operation over FDDI, Token Ring, and ATM LANE.............23 + 9.1 Operation over FDDI...................................23 + 9.2 Operation over Token Ring.............................23 + 9.3 Operation over ATM LANE...............................25 + 10. Security Considerations...................................26 + 11. Intellectual Property.....................................26 + 12. Acknowledgments...........................................27 + 13. Normative References......................................27 + 14. Informative References....................................28 + 15. Editors' Address..........................................28 + 16. Changes from RFC2338......................................29 1. Introduction There are a number of methods that an end-host can use to determine its first hop router towards a particular IP destination. These include running (or snooping) a dynamic routing protocol such as Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running an ICMP router discovery client [DISC] or using a statically configured default route. @@ -116,43 +115,35 @@ VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable. Any of the virtual router's IP addresses on a LAN can then be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. - VRRP provides a function similar to a Cisco Systems, Inc. proprietary - protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a - Digital Equipment Corporation, Inc. proprietary protocol named IP - Standby Protocol [IPSTB]. + VRRP provides a function similar to the proprietary protocols "Hot + Standby Router Protocol (HSRP)" [HSRP] and "IP Standby Protocol" + [IPSTB]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. - The IESG/IETF take no position regarding the validity or scope of any - intellectual property right or other rights that might be claimed to - pertain to the implementation or use of the technology, or the extent - to which any license under such rights might or might not be - available. See the IETF IPR web page at http://www.ietf.org/ipr.html - for additional information. - 1.1 Contributors The following people, who are the authors of the RFC2338 that this document is based on and replaces, contributed to the text in this document. They are P. Higginson, R. Hinden, P. Hunt, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Weaver, and D. Whipple. They are not - listed as authors of the document due to currnet RFC-Editor policies. + listed as authors of the document due to current RFC-Editor policies. 1.2 Scope The remainder of this document describes the features, design goals, and theory of operation of VRRP. The message formats, protocol processing rules and state machine that guarantee convergence to a single Virtual Router Master are presented. Finally, operational issues related to MAC address mapping, handling of ARP requests, generation of ICMP redirect messages, and security issues are addressed. @@ -237,22 +228,22 @@ 2.3 Minimization of Unnecessary Service Disruptions Once Master election has been performed then any unnecessary transitions between Master and Backup routers can result in a disruption in service. The protocol should ensure after Master election that no state transition is triggered by any Backup router of equal or lower preference as long as the Master continues to function properly. Some environments may find it beneficial to avoid the state - transition triggered when a router becomes available that is more - preferential than the current Master. It may be useful to support an + transition triggered when a router becomes available that is + preferred over the current Master. It may be useful to support an override of the immediate convergence to the preferred path. 2.4 Efficient Operation over Extended LANs Sending IP packets on a multiaccess LAN requires mapping from an IP address to a MAC address. The use of the virtual router MAC address in an extended LAN employing learning bridges can have a significant effect on the bandwidth overhead of packets sent to the virtual router. If the virtual router MAC address is never used as the source address in a link level frame then the station location is @@ -490,21 +481,22 @@ The type field specifies the type of this VRRP packet. The only packet type defined in this version of the protocol is: 1 ADVERTISEMENT A packet with unknown type MUST be discarded. 5.3.3 Virtual Rtr ID (VRID) The Virtual Router Identifier (VRID) field identifies the virtual - router this packet is reporting status for. + router this packet is reporting status for. Configurable item in the + range 1-255 (decimal). There is no default. 5.3.4 Priority The priority field specifies the sending VRRP router's priority for the virtual router. Higher values equal higher priority. This field is an 8 bit unsigned integer field. The priority value for the VRRP router that owns the IP address(es) associated with the virtual router MUST be 255 (decimal). @@ -584,23 +576,23 @@ 5.3.10 Authentication Data The authentication string is currently only used to maintain backwards compatibility with RFC2338. It SHOULD be set to zero on transmission and ignored on reception. 6. Protocol State Machine 6.1 Parameters per Virtual Router - VRID Virtual Router Identifier. Configured item - in the range 1-255 (decimal). There is no - default. + VRID Virtual Router Identifier. Configurable + item in the range 1-255 (decimal). There is + no default. Priority Priority value to be used by this VRRP router in Master election for this virtual router. The value of 255 (decimal) is reserved for the router that owns the IP addresses associated with the virtual router. The value of 0 (zero) is reserved for Master router to indicate it is releasing responsibility for the virtual router. The range 1-254 (decimal) is @@ -1064,28 +1056,42 @@ Operation of VRRP over ATM LANE on routers with ATM LANE interfaces and/or routers behind proxy LEC's are beyond the scope of this document. 10. Security Considerations VRRP does not currently include any type of authentication. Earlier versions of the VRRP specification included several types of authentication ranging from none to strong. Operational experience and further analysis determined that these did not provide any real - measure of security and due to the nature of the VRRP protocol they - did not prevent incorrectly configured or hostile routers from - becoming VRRP masters. In general due to the nature of LANs, any - device on the LAN has the ability to disrupt all communication. - Consequentially it was determined it was better to remove the - additional authentication methods in this specification of the VRRP - protocol as it did not provide the authentication originally - intended. + measure of security. Due to the nature of the VRRP protocol, even if + VRRP messages are cryptographically protected, it does not prevent + hostile routers from behaving as if they are a VRRP master, creating + multiple masters. Authentication of VRRP messages could have + prevented a hostile router from causing all properly functioning + routers from going into backup state. However, having multiple + masters can cause as much disruption as no routers, which + authentication cannot prevent. Also, even if a hostile router could + not disrupt VRRP, it can disrupt ARP and create the same effect as + having all routers go into backup. + + It should be noted that these attacks are not worse and are a subset + of the attacks that any node attached to a LAN can do independently + of VRRP. The kind of attacks a malicious node on a LAN can do + include promiscuously receiving packets for any routers MAC address, + sending packets with the routers MAC address as the source MAC + addresses in the L2 header to tell the L2 switches to send packets + addressed to the router to the malicious node instead of the router, + send redirects to tell the hosts to send their traffic somewhere + else, send unsolicited ARP replies, answer ARP requests, etc., etc. + All of this can be done independently of implementing VRRP. VRRP + does not add to these vulnerabilities. Independent of any authentication type VRRP includes a mechanism (setting TTL=255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks. VRRP does not provide any confidentiality. Confidentiality is not necessary for the correct operation of VRRP and there is no information in the VRRP messages that must be kept secret from other nodes on the LAN. @@ -1097,39 +1103,42 @@ 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. + be obtained from the IETF Secretariat. See the IETF IPR web page at + http://www.ietf.org/ipr.html for additional information. 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, Rob Coltun, and Radia - Perlman for their comments and suggestions. + Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, Radia Perlman, + Russ Housley, Harald Alvestrand, Steve Bellovin, Ned Freed, Ted + Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex Zinin for + their comments and suggestions. 13. Normative References [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std 802.1D, 1993 edition. [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the Internet Checksum", RFC1071, September 1988. [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby @@ -1172,41 +1181,41 @@ 15. Editor's Address Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US Phone: +1 650 625-2004 - Email: hinden@iprg.nokia.com + Email: bob.hinden@nokia.com 16. Changes from RFC2338 - Moved authors of RFC2338 to new Contributers section to comply with RFC editor policy and listed R. Hinden as Editor. - Removed authentication methods from VRRP. Changes included: o Removed the values for password and IPSEC based authentication. The fields and values are retained to keep backwards compatibility with RFC2338. o Removed section on extensible security o Updated security consideration section to remove discussion of different authentication methods and added new text explaining - motivation for change. + motivation for change and describe vulnerabilities. - 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. - - Changed order of author list based on contribution level. + - Various small editorial changes.