Re: [VRRP] New Version Notification fordraft-ietf-vrrp-unified-spec-03

["Stephen Nadas" <[e-mail]>]

I concur and will change this, thanks. 
Steve  

-----Original Message-----
From: Don Provan [mailto:[e-mail]] 
Sent: Tuesday, July 07, 2009 8:26 PM
To: Stephen Nadas; [e-mail]
Cc: Radia Perlman; Mukesh Gupta
Subject: RE: [VRRP] New Version Notification 
fordraft-ietf-vrrp-unified-spec-03

For section 7,

  7) section 6.1 add "Virtual_Router_MAC_Address"

  1003a1034,1038
  > 	    <t hangText="Virtual_Router_MAC_Address">The MAC address  
  > 	    used for the source MAC address in VRRP advertisements
  > 	    (and in some other cases as well).</t>

I suggest "The MAC address used for the source MAC address in 
VRRP advertisements and advertised in ARP responses as the MAC 
address to use for IP_Addresses." This serves two purposes. 
First, to emphasize what is really the central use of the VR 
MAC address. Second, to discourage thinking that there are any 
"other cases" beyond these two where the VR MAC address should be used.

Everything else looks OK to me.
-don

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On 
Behalf Of Stephen Nadas
Sent: Tuesday, July 07, 2009 8:57 AM
To: [e-mail]
Cc: Radia Perlman; Mukesh Gupta
Subject: Re: [VRRP] New Version Notification
fordraft-ietf-vrrp-unified-spec-03

Hi, 

The main technical changes as result of IESG review are below.  
See below for diffs around these.  Please comment to list. 

1) section 2.5 add para to discuss delivering more packets onto 
the LAN than can be accomodated
2) section 2.5 clarifcations
3) section 4.1 clarify that Rtr1 reassert mastership. 
4) section 5.1 clarify that there are IPvX headers before VRRP version
5) section 5.2.4 clarify how pri values are to work
6) section 6.1 accept_mode - clarify when may want to set to 
True and make should into MUST
7) section 6.1 add "Virtual_Router_MAC_Address"
8) section 6.1.4 clarify what is meant by startup event
9) section 6.4.2 clarify that grap ARP is for IPv4 addr.  
s/should not/MUST NOT/ when accept_mode is false
10) section 6.4.3 add to recompute skew_time
11) section 7.1 remove the MUST drop language
12) section 8.1.2 remove text about implementation choosing vrrp macs.
add that for some appls, must use IP address known to belong to router. 
13) Move, FDDI etc to appendix B & (not note here) moved the 
refs in the new appendix to informational
14) (not noted below) used new idnits and to get by those 
checks, selected "truse200811" and added pre-rfc5378 disclaimer 
language. Please NOTE that I am not sure this is correct - we 
may need to respin this aspect... 

Thanks,
Steve 



1) section 2.5 add para to discuss delivering more packets onto the LAN
than can be accomodated

439,442c440,461
< 	needed in both IPv4 and IPv6 environments.  In <xref
< 	target="I-D.ietf-vrrp-ipv6-spec"/>, sub-second operation was
< 	defined for IPv6; this specification extends that support for
< 	IPv4.</t>
---
> 	needed in both IPv4 and IPv6 environments.  Earlier work 
>         proposed sub-second operation was
> 	for IPv6; this specification leverages that earlier approach for
> 	IPv4 and IPv6.</t>
> 
> 	<t>One possible problematic scenario when using small
> 	VRRP_Advertisement intervals may occur when a router is
> 	delivering more packets onto the LAN than can be accomodated,
> 	and so a queue builds up in the router.  It is possible that
> 	packets being transmitted onto the VRRP-protected LAN could
> 	see larger queueing delay than the the smallest VRRP
> 	Advertisement_Interval.  In this case, the
> 	Master_Down_Interval will be small enough so that normal
> 	queuing delays might cause a VRRP backup to conclude that the
> 	master is down, and therefore promote itself to master.  Very
> 	shortly afterwards, the delayed VRRP packets from the master
> 	causing a switch back to backup status.  Furthermore, this
> 	process can repeat many times per second, causing significant
> 	disruption to traffic.  Priority forwarding of VRRP packets
> 	should be considered to mitigate this problem.  It should be
> 	possible for a VRRP master to observe that this situation is
> 	occurring frequently and at least log the problem.</t>

2) section 2.5 clarifcations 

465,471c484,492
<       an interface, and may also be configured with additional virtual
<       router mappings and priority for virtual routers it is willing
<       to backup.  The mapping between VRID and its IPvX address(es)
<       must be coordinated among all VRRP routers on a LAN.  However,
<       there is no restriction against reusing a VRID with a different
<       address mapping on different LANs.  The scope of each virtual
<       router is restricted to a single LAN.  Note that there is no
---
>       an interface.  The scope of each virtual router is restricted to
>       a single LAN.  A VRRP router may be configured with additional
>       virtual router mappings and priority for virtual routers it is
>       willing to backup.  The mapping between VRID and its IPvX
>       address(es) must be coordinated among all VRRP routers on a
>       LAN.</t>
> 
>       <t>There is no restriction against reusing a VRID with a
different
>       address mapping on different LANs. Nor is there a 

3) section 4.1 clarify that Rtr1 reassert mastership. 

593c614,615
<         uninterrupted service to the hosts.</t>
---
>         uninterrupted service to the hosts.  When Rtr1 returns to
>         service it will re-assert itself as Master.</t>

4) section 5.1 clarify that there are IPvX headers before VRRP version

708a731,734
>    |                    IPv4 Fields or IPv6 Fields                 |
>   ...                                                             ...
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5) section 5.2.4 clarify how pri values are to work 

951,952c977,979
< 	    routers backing up the virtual router.  The default value
< 	    is 100 (decimal).</t>
---
> 	    routers backing up the virtual router.  Higher values
> 	    indicate higher priorities. The default value is 100
> 	    (decimal).</t>

6) section 6.1 accept_mode - clarify when may want to set to True and
make should into MUST 

998c1025,1028
< 	    the IPvX address owner.  Default is False.</t>
---
> 	    the IPvX address owner.  The default is False.
> 	    Deployments that rely on, for example, pinging the address
> 	    owner's IPvX address may wish to configure Accept_Mode to
> 	    True.</t>

1001c1031
< 	    Advertisements should not be dropped when Accept_Mode is
---
> 	    Advertisements MUST not be dropped when Accept_Mode is

7) section 6.1 add "Virtual_Router_MAC_Address"

1003a1034,1038
> 	    <t hangText="Virtual_Router_MAC_Address">The MAC address
> 	    used for the source MAC address in VRRP advertisements
> 	    (and in some other cases as well).</t>
> 
> 

8) section 6.1.4 clarify what is meant by startup event 

1061c1096,1099
< 	  <t>The purpose of this state is to wait for a Startup
event.</t>
---
> 	  <t>The purpose of this state is to wait for a Startup event,
> 	  that is, an implementation defined mechanism that initiates
> 	  the protocol once it has been configured.  The configuration
> 	  mechanism is out of scope of this specification .</t>

9) section 6.4.2 clarify that grap ARP is for IPv4 addr.  s/should
not/MUST NOT/ when accept_mode is false 

1195,1197c1233,1236
< 		      <t>* Broadcast a gratuitous ARP request containing
< 		      the virtual router MAC address for each IPv4
< 		      address associated with the virtual router</t>
---
> 		      <t>* Broadcast a gratuitous ARP request on that
> 		      interface containing the virtual router MAC
> 		      address for each IPv4 address associated with
> 		      the virtual router</t>

1326a1366,1369
> 		  <t>+ if Accept_mode is False: MUST NOT drop IPv6
> 		  Neighbor Solicitations and Neighbor
> 		  Advertisements.</t>
> 
1339,1343d1381
< 	      <t>Note: IPv6 Neighbor Solicitations and Neighbor
< 	      Advertisements should not be dropped when Accept_Mode is
< 	      False.</t>
< 
< 	      

10) section 6.4.3 add to recompute skew_time 


1404,1405d1441
< 			  <t>@ Recompute the Master_Down_Interval</t>
< 
1408a1445,1448
> 			  <t>@ Recompute the Skew_Time</t>
> 
> 			  <t>@ Recompute the Master_Down_Interval</t>
> 

11) section 7.1 remove the MUST drop. 


1496,1500c1536,1537
< 	and MAY indicate via network management that a
< 	misconfiguration was detected.  If the packet was not
< 	generated by the address owner (Priority does not equal 255
< 	(decimal)), the receiver MUST drop the packet, otherwise
< 	continue processing.</t>
---
> 	and MAY indicate via network management that a misconfiguration
> 	was detected.</t>

1502c1539,1543
<       </section>
---
>         <!-- If the packet was not generated by the address owner
>         (Priority does not equal 255 (decimal)), the receiver MUST
>         drop the packet, and SHOULD log the event. -->
>  
>      </section>


12) section 8.1.2 remove text about implementation choosing vrrp macs.
add that for some appls, must use IP address known to belong to router. 

1589,1595d1629
< 	<t>For IPv6, each VRRP virtual router requires a link-local
< 	address.  If there are several VRRP routers, it is cumbersome
< 	for the operator to configure the same VRRP protected
< 	link-local address on all of them.  An implementation might
< 	choose simplify this for the operator by using the VRRP MAC in
< 	the formation of these link local addresses. </t>
< 
1635c1669
< 	  <t>When a VRRP router restarts or boots, it SHOULD not send
---
> 	  <t>When a VRRP router restarts or boots, it SHOULD NOT send

1650a1685,1688
> 
> 	      <t>When, for example, ssh access, to a particular VRRP
> 	      router is required, an IP address known to belong to
> 	      that router must be used. </t>


13) Move, FDDI etc to appendix B 

1795,1998d1832
< 
<     <section title="Operation over FDDI, Token Ring, and ATM LANE">
< 
<       <section title="Operation over FDDI">
< 
< 	<t>FDDI interfaces remove from the FDDI ring frames that have
< 	a source MAC address matching the device's hardware address.
< 	Under some conditions, such as router isolations, ring
< 	failures, protocol transitions, etc., VRRP may cause there to
< 	be more than one Master router.  If a Master router installs
< 	the virtual router MAC address as the hardware address on a
< 	FDDI device, then other Masters' ADVERTISEMENTS will be
< 	removed from the ring during the Master convergence, and
< 	convergence will fail.</t>
< 
< 	<t>To avoid this an implementation SHOULD configure the
< 	virtual router MAC address by adding a unicast MAC filter in
< 	the FDDI device, rather than changing its hardware MAC
< 	address.  This will prevent a Master router from removing any
< 	ADVERTISEMENTS it did not originate.</t>
< 	
<       </section>
< 
<       <section title="Operation over Token Ring">
< 
< 	<t>Token ring has several characteristics that make running
< 	VRRP difficult. These include:</t>
< 
< 	  <t><list style="symbols"> 
< 
< 	      <t>In order to switch to a new master located on a
< 	      different bridge token ring segment from the previous
< 	      master when using source route bridges, a mechanism is
< 	      required to update cached source route information.</t>
< 
< 	      <t>No general multicast mechanism supported across old
< 	      and new token ring adapter implementations. While many
< 	      newer token ring adapters support group addresses, token
< 	      ring functional address support is the only generally
< 	      available multicast mechanism. Due to the limited number
< 	      of token ring functional addresses these may collide
< 	      with other usage of the same token ring functional
< 	      addresses.</t>
< 
< 	  </list></t>
< 
< 	<t>Due to these difficulties, the preferred mode of operation
< 	over token ring will be to use a token ring functional address
< 	for the VRID virtual MAC address. Token ring functional
< 	addresses have the two high order bits in the first MAC
< 	address octet set to B'1'.  They range from 03-00-00-00-00-80
< 	to 03-00-02-00-00-00 (canonical format). However, unlike
< 	multicast addresses, there is only one unique functional
< 	address per bit position. The functional addresses
< 	03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by
< 	the Token Ring Architecture <xref target="TKARCH"/> for
user-defined
< 	applications.  However, since there are only 12 user-defined
< 	token ring functional addresses, there may be other non-IPvX
< 	protocols using the same functional address. Since the Novell
< 	IPX <xref target="IPX"/> protocol uses the 03-00-00-10-00-00
< 	functional address, operation of VRRP over token ring will
< 	avoid use of this functional address. In general, token ring
< 	VRRP users will be responsible for resolution of other
< 	user-defined token ring functional address conflicts.</t>
< 
< 	<t>VRIDs are mapped directly to token ring functional
< 	addresses. In order to decrease the likelihood of functional
< 	address conflicts, allocation will begin with the largest
< 	functional address. Most non-IPvX protocols use the first or
< 	first couple user-defined functional addresses and it is
< 	expected that VRRP users will choose VRIDs sequentially
< 	starting with 1.</t>
< 
< 	<figure align="center">
< 
< 	  <artwork align="left"><![CDATA[
<    VRID      Token Ring Functional Address
<    ----      -----------------------------
<       1             03-00-02-00-00-00
<       2             03-00-04-00-00-00
<       3             03-00-08-00-00-00
<       4             03-00-10-00-00-00
<       5             03-00-20-00-00-00
<       6             03-00-40-00-00-00
<       7             03-00-80-00-00-00
<       8             03-00-00-01-00-00
<       9             03-00-00-02-00-00
<      10             03-00-00-04-00-00
<      11             03-00-00-08-00-00
<             ]]></artwork>
< 
< 	</figure>
< 	
< 	<t>Or more succinctly, octets 3 and 4 of the functional
< 	address are equal to (0x4000 >> (VRID - 1)) in non-canonical
< 	format. </t>
< 
< 	<t>Since a functional address cannot be used as a MAC level
< 	source address, the real MAC address is used as the MAC source
< 	address in VRRP advertisements. This is not a problem for
< 	bridges since packets addressed to functional addresses will
< 	be sent on the spanning-tree explorer path <xref
< 	target="ISO.10038.1993"/>.</t>
< 
< 	<t>The functional address mode of operation MUST be
< 	implemented by routers supporting VRRP on token ring. </t>
< 
< 	<t>Additionally, routers MAY support unicast mode of operation
< 	to take advantage of newer token ring adapter implementations
< 	that support non-promiscuous reception for multiple unicast
< 	MAC addresses and to avoid both the multicast traffic and
< 	usage conflicts associated with the use of token ring
< 	functional addresses. Unicast mode uses the same mapping of
< 	VRIDs to virtual MAC addresses as Ethernet.  However, one
< 	important difference exists. ND request/reply packets contain
< 	the virtual MAC address as the source MAC address. The reason
< 	for this is that some token ring driver implementations keep a
< 	cache of MAC address/source routing information independent of
< 	the ND cache. Hence, these implementations have to
< 	receive a packet with the virtual MAC address as the source
< 	address in order to transmit to that MAC address in a
< 	source-route bridged network.</t>
< 
< 	<t>Unicast mode on token ring has one limitation that should
< 	be considered.  If there are VRID routers on different
< 	source-route bridge segments and there are host
< 	implementations that keep their source-route information in
< 	the ND cache and do not listen to gratuitous NDs, these hosts
< 	will not update their ND source-route information correctly
< 	when a switch-over occurs. The only possible solution is to
< 	put all routers with the same VRID on the same source-bridge
< 	segment and use techniques to prevent that bridge segment from
< 	being a single point of failure. These techniques are beyond
< 	the scope this document.</t>
< 
< 	<t>For both the multicast and unicast mode of operation, VRRP
< 	advertisements sent to 224.0.0.18 should be encapsulated as
< 	described in <xref target="RFC1469"/>.</t>
< 
<       </section>
< 
<       <section title="Operation over ATM LANE">
< 
< 	<t>Operation of VRRP over ATM LANE on routers with ATM LANE
< 	interfaces and/or routers behind proxy LEC's are beyond the
< 	scope of this document.</t>
< 
<       </section>
< 
<     </section>
< 
<     <section title="Security Considerations">
< 
<       <t>VRRP for IPvX does not currently include any type of
<       authentication.  Earlier versions of the VRRP (for IPv4)
<       specification included several types of authentication ranging
<       from none to strong.  Operational experience and further
<       analysis determined that these did not provide sufficient
<       security to overcome the vulnerability of misconfigured secrets
<       causing multiple masters to be elected.  Due to the nature of
<       the VRRP protocol, even if VRRP messages are cryptographically
<       protected, it does not prevent hostile routers from behaving as
<       if they are a VRRP master, creating multiple masters.
<       Authentication of VRRP messages could have prevented a hostile
<       router from causing all properly functioning routers from going
<       into backup state.  However, having multiple masters can cause
<       as much disruption as no routers, which authentication cannot
<       prevent.  Also, even if a hostile router could not disrupt VRRP,
<       it can disrupt ARP and create the same effect as having all
<       routers go into backup.</t>
< 
<       <t>It should be noted that these attacks are not worse and are a
<       subset of the attacks that any node attached to a LAN can do
<       independently of VRRP.  The kind of attacks a malicious node on
<       a LAN can do include promiscuously receiving packets for any
<       router's MAC address, sending packets with the router's MAC
<       address as the source MAC addresses in the L2 header to tell the
<       L2 switches to send packets addressed to the router to the
<       malicious node instead of the router, send redirects to tell the
<       hosts to send their traffic somewhere else, send unsolicited ND
<       replies, answer ND requests, etc., etc.  All of this can be done
<       independently of implementing VRRP.  VRRP does not add to these
<       vulnerabilities.</t>
<       
<       <t>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.</t>
<       
<       <t>VRRP does not provide any confidentiality.  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.</t>
< 
<       <t>In the context of IPv6 operation, if SEcure Neighbor
<       Discovery (SEND) <xref target="RFC3791"/> is deployed, VRRP
<       authentication could be usefully added, because misconfiguration
<       of secrets will not be an issue.  Routers with different secrets
<       will have different IPv6 addresses, and therefore there will be
no
<       issue with multiple masters with the same IPv6 (and MAC)
<       addresses.  Also, SEND will prevent malicious routers from
<       sending misleading ND messages.</t>
< 
<     </section>
2160c1994
<       &RFC3791;
---
>       &RFC3971;
2255c2089,2293
<     <section anchor="app4" title="Changes from
draft-ietf-vrrp-unified-spec-01">
---
>     <section anchor="app9" title="Operation over FDDI, Token Ring, and
ATM LANE">
> 
>       <section title="Operation over FDDI">
> 
> 	<t>FDDI interfaces remove from the FDDI ring frames that have
> 	a source MAC address matching the device's hardware address.
> 	Under some conditions, such as router isolations, ring
> 	failures, protocol transitions, etc., VRRP may cause there to
> 	be more than one Master router.  If a Master router installs
> 	the virtual router MAC address as the hardware address on a
> 	FDDI device, then other Masters' ADVERTISEMENTS will be
> 	removed from the ring during the Master convergence, and
> 	convergence will fail.</t>
> 
> 	<t>To avoid this an implementation SHOULD configure the
> 	virtual router MAC address by adding a unicast MAC filter in
> 	the FDDI device, rather than changing its hardware MAC
> 	address.  This will prevent a Master router from removing any
> 	ADVERTISEMENTS it did not originate.</t>
> 	
>       </section>
> 
>       <section title="Operation over Token Ring">
> 
> 	<t>Token ring has several characteristics that make running
> 	VRRP difficult. These include:</t>
> 
> 	  <t><list style="symbols"> 
> 
> 	      <t>In order to switch to a new master located on a
> 	      different bridge token ring segment from the previous
> 	      master when using source route bridges, a mechanism is
> 	      required to update cached source route information.</t>
> 
> 	      <t>No general multicast mechanism supported across old
> 	      and new token ring adapter implementations. While many
> 	      newer token ring adapters support group addresses, token
> 	      ring functional address support is the only generally
> 	      available multicast mechanism. Due to the limited number
> 	      of token ring functional addresses these may collide
> 	      with other usage of the same token ring functional
> 	      addresses.</t>
> 
> 	  </list></t>
> 
> 	<t>Due to these difficulties, the preferred mode of operation
> 	over token ring will be to use a token ring functional address
> 	for the VRID virtual MAC address. Token ring functional
> 	addresses have the two high order bits in the first MAC
> 	address octet set to B'1'.  They range from 03-00-00-00-00-80
> 	to 03-00-02-00-00-00 (canonical format). However, unlike
> 	multicast addresses, there is only one unique functional
> 	address per bit position. The functional addresses
> 	03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by
> 	the Token Ring Architecture <xref target="TKARCH"/> for
user-defined
> 	applications.  However, since there are only 12 user-defined
> 	token ring functional addresses, there may be other non-IPvX
> 	protocols using the same functional address. Since the Novell
> 	IPX <xref target="IPX"/> protocol uses the 03-00-00-10-00-00
> 	functional address, operation of VRRP over token ring will
> 	avoid use of this functional address. In general, token ring
> 	VRRP users will be responsible for resolution of other
> 	user-defined token ring functional address conflicts.</t>
> 
> 	<t>VRIDs are mapped directly to token ring functional
> 	addresses. In order to decrease the likelihood of functional
> 	address conflicts, allocation will begin with the largest
> 	functional address. Most non-IPvX protocols use the first or
> 	first couple user-defined functional addresses and it is
> 	expected that VRRP users will choose VRIDs sequentially
> 	starting with 1.</t>
> 
> 	<figure align="center">
> 
> 	  <artwork align="left"><![CDATA[
>    VRID      Token Ring Functional Address
>    ----      -----------------------------
>       1             03-00-02-00-00-00
>       2             03-00-04-00-00-00
>       3             03-00-08-00-00-00
>       4             03-00-10-00-00-00
>       5             03-00-20-00-00-00
>       6             03-00-40-00-00-00
>       7             03-00-80-00-00-00
>       8             03-00-00-01-00-00
>       9             03-00-00-02-00-00
>      10             03-00-00-04-00-00
>      11             03-00-00-08-00-00
>             ]]></artwork>
> 
> 	</figure>
> 	
> 	<t>Or more succinctly, octets 3 and 4 of the functional
> 	address are equal to (0x4000 >> (VRID - 1)) in non-canonical
> 	format. </t>
> 
> 	<t>Since a functional address cannot be used as a MAC level
> 	source address, the real MAC address is used as the MAC source
> 	address in VRRP advertisements. This is not a problem for
> 	bridges since packets addressed to functional addresses will
> 	be sent on the spanning-tree explorer path <xref
> 	target="ISO.10038.1993"/>.</t>
> 
> 	<t>The functional address mode of operation MUST be
> 	implemented by routers supporting VRRP on token ring. </t>
> 
> 	<t>Additionally, routers MAY support unicast mode of operation
> 	to take advantage of newer token ring adapter implementations
> 	that support non-promiscuous reception for multiple unicast
> 	MAC addresses and to avoid both the multicast traffic and
> 	usage conflicts associated with the use of token ring
> 	functional addresses. Unicast mode uses the same mapping of
> 	VRIDs to virtual MAC addresses as Ethernet.  However, one
> 	important difference exists. ND request/reply packets contain
> 	the virtual MAC address as the source MAC address. The reason
> 	for this is that some token ring driver implementations keep a
> 	cache of MAC address/source routing information independent of
> 	the ND cache. Hence, these implementations have to
> 	receive a packet with the virtual MAC address as the source
> 	address in order to transmit to that MAC address in a
> 	source-route bridged network.</t>
> 
> 	<t>Unicast mode on token ring has one limitation that should
> 	be considered.  If there are VRID routers on different
> 	source-route bridge segments and there are host
> 	implementations that keep their source-route information in
> 	the ND cache and do not listen to gratuitous NDs, these hosts
> 	will not update their ND source-route information correctly
> 	when a switch-over occurs. The only possible solution is to
> 	put all routers with the same VRID on the same source-bridge
> 	segment and use techniques to prevent that bridge segment from
> 	being a single point of failure. These techniques are beyond
> 	the scope this document.</t>
> 
> 	<t>For both the multicast and unicast mode of operation, VRRP
> 	advertisements sent to 224.0.0.18 should be encapsulated as
> 	described in <xref target="RFC1469"/>.</t>
> 
>       </section>
> 
>       <section title="Operation over ATM LANE">
> 
> 	<t>Operation of VRRP over ATM LANE on routers with ATM LANE
> 	interfaces and/or routers behind proxy LEC's are beyond the
> 	scope of this document.</t>
> 
>       </section>
> 
>     </section>
> 
>     <section title="Security Considerations">
> 
>       <t>VRRP for IPvX does not currently include any type of
>       authentication.  Earlier versions of the VRRP (for IPv4)
>       specification included several types of authentication ranging
>       from none to strong.  Operational experience and further
>       analysis determined that these did not provide sufficient
>       security to overcome the vulnerability of misconfigured secrets
>       causing multiple masters to be elected.  Due to the nature of
>       the VRRP protocol, even if VRRP messages are cryptographically
>       protected, it does not prevent hostile routers from behaving as
>       if they are a VRRP master, creating multiple masters.
>       Authentication of VRRP messages could have prevented a hostile
>       router from causing all properly functioning routers from going
>       into backup state.  However, having multiple masters can cause
>       as much disruption as no routers, which authentication cannot
>       prevent.  Also, even if a hostile router could not disrupt VRRP,
>       it can disrupt ARP and create the same effect as having all
>       routers go into backup.</t>
> 
>       <t>It should be noted that these attacks are not worse and are a
>       subset of the attacks that any node attached to a LAN can do
>       independently of VRRP.  The kind of attacks a malicious node on
>       a LAN can do include promiscuously receiving packets for any
>       router's MAC address, sending packets with the router's MAC
>       address as the source MAC addresses in the L2 header to tell the
>       L2 switches to send packets addressed to the router to the
>       malicious node instead of the router, send redirects to tell the
>       hosts to send their traffic somewhere else, send unsolicited ND
>       replies, answer ND requests, etc., etc.  All of this can be done
>       independently of implementing VRRP.  VRRP does not add to these
>       vulnerabilities.</t>
>       
>       <t>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.</t>
>       
>       <t>VRRP does not provide any confidentiality.  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.</t>
> 
>       <t>In the context of IPv6 operation, if SEcure Neighbor
>       Discovery (SEND) <xref target="RFC3971"/> is deployed, VRRP
>       authentication could be usefully added, because misconfiguration
>       of secrets will not be an issue.  Routers with different secrets
>       will have different IPv6 addresses, and therefore there will be
no
>       issue with multiple masters with the same IPv6 (and MAC)
>       addresses.  Also, SEND will prevent malicious routers from
>       sending misleading ND messages.</t>
> 
>     </section> 
> 
>     <section anchor="appa" title="Changes from
draft-ietf-vrrp-unified-spec-01"> 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[e-mail]] 
Sent: Tuesday, July 07, 2009 11:50 AM
To: Stephen Nadas
Subject: New Version Notification for draft-ietf-vrrp-unified-spec-03 


