From: Stephen Nadas <stephen.nadas <at> ericsson.com>
To: Pasi Eronen <pasi.eronen <at> nokia.com>; iesg <at> ietf.org
Cc: vrrp-chairs <at> tools.ietf.org; draft-ietf-vrrp-unified-spec <at> tools.ietf.org; vrrp <at> ietf.org
Sent: Thursday, November 6, 2008 10:25:23 PM
Subject: Re: [VRRP] DISCUSS: draft-ietf-vrrp-unified-spec

Hi Pasi,

Thank you for the feedback.  Putting to VRRP list for WG feedback.

Regards,
Steve 

> -----Original Message-----
> From: Pasi Eronen [mailto:pasi.eronen <at> nokia.com]
> Sent: Thursday, November 06, 2008 11:41
> To: iesg <at> ietf.org
> Cc: vrrp-chairs <at> tools.ietf.org;
> draft-ietf-vrrp-unified-spec <at> tools.ietf.org
> Subject: DISCUSS: draft-ietf-vrrp-unified-spec
>
> Discuss:
> I have reviewed draft-ietf-vrrp-unified-spec-02. Overall, the
> document looks good, but I have the following concerns that
> I'd like to discuss before recommending approval of the document:
>
> 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?
>
>
> An additional question about Section 7.4: I'm slightly
> confused by the text here -- does every router create its own
> link-local address (in which case failover is visible to
> hosts in this subnet), or do they share the same link-local
> address? The 1st paragraph says "They MUST NOT use the
> Virtual Router MAC address to create the Modified EUI-64
> identifiers", but the 3rd paragraph talks about "using the
> VRRP MAC in the formation of these link local addresses" --
> are these contradicting each other, or am I just
> misunderstanding how this works?
>
>
>
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp