And some security comments

Since I'm about to disappear again, I thought I'd
make some preliminary security observations, although
I'd prefer waiting for the answers to some of my
basic vrrp questions first.

1) I have a lot of sympathy with whoever said that
there are so many ways of doing DOS with bridges
and LANs, that it's overkill to do heavy-handed crypto.

2) "use AH" isn't a completely specified answer.
What is the SPI? What is the sequence number?
What do you do as a result of seeing a particular
sequence number? Is it allowed to wrap around?
What if someone transmits something with the
highest possible sequence number?

3) AH does not seem like an appropriate solution.
Why protect the IP header? (which I'd think
shouldn't be there either...this is a local-to-a-LAN
protocol...the IP header doesn't do anything for you).
I'd think it would be more straightforward to
replace the cleartext password with a keyed hash,
and some very careful specification of sequence
number discipline. AH (or ESP) is much more appropriate
for 2-party communication.

4) After careful analysis it really might be
decided that crypto is not really appropriate.
Or even passwords (see my other note about asking

naive VRRP questions

Hi. I'm just jumping into this since I've been asked to
comment about VRRP's security. So it seemed prudent
to first try to understand VRRP. I think I do, but
I have some questions. My next email will specifically
comment on the security.

1) Why are there multiple IP addresses for the virtual
router? I gathered that to allow load splitting,
you might have two default router IP addresses; R1 and R2,
and configure half the endnodes to use R1 and half to
use R2. So I'd assume there might be two elections
going on...one for becoming "R1" and one for becoming
"R2".

2) Maybe because I'm confused about 1)...what is the
"virtual router ID"? I'd think they could fight
about becoming "R1" without also having to be
configured with a virtual router ID.

3) Maybe this is the reason for 2).. If you had
an arbitrary IP address "R1" it wouldn't be immediately
obvious which MAC address to use... since "R1" would
be 4 bytes, there isn't enough space in a MAC
address to embed it. So is that why the VRID,
so that there would be a 2-byte quantity that
would be able to be plopped into a MAC address?
If that's the whole reason for it, I'd suggest using
the bottom 2 bytes of "R1". Maybe occasionally you'd
intend to have 2 routers and they'd both map to

VRRPv3 Review

Hi All,

VRRPv3 draft is now available for your review. I request everyone to please spare some time and
review the draft.

I would specially request people who have implemented VRRPv3 to share their implementation
experience with the WG and comment on the draft.

regards
Mukesh

"ext Internet-Drafts <at> ietf.org" wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF.
>
>         Title           : Virtual Router Redundancy Protocol for IPv6
>         Author(s)       : R. Hinden
>         Filename        : draft-ietf-vrrp-ipv6-spec-03.txt
>         Pages           : 31
>         Date            : 2002-12-6
>
> This memo defines the Virtual Router Redundancy Protocol (VRRP) for
> IPv6.  It is version three (3) of the protocol.  It is based on the
> original version of VRRP (version 2) for IPv4 that is defined in
> RFC2338.
> VRRP specifies an election protocol that dynamically assigns
> responsibility for a virtual router to one of the VRRP routers on a
> LAN.  The VRRP router controlling the IP address associated with a
> virtual router is called the Master, and forwards packets sent to

Slashdot VRRP

http://books.slashdot.org/books/02/12/07/1320239.shtml?tid=95

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Re: And some security comments

I agree with your points.  if the working group had
largely done a cut-n-paste of ospf or ripv2 or any other
protocol usage of md5 to create a digest then vrrp
strong authentication specification would have been
completed long ago.

my perception on why vrrp working group didn't take that
tack at the time was that ietf preferred to leverage
ipsec protocols as standardized security and
authentication rather than having every working group
spin its own solutions.  then once headed down that path
AH seems the appropriate ipsec protocol since
privacy/encryption were not really a concern.  to me the
fact that AH would additionally cover the IP header
seems largely a non-issue and inconsequential extra
overhead.

your stream of issues within point (2) sums up a number
of reasons why vrrp AH mode still does not exist.  no
one has spent the time and effort to go through and
understand all those issues and document solution.  at
the time vrrp was being developed I remember pim and
other working groups seemed to have very similar
security issues and discussion; how to authenticate
multicast group-based protocol and leverage ipsec
protocols.  it was my hope that one of those groups or a
specific working group chartered for this sole purpose
would develop a standard or template solution.  then all
that would be required by vrrp working group is to
reference the standardized solution.  I guess expecting 

Re: naive VRRP questions

