Re: [secdir] Secdir review of draft-ietf-bmwg-issu-meth-01

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Frank,
Thanks for your review and comments.

On #1, DoS attacks: since human control is involved here,
it seems unlikely that operators will begin an upgrade
during a DoS attack when they know it's in-progress, IMO.
Others should chime-in if they have other rationale or opinions.

On #4, That's the draft date, not the expiration date.
see below,
Al
doc shepherd

Benchmarking Working Group                                  Sarah Banks
Internet Draft                                           VSS Monitoring
Intended status: Informational                        Fernando Calabria
Expires: November 30, 2015                                Cisco Systems
                                                           Gery Czirjak
                                                          Ramdas Machat
                                                       Juniper Networks
                                                           May 30, 2015

ISSU Benchmarking Methodology
draft-ietf-bmwg-issu-meth-01

From: Xialiang (Frank) [mailto:[e-mail]]
Sent: Tuesday, June 30, 2015 9:29 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: Secdir review of draft-ietf-bmwg-issu-meth-01

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 comment.

This draft specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.

I have the following comments:

1.       Should the ISSU test methodology include the verification and test when the DUT is under network DDoS attacks?

2.       In the software download stage, in addition to compatibility checks and verification of checksums, we should also explicitly mention that the device should verify the authenticity and integrity of its download. I.e. verify signatures on signed code and OCSP/CRL for the used signature. And that a system must not load unverified code;

3.       even in a test environment all deployed software components must be verified (e.g. using signatures);

4.       Nits: this draft has expired on May-30, 2015

Recommendation:  Ready With Issues

B.R.
Frank