[secdir] SECDIR review of draft-ietf-ccamp-pc-and-sc-reqs-06

[Jeffrey Hutzelman <[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 a procedure to be used within a 
GMPLS network to convert a permanent connection, which is provisioned 
throughout the network, into a soft permanent connection, which is 
provisioned at the edges but set up by the control plane in the middle, and 
back, without interrupting the flow of data.

As a requirements document, this document does not directly create any new 
security considerations, but does raise some points which must be addressed 
by any solution.  Overall, I think this document is fine.

I also asked David Harrington <[e-mail]> to take a look at a 
paragraph referring to SNMP, which seemed to me to make too many 
assumptions about which pieces would "always" be used together.  David had 
the following to add:


> OK. It is incorrect to reference to MIBs as SNMP MIBs. MIBs are
> defined indepednently from SNMP. MIBs can theoretically be used by
> other protocols.
>
> There is standard boilerplate for MIB documents. Since this document
> does not contain a MIB module, most of it does not directly apply.
> However, the boilerplate discusses using a secure protocol and access
> control. I recommend that these authors use that section of the
> boilerplate text:
>
> <full boilerplate>
>    SNMP versions prior to SNMPv3 did not include adequate security.
>    Even if the network itself is secure (for example by using IPsec),
>    even then, there is no control as to who on the secure network is
>    allowed to access and GET/SET (read/change/create/delete) the
> objects
>    in this MIB module.
>
>    It is RECOMMENDED that implementers consider the security features
> as
>    provided by the SNMPv3 framework (see [RFC3410], section 8),
>    including full support for the SNMPv3 cryptographic mechanisms (for
>    authentication and privacy).
>
>    Further, deployment of SNMP versions prior to SNMPv3 is NOT
>    RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
>    enable cryptographic security.  It is then a customer/operator
>    responsibility to ensure that the SNMP entity giving access to an
>    instance of this MIB module is properly configured to give access
> to
>    the objects only to those principals (users) that have legitimate
>    rights to indeed GET or SET (change/create/delete) them.
> <boilerplate>
>
> This could be as simple as
>
>    If SNMP is used for configuration, then it is RECOMMENDED
>    that implementers consider the security features as
>    provided by the SNMPv3 framework (see [RFC3410], section 8),
>    including full support for the SNMPv3 cryptographic mechanisms (for
>    authentication and privacy).
>
> As the IETF is moving toward a multi-protocol approach to network
> management, I would change the paragraph to encompass a wider
> approach:
>
> "Any protocol used to configure a device should support
> authentication, encryption, integrity checking, and control of access
> to the configuration parameters. It is RECOMMENDED to deploy an IETF
> standard protocol for secure configuration, such as Netconf [RFC4741]
> or SNMPv3 [RFC3410].  Operators SHOULD enable cryptographic security
> and ensure that the entity giving access to configuration parameters
> is properly configured to give access only to those principals (users)
> that have legitimate rights to read/create/change/delete the
> parameters."
>
> I have asked the OPS and Security ADs to comment on this last
> paragraph as a proposed new boilerplate regarding secure management.


My only other comment is regarding the abstract.  A document and its 
abstract should each stand on their own, independently.  In particular, it 
should not be necessary to read the abstract in order to understand the 
document, and the abstract should contain only a brief description of what 
the document is about, intended to be read by someone trying to determine 
whether the document is of interest.  In the case of this document, text 
invoking RFC2119 does not belong in the abstract; rather, it belongs in the 
main document body.

-- Jeffrey T. Hutzelman (N3NHS) <[e-mail]>
   Carnegie Mellon University - Pittsburgh, PA