Subject: Re: [VRRP] DISCUSS: draft-ietf-vrrp-unified-spec

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 6 Nov 2008 10:55:23 -0600

Hi Pasi, 

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

Regards, 
Steve  

> -----Original Message-----
> From: Pasi Eronen [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2008 11:41
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "don provan" <[email-masked]>
Date: Thu, 6 Nov 2008 14:08:09 -0800

WARNING: contains banned part

Subject: RE: [VRRP] DISCUSS: draft-ietf-vrrp-unified-spec
From: "don provan" <[email-masked]>
To: "'Stephen Nadas'" <[email-masked]>, "'Pasi Eronen'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 6 Nov 2008 14:08:09 -0800

An existing security model in VRRP was discarded because it
didn't work. In fact, it did nothing but introduce additional
vulnerabilities. Eliminating it made the protocol both safer
and simpler, a rare combination. Some of the text addressing
security is echoing that decision.

As to whether some *other* mechanism might apply, I cannot
say. When the WG discussed it, no one brought up anything
except mechanisms that were general to the MAC layer, such
as a switch maintained concept of a trusted host, that did
not seem to have any impact on VRRP, and seemed no more
relevant to the VRRP spec than they would be to, say, an
HTTP spec.

I don't think the spec rules out anything, though, so the
WG should be open to proposed additions.

As to the IPv6 addresses, I know very little about IPv6, but
I think the bottom line in this: a physical interface should
never, ever have link-local address based on the VR MAC
address. But on the other hand, the virtual interface itself
also has a link-local address (doesn't it?) that *is* based
on the VR MAC address. I think that's what the text is
trying to say, but I don't know enough to say whether terms
like "Modified EUI-64 identifier" are being used in a way
that is right, wrong, or misleading. I took it to mean
"the Modified EUI-64 identifier to be used in the link-local
address of a physical interface", so perhaps adding those
additional qualifiers would make it clearer.
-don

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stephen Nadas
> Sent: Thursday, November 06, 2008 8:55 AM
> To: Pasi Eronen; [email-masked]
> [email-masked]; [email-masked]
> Subject: Re: [VRRP] DISCUSS: draft-ietf-vrrp-unified-spec
> 
> 
> Hi Pasi, 
>