[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

WARNING: contains banned part
--- Begin Message --- 
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

> -----Original Message-----
> From: vrrp-bounces at ietf.org [mailto:vrrp-bounces at ietf.org]On Behalf Of
> Stephen Nadas
> Sent: Thursday, November 06, 2008 8:55 AM
> To: Pasi Eronen; iesg at ietf.org
> Cc: vrrp-chairs at tools.ietf.org;
> draft-ietf-vrrp-unified-spec at tools.ietf.org; vrrp at ietf.org
> 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

<<attachment: winmail.dat>>


--- End Message ---
_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp