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.orghttps://www.ietf.org/mailman/listinfo/vrrp