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/