A new version of I-D, draft-ietf-vrrp-unified-spec-03.txt has 
been successfuly submitted by Stephen Nadas and posted to the 
IETF repository.

Filename:	 draft-ietf-vrrp-unified-spec
Revision:	 03
Title:		 Virtual Router Redundancy Protocol Version 3 
for IPv4 and IPv6
Creation_date:	 2009-07-07
WG ID:		 vrrp
Number_of_pages: 42

Abstract:
This memo defines the Virtual Router Redundancy Protocol (VRRP) for
IPv4 and IPv6.  It is version three (3) of the protocol and it 
is based on VRRP (version 2) for IPv4 that is defined in RFC 
3768 and on draft-ieft-vrrp-ipv6-spec-08.txt.  VRRP specifies 
an election protocol that dynamically assigns responsibility 
for a virtual router to one of the VRRP routers on a LAN.  The 
VRRP router controlling the
IPv4 or IPv6 address(es) associated with a virtual router is 
called the Master, and forwards packets sent to these IPv4 or 
IPv6 addresses.  VRRP Master routers are configured with virtual IPv4 or
IPv6 addresses and VRRP Backup routers infer the address family 
of the virtual addresses being carried based on the transport protocol.
Within a VRRP router the virtual routers in each of the IPv4 
and IPv6 address families are a domain unto themselves and do 
not overlap.
The election process provides dynamic fail over in the 
forwarding responsibility should the Master become unavailable. 
 For IPv4, the advantage gained from using VRRP is a higher 
availability default path without requiring configuration of 
dynamic routing or router discovery protocols on every 
end-host.  For IPv6, the advantage gained from using VRRP for 
IPv6 is a quicker switch over to back up routers than can be 
obtained with standard IPv6 Neighbor Discover (RFC 4861) mechanisms.
                                                                
                  


The IETF Secretariat.


_______________________________________________
vrrp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vrrp