Subject: RE: [VRRP] Security Issues with VRRP

From: [email-masked]
Date: Tue, 26 Nov 2002 09:56:40 -0800

After reading through your description, I see the potential for a cascade of error messages being generated. 
This is because, there is no centralized location for validating the authentication password. Router A could well be having an incorrect password, or 
it is possible that router A was the "unauthorized" router in the network, whereas router B was legitimate. This scenario presumes that the router that comes up first is always the preferred gateway.
I see 2 solutions for implementing "proper" security here:

 1. Silently drop the packet and notify the administrator (as originally intended)
 2. Authenticate router B with a 3rd party agent, before permitting it to become Router A's peer.  The authentication need not be performed every time a VRRP advertisement is sent, but it is a good to do this once in a while.
This will ofcourse complicate the protocol, but its a compromise that may be required to enforce a degree of security.

Your comments.

Balaji

-----Original Message-----
From: ext PC Drew [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 9:26 AM
To: Gupta Mukesh (IPRG/MtView)
Cc: [email-masked]; [email-masked]
Subject: Re: [VRRP] Security Issues with VRRP

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?

Mukesh Gupta wrote:
> 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
> 
> ext Mukesh Gupta wrote:
> 
> 
>>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
> 
> 
> _______________________________________________
> vrrp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/vrrp

-- 
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

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

---

From: Mukesh Gupta <[email-masked]>
Date: Tue, 26 Nov 2002 10:34:44 -0800

[WG chair hat off]

There will not be any cascade or error messages. To implement what PC suggested, we will have to add one more packet type RESPONSE in the protocol and the negative acknowledgement (with type RESPONSE) will only be sent in
response to ADVERTISEMENTs.

But adding this negative acknowledgement doesn't solve the problem. As Balaji said, we don't know who in A and B is the legitimate router. Also it will be affected by who comes up first and we will need to define the response in
all 3 states (Init, Master, Backup).

VRRP was selected against HSRP because it was simple and it had just one type of message and 3 states. Adding one more type or the suggested 3rd party agent adds more complexity to it and defeats the purpose of keeping it simple.

The scenario in question is a misconfiguration or an attack and having 2 masters in this scenario is not a security breach. I think, we should go for:

- Silently drop the packet and notify the administrator

Comments.

regards
Mukesh

---

From: PC Drew <[email-masked]>
Date: Tue, 26 Nov 2002 12:39:42 -0700

Just out of curiosity, what is the cascade of error messages that you 
see?  Wouldn't Router B stop trying to initialize and not come up?

Also, I agree with your observation that there is no centralization for 
validating passwords.  Based on that, I think that the solution can only 
be one of two things:

1.  Centralize the authentication (as you're recommending).
2.  Agree that the router that is currently the Master is the authenticator.

Is option 2 really a bad option?  I'd rather not move to a centralized 
authentication scheme like RADIUS, TACACS, etc if possible.  However, I 
think that having those schemes as implementation options is a good idea 
(i.e. Acme VRRP implementation allows for authentication over RADIUS as 
well as stored passwords).

-- 
PC Drew
Manager, Client Services

IBSN

---

From: Bob Hinden <[email-masked]>
Date: Tue, 26 Nov 2002 11:12:04 -0800

One thing to keep in mind when thinking about the appropriate 
authentication measures in VRRP is that once a node is connected to a LAN, 
there are many attacks that can be performed.  For example an attacker can 
send bogus ARP replies, listen to all traffic, forward packets to new 
places, etc.  Strong authentication in VRRP doesn't help with any of 
these.  An attacker can disrupt communication a LAN without going to the 
trouble of implementing VRRP.  I suggest that it is better to focus on 
detecting misconfiguration, than worrying too much about using strong 
authentication to prevent attacks.

The consequences of being misconfigured only results in two masters that 
forward packets to the same destination.  This is better than having no 
VRRP routers forwarding traffic :-)

Solutions that inform the people configuring the routers via console 
messages, SNMP traps, etc., seem a reasonable approach to me.

Bob

---

From: Mukesh Gupta <[email-masked]>
Date: Tue, 26 Nov 2002 11:50:07 -0800

[WG chair hat ON]

I agree with Bob.

For the following reasons, I would prefer the solutions that will inform the
administrator about the authentication failure.

- Authentication mechanisms in VRRP (or in other routing protocols) do not
provide much security against various possible attacks on LANs.
- VRRP is supposed to be running in an enterprize network which is secured
from the internet via other means.
- There are many VRRP implementations already out there so making major
changes to the protocol will not be a good idea.

So please don't digress to new schemes and try to decide if "notifying the
administrator" is enough or not.

Anyone who thinks that "notifying the administrator about the authentication
failure" doesn't suffice, please speak up. If we don't hear anything back for
a week or so, I would consider the matter resolved.

regards
Mukesh

---

From: "Don Provan" <[email-masked]>
Date: Wed, 27 Nov 2002 10:01:23 -0800

Sounds like the right answer to me. So to refer this answer back to the
original problem report, we're saying that the following statement from
Ravi's complaint is no longer true:

"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."

To make this happen, the following text from draft-ietf-vrrp-spec-v2-06.txt
section 10.2 should be removed:

   "This type of authentication is useful to protect against accidental
   misconfiguration of routers on a LAN.  It protects against routers
   inadvertently backing up another router.  A new router must first be
   configured with the correct password before it can run VRRP with
   another router."

Perhaps we could replace this text with something saying the authentication
alarm alerts the operator to this problem, but nothing prevents it.

Will section 7.1 also change to make reporting an authentication failure a
MUST? Currently logging is a SHOULD and reporting is a MAY.

-don provan
[email-masked]

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mukesh Gupta
> Sent: Tuesday, November 26, 2002 11:50 AM
> To: [email-masked]