> 1) Why are there multiple IP addresses for the virtual
> router? I gathered that to allow load splitting,
> you might have two default router IP addresses; R1 and R2,
> and configure half the endnodes to use R1 and half to
> use R2. So I'd assume there might be two elections
> going on...one for becoming "R1" and one for becoming "R2".

I think the multiple addresses within a single virtual router
was a request to simplify configuration and protocol overhead
in support for a single link running multiple IP subnet.  
e.g. if router R1 has addresses 10.1.1.1/8, 172.16.1.1/16,
and 192.168.1.1/24 they can all be backed up & failed over
as a unit using a single virtual router.

> 2) Maybe because I'm confused about 1)...what is the
> "virtual router ID"? I'd think they could fight
> about becoming "R1" without also having to be
> configured with a virtual router ID.

as I see it the primary usage of the vrid is it 
provides a unique value per-link to derive vmac.

> 3) Maybe this is the reason for 2).. If you had
> an arbitrary IP address "R1" it wouldn't be immediately
> obvious which MAC address to use... since "R1" would
> be 4 bytes, there isn't enough space in a MAC
> address to embed it. So is that why the VRID,
> so that there would be a 2-byte quantity that
> would be able to be plopped into a MAC address?
> If that's the whole reason for it, I'd suggest using

Configuration Question

Re: Configuration Question

my opinion on vrrp security

Now that I think I understand vrrp...

1) I definitely think you should remove the 2nd
form of security (cleartext password). It does not
solve any sort of malicious stuff, and it adds
a new form of misconfiguration, and doesn't solve
any form of nonmalicious misconfiguration.

2) I think you should not bother with cryptographic
security either. What does the security prevent?
   a) having multiple routers answering ARPs for IP address "R1"?

   
   No. It doesn't prevent that. You don't have to win the vrrp
   election in order to answer ARPs.

   
   b) having zero routers answering ARPs for IP address "R1"?

   This is more plausible...that a malicious guy would win the
   vrrp election, but then not do the job of forwarding packets.

   But again, I think he can simply respond to ARPs to "R1" and
   not forward. It could be the real guy will also respond to ARPs,
   but if the malicious guy later does an ARP query (isn't that the
   thing that causes people who have "R1" in their ARP cache to
   update the entry if it's changed?) to some other MAC address,
   he can simply not forward packets.

I think a security considerations section could make a good case
that vrrp does not cause any security problems more than already
exists, so adding vrrp with no cryptographic security does not
make the LAN any less secure.

Radia

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

Choices for Security in VRRP

Thanks Radia.

If people don't have any comments on what Radia suggested, we have 2
choices infront of us:

Choice 1: We remove the security completely from VRRP explaining why it
is not needed in the security consideration section. This includes
modifying the VRRP header and affecting all the existing
implementations.

Choice 2: We leave the security section as it is and "notify the
administrator" for authentication failure. This needs less changes. The
RFC just recommends and discusses all the authentication types. None of
them is a MUST requirement in the RFC. This leaves the choice to the
implementor or administrator.

I would like to know what WG members will prefer. I would appreciate if
people can send a mail with the choice they would prefer or they would
NOT prefer.

regards
Mukesh

ext Radia Perlman - Boston Center for Networking wrote:

> Now that I think I understand vrrp...
>
> 1) I definitely think you should remove the 2nd
> form of security (cleartext password). It does not
> solve any sort of malicious stuff, and it adds
> a new form of misconfiguration, and doesn't solve
> any form of nonmalicious misconfiguration.
>
> 2) I think you should not bother with cryptographic
> security either. What does the security prevent?
>    a) having multiple routers answering ARPs for IP address "R1"?
>
>
>    No. It doesn't prevent that. You don't have to win the vrrp
>    election in order to answer ARPs.
>
>
>    b) having zero routers answering ARPs for IP address "R1"?
>
>    This is more plausible...that a malicious guy would win the
>    vrrp election, but then not do the job of forwarding packets.
>
>    But again, I think he can simply respond to ARPs to "R1" and
>    not forward. It could be the real guy will also respond to ARPs,
>    but if the malicious guy later does an ARP query (isn't that the
>    thing that causes people who have "R1" in their ARP cache to
>    update the entry if it's changed?) to some other MAC address,
>    he can simply not forward packets.
>
> I think a security considerations section could make a good case
> that vrrp does not cause any security problems more than already
> exists, so adding vrrp with no cryptographic security does not
> make the LAN any less secure.
>
> Radia
>
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp