Return-Path: 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 6DA481A87BE; Wed, 1 Jul 2015 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 V2oMSeY0PadW; Wed, 1 Jul 2015 05:59:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8318F1A87B2; Wed, 1 Jul 2015 05:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24411; q=dns/txt; s=iport; t=1435755595; x=1436965195; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AxFjaCdO/xKHMlwN9K5y8EJp7rUgGaGo+RxxzwaJJ3U=; b=B13AAA521GRVExC3/5DGzrgSq+xkttu5HgSNeR459hbYkMzv8FtsrgX5 S8Mg9Q/lN4IGX3mq4EqoUGeVZD0vsdWNfGd8H1LjBvd4bc6ZueBoI8xSd QU6lRXLxsB86sEihgK/OjWVsqXKY8NKUOKOFX4CRzZhOmf4W2wKjOIzoI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBAD045NV/5RdJa1bgkVMVF8GvSgJhDKDNAKBUTgUAQEBAQEBAYEKhCIBAQEELUcVAgEIEQMBAQEhBwcyFAkIAQEEARKIL8thAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhGITFwGEKwEElBABi2CBOochjAyDXSaDem+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.15,385,1432598400"; d="scan'208,217";a="164631800" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2015 12:59:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t61CxrPX030194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 12:59:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.60]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 07:59:53 -0500 From: "Fernando Calabria (fcalabri)" To: "MORTON, ALFRED C (AL)" , "Xialiang (Frank)" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-bmwg-issu-meth.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-bmwg-issu-meth-01 Thread-Index: AdCznVhNjRYm7y6ZS9SgpDHakbeZ2QAWCOBAAAQtUQA= Date: Wed, 1 Jul 2015 12:59:52 +0000 Message-ID: References: <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.117.99.244] Content-Type: multipart/alternative; boundary="_000_D1B950B649F87fcalabriciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 06:19:00 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:59:57 -0000 --_000_D1B950B649F87fcalabriciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 sy= stems within vendors, have =93consistent implementations" of Digital Si= gnatures nor Certificates and do not make these checks a mandatory task b= efore performing a Software upgrade. Because of it we tried to address it with a =91generic=92 statement on Sec= tions 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) =85" =97 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=85. The authors of this document understand how these are real issues / concer= ns on managing an operating a Software environment, , but we do not bel= ieve that an specific ISSU document should addresses them in detail -Fernando From: , "ALFRED C (AL)" > Date: Wednesday, July 1, 2015 at 8:08 AM To: "Xialiang (Frank)" >, "secdir@ietf.org" >, "iesg@ietf.org" >, "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=92s in-progress, IMO. Others should chime-in if they have other rationale or opinions. On #4, That=92s 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] Sent: Tuesday, June 30, 2015 9:29 PM To: secdir@ietf.org; iesg@ietf.org; 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y 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 check= s 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 t= hat a system must not load unverified code; 3. even in a test environment all deployed software components must b= e verified (e.g. using signatures); 4. Nits: this draft has expired on May-30, 2015 Recommendation: Ready With Issues B.R. Frank --_000_D1B950B649F87fcalabriciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7DA14B3390DD7345A2036F7DFA37DCB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

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 authentici= ty of a SW package may be a concern , even more,   nowadays,  wit= h emerging SDN  like implementations , 

Unfortunately   not all the vendors nor even software specific op= erating systems  within vendors,  have =93consistent  implem= entations" of  Digital Signatures nor  Certificates and do n= ot make these checks a mandatory task  before performing a Software up= grade.

Because of it  we tried to address it with a =91generic=92 statem= ent 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 an= y other
   pertinent checks. Depending upon vendor implementation, t= hese
   mechanisms may extend to include verification that the do= wnloaded
   module(s) =85"

=97

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 downl= oaded as
   well as any other pertinent checks=85.



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

-Fernando 







From: <MORTON>, "ALFRED = C (AL)" <acmorton@att.com&g= t;
Date: Wednesday, July 1, 2015 at 8:= 08 AM
To: "Xialiang (Frank)" &l= t;frank.xialiang@huawei.com>, "secdir@ietf.org" &= lt;secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-bmwg-issu-met= h.all@ietf.org" <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 upgra= de

during a DoS attack when they know it=92s in-progres= s, IMO.

Others should chime-in if they have other rationale = or opinions.

 

On #4, That=92s the draft date, not the expiration d= ate.

see below,

Al

doc shepherd

 

Benchmarking Working Group    &n= bsp;            = ;            &n= bsp;    Sarah Banks

Internet Draft      &n= bsp;            = ;            &n= bsp;           VSS Monito= ring

Intended status: Informational   &nbs= p;            &= nbsp;       Fernando Calabria

Expires: November 30, 2015    &n= bsp;            = ;            &n= bsp;  Cisco Systems

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Ger= y Czirjak

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           Ramdas Ma= chat

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Juniper Networks=

        &nbs= p;            &= nbsp;            &nb= sp;            =             May= 30, 2015

        &nbs= p;            &= nbsp;

ISSU Benchmarking Methodology

draft-ietf-bmwg-issu-meth-01

 

From:<= span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif;"> Xialiang = (Frank) [mailto:frank.xialiang= @huawei.com]
Sent: Tuesday, June 30, 2015 9:29 PM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-bmwg-issu-meth.all@ietf.org
Subject: Secdir review of draft-ietf-bmwg-issu-meth-01

 =

I have re= viewed this document as part of the security directorate's ongoing eff= ort to review all IETF documents being processed by the IESG.  Th= ese 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.

&nbs= p;

This draf= t specifies a set of common methodologies and procedures designed to charac= terize the overall behavior of a Device Under Test (DUT), subject to an ISS= U event.

&nbs= p;

I have th= e 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 devic= e 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 veri= fied (e.g. using signatures);

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

&nbs= p;

Recommend= ation:  Ready With Issues

&nbs= p;

B.R.=

Frank

 --_000_D1B950B649F87fcalabriciscocom_--