--- 1/draft-ietf-vrrp-spec-02.txt 2006-02-05 02:09:47.000000000 +0100 +++ 2/draft-ietf-vrrp-spec-03.txt 2006-02-05 02:09:47.000000000 +0100 @@ -1,47 +1,47 @@ INTERNET-DRAFT S. Knight -October 12, 1997 D. Weaver +October 23, 1997 D. Weaver Ascend Communications, Inc. D. Whipple Microsoft, Inc. R. Hinden D. Mitzel P. Hunt Ipsilon Networks, Inc. P. Higginson M. Shand Digital Equipment Corp. Virtual Router Redundancy Protocol - + Status of this Memo This document is an Internet-Draft. 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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). - This internet draft expires on April 12, 1998. + This internet draft expires on April 23, 1998. Abstract This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically allows a set of routers running VRRP to backup each other on a LAN. The VRRP router controlling one or more IP addresses is called the Master router, 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 VRRP routers @@ -526,23 +526,23 @@ of the Authentication Data field should be set to the locally configured password on transmission. There is no default password. The receiver MUST check that the Authentication Data in the packet matches its configured authentication string. Packets that do not match MUST be discarded. 5.3.6.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 HMAC: Keyed-Hashing for Message - Authentication [HMAC]. Keys may be either configured manually or via - a key distribution protocol. + Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP + and AH" [HMAC]. Keys may be either configured manually or via a key + distribution protocol. If a packet is received that does not pass the authentication check due to a missing authentication header or incorrect message digest, then the packet MUST be discarded. The contents of the Authentication Data field should be set to zero on transmission and ignored on reception. 5.3.7 Advertisement Interval (Adver Int) The Advertisement interval indicates the time interval (in seconds) @@ -949,22 +949,22 @@ operation of Token Ring by the authors, this version of VRRP does not work over Token Ring networks. This may be remedied in new version of this document, or in a separate document. 10. Security Considerations VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes several authentication methods ranging from no authentication, simple clear text passwords, and strong authentication using IP Authentication - with HMAC. The details on each approach including possible attacks - and recommended environments follows. + with MD5 HMAC. The details on each approach including possible + attacks and recommended environments follows. 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. 10.1 No Authentication The use of this authentication type means that VRRP protocol exchanges are not authenticated. This type of authentication SHOULD @@ -987,22 +987,22 @@ with the TTL check makes it difficult for a VRRP packet to be sent from another link to disrupt VRRP operation. This type of authentication is RECOMMENDED when there is minimal risk of nodes on the link actively disrupting VRRP operation. 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 HMAC: Keyed-Hashing for Message - Authentication [HMAC]. This provides strong protection against + 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 the link. 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) which are independent from VRRP and are not protected. @@ -1016,22 +1016,23 @@ [AUTH] Atkinson, R., "IP Authentication Header", RFC-1826, August 1995. [DISC] Deering, S., "ICMP Router Discovery Messages", RFC-1256, September 1991. [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC-1541, October 1993. - [HMAC] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing - for Message Authentication", RFC-2104, February 1997. + [HMAC] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP + and AH", Internet Draft, , July 1997. [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Hot Standby Router Protocol (HSRP)", Internet Draft, , June 1997. [OSPF] Moy, J., "OSPF version 2", RFC-1583, July 1997. [RIP] Hedrick, C., "Routing Information Protocol" , RFC-1058, June 1988. @@ -1092,20 +1093,26 @@ Digital Equipment Corp. Digital Park Imperial Way Reading Berkshire RG2 0TE UK 14. Changes from Previous Drafts + Changes from + + - Updated text and references to point to "The Use of HMAC-MD5-96 + within ESP and AH" that is the correct reference for the use of + IPSEC AH with MD5. + Changes from Major change to use real IP addresses instead of virtual IP addresses. Changes include: - Updated version number to 2. - Modified packet header - New terminology (removed cluster, virtual IP address, etc., added VRID, associated IP address(es), etc.). - Special case of priority = 255 for router owning VRID and