Subject: [VRRP] Security Issues with VRRP

From: Mukesh Gupta <[email-masked]>
Date: Mon, 25 Nov 2002 11:14:32 -0800

Here is the thread regarding security issues with VRRP. I am including
this so that everyone knows what the issue is. Please respond to this
email with what you think.

======= Original mail from Ravi
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.
========== Reply from PC Drew
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.
============

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Don Provan" <[email-masked]>
Date: Mon, 25 Nov 2002 12:12:49 -0800

Gee, I came on line just after the security flap has passed and thought it
was all settled because I thought I saw verbiage in the ID that seemed to
cover it. Well, if it's still under debate:

I think the response included in this summary pretty much covers the ground:
the problem isn't that authentication doesn't work, it's just that an
innocent yet misconfigured node winds up cut off from its intended peers and
happily negotiating with itself instead of reporting the authentication
failure and waiting. In general the proposed solution sounds right: a tweak
or two to the procedure should avoid that node thinking it should take
control if alls it's getting are authentication failures. A couple of fine
points to work out, but basically sound.

For security purposes, authentication works fine: an intruder cannot disrupt
a VRRP community without being authenticated. This authentication does
absolutely nothing to stop an intruder from sending bogus ARP messages and
trying to take control of the Virtual Router addresses, but, of course, that
has nothing to do with VRRP.

-don provan
[email-masked]

---

From: Vikram Pendharkar <[email-masked]>
Date: Mon, 25 Nov 2002 12:55:53 -0800 (PST)

I am not sure I understand PC Drew's solution from implementation point of view. Does it mean that while vrrp fsm is in initial state (and crunching away some cycles) vrrp advt. may be received which interrupts the vrrp fsm operation and causes the advt. to be processsed first?
If so, is there an assumption about the way vrrp would be implemented (and is the unmentioned part in the solution)? An assumption which is not made in the RFC (in the INITIAL state there is no mention of the event an advt is recvd.)
Vikram
 Mukesh Gupta <[email-masked]> wrote:
<snip>

<snip>

----
NO sense being pessimistic. It wouldnt work anyway

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

---

From: Mukesh Gupta <[email-masked]>
Date: Mon, 25 Nov 2002 13:25:22 -0800

Here is what I think as a WG member.
[WG chair hat off]

"No security" is not acceptable because a rogue or misconfigured router can
send VRRP advertisements with a higher priority and become the Master. The
valid current Master will switch to the Backup state and will stop
forwarding the traffic. If the rogue or misconfigured router is not
forwarding the traffic, the traffic is not forwarded at all.

Now consider the scnerio with the current authentication schemes, if the
rogue or misconfigured router sends VRRP advertisements that fail the
authentication check, the valid Master still remains the Master and the
rogue or misconfigured router also becomes the Master. Though we have 2
Masters and both of them are forwarding the traffic, it is at least better
than dropping the packets all together.

If a router is receiving VRRP advertisements which do not pass the
authentication checks, there can be 2 reasons:
- Someone is building these packets to crack VRRP. [VRRP being attacked]
- Someone misconfigured the other router

In both the cases, the best thing is to let the administrator know. I would
suggest adding something like the following line in the specs:

"The authentication failure event MUST be conveyed to the administrator via
logging an error and sending a vrrpTrapAuthFailure trap. The error and trap
SHOULD contain the source IP address of the packet that failed the
authentication check."

Comments ??

regards
Mukesh

---

From: PC Drew <[email-masked]>
Date: Tue, 26 Nov 2002 10:26:21 -0700

After reading through this thread and Ravi's response to my original 
response, I believe I misunderstood what he was asking.  Ravi is 
describing a situation where the misconfigured router doesn't know it's 
misconfigured and so it tries to become the master.

Here's an example scenario:

Router A:
     - owns the Virtual IP (it is by default the master)
     - has a password of "correct_password"
     - was initialized at 8:00AM

Router B:
     - is intended to be a backup
     - has a password of "incorrect_password"
     - was initialized at 9:00AM

When Router A comes up, it takes over as the master because there are no 
  backups (Router B is still down).  At 9:00AM, when Router B comes up, 
it sends an advertisement which is dropped by Router A because the 
password is wrong.  After the Master_Down_Timer fires (because no 
response was received) it thinks that the Master is down and transitions 
to the Master state.

I think the only solution to the above scenario is to not only require 
that Router A notify network administrators of a configuration error, 
but it should also respond to Router B's advertisement with an 
acknowledgement.  The acknowledgement in this case would be a negative 
acknowledgement with a reason of "misconfigured password" or something.

In fact, all of the checks mentioned in section 7.1 of the RFC probably 
ought to have a response:

       - MUST verify that the IP TTL is 255.
       - MUST verify the VRRP version
       - MUST verify that the received packet length is greater than or
         equal to the VRRP header
       - MUST verify the VRRP checksum
       - MUST perform authentication specified by Auth Type
       - MUST verify that the VRID is valid on the receiving interface
       - MAY verify that the IP address(es) associated with the VRID are
         valid

Are there any security concerns with generating negative 
acknowledgements instead of silently dropping the packets?

-- 
PC Drew
Manager, Client Services

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

Email: [email-masked]
Phone: 303-984-4727
Cell: 720-841-4543
Fax: 303-984-4730