draft-ietf-vrrp-spec-v2-04.txt   draft-ietf-vrrp-spec-v2-05.txt 
INTERNET-DRAFT S. Knight INTERNET-DRAFT S. Knight
October 20, 1999 D. Weaver January 5, 2000 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
Nokia Nokia
P. Higginson P. Higginson
M. Shand M. Shand
Digital Equipment Corp. Digital Equipment Corp.
A. Lindem A. Lindem
IBM Corporation IBM Corporation
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-v2-04.txt> <draft-ietf-vrrp-spec-v2-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This internet draft expires on April 20, 2000. This internet draft expires on July 5, 2000.
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 assigns VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a responsibility for a virtual router to one of the VRRP routers on a
LAN. The VRRP router controlling the IP address(es) associated with LAN. The VRRP router controlling the IP address(es) associated with
a virtual router is called the Master, and forwards packets sent to a virtual router is called the Master, and forwards packets sent to
these IP addresses. The election process provides dynamic fail over these IP addresses. The election process provides dynamic fail over
in the forwarding responsibility should the Master become in the forwarding responsibility should the Master become
skipping to change at page 26, line 19 skipping to change at page 26, line 19
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 MD5 HMAC. The details on each approach including possible with MD5 HMAC. The details on each approach including possible
attacks 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.
The security measures discussed in the following sections only
provide various kinds of authentication. No confidentiality is
provided. 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.
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
only be used in environments were there is minimal security risk and only be used in environments were there is minimal security risk and
little chance for configuration errors (e.g., two VRRP routers on a little chance for configuration errors (e.g., two VRRP routers on a
LAN). LAN).
10.2 Simple Text Password 10.2 Simple Text Password
skipping to change at page 28, line 5 skipping to change at page 27, line 22
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 a LAN. While this type control over the administration of nodes on a LAN. While this type
of authentication does protect the operation of VRRP, there are other of authentication does protect the operation of VRRP, there are other
types of attacks that may be employed on shared media links (e.g., types of attacks that may be employed on shared media links (e.g.,
generation of bogus ARP replies) that are independent from VRRP and generation of bogus ARP replies) that are independent from VRRP and
are not protected. 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.
11. Intellectual Property 11. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 32, line 20 skipping to change at page 32, line 20
- Corrected text in Preempt_Mode definition. - Corrected text in Preempt_Mode definition.
- Changed authentication to be per Virtual Router instead of per - Changed authentication to be per Virtual Router instead of per
Interface. Interface.
- Added new subsection (9.3) stating that VRRP over ATM LANE is - Added new subsection (9.3) stating that VRRP over ATM LANE is
beyond the scope of this document. beyond the scope of this document.
- Clarified text describing received packet length check. - Clarified text describing received packet length check.
- Clarified text describing received authentication check. - Clarified text describing received authentication check.
- Clarified text describing VRID verification check. - Clarified text describing VRID verification check.
- Added new subsection (8.4) describing need to not forward packets - Added new subsection (8.4) describing need to not forward packets
for adopted IP addresses. for adopted IP addresses.
- Added clarification to the security considerations section.
- Added reference for computing the internet checksum. - Added reference for computing the internet checksum.
- Updated references and author information. - Updated references and author information.
 End of changes. 

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