Skip to main content

Last Call Review of draft-ietf-dhc-dhcpv6-failover-requirements-06
review-ietf-dhc-dhcpv6-failover-requirements-06-secdir-lc-kelly-2013-07-18-00

Request Review of draft-ietf-dhc-dhcpv6-failover-requirements
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-07-17
Requested 2013-07-05
Authors Tomek Mrugalski , Kim Kinnear
I-D last updated 2013-07-18
Completed reviews Genart Last Call review of -06 by Elwyn B. Davies (diff)
Secdir Last Call review of -06 by Scott G. Kelly (diff)
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-ietf-dhc-dhcpv6-failover-requirements by Security Area Directorate Assigned
Reviewed revision 06 (document currently at 07)
Result Has issues
Completed 2013-07-18
review-ietf-dhc-dhcpv6-failover-requirements-06-secdir-lc-kelly-2013-07-18-00
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.

This document describes requirements for dhcpv6 failover. The document seems to
be a combined problem statement and requirements document.

When I read requirements document like this, I expect to see a progression from
use cases to goals to requirements. Sometimes the use cases (and some/all
goals) are outlined in a problem statement, but the point is that the described
requirements have some associated basis/rationale. This allows us to understand
the relative importance of a given requirement, and the tradeoffs if we can't
meet it for some reason.

I didn't find this when it comes to security. There is a security
considerations section, and for convenience, here it is:

   The design must allow secure communication between the failover
   partners.  This requirement applies to the specification only, i.e.
   the design must include a way to secure communication.  It does not
   mandate such security be employed, just that it be available.

   The protocol specification, when it is written, should provide
   operational guidelines in the case of authentication mechanisms that
   require access to network servers that have the potential to be
   unreachable (e.g. what to do if a partner is reachable, but remote
   Certificate Authority is unreachable due to network partition event).

   The security considerations for the design itself will be discussed
   in the design document.

What is "secure communication", and why is it required? The second paragraph
seems to imply that authentication is part of it, but is that all?

The last line seems to punt on security considerations, and maybe that is
acceptable to the working group. I'm not advocating for a detailed security
analysis in the requirements document, but I do think a high level discussion
of goals/requirements for confidentiality, integrity, and availability makes
sense. You will need this in order to discuss the suitability of any proposed
security mechanisms in later documents. This document seems like the right
place for that.

--Scott