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

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 1 Jul 2015 08:08:01 -0400

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:[email-masked]]
Sent: Tuesday, June 30, 2015 9:29 PM
To: [email-masked]; [email-masked]; [email-masked]
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

---

From: "Fernando Calabria (fcalabri)" <[email-masked]>
Date: Wed, 1 Jul 2015 12:59:52 +0000

Thank you Frank for your review and Al for addressing # 1 and # 4 ..

In regards to # 2 and #3

We also saw and considered how  verifications like the authenticity of a SW package may be a concern , even more,   nowadays,  with emerging SDN  like implementations ,

Unfortunately   not all the vendors nor even software specific operating systems  within vendors,  have “consistent  implementations" of  Digital Signatures nor  Certificates and do not make these checks a mandatory task  before performing a Software upgrade.

Because of it  we tried to address it with a ‘generic’ statement on Sections 3.1 and 3.2 that basically read:

"Internal compatibility
   verification may be performed by the software running on the DUT, to
   verify the checksum of the files downloaded as well as any other
   pertinent checks. Depending upon vendor implementation, these
   mechanisms may extend to include verification that the downloaded
   module(s) …"

—

Internal compatibility verification may be
   performed by the software running on the DUT, as part of the upgrade
   process itself, to verify the checksum of the files downloaded as
   well as any other pertinent checks….

The authors of this document understand  how these are real issues / concerns on managing an operating a  Software   environment, ,  but we do not believe that an specific ISSU  document should addresses them in  detail

-Fernando

From: <MORTON>, "ALFRED C (AL)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 1, 2015 at 8:08 AM
To: "Xialiang (Frank)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Secdir review of draft-ietf-bmwg-issu-meth-01

Hi Frank,

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

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

B.R.
Frank

---

From: Sarah Banks <[email-masked]>
Date: Wed, 1 Jul 2015 10:39:03 -0700

Hi Frank,
	Thanks for your review! To add to what Fernando discussed below, for your points 2 and 3, we came to this conclusion not only because vendors don't have consistency in implementation, but also because customers with that running code weren't asking for it either. Often, they're downloading the code via login from the vendors' site - this doesn't mitigate your points, but it sheds some light on why perhaps they're not as concerned about it. I echo Fer's thoughts though, that we feel it's as covered as it could be with the section of the draft he quotes below - that the operator performing the ISSU should ensure the veracity of the code before installing it.

	Finally, I too share Al's thought, that a DDOS wouldn't likely be underway before an ISSU starts. A DDOS could, in theory, start after the ISSU starts, but then, any number of corner cases could occur when an ISSU starts, and that part might be a whole new draft. :) IMHO this is unlikely, and I'm not moved to cover it in the draft, however, if you have suggestions, we're willing to review them.

Thanks
Sarah

> On Jul 1, 2015, at 5:59 AM, Fernando Calabria (fcalabri) <[email-masked]> wrote:
> 
> 
> From: <MORTON>, "ALFRED C (AL)" <[email-masked] <mailto:[email-masked]>>
> To: "Xialiang (Frank)" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: Xialiang (Frank) [mailto:[email-masked] <mailto:[email-masked]>] 
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 2 Jul 2015 02:07:54 +0000

Hi authors,
Thank you for the detailed feedbacks. It helps me understand your consideration and decision more clear. I think  we all agree with the importance of authenticity and integrity verification for SW package.
Since the test method aims to mimic the real network application, and the complexity and risks of real network will cause the  unverified SW package quite possible, so I suggest to consider the related test steps.
Of course, you can make the test steps to be optional, not mandatory, due to the reality.

Anyway, it’s just my suggestion, you can decide by your own.

B.R.
Frank

发件人: Sarah Banks [mailto:[email-masked]]
发送时间: 2015年7月2日 1:39
收件人: Fernando Calabria (fcalabri)
抄送: ALFRED MORTON; Xialiang (Frank); [email-masked]; [email-masked]; [email-masked]
主题: Re: Secdir review of draft-ietf-bmwg-issu-meth-01

Hi Frank,

Thanks
Sarah

On Jul 1, 2015, at 5:59 AM, Fernando Calabria (fcalabri) <[email-masked]<mailto:[email-masked]>> wrote:

In regards to # 2 and #3

"Internal compatibility

―

-Fernando

Hi Frank,

B.R.
Frank

---

From: Ramdas Machat <[email-masked]>
Date: Thu, 2 Jul 2015 04:37:13 +0000

Hi Frank,
Thank you for your comments.
  #1
I agree with Al. ISSU upgrade is a manual procedure, and usually operators would well prepare for this event. Given this an ISSU upgrade during the DoS attack is very unlikely done by Operators.
#2, #3
It is a valid concern, since the images are huge and bulky, running into integrity and corruption issues are very likely. I conquer with Fernando on his response. This has been addressed in section 3.1.

-Ramdas

From: "Fernando Calabria (fcalabri)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 1, 2015 at 6:29 PM
To: "MORTON, ALFRED C (AL)" <[email-masked]<mailto:[email-masked]>>, "Xialiang (Frank)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Secdir review of draft-ietf-bmwg-issu-meth-01

In regards to # 2 and #3

"Internal compatibility

—

-Fernando

Hi Frank,

B.R.
Frank

---

From: Dacheng <[email-masked]>
Date: Sun, 5 Jul 2015 21:46:49 +0800

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 explores the topic of Network Reconnaissance in IPv6 networks. It analyzes the feasibility of address-scan attacks in IPv6 networks in different scenarios and proposes comments to mitigate to certain issues. 
Follows are two comments:
1) There are overlaps in the contents of the security consideration and conclusions. Maybe it is reasonable to integrate the the conclusions into security considerations. In addition, the security consideration section is normally about the new issues or concerns raised by the proposed work. However, this memo does not propose any new mechanism and so introduce no security vulnerability. I suggest the authors clarify this in the security consideration section. 
2) There is a very big section and a lot of short sections. I suggest to combine sections 4-14 into a single one to make the lengths of different sections more balanced. 
Anyway,  the  analysis in this work is quite extensive. I really enjoy reading it. I think this document is nearly ready for publication with some tiny modifications. 
Cheers
Dacheng

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 15:38:42 -0300

Hi, Dacheng,

Thanks so much for your feedback! Please find my comments in-line....

On 07/05/2015 10:46 AM, Dacheng wrote:
> 1) There are overlaps in the contents of the security consideration
> and conclusions. 

It would seem that we could move the "Conclusions" section as Section
3.6? (Tim?)
Some overlap is usually fine, anyway -- particularly with the Intro and
Sec Cons sections...

> Maybe it is reasonable to integrate the the
> conclusions into security considerations. In addition, the security
> consideration section is normally about the new issues or concerns
> raised by the proposed work. However, this memo does not propose any
> new mechanism and so introduce no security vulnerability. I suggest
> the authors clarify this in the security consideration section.

How about changing the fist sentence of the Sec Cons section to:
" This document explores the topic of Network Reconnaissance in IPv6
   networks, but does not introduce any new security issues."

  -- although one might argue that we do introduce new *concerns*.

> 2) There is a very big section and a lot of short sections. I suggest
> to combine sections 4-14 into a single one to make the lengths of
> different sections more balanced.

The sections have been split on a "topic" rather than "length" basis.
While the length is unbalanced, it makes it easy to reference each
specific reconnaissance technique (e.g., from the table earlier in the
document).

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492