[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VRRP] Review of draft-ietf-vrrp-unified-spec-02
Hi Magnus,
Thank you for your comments. I am copying vrrp list for their feedback.
Regards,
Steve
> -----Original Message-----
> From: Magnus Nyström [mailto:magnus at rsa.com]
> Sent: Wednesday, November 05, 2008 17:50
> To: iesg at ietf.org; secdir at mit.edu; Stephen Nadas;
> rcallon at juniper.net; dward at cisco.com
> Cc: secdir-secretary at mit.edu
> Subject: Review of draft-ietf-vrrp-unified-spec-02
>
> I have reviewed this document as part of the security
> directorate's ongoing effort to review all IETF documents
> being processed by the IESG.
> These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs
> should treat these comments just like any other last call comments.
>
> Background
> ----------
>
> This document defines/describes version 3 of the Virtual
> Router Redundancy Protocol (VRRP), a protocol that assigns
> virtual routers to physical
> (VRRP) routers. Claimed benefits of the protocol include high
> availability default route (IPv4) and fast switch to backup
> routers (IPv6).
>
> Comments
> --------
>
> Overall, this document reads well to me. I am not an expert
> on VRRP and so I am probably missing some context here, but
> it was a bit surprising to see a new version of a protocol in
> the routing space that does not have any security
> functionality built-in, especially considering efforts such as RPSEC.
>
> Also, the Security Considerations section states "VRRP ...
> does not currently include any type of authentication" but
> then goes on to say "In the context of IPv6 operation ...
> VRRP authentication could be usefully added ..." I guess it
> would have been useful to learn why this functionality
> (authentication of sender) was not added despite usages
> (there is a note on problems with the authentication method
> used in previous version but those problems do not seem to
> apply to IPv6 environments, so why was the functionality removed?).
>
> A reference to RFC 4593 may also be in place.
>
> -- Magnus
>
>
_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp