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

Ramdas Machat <rmachat@juniper.net> Thu, 02 July 2015 04:37 UTC

Return-Path: <rmachat@juniper.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 521BE1A1A5A; Wed, 1 Jul 2015 21:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 hTbyW_ITTx1m; Wed, 1 Jul 2015 21:37:15 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598B91B2E31; Wed, 1 Jul 2015 21:37:15 -0700 (PDT)
Received: from BY2PR05MB791.namprd05.prod.outlook.com (10.141.225.22) by BY2PR05MB791.namprd05.prod.outlook.com (10.141.225.22) with Microsoft SMTP Server (TLS) id 15.1.201.16; Thu, 2 Jul 2015 04:37:13 +0000
Received: from BY2PR05MB791.namprd05.prod.outlook.com ([10.141.225.22]) by BY2PR05MB791.namprd05.prod.outlook.com ([10.141.225.22]) with mapi id 15.01.0201.000; Thu, 2 Jul 2015 04:37:13 +0000
From: Ramdas Machat <rmachat@juniper.net>
To: "Fernando Calabria (fcalabri)" <fcalabri@cisco.com>, "MORTON, ALFRED C (AL)" <acmorton@att.com>, "Xialiang (Frank)" <frank.xialiang@huawei.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-bmwg-issu-meth.all@ietf.org" <draft-ietf-bmwg-issu-meth.all@ietf.org>
Thread-Topic: Secdir review of draft-ietf-bmwg-issu-meth-01
Thread-Index: AdCznVhNjRYm7y6ZS9SgpDHakbeZ2QAWCOBAAAQtUQAAKndLAA==
Date: Thu, 02 Jul 2015 04:37:13 +0000
Message-ID: <D1BABC91.16DA5%rmachat@juniper.net>
References: <C02846B1344F344EB4FAA6FA7AF481F12ADE7046@SZXEMA502-MBS.china.huawei.com> <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> <D1B950B6.49F87%fcalabri@cisco.com>
In-Reply-To: <D1B950B6.49F87%fcalabri@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.0.150423
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [116.197.184.13]
x-microsoft-exchange-diagnostics: 1; BY2PR05MB791; 5:y+k2IQEL+sjBS4Hie3AXc8U0T2cWN45Z/Wlyn6//itRYAULT8Jb6dWOuGXd7kY3ChahDNN2BHwxO9W+p/y5SMmt4g6b/LoMHaQ4AwZaVrwoF6idfyEtlqgmeZw5WYhLGAB0rUdEBLgnLg9NT89c1uw==; 24:wM9btRu6XJ809kXmKpoB/INvs120zfxlOgE9hdD7VfOeb3eQYlrBbUWY1q4MhEr2uE5scUppri8HZnybbq9/fnA/VyVc5Df5GDXtWXpmgR8=; 20:PS5FDtQQ0FZq5HR9IhGbTRzDGq+Y8vbSnaDjgXbnV7CHo8Fv4bbk/9wuZFLvtfWNQ00BZC29+WCX3BMi2X04xw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB791;
x-microsoft-antispam-prvs: <BY2PR05MB791713574163948176DDB16B4970@BY2PR05MB791.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR05MB791; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB791;
x-forefront-prvs: 06259BA5A2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(99286002)(19300405004)(50986999)(76176999)(54356999)(230783001)(19625215002)(15187005004)(16236675004)(2201001)(2501003)(66066001)(4001350100001)(5001960100002)(2950100001)(2900100001)(107886002)(102836002)(5001770100001)(15975445007)(77096005)(36756003)(189998001)(5002640100001)(46102003)(83506001)(40100003)(19580405001)(92566002)(19580395003)(77156002)(2656002)(62966003)(87936001)(122556002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB791; H:BY2PR05MB791.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_D1BABC9116DA5rmachatjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2015 04:37:13.4311 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB791
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/tEZdnbVNj5ypI3mVL2hCPblcUUk>
X-Mailman-Approved-At: Thu, 02 Jul 2015 02:40:23 -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 <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: Thu, 02 Jul 2015 04:37:18 -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)" <fcalabri@cisco.com<mailto:fcalabri@cisco.com>>
Date: Wednesday, July 1, 2015 at 6:29 PM
To: "MORTON, ALFRED C (AL)" <acmorton@att.com<mailto:acmorton@att.com>>, "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


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]
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