draft-ietf-vrrp-spec-02.txt   draft-ietf-vrrp-spec-03.txt 
INTERNET-DRAFT S. Knight INTERNET-DRAFT S. Knight
October 12, 1997 D. Weaver October 23, 1997 D. Weaver
Ascend Communications, Inc. Ascend Communications, Inc.
D. Whipple D. Whipple
Microsoft, Inc. Microsoft, Inc.
R. Hinden R. Hinden
D. Mitzel D. Mitzel
P. Hunt P. Hunt
Ipsilon Networks, Inc. Ipsilon Networks, Inc.
P. Higginson P. Higginson
M. Shand M. Shand
Digital Equipment Corp. Digital Equipment Corp.
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-02.txt> <draft-ietf-vrrp-spec-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
This internet draft expires on April 12, 1998. This internet draft expires on April 23, 1998.
Abstract Abstract
This memo defines the Virtual Router Redundancy Protocol (VRRP). This memo defines the Virtual Router Redundancy Protocol (VRRP).
VRRP specifies an election protocol that dynamically allows a set of VRRP specifies an election protocol that dynamically allows a set of
routers running VRRP to backup each other on a LAN. The VRRP router 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 controlling one or more IP addresses is called the Master router, and
forwards packets sent to these IP addresses. The election process forwards packets sent to these IP addresses. The election process
provides dynamic fail over in the forwarding responsibility should provides dynamic fail over in the forwarding responsibility should
the Master become unavailable. This allows any of the VRRP routers the Master become unavailable. This allows any of the VRRP routers
skipping to change at page 13, line 9 skipping to change at page 13, line 9
of the Authentication Data field should be set to the locally of the Authentication Data field should be set to the locally
configured password on transmission. There is no default password. configured password on transmission. There is no default password.
The receiver MUST check that the Authentication Data in the packet The receiver MUST check that the Authentication Data in the packet
matches its configured authentication string. Packets that do not matches its configured authentication string. Packets that do not
match MUST be discarded. match MUST be discarded.
5.3.6.3 IP Authentication Header 5.3.6.3 IP Authentication Header
The use of this authentication type means the VRRP protocol exchanges The use of this authentication type means the VRRP protocol exchanges
are authenticated using the mechanisms defined by the IP are authenticated using the mechanisms defined by the IP
Authentication Header [AUTH] using HMAC: Keyed-Hashing for Message Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP
Authentication [HMAC]. Keys may be either configured manually or via and AH" [HMAC]. Keys may be either configured manually or via a key
a key distribution protocol. distribution protocol.
If a packet is received that does not pass the authentication check If a packet is received that does not pass the authentication check
due to a missing authentication header or incorrect message digest, due to a missing authentication header or incorrect message digest,
then the packet MUST be discarded. The contents of the then the packet MUST be discarded. The contents of the
Authentication Data field should be set to zero on transmission and Authentication Data field should be set to zero on transmission and
ignored on reception. ignored on reception.
5.3.7 Advertisement Interval (Adver Int) 5.3.7 Advertisement Interval (Adver Int)
The Advertisement interval indicates the time interval (in seconds) The Advertisement interval indicates the time interval (in seconds)
skipping to change at page 22, line 22 skipping to change at page 22, line 22
operation of Token Ring by the authors, this version of VRRP does not 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 work over Token Ring networks. This may be remedied in new version
of this document, or in a separate document. of this document, or in a separate document.
10. Security Considerations 10. Security Considerations
VRRP is designed for a range of internetworking environments that may VRRP is designed for a range of internetworking environments that may
employ different security policies. The protocol includes several employ different security policies. The protocol includes several
authentication methods ranging from no authentication, simple clear authentication methods ranging from no authentication, simple clear
text passwords, and strong authentication using IP Authentication text passwords, and strong authentication using IP Authentication
with HMAC. The details on each approach including possible attacks with MD5 HMAC. The details on each approach including possible
and recommended environments follows. attacks and recommended environments follows.
Independent of any authentication type VRRP includes a mechanism Independent of any authentication type VRRP includes a mechanism
(setting TTL=255, checking on receipt) that protects against VRRP (setting TTL=255, checking on receipt) that protects against VRRP
packets being injected from another remote network. This limits most packets being injected from another remote network. This limits most
vulnerabilities to local attacks. vulnerabilities to local attacks.
10.1 No Authentication 10.1 No Authentication
The use of this authentication type means that VRRP protocol The use of this authentication type means that VRRP protocol
exchanges are not authenticated. This type of authentication SHOULD exchanges are not authenticated. This type of authentication SHOULD
skipping to change at page 23, line 15 skipping to change at page 23, line 15
with the TTL check makes it difficult for a VRRP packet to be sent with the TTL check makes it difficult for a VRRP packet to be sent
from another link to disrupt VRRP operation. from another link to disrupt VRRP operation.
This type of authentication is RECOMMENDED when there is minimal risk This type of authentication is RECOMMENDED when there is minimal risk
of nodes on the link actively disrupting VRRP operation. of nodes on the link actively disrupting VRRP operation.
10.3 IP Authentication Header 10.3 IP Authentication Header
The use of this authentication type means the VRRP protocol exchanges The use of this authentication type means the VRRP protocol exchanges
are authenticated using the mechanisms defined by the IP are authenticated using the mechanisms defined by the IP
Authentication Header [AUTH] using HMAC: Keyed-Hashing for Message Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP
Authentication [HMAC]. This provides strong protection against and AH", [HMAC]. This provides strong protection against
configuration errors, replay attacks, and packet configuration errors, replay attacks, and packet
corruption/modification. corruption/modification.
This type of authentication is RECOMMENDED when there is limited This type of authentication is RECOMMENDED when there is limited
control over the administration of nodes on the link. While this control over the administration of nodes on the link. While this
type of authentication does protect the operation of VRRP, there are type of authentication does protect the operation of VRRP, there are
other types of attacks that may be employed on shared media links other types of attacks that may be employed on shared media links
(e.g., generation of bogus ARP replies) which are independent from (e.g., generation of bogus ARP replies) which are independent from
VRRP and are not protected. VRRP and are not protected.
skipping to change at page 24, line 16 skipping to change at page 24, line 16
[AUTH] Atkinson, R., "IP Authentication Header", RFC-1826, August [AUTH] Atkinson, R., "IP Authentication Header", RFC-1826, August
1995. 1995.
[DISC] Deering, S., "ICMP Router Discovery Messages", RFC-1256, [DISC] Deering, S., "ICMP Router Discovery Messages", RFC-1256,
September 1991. September 1991.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC-1541, [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC-1541,
October 1993. October 1993.
[HMAC] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing [HMAC] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP
for Message Authentication", RFC-2104, February 1997. and AH", Internet Draft, <draft-ietf-ipsec-auth-hmac-
md5-96-00.txt> , July 1997.
[HSRP] Li, T., B. Cole, P. Morton, D. Li, "Hot Standby Router [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Hot Standby Router
Protocol (HSRP)", Internet Draft, <draft-li-hsrp-00.txt>, Protocol (HSRP)", Internet Draft, <draft-li-hsrp-00.txt>,
June 1997. June 1997.
[OSPF] Moy, J., "OSPF version 2", RFC-1583, July 1997. [OSPF] Moy, J., "OSPF version 2", RFC-1583, July 1997.
[RIP] Hedrick, C., "Routing Information Protocol" , RFC-1058, [RIP] Hedrick, C., "Routing Information Protocol" , RFC-1058,
June 1988. June 1988.
skipping to change at page 26, line 6 skipping to change at page 26, line 6
REO2-F/D9 EMail: shand@mail.dec.com REO2-F/D9 EMail: shand@mail.dec.com
Digital Equipment Corp. Digital Equipment Corp.
Digital Park Digital Park
Imperial Way Imperial Way
Reading Reading
Berkshire Berkshire
RG2 0TE RG2 0TE
UK UK
14. Changes from Previous Drafts 14. Changes from Previous Drafts
Changes from <draft-ietf-vrrp-spec-02.txt>
- 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 <draft-ietf-vrrp-spec-01.txt> Changes from <draft-ietf-vrrp-spec-01.txt>
Major change to use real IP addresses instead of virtual IP Major change to use real IP addresses instead of virtual IP
addresses. Changes include: addresses. Changes include:
- Updated version number to 2. - Updated version number to 2.
- Modified packet header - Modified packet header
- New terminology (removed cluster, virtual IP address, etc., added - New terminology (removed cluster, virtual IP address, etc., added
VRID, associated IP address(es), etc.). VRID, associated IP address(es), etc.).
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/