[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VRRP] Clear draft-ietf-vrrp-unified-spec 6
Hi Stephen,
Yes, the proposed text would address the 1st part of my discuss.
Best regards,
Pasi
> -----Original Message-----
> From: ext Stephen Nadas [mailto:stephen.nadas at ericsson.com]
> Sent: 03 October, 2009 00:54
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: adrian.farrel at huawei.com; Radia.Perlman at Sun.COM; Mukesh Gupta;
> vrrp at ietf.org
> Subject: Clear draft-ietf-vrrp-unified-spec 6
>
> Hi Pasi,
>
> With respect to your 1st part of discuss (2nd part still in process):
>
> The security considerations text basically says security doesn't
> have
> to be considered here because an attacker can cause havoc with
> ARP
> anyway. I don't think this is fully accurate description. Many
> networks with untrusted hosts use switch security features that
> prevent hosts from bringing down the network with spoofed ARP
> packets
> (somewhat similar to what SAVI WG is working on). While
> compromising
> one of the switches or routers would still cause damage,
> compromised
> or malicious ordinary hosts (attached to switch ports where these
> features are enabled) can't do that much.
>
> The other reason for removing cryptographic authentication of
> VRRP
> messages is said to be misconfigured secrets (which obviously
> does
> cause problems -- but on the other hand, this situation should be
> detected very quickly). If it's indeed the case that
> cryptographic
> per-message authentication isn't a good solution to securing
> VRRP, at
> the very least the document should discuss other possible
> mechanisms.
> Perhaps e.g. filtering mechanisms in switches, configured on per-
> port
> basis, could provide some protection? Or could this somehow
> leverage
> the existing mechanisms for ARP?
>
> Does the below text capture your concerns? If not could you please
> suggest changes that would?
>
> VRRP for IPvX does not currently include any type of
> authentication. Earlier versions of the VRRP (for IPv4)
> specification included several types of authentication ranging
> from none to strong. Operational experience and further
> analysis determined that these did not provide sufficient
> security to overcome the vulnerability of misconfigured secrets
> causing multiple masters to be elected. Due to the nature of
> the VRRP protocol, even if VRRP messages are cryptographically
> protected, it does not prevent hostile nodes from behaving as
> if they are a VRRP master, creating multiple masters.
> Authentication of VRRP messages could have prevented a hostile
> node from causing all properly functioning routers from going
> into backup state. However, having multiple masters can cause
> as much disruption as no routers, which authentication cannot
> prevent. Also, even if a hostile nodes could not disrupt VRRP,
> it can disrupt ARP and create the same effect as having all
> routers go into backup.
>
> Some L2 switches provide the capability to filter out, e.g., ARP
> and/or ND messages from end hosts on a switch port basis. This
> mechanism could also filter VRRP messages from switch ports
> associated with end hosts and can be considered for deployments
> with untrusted hosts.
>
> Thanks,
> Steve