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

Sarah Banks <sbanks@encrypted.net> Wed, 01 July 2015 17:39 UTC

Return-Path: <sbanks@encrypted.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732A61ACDB3; Wed, 1 Jul 2015 10:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfGOl_q3aEA0; Wed, 1 Jul 2015 10:39:14 -0700 (PDT)
Received: from firefly.encrypted.net (firefly.encrypted.net [72.13.81.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1851ACD68; Wed, 1 Jul 2015 10:39:01 -0700 (PDT)
Received: from firefly.encrypted.net (localhost [127.0.0.1]) by firefly.encrypted.net (Postfix) with ESMTP id 59B4333E76; Wed, 1 Jul 2015 10:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at encrypted.net
Received: from firefly.encrypted.net ([127.0.0.1]) by firefly.encrypted.net (firefly.encrypted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik-RAWcb8Vnv; Wed, 1 Jul 2015 10:39:00 -0700 (PDT)
Received: from divinaair.global.tektronix.net (66-7-254-66.static-ip.telepacific.net [66.7.254.66]) by firefly.encrypted.net (Postfix) with ESMTPSA id 03B5633E74; Wed, 1 Jul 2015 10:39:00 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C06B8EEB-BD98-4923-B765-279994070D8A"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Sarah Banks <sbanks@encrypted.net>
In-Reply-To: <D1B950B6.49F87%fcalabri@cisco.com>
Date: Wed, 1 Jul 2015 10:39:03 -0700
Message-Id: <9E32EDE7-875D-400C-BC45-806C854C3AAB@encrypted.net>
References: <C02846B1344F344EB4FAA6FA7AF481F12ADE7046@SZXEMA502-MBS.china.huawei.com> <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> <D1B950B6.49F87%fcalabri@cisco.com>
To: "Fernando Calabria (fcalabri)" <fcalabri@cisco.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Ka7n-q7dzWOAjsMwM1GUBXWaag4>
X-Mailman-Approved-At: Wed, 01 Jul 2015 14:39:15 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-bmwg-issu-meth.all@ietf.org" <draft-ietf-bmwg-issu-meth.all@ietf.org>, ALFRED MORTON <acmorton@att.com>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-bmwg-issu-meth-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2015 17:39:17 -0000

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) <fcalabri@cisco.com> wrote:
> 
> 
> 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)" <acmorton@att.com <mailto:acmorton@att.com>>
> Date: Wednesday, July 1, 2015 at 8:08 AM
> To: "Xialiang (Frank)" <frank.xialiang@huawei.com <mailto:frank.xialiang@huawei.com>>, "secdir@ietf.org <mailto:secdir@ietf.org>" <secdir@ietf.org <mailto:secdir@ietf.org>>, "iesg@ietf.org <mailto:iesg@ietf.org>" <iesg@ietf.org <mailto:iesg@ietf.org>>, "draft-ietf-bmwg-issu-meth.all@ietf.org <mailto:draft-ietf-bmwg-issu-meth.all@ietf.org>" <draft-ietf-bmwg-issu-meth.all@ietf.org <mailto:draft-ietf-bmwg-issu-meth.all@ietf.org>>
> Subject: RE: Secdir review of draft-ietf-bmwg-issu-meth-01
> 
> 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:frank.xialiang@huawei.com <mailto:frank.xialiang@huawei.com>] 
> Sent: Tuesday, June 30, 2015 9:29 PM
> To: secdir@ietf.org <mailto:secdir@ietf.org>; iesg@ietf.org <mailto:iesg@ietf.org>; draft-ietf-bmwg-issu-meth.all@ietf.org <mailto:draft-ietf-bmwg-issu-meth.all@ietf.org>
> 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