Subject: RE: [VRRP] Security Issues with VRRP

From: [email-masked]
Date: Tue, 26 Nov 2002 10:56:15 -0800

Consider the following situation:

   1. Router A and Router B will be turned on within say 5 minutes of each other.
   2. Router A becomes master and is sending out advertisements every M seconds.
   3. Router B comes up after a while and has a mismatching auth password.
   4. B is setup to advertise every N seconds (N < M)
   5. Depending on the timing B may or may not see A's advertisment, and become Master. If it does not see a NACK, it will not revert to INIT state.
   6. Every (M*N) seconds, both A and B will see each other and send out authentication failure messages.
   7. We have a cascade of messages.  :)
 
I also have a problem with sending out a RESPONSE and/or NACK for every advertisement. This will make it look more and more like a TCP handshake defeating the purpose of VRRP.It can cause problems when the network is heavily loaded (RESPONSE packets getting lost etc.). 
As I suggested, the authentication need occur only once, once the other router is authenticated, the protocol reverts back to its "simple" state. 

-----Original Message-----
From: Gupta Mukesh (IPRG/MtView) 
Sent: Tuesday, November 26, 2002 10:35 AM
To: Prasad Balaji (NET/MtView)
Cc: [email-masked]
Subject: Re: [VRRP] Security Issues with VRRP

[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

"ext [email-masked]" wrote:

> 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

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