Subject: VRRP: authentication -- really required ??

From: Ravi Singh <[email-masked]>
Date: Tue, 14 May 2002 13:50:54 -0700 (PDT)

Hello!

VRRP for IPv4 (RFC 2338) and VRRP for IPv6
(draft-ietf-vrrp-ipv6-spec-02.txt - Feb 28, 2002), have a section on
security considerations.

In my opinion, these sections are not required because trying to do
auth checks on VRRP packets serves no purpose.

The intended aim is to ENSURE that there is only 1 master for a certain
VRID, on a LAN. And that the master be THE ONE with the highest priority
among the set of correctly configured VRRP routers for this VRID.

This can NOT be ensured by the authentication schemes as described in VRRP
RFC/draft.

Scenario:
On a certain LAN, there is a bunch of routers configured for a certain
VRID. They are all configured with the same authentication mechanism with
identical parameters. The router, in this group, with the highest priority
would become the master (say M).
Now, lets assume another router (say X) comes up configured for the
same VRID as the group above. If X is configured such that its
authentication parameters are different from those of the group, then it
will ultimately (after 3*AdvInterval) also change state to master for the
same VRID. This would happen because X would discard the received
advertisements from M (due to auth failure) and after 3*AdvInterval it
would assume there is no correctly configured master. And X would
also assume mastership. The question boils down to, how does either of X
or M know that is NOT the mis-configured one ?
Now, X also starts sending out periodic advertisements. These
advertisements are rejected by the original group (auth failure). So there
are 2 masters at the same time for the same VRID, caused by authentication
failure.

Therefore, the original problem that we were trying to solve, remains
unsolved.
I cant come up with any scenario where authentication solves the problem.

So, why have authentication fields in VRRP packets at all?

Modifying the authentication schemes by complex key exchange mechanisms
also may not solve the problem. That would still not prevent some node
from sending out VRRP advertisments using a simple traffic generator
without caring for the auth fields.

So, would it not be a good idea to remove the authentication sections from
(and make corresponding changes to the packet format to) the VRRP for v6
draft.

Also, would it make sense to do similar stuff with RFC-2338 ?

Regards
Ravi.

---

From: PC Drew <[email-masked]>
Date: Wed, 15 May 2002 06:08:31 -0600

You bring up an excellent point: death by mis-configuration is not good.  I 
wonder, however, if a solution is simply to rearrange some statements in 
section 7.1 of the RFC?  Section 7.1 says validate TTL, VRRP version, 
packet length, checksum, and authentication.  Then validate that the VRID 
is valid for the receiving interface.

A solution to the problem you bring up is to verify that the VRID is valid 
on the reciving interface, then perform the authentication.  If the 
authentication fails and it's in an initial state, then the VRRP 
implementation should believe it is misconfigured and may notify network 
management of the misconfiguration and NOT try to become a master.  On the 
flip side, if authentication fails and it's not in an initial state (i.e. 
it's already a backup or a master), it must drop the packet and may notify 
network management of a misconfiguration on the part of the sender.

With regard to your other point about not needing authentication, I 
disagree.  Without authentication, it becomes much easier to forge VRRP 
packets and disrupt entire flows of traffic.  While nothing can be 
completely secure, I consider authenticating these kinds of control packets 
a must on the public internet.

--
PC Drew

IBSN
12600 W. Cedar Drive, Suite 100
Lakewood, CO 80228

Email: [email-masked]
Phone: 303-984-4727
Fax: 303-984-4730

---

From: Ravi Singh <[email-masked]>
Date: Wed, 15 May 2002 10:55:02 -0700 (PDT)

Please see inline....

> Date: Wed, 15 May 2002 06:08:31 -0600
> From: PC Drew <[email-masked]>
> To: [email-masked]
> Subject: Re: VRRP: authentication  -- really required ??
>

Isn't there an assumption being made here that the misconfigured one is
coming up (in INIT state) when there already is a master. On a LAN, where
routers never crash/reboot and where it is possible to ensure that the
misconfigured  (from auth viewpoint) router will come up after master
election (among properly configured ones) has already happened this will
work,provided the protocol is changed to REQUIRE a router be in INIT state
for about 3*AdvTime.
However, are the above assumptions, fair assumptions to make ?
I dont think so.

> a must on the public internet.

I agree that authentication is good to have, provided it achieves some
purpose. However, in my opinion that is not the case here. It is just
being an overhead here.

Ravi.