Al: This resolves most of my concern. Is there anything more that can be said about the key management to improve the likelihood that the same interfaces are used in the lab and production? I am not sure. Russ > On Jan 26, 2018, at 4:55 PM, MORTON, ALFRED C (AL) <acmorton@xxxxxxx> wrote: > > Hi Russ, > >> Major Concerns >> >> The tests cover encrypted and unencrypted communications, but nothing >> is said about the key management. I recognize that the tests will be >> conducted in the lab, but it would be desirable for the key management >> to exercise the same interfaces that will be used in a production >> setting. > > Encrypted connections with network devices are mentioned in general, > primarily in Section 4.4, as a possibility that may be tested: > https://tools.ietf.org/html/draft-ietf-bmwg-sdn-controller-benchmark-meth-07#section-4.4 > > It will help if we can iterate on text to satisfy your comment, > such as adding: > 4.4. Connection Setup > > There may be controller implementations that support unencrypted and > encrypted network connections with Network Devices. Further, the > controller may have backward compatibility with Network Devices > running older versions of southbound protocols. It may be useful to > measure the controller performance with one or more applicable > connection setup methods defined below. > ADD > For cases with encrypted communications between the controller and the > switch, key management and key exchange MUST take place before > any performance or benchmark measurements. > > just trying to clarify what you want to see added, > Al > doc shepherd > > >> -----Original Message----- >> From: Russ Housley [mailto:housley@xxxxxxxxxxxx] >> Sent: Friday, January 26, 2018 4:04 PM >> To: secdir@xxxxxxxx >> Cc: ietf@xxxxxxxx; bmwg@xxxxxxxx; draft-ietf-bmwg-sdn-controller- >> benchmark-meth.all@xxxxxxxx >> Subject: Secdir last call review of draft-ietf-bmwg-sdn-controller- >> benchmark-meth-07 >> >> Reviewer: Russ Housley >> Review result: Has Issues >> >> I 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 authors, document editors, and WG chairs should >> treat these comments just like any other IETF Last Call comments. >> >> Document: draft-ietf-bmwg-sdn-controller-benchmark-meth-05 >> Reviewer: Russ Housley >> Review Date: 2018-01-26 >> IETF LC End Date: 2018-02-02 >> IESG Telechat date: Unknown >> >> Summary: Has (Minor) Issues >> >> Major Concerns >> >> The tests cover encrypted and unencrypted communications, but nothing >> is said about the key management. I recognize that the tests will be >> conducted in the lab, but it would be desirable for the key management >> to exercise the same interfaces that will be used in a production >> setting. >> >> >> Minor Concerns >> >> Section 1: Please update the first paragraph to reference RFC 8174 >> in addition to RFC 2119, as follows: >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in BCP >> 14 [RFC2119] [RFC8174] when, and only when, they appear in all >> capitals, as shown here. >> >> RFC 2119 is missing from the normative references. If you accept the >> above suggestion, RFC 8174 needs to be added as well. >> >> >> Nits >> >> The term "SDN Controller" is not defined in the companion terminology >> document, and a definition does not emerge in this document until >> Section 2, where it says: >> >> ... the SDN controller is a function that manages and >> controls Network Devices. ... >> >> I recognize that this is very basic, but it also seems like very >> important information for the Introduction. >> >> Similarly, please explain the difference between a "cluster of >> homogeneous controllers" and a "federation of controllers." >> >> The indenting in the document shifts in Section 5. Some lines >> other than Section headers are flush with the left margin. >> >