Subject: Comments on VRRP-spec-06 Draft

From: "M. T. Hollinger" <[email-masked]>
Date: Thu, 2 Apr 1998 20:16:41 -0500

Prodded by the discussion at the WG session yesterday, I took another look
at the VRRP spec.  This document has come a long way since I last read it,
but I believe there is still room for refinement.  Various technical
comments follow.

>5.2.3  TTL
>
>  The TTL MUST be set to 255.  A VRRP router receiving a packet with
>   the TTL not equal to 255 MUST discard the packet.

Although I've heard some of the arguments for the choice of 255, I am
unconvinced.  When all the routers on the LAN are behaving properly, they
won't forward the packet regardless of IP TTL.  So why not set the field
to something more representative of expected behavior, such as 1?  That
would be a lot less scary for the poor guy trying to troubleshoot the
network, looking at packet traces and knowing very little about VRRP.

>5.3.4  Priority
>...
>  VRRP routers backing up a virtual router MUST use priority values
>  between 1-254 (decimal).  The default priority value for VRRP routers
>  backing up a virtual router is 100 (decimal).

It might be nice to emphsize right up front that when there are multiple
backup routers, their priorities should be widely distributed.  For
example, if you set the priority to100 on backup router B1 and 99 on B2,
then both routers would try to take over about 3.61 seconds after the
master sent its last advertisement.  By setting B1's priority to 150 and
B2's to 50, you would more likely avoid a brief period when B1 and B2 each
consider themselves the master.  B1 would send out an advertisement 3.41
seconds.  B2 would have time to notice this before its timer expired, at
3.81 seconds, and not try to become the new master.

Clearly, the authors of the draft already know this, but the readers of it
may not.  One added sentence would help, something like: For faster
convergence after a transition, backup routers should be assigned priority
values which are widely distributed.

> 7.1  Receiving VRRP Packets

Although I realize an implementation would not have to perform its checks
in the same order specified in the draft, I would still like to see them
specified in a reasonable order.  Specifically, it would make sense to
check for a valid VRID before bothering to compute the checksum or perform
authentication.  If there are other virtual routers on the LAN, there will
be a lot of packets coming in with VRID's you don't care about.  The
faster you can discard those uninteresting packets, the better.

>      - MUST perform authentication specified by Auth Type

I'd break this bullet item into two:

       - MUST verify that Auth Type contains the expected value
       - MUST perform authentication as expected for this VRID

In other words, if I'm configured to expect an Authentication Header, but
a packet comes in specifying an Auth Type of 0, it's a bogus advertisement
and should be discarded.

>      - MUST verify that the Adver Interval in the packet is the same as
>       the locally configured for this virtual router
>
>   If the above check fails, the receiver MUST discard the packet,
>   SHOULD log the event and MAY indicate via network management that a
>   misconfiguration was detected.

I quite object to this one.  Suppose some network administrator decides
to change his advertisement interval from 1 second to 2.  But maybe he
misses one router, or maybe it was down for maintenance at the time of
the change, or maybe he's trying to be clever by setting a different value
on the backup router from what the master uses.  In any case, a
misconfiguration exists, but logging that fact really isn't enough.

The way the draft reads now, the backup router will discard the master's
advertisements due to the mismatch and start sending out advertisements of
its own.  These will confuse the bridges, with their spanning tree
algorithm, and create instability on the LAN.  If the backup is on the
same LAN segment as the master, then it will start forwarding a second
copy of each and every outbound packet sent to the VR.  This will continue
indefinitely, perhaps for days or weeks, until the network administrator
notices the log and corrects the misconfiguration.

A better way to handle this error would be for the backup routers to just
stay in Backup state.  Or maybe they could update their advertisement
interval (if the one in the packet is in a reasonable range), log the
event, and continue.  I'm not sure what the right behavior is, but
discarding the packet and allowing two masters at once isn't the answer.

A similar argument could be made for other cases in which the
authentication checks out but the rest of the packet is flawed.  A backup
router should just back off, log the problem, and let the
differently-configured master continue its work.

>7.2 Transmitting VRRP Packets
>...
>      - Set the source MAC address to Virtual Router MAC Address

I really think this, and other uses of the VR MAC address, should be an
optional part of the protocol.  With most existing host implementations
out there, sending unsolicited ARP messages to update the MAC address
after router failover will work just fine.  Particularly with unusual LAN
topologies (including FDDI and Token Ring), use of the VR MAC address is
problematic.  If it creates problems and is unnecessary, why make the use
of that MAC address a required part of VRRP?

>8.1 ICMP Redirects
>   The IP source address of an ICMP redirect should be the address the
>   end host used when making its next hop routing decision.

That's easier said than done, and may not always be possible.  If a
particular virtual router serves multiple addresses, and two or more of
the addresses are in the same subnet, then there is no way to tell which
one the host used.  Of course, this problem is not unique to VRRP routers;
any router would have the same limitation.

>   When a VRRP router restarts or boots, it SHOULD not send any ARP
>   messages with its physical MAC address for the IP address it owns, it
>   should only send ARP messages that include Virtual MAC addresses.
>   This may entail:
>
>    - When configuring an interface, VRRP routers should broadcast a
>      gratuitous ARP request containing the virtual router MAC address
>      for each IP address on that interface.

I wouldn't send any ARP requests at boot or interface configuration time.
If we're to become the Master, the ARP messages will be sent upon VRRP
startup anyway -- no need to send them twice.  And if we're the backup,
with the master already up and running elsewhere on the LAN, then sending
ARP messages using the VR MAC address will just confuse the bridges into
thinking that station is now on our local segment (when in fact it hasn't
moved).

>8.3 Proxy ARP
>
>   If Proxy ARP is to be used on a VRRP router, then the VRRP router
>   must advertise the Virtual Router MAC address in the Proxy ARP
>   message.  Doing otherwise could cause hosts to learn the real MAC
>   address of the VRRP router.

Well, that would depend on the reason for doing proxy ARP.  If the router
is doing proxy ARP for the entire Internet, as a way to avoid configuring
a particular default gateway on the hosts, then sure, use the VR MAC
address.  But if the router is doing proxy ARP for some host to which it
alone is able to reach (by serial line, radio link, infrared, ...), as a
way to avoid allocating a subnet, then the router should use its own MAC
address in the proxy ARP response.

                  Mark  "MyTH"

---

From: Scott Barvick <[email-masked]>
Date: Fri, 03 Apr 1998 17:11:50 -0500

I said I would post something on the authentication so I'll do it along
with my comments on the following issues:

M. T. Hollinger wrote:
...
> network, looking at packet traces and knowing very little about VRRP.

Agree.
 
> values which are widely distributed.

Agree with the need for at least a statement about distributing the
values, but aren't we really saying that this part of the operation is
overengineered?  We need some algorithm to pick a timer value, but I
expect that few implementers will be strict about the timer value if it
doesn't fit with timer services already implemented.  It is good to try
to minimize changing masters by giving higher priority backups a bit of
an edge in time, but if we don't expect people to really implement it
that way, we may just want to define Skew_Time as something like (Sec
6.1.2):

"Time to skew Master_Down_Timer in seconds.  The specific calculation is
an implementation-specific function of virtual router priority that
produces a value between 0 and 1 second with the property that higher
priorities result in Skew_Times less than or equal to those of lower
priorities."

Of course, this may result in different vendor implementations causing
different resulting Skew_Times, but that is why we actually do the real
priority processing on received advertisements. 

...
...
> differently-configured master continue its work.

I agree strongly with this one.  It is far too easy to end up with two
masters.  

Authentication:
I suggest removing the text in the draft (Sections 5.3.6 and 5.3.6.3)
and MIB (vrrpOperHMACMD5Key) concerning MD5 authentication. Even though
OSPF allows this, I find it unlikely that anyone would bother putting
the keys in each VRRP router configuration.  Additionally, Section
5.3.10 of the protocol draft effectively defers support for this
capability.  I think that very soon we will have IPSec transport SA
security of all router to router communications (OSPF, VRRP, BGP, etc)
and to put the capability in each protocol is not the right way to go. 
This leaves the simple text password as a useful, but hardly secure,
sanity check.  I don't have any problems leaving that in as is. 

-- 
Scott Barvick
[email-masked]
(978) 952-6000 x162