headers
Smith, Mark - Sydney | 3 May 2002 02:23
Picon

RE: Q's about VRRPv3 draft

Hi Bob,

Sorry not to get back to you sooner. I've been a bit busy recently preparing
for a product launch. At least I've had plenty of time to think a few things
through.

<snip>

> 
> Care to suggest some text?  I submitted a new VRRP (for IPv4) 
> draft so the 
> other clarifications could included in a new RFC.  This could 
> be added as well.
> 

I'll do a bit more thinking about this, I thought I needed to get back to
you with something ... I've added a few things below.

> > > >8.2  ND Neighbour Solicitation
>

<snip>

> I added text to the new VRRP for IPv6 draft.  Does this suffice?
> 

It certainly does. There is a tiny grammar error though - "hosts" probably
should be "host's"

VRRP for IPv4 would also benefit from a paragraph specifying similar
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aron Silverton | 6 May 2002 18:33
Picon

KAME VRRP Plans

To all those interested, it appears:

http://www.kame.net/roadmap-2002.html

that the KAME project has plans to implement VRRPv3 with work beginning 
in October '02 and scheduled for completion by March '03.

Aron

--

-- 
Aron J. Silverton
Motorola Laboratories, Networks and Infrastructure Research
Motorola, Inc.

Telephone: 847-576-8747    
Fax: 847-576-3420
Pager: 800-759-8888 PIN 1147344
mailto: Aron.J.Silverton <at> Motorola.com
Permalink | Reply | 0 comments |
headers
Ravi Singh | 14 May 2002 22:50
Picon

VRRP: authentication -- really required ??

Hello!

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 ?
(Continue reading)

Permalink | Reply | 2 comments |
headers
PC Drew | 15 May 2002 14:08

Re: VRRP: authentication -- really required ??

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.

--On Tuesday, May 14, 2002 01:50:54 PM -0700 Ravi Singh 
<ravsingh <at> IPRG.nokia.com> wrote:

> Hello!
>
> 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.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ravi Singh | 15 May 2002 19:55
Picon

Re: VRRP: authentication -- really required ??

Please see inline....

> Date: Wed, 15 May 2002 06:08:31 -0600
> From: PC Drew <drewpc <at> ibsncentral.com>
> To: vrrp <at> drcoffsite.com
> Subject: Re: VRRP: authentication  -- really required ??
>
> 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.

Isn't there an assumption being made here that the misconfigured one is
coming up (in INIT state) when there already is a master. On a LAN, where
routers never crash/reboot and where it is possible to ensure that the
misconfigured  (from auth viewpoint) router will come up after master
election (among properly configured ones) has already happened this will
work,provided the protocol is changed to REQUIRE a router be in INIT state
for about 3*AdvTime.
However, are the above assumptions, fair assumptions to make ?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane