Re: 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:[email protected]]
> Sent: 03 October, 2009 00:54
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email protected]; [email protected]; Mukesh Gupta;
> [email protected]
> 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
_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp