Mailing List Archive: Securing VRRP/VRRP-E?

Securing VRRP/VRRP-E?

Apr 6, 2004, 5:13 PM

Post #1 of 4 (1451 views)

All:

Anyone know if Foundry is looking at securing VRRP/VRRP-E on their
boxes? I looked at RFC2338 and there is an additional authentication
type that I don't see as an option.

----------

10.3 IP Authentication Header

The use of this authentication type means the VRRP protocol exchanges
are authenticated using the mechanisms defined by the IP
Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP
and AH", [HMAC]. This provides strong protection against
configuration errors, replay attacks, and packet
corruption/modification.

This type of authentication is RECOMMENDED when there is limited
control over the administration of nodes on a LAN. While this type
of authentication does protect the operation of VRRP, there are other
types of attacks that may be employed on shared media links (e.g.,
generation of bogus ARP replies) which are independent from VRRP and
are not protected.

----------

ssh@Foundry(config-vif-69)#ip vrrp-e auth
no-auth No authentication
simple-text-auth Simple text authentication
ssh@Foundry(config-vif-69)#ip vrrp auth
no-auth No authentication
simple-text-auth Simple text authentication

----------

Devon

Securing VRRP/VRRP-E? [ In reply to ]

niels=foundry-nsp at bakker

Apr 7, 2004, 9:47 AM

Post #2 of 4 (1430 views)

Permalink

* devon@noved.org (Devon) [Tue 06 Apr 2004, 23:18 CEST]:
> Anyone know if Foundry is looking at securing VRRP/VRRP-E on their
> boxes? I looked at RFC2338 and there is an additional authentication
> type that I don't see as an option.

Although it seems like a better thing than simple authentication to
use on networks with untrusted hosts on it, I'm unaware of any vendor
implementing this...

-- Niels.

--

Securing VRRP/VRRP-E? [ In reply to ]

devon at noved

Apr 7, 2004, 6:05 PM

Post #3 of 4 (1467 views)

Permalink

Niels,

> Although it seems like a better thing than simple authentication to
> use on networks with untrusted hosts on it, I'm unaware of any vendor
> implementing this...

It looks like Juniper has MD5 authentication.

<http://www.juniper.net/techpubs/software/junos/junos56/swconfig56-interfaces/html/interfaces-ethernet-config25.html>

----------

"authentication can be none, simple, or md5. The authentication type
must be the same for all routers in the VRRP group."

----------

However, I don't see the same option for Cisco.

<http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7ec3.html#wp1079676>

----------

"When a VRRP packet arrives from another router in the VRRP group, its
authentication string is compared to the string configured on the local
system. If the strings match, the message is accepted. If they do not
match, the packet is discarded.

All routers within the group must be configured with the same
authentication string.

Note that plain text authentication is not meant to be used for
security. It simply provides a way to prevent a misconfigured router
from participating in VRRP. "

----------

I would like to see Foundry use some form of stronger authentication
than plain-text. Has no one else complained about the lack of security?
Or is this something we just "deal with"? Any Foundry people willing to
talk about it?

I'll ping our sales rep, but I am curious to know if anyone has thought
about this issue and if anyone has taken steps to limit their exposure.

Devon

Securing VRRP/VRRP-E? [ In reply to ]

niels=foundry-nsp at bakker

Apr 7, 2004, 6:28 PM

Post #4 of 4 (1438 views)

Permalink

* devon@noved.org (Devon) [Thu 08 Apr 2004, 00:05 CEST]:
[vrrp]
> It looks like Juniper has MD5 authentication.

Indeed, you're right:

---
[.edit interfaces fe-0/0/1 unit 0 family inet address 192.168.1.3/24 vrrp-group 123]
niels@junix# set authentication-type ?
Possible completions:
md5 HMAC-MD5-96
simple Simple password
---

Too bad the Cisco this particular Juniper is talking VRRP with doesn't
support it! ;)

---
Rtr1(config-if)#vrrp 123 auth ?
text TEXT authentication
---

> I'll ping our sales rep, but I am curious to know if anyone has thought
> about this issue and if anyone has taken steps to limit their exposure.

If you want to keep collocated customers from participating in your VRRP
setup you could use port security to lock them down to one MAC address,
keeping them from sourcing ARP replies from the virtual address.
Doesn't address the normal insecurity of ARP, though, but neither would
supporting better crypto in VRRP...

I agree that a statement from Foundry whether this will be supported
would be nice to see on this list.

To answer your question, I'm not running VRRP on Ethernets with
untrusted machines, so the risk exposure here is limited. Unused switch
ports are disabled or in the default (non-production) VLAN.

-- Niels.

--