[secdir] secdir review of draft-ietf-dhc-dhcpv6-failover-requirements

["Scott G. Kelly" <[e-mail]>]

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