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/