Re: [bmwg] WGLC on New version of draft-ietf-bmwg-ngfw-performance

"MORTON JR., AL" <acmorton@att.com> Tue, 13 July 2021 17:13 UTC

Return-Path: <acmorton@att.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFF93A0E11 for <bmwg@ietfa.amsl.com>; Tue, 13 Jul 2021 10:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level:
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com
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 Bi4-j-QxORXR for <bmwg@ietfa.amsl.com>; Tue, 13 Jul 2021 10:13:51 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838393A0E12 for <bmwg@ietf.org>; Tue, 13 Jul 2021 10:13:51 -0700 (PDT)
Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 16DHD72c013719; Tue, 13 Jul 2021 13:13:32 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 39sf0f02s6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jul 2021 13:13:31 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 16DHDTHv020916; Tue, 13 Jul 2021 13:13:31 -0400
Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 16DHDMqL020759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Jul 2021 13:13:22 -0400
Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id 713CA4016DA9; Tue, 13 Jul 2021 17:13:22 +0000 (GMT)
Received: from MISOUT7MSGED1AA.ITServices.sbc.com (unknown [135.66.184.195]) by zlp27128.vci.att.com (Service) with ESMTP id 2F3A24016DA8; Tue, 13 Jul 2021 17:13:22 +0000 (GMT)
Received: from MISOUT7MSGEX2BA.ITServices.sbc.com (135.66.184.217) by MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 13 Jul 2021 13:13:21 -0400
Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGEX2BA.ITServices.sbc.com (135.66.184.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Tue, 13 Jul 2021 13:13:21 -0400
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.173) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Tue, 13 Jul 2021 13:13:19 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UH6poQYhdcxHEP1FJkHH75TxM98//aThgV1wUfWHJqvzbUaVipaNLSExe3K4GtkYePF9F//c+Du/t9BzyPYRm9FcJkfdFspy1Ar61DIcd9LC2aEAAoXo+VqBO2WgP+vZjZJbk+9FrR3RqEF2sjrf4HrM6RbHZ20xD5+XS7NunclWw/kmAfbK8EV4eeZNlioTMsjRBo5fVtEGaR1kPqcuthkDgfx7s5bPBADmsN7N3lLPfxHgBcsTR/09sOS+ysQOpMHpI86GPSQHoL5mpCsJfDs+VRI8xTDb0qBSBuDfanOSA2f3xyJ76iaSa5FpO+018A3xHoo1nP6zT0YErApQQA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S6VIrK9QiknK4OfpYnAQFcA8aKUK0E+TNKjr5uibm7M=; b=MjuNnLZh02iONuNSMEMms9FtiInDAo3qOC5OIkA6JP8MljJ9BvVOTzwpOgDjQo7AHUCOe+NxcbAapnXV63bcCeBPFXyI1Nd1BAD44HKmuADXS3TjQbvIlbmc6XQibkBjazVXjjIEATNJtoDAGVB42P90j5/XBmuPXIPpz5CofSVQKpTmoy4S/vnws7rm/eTZeX0cBJEsyQayJs9Hp1mY25lyJHbAXjm5OidRhI9LGXWhrv+b7ELuvFL/qKwQSBlOhOCsuNMcFfz6Ug7yaWazMzBcfJvksAMZ1dhx1dkl4b1acfUzCI1wYLZny4MNZu+yvMHrWDrzceXgcRSd0AZrig==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S6VIrK9QiknK4OfpYnAQFcA8aKUK0E+TNKjr5uibm7M=; b=IXav7T1j/2rSX2o710n13RrOHUYTVqbDMd5JiqLbd8TcuL3QMtHu81f28qEkUm/HVt5lfhdAD8ROiChK+f4c1w0+KECDkVjMFG/iOc56LQjx05xVKy1gTAKTfgp8jBM957wFeONWlQMCwM+UopO22ILyo1+aYbPBwK9MPCgUoNs=
Received: from SJ0PR02MB7853.namprd02.prod.outlook.com (2603:10b6:a03:32e::8) by BY5PR02MB6450.namprd02.prod.outlook.com (2603:10b6:a03:1b4::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Tue, 13 Jul 2021 17:13:15 +0000
Received: from SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::40d9:d8df:7dfa:3180]) by SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::40d9:d8df:7dfa:3180%6]) with mapi id 15.20.4308.027; Tue, 13 Jul 2021 17:13:15 +0000
From: "MORTON JR., AL" <acmorton@att.com>
To: Carsten Rossenhoevel <cross@eantc.de>, "bmonkman@netsecopen.org" <bmonkman@netsecopen.org>, 'Sarah Banks' <sbanks@encrypted.net>, "'MORTON, ALFRED C (AL)'" <acm@research.att.com>
CC: "bmwg@ietf.org" <bmwg@ietf.org>, "asamonte@fortinet.com" <asamonte@fortinet.com>, "amritam.putatunda@keysight.com" <amritam.putatunda@keysight.com>, 'Bala Balarajah' <bala@netsecopen.org>, 'Christopher Brown' <cbrown@iol.unh.edu>, "'Jack, Mike'" <Mike.Jack@spirent.com>, "'Ryan Liles (ryliles)'" <ryliles@cisco.com>, 'Timothy Carlin' <tjcarlin@iol.unh.edu>, 'Timothy Otto' <totto@juniper.net>
Thread-Topic: [bmwg] WGLC on New version of draft-ietf-bmwg-ngfw-performance
Thread-Index: AQHXTbeaOGUmGWbtmESUQ0dgvoKXO6r2c6iAgBnsMwCAGZG0gIAWOoc4gAEjogCAAAQFUIAABRQAgAARbQCAAAnvcA==
Date: Tue, 13 Jul 2021 17:13:14 +0000
Message-ID: <SJ0PR02MB7853E07B1ECA0F2985DB6073D3149@SJ0PR02MB7853.namprd02.prod.outlook.com>
References: <413e779fd7eb4dd4b3aa8473c171e282@att.com> <f1a2b5c5-ebf2-12ab-b053-b9b2538342ad@hit.bme.hu> <047501d745bb$e22f4ab0$a68de010$@netsecopen.org> <7dc6b282-7f41-bf7c-f09c-65e7ce94b674@hit.bme.hu> <048801d745be$31424b50$93c6e1f0$@netsecopen.org> <84196d5ce7474f9196ab000be64c49fd@att.com> <02629ACE-FDA4-4ACF-9459-825521596B83@encrypted.net> <001201d75266$05979140$10c6b3c0$@netsecopen.org> <059e01d75f7d$a62a4de0$f27ee9a0$@netsecopen.org> <009b01d76c46$8063e5a0$812bb0e0$@netsecopen.org> <770F93CB-A8CC-4420-8C1B-CB7B7A2289FB@encrypted.net> <021f01d77356$7e19a2f0$7a4ce8d0$@netsecopen.org> <D1ED6898-D8C3-4C56-A3D3-221DD16B7300@encrypted.net> <004701d777f5$94844bf0$bd8ce3d0$@netsecopen.org> <SJ0PR02MB7853CAF5D40CBAFA6C3B4154D3149@SJ0PR02MB7853.namprd02.prod.outlook.com> <005201d777fa$2133a100$639ae300$@netsecopen.org> <4e51a7d5-8c59-a4fc-6c65-457ee7655c74@eantc.de>
In-Reply-To: <4e51a7d5-8c59-a4fc-6c65-457ee7655c74@eantc.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: eantc.de; dkim=none (message not signed) header.d=none;eantc.de; dmarc=none action=none header.from=att.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 663486dd-3996-4c52-36a8-08d946218061
x-ms-traffictypediagnostic: BY5PR02MB6450:
x-microsoft-antispam-prvs: <BY5PR02MB6450699C09D7C87D74774DA3D3149@BY5PR02MB6450.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QIAuOVdTVFwa4/7MZkoN0yz1mPgH0linpxB2g3H1l1twxCfDQuq+nh4G+t9sxrN/BqB2K4I7T6VWh4/m1ErdmmNSaaFtOmRa4y9lffwz/eJ5nAXEZdaHjvP3tahBeRRix7hJxqlcKPYLglHV3Xe6mBP4X0QfXRSm7lNV8H2TDEuF7qnHwAtQyF9gbhPa0aJ+TM82eNlnMeaVTV0MuwMyNfU0OLMF46DAavGvySmv9zh0r6Io7+8lPv0maW7cSCQvgy+rbfYfyLAS1rqQCgNXbImwGyJMfY/E7htuBNGALm8BKAJHWvR85cUiG5TkSff9OnMk3PmWeKYUIe2Jsujcj2E9fMPrRB1MV92pgv5Jjy7OO15z5IDiVy9JyKx8kAQSKdglllUcV+A6Qr33We/w1HSlUAokSthbo36PMNwztG5nmp5lICx0ypjDQ4BBBKUl6xeyeNyOKsi/up8eyTaai7OnTbdKkvof8DM9uCQIpsJDSdrB33Zi/yk9vDn9k7B998mmd9mWJzknGdh9e93ijiK6bl/8H7lCsu/A/6j5QFZ98VGyhoq4GgSQIWhUUnTiOnbwho00N3hU3sSXJeOoKp0PwaD4UZVPQfD5cY//BXYAvYh9FqJf430i2EGRb/sUG5DYXKCsgVBkHDArOJl9tMHTxq/Bf8xwnlCslY+i/sxpUPHxoQA99tOPPoskMTJGfE/TPpZLC4MKHBMxA3VOn7aZ8/5LInptd2sCD7yKcLE=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB7853.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(376002)(136003)(396003)(346002)(8676002)(30864003)(5660300002)(66574015)(83380400001)(122000001)(26005)(316002)(71200400001)(166002)(82202003)(38100700002)(8936002)(7696005)(966005)(52536014)(478600001)(55016002)(110136005)(86362001)(4326008)(54906003)(53546011)(6506007)(66556008)(64756008)(66446008)(76116006)(66476007)(66946007)(7416002)(9686003)(186003)(33656002)(2906002)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: VgQwgmsycw6JUqe36oAqiQsQEK7LdhIfQ/SckSnw23gDuCsq2K69hF0O02YQJtKx+i3Be0JTgjNJ/7Jv0hPBpB6PtGU2l8zrrVN6hoAfqQP8BPOs6W0f6Ud4E6kZRrHea6z8N+EWJ/wyLTjSYZRr9txp/xp5tcQcYE4pyOil2KG9Z5OPeUL8oAnZmPgWmYlfzDHAp0KTBgsykAd4rmKBrxm6Ob1MTBv7gxNqRluYvqZxDvA22QEXcMeENqY2jqimXywdMdiWwCKQBRdxWIAWo9TIqtUmNzpOEw2dCooHEzI8qtApifMD+qO3FsJoJC1koAPbrodD8whNEv13Z5daQ1MPTBfKhLntamIcdpa1Ogl/rAuel84BV2MB4/R3lGzr94Dde10jGaUQCmFrWos9NrYaht19r5P/DOSKL6SiznplD+IkDsSzQc9pJzK1hGW69NfsRqUa09qra0EeyeKIQbh/N1YA0r4EdCvBLLxKc2YTeKV0u5H0VE9w5AJavEFya+gshVRC5cbFVL22B8j3TDNUbrj0oHNHIJApLchMcraat9LfNl+KeDSlOOz1sPYbB/WC9+fr1FcX16B7NWPF8kjmjkHW+8cZMlnGcXxLZEJ/HbRzeVbYatX3CaXBTa1yAhMJ1Kqj0wL2AP/l01mlob0sgZqD3/AZv8v0uJg8/Ry+yg2eU0tuKnTW1ITyKjua2IYewze0RomDUSnrLot3xCnEuCK5ZmGotIL+OJOEV4qAijYXe6Z637zG9+UAU/7/0Ce3B2JLDDyXYPHszH7QWSv/EeJX9GNwgXg4kf9E4dHfPjyEzg65AAE+g3uMKrXLlQ8XVWSNdxFpbN2tzyhv/bDfx230pl4CTMQjP6ZbwHrDFXWoGfuLGlKZ3iuzBeFquRMWjP6beT3AeQjTdTt7tzJMJ6eB2lcdrW9b4LyH3EfLRtxTZxWxLZssUoMbxftWLWqOgyLbo9gHLdjCQFTUTMfnaQqms6DN1/cImfcKRRafRFEqwYUZwJQejQfBFj/crTnmEBttL1m/3P2aWYtNyX9ElH46XZpi4QGw+7Bp1izC2ypmhYGgibjZEM9x6qCCtqXu6J5OaoE+vW+dgkuwxcGkE3PRD6Vulnk7ir2rJgG/U2EG36ITBOczK9pQwADHq+3Bk2PaFrNKSYGN4FtloeTXkkX0JY45CxAdhl7MN3Ib3W2APLlO3pUm1xc/e4razmsPtRrNiaPE1hPmq1dVyicbwf4uvfEXjBAL2t7twsDX+8HlGagHtPw2nb0EqlLtqRQwT1P+sf5uqYniD5LIwSaKcJIwbXaVKSA/eitIq7MMdic+myVdJfPtFH60ZS08
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SJ0PR02MB7853E07B1ECA0F2985DB6073D3149SJ0PR02MB7853namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7853.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 663486dd-3996-4c52-36a8-08d946218061
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2021 17:13:14.9384 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /1xAfGowAh4neC1PtP2rRbU92btoSVM2S+GJ/o8O8Qd5GKWbqj44O/KMua4gqA5v
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR02MB6450
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: ED11C0D0A195D5D2AE497E1F984F1802E723C853CDD0829CFABB3097A21D3E672
X-Proofpoint-ORIG-GUID: FUfBRtcZtkaQu3s8gvQKo4nFOoHV-4j0
X-Proofpoint-GUID: FUfBRtcZtkaQu3s8gvQKo4nFOoHV-4j0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-13_10:2021-07-13, 2021-07-13 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 clxscore=1015 impostorscore=0 adultscore=0 bulkscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107130109
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/oUl5qGlPbaKR5cznfw7IBDoaAa4>
X-Mailman-Approved-At: Tue, 13 Jul 2021 10:27:30 -0700
Subject: Re: [bmwg] WGLC on New version of draft-ietf-bmwg-ngfw-performance
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2021 17:13:58 -0000

Hi Carsten and all,
please see replies below, [acm]


From: Carsten Rossenhoevel <cross@eantc.de>
Sent: Tuesday, July 13, 2021 12:19 PM
To: bmonkman@netsecopen.org; MORTON JR., AL <acmorton@att.com>; 'Sarah Banks' <sbanks@encrypted.net>; 'MORTON, ALFRED C (AL)' <acm@research.att.com>
Cc: bmwg@ietf.org; asamonte@fortinet.com; amritam.putatunda@keysight.com; 'Bala Balarajah' <bala@netsecopen.org>; 'Christopher Brown' <cbrown@iol.unh.edu>; 'Jack, Mike' <Mike.Jack@spirent.com>; 'Ryan Liles (ryliles)' <ryliles@cisco.com>; 'Timothy Carlin' <tjcarlin@iol.unh.edu>; 'Timothy Otto' <totto@juniper.net>
Subject: Re: [bmwg] WGLC on New version of draft-ietf-bmwg-ngfw-performance

The question is, how much more time will be required to discuss this topic in an IETF meeting (whether regular or interim)?
Al (as chair) and Sarah (as contributor), what do you think?  Would it fit into the regular BMWG meeting at IETF111 at all anyway?
[acm] Given the current agenda requests and our session scheduled for 120 minutes, we could easily allocate 60 minutes (maybe more) to resolve issues raised on a mature working group draft like this. Perhaps not all of the issues, but the most important ones! Others may need to be deferred to follow-up activity.
In my view, resolving comments at a faster pace than possible with e-mail exchange in exactly what our IETF sessions are intended to accomplish. While the WG drafts have time priority, other discussions took place on the list since we last met and it seems fair to allocate some time to those as well. The good news is that we have a sufficiently active list to more-than-justify a live session during this IETF. That’s the next step.
Al
bmwg co-chair

My personal view is that it will take a considerable time to explain the positions and reach consensus, specifically related to the rather fundamental questions about the scope of the next-gen security device industry.

Sarah, is it acceptable to kindly ask you to prepare constructive editorial suggestions how to resolve her concerns?

The WGLC process has already been delayed by yet another IETF meeting cycle, and I would like to ask for your support to avoid any further unnecessary delays.  I would like to remind everyone of RFC 7154<https://urldefense.com/v3/__https:/tools.ietf.org/search/rfc7154__;!!BhdT!x_nyyuYbLuR_bxaZQzRebn-62Pq05wFObCEJ0-gdObGoaHM0WyFnsfztUjSU$> (IETF Guidelines for Conduct) section 2.4.

Best regards, Carsten




On 13.07.2021 16:17, bmonkman@netsecopen.org<mailto:bmonkman@netsecopen.org> wrote:

Thanks for your response Al.



Given that the BMWG session is only 9 working days away I doubt very much we

will be able to get together as a group on our side and work through the

remaining issues. It might be possible to get our response out by the end of

next week, but I don't think that will provide enough time for it to be

reviewed and a response formulated by the meeting on July 26th.



I think it would be preferable to schedule an interim.



Brian



-----Original Message-----

From: MORTON JR., AL <acmorton@att.com><mailto:acmorton@att.com>

Sent: Tuesday, July 13, 2021 11:01 AM

To: bmonkman@netsecopen.org<mailto:bmonkman@netsecopen.org>; 'Sarah Banks' <sbanks@encrypted.net><mailto:sbanks@encrypted.net>; 'MORTON,

ALFRED C (AL)' <acm@research.att.com><mailto:acm@research.att.com>

Cc: bmwg@ietf.org<mailto:bmwg@ietf.org>; asamonte@fortinet.com<mailto:asamonte@fortinet.com>; amritam.putatunda@keysight.com<mailto:amritam.putatunda@keysight.com>;

'Bala Balarajah' <bala@netsecopen.org><mailto:bala@netsecopen.org>; 'Carsten Rossenhoevel'

<cross@eantc.de><mailto:cross@eantc.de>; 'Christopher Brown' <cbrown@iol.unh.edu><mailto:cbrown@iol.unh.edu>; 'Jack, Mike'

<Mike.Jack@spirent.com><mailto:Mike.Jack@spirent.com>; 'Ryan Liles (ryliles)' <ryliles@cisco.com><mailto:ryliles@cisco.com>;

'Timothy Carlin' <tjcarlin@iol.unh.edu><mailto:tjcarlin@iol.unh.edu>; 'Timothy Otto' <totto@juniper.net><mailto:totto@juniper.net>

Subject: RE: [bmwg] WGLC on New version of draft-ietf-bmwg-ngfw-performance



Hi Brian,



Our next opportunity to discuss this draft and comment resolution is during

the BMWG session at IETF-111.

Let's try to make that work for everyone.



thanks!

Al





-----Original Message-----

From: bmonkman@netsecopen.org<mailto:bmonkman@netsecopen.org> <bmonkman@netsecopen.org><mailto:bmonkman@netsecopen.org>

Sent: Tuesday, July 13, 2021 10:44 AM

To: 'Sarah Banks' <sbanks@encrypted.net><mailto:sbanks@encrypted.net>; 'MORTON, ALFRED C (AL)'

<acm@research.att.com><mailto:acm@research.att.com>

Cc: bmwg@ietf.org<mailto:bmwg@ietf.org>; asamonte@fortinet.com<mailto:asamonte@fortinet.com>;

amritam.putatunda@keysight.com<mailto:amritam.putatunda@keysight.com>; 'Bala Balarajah' <bala@netsecopen.org><mailto:bala@netsecopen.org>;

'Carsten Rossenhoevel'

<cross@eantc.de><mailto:cross@eantc.de>; 'Christopher Brown' <cbrown@iol.unh.edu><mailto:cbrown@iol.unh.edu>; 'Jack, Mike'

<Mike.Jack@spirent.com><mailto:Mike.Jack@spirent.com>; 'Ryan Liles (ryliles)' <ryliles@cisco.com><mailto:ryliles@cisco.com>;

'Timothy Carlin' <tjcarlin@iol.unh.edu><mailto:tjcarlin@iol.unh.edu>; 'Timothy Otto'

<totto@juniper.net><mailto:totto@juniper.net>

Subject: RE: [bmwg] WGLC on New version of

draft-ietf-bmwg-ngfw-performance



Looping in the others on my original post.



Thanks Sarah,



Good to see the issues are being whittled down. Of the remaining five

or six issues I doubt we will have a response prior to IETF 111.



Al,



Could we schedule an interim meetup/call for some time early August?



Brian





-----Original Message-----

From: Sarah Banks <sbanks@encrypted.net><mailto:sbanks@encrypted.net>

Sent: Monday, July 12, 2021 5:20 PM

To: bmonkman@netsecopen.org<mailto:bmonkman@netsecopen.org>

Cc: bmwg@ietf.org<mailto:bmwg@ietf.org>

Subject: Re: [bmwg] WGLC on New version of

draft-ietf-bmwg-ngfw-performance



Hi Brian et al,

    First, my apologies for the delay, and I very much appreciate your

patience. I also appreciate the time and effort that went into the

reply to my comments, which can be even more difficult to do as a

large group :) Please see inline.



Thank you,

Sarah (as a participant)





Hi Sarah,



As I mentioned in the previous message, we will remove reference to

IDS from the draft. Given that, none of the IDS related

comments/questions are being addressed.



SB// Makes sense, thank you.



- The draft aims to replace RFC3511, but expands scope past

Firewalls, to "next generation security devices". I'm not finding a

definition of what a "next generation security device is", nor an

exhaustive list of the devices covered in this draft. A list that

includes is nice, but IMO not enough to cover what would be

benchmarked here - I'd prefer to see a definition and an exhaustive

list.



[bpm] "We avoid limiting the draft by explicitly adding a list of

NG security devices currently available in the market only. In the

future, there may be more and more new types of NG security devices

that will appear on the market.



SB// I think there are 2 types of devices called out; I'm not seeing a

definition of what a "NG security device" is, and I'm not comfortable

with a draft that has a blanket to encompass what would come later.

Who knows what new characteristics would arrive with that new device?

I think the scope here is best suited for the devices we know about

today and can point to and say we're applying knowledgeable benchmarking

tests against.





[bpm] This draft includes a list of security features that the

security device can have ( RFC 3511 doesn't have such a list).

Also, we will describe in the draft that the security devices must

be

configured ""in-line"" mode.

We believe these two points qualifying the definition of next

generation security.





SB// I strongly disagree. Well, I mean OK, for active inline devices

maybe this is OK, but to say that the only way a device can be "NG" is

to be active/inline, I disagree with. And if there is, have we

gathered all of the items we'd want to actively test for in that case?

For example, what about their abilities to handle traffic when a failure

occurs? (fail open/closed).

What about alerts and detections and the whole federation of tests

around positives/false positives/false negatives, etc? I'm onboard

with expanding the scope, but then we have to do the devices

benchmarking justice, and I feel we're missing a lot here.



- What is a NGIPS or NGIDS? If there are standardized definitions

pointing to them is fine, otherwise, there's a lot of wiggle room here.



[bpm] See above. We are removing NGIDS from the draft.



SB// Understood, thank you.





- I still have the concern I shared at the last IETF meeting, where

here, we're putting active inline security devices in the same

category as passive devices. On one hand, I'm not sure I'd lump

these three together in the first place; on the other, active

inline devices typically include additional functions to allow

administrators to control what happens to packets in the case of

failure, and I don't see those test cases included here.



[bpm] This draft focuses on ""in-line"" mode security devices only.

We will describe this in section 4 in more detail.



SB// Understood, thank you.





[bpm] Additionally, the draft focuses mainly on performance tests.

The DUT must be configured in ""fail close"" mode. We will describe

this under section 4. Any failure scenarios like ""fail open"" mode

is

out of scope.



SB// OK, but I think an RFC that is going to encompass this device

under the "NG security devices" classification is missing out on large

portions of what customers will want to test. It'll also beg for

another draft to cover them, and then I'm not sure we're serving the

industry as well as we could.





- Section 4.1 - it reads as if ANY device in the test setup cannot

contribute to network latency or throughput issues, including the

DUTs

- is that what you intended?



[bpm] "Our intention is, if the external devices (routers and

switches) are used in the test bed, they should not negatively

impact

DUT/SUT performance.

To address this, we added a section ( section 5 ""Test Bed

Considerations"") which recommends a pre-test.  We can rename this

as reference test or baseline test. "





SB// Thank you for the clarification. I think there's still a concern

there.

Who defines what "negative impact" is? You're traversing at least

another L2 or L3 step in the network with each bump, which contributes

some amount of latency. If they don't serve in control plane decisions

and are passively passing data on, then we could consider removing

them from the setup and removing the potential skew on results.





- Option 1: It'd be nice to see a specific, clean, recommended test

bed.

There are options for multiple emulated routers. As a tester, I

expect to see a specific, proscribed test bed that I should

configure and test against.



[bpm] The draft describes that Option 1 is the recommended test setup.

However. We added emulated routers as optional in option 1. The

reason for

that:

Some type of security devices for some deployment scenarios

requires routers between test client/server and the DUT (e.g.,

NGFW) and some DUT/SUT doesn't need router (e.g. NGIPS )



- Follow on: I'm curious as to the choice of emulated routers here.

The previous test suggests you avoid routers and switches in the

topo, but then there are emulated ones here. I'm curious as to what

advantages you think these bring over the real deal, and why they

aren't subject to the same limitations previously described?



[bpm] Comparing real router, the emulated router gives more

advantages for

L7 testing.



[bpm] - Emulated router doesn't add latency. Even if it adds delay

due to the routing process, the test equipment can report the added

latency, or it can consider this for the latency measurement.



[bpm] - Emulated routers simply do routing function only. But in a

"real"

router, we are not sure what else the router is doing with the packets.



SB// Maybe I'm missing something here - a device can't perform a

function for free, right? Even if it's impact is negligible, it's an

impact of some sort. We're saying the emulated router is doing the

routing - OK - but I think the same thing applies to the physical

router - how do you know what else the emulated router is doing? if

the test gear can call out the latency, I'd like to see clarification

around how it's doing that and distinguishing the latency introduced

by Device A, versus Device B, versus the DUT, etc.







[bpm] Your question regarding the need for routers:



[bpm] - We avoid impacting the DUT/SUT performance due to ARP or ND

process



[bpm] - Represent realistic scenario (In the production environment

the security devices will not be directly connected with the

clients.)



[bpm] - Routing (L3 mode) is commonly used in the NG security devices.



[bpm] However, in both figures we mentioned that router including

emulated router is optional. If there is no need have routing

functionality on the test bed (e.g., if we used very small number

of clients and server IPs or the DUT operates in Layer 2 mode), it

can be

ignored.



[bpm] Also, we described in Option 1, that the external devices are

if there is need to aggregate the interfaces of the tester or DUT.

For an example, DUT has 2 Interfaces, but tester need to use it's 4

interfaces to achieve the performance. So here we need

switch/router to aggregate tester interface from 4 to 2.



- In section 4.1 the text calls out Option 1 as the preferred test

bed, which includes L3 routing, but it's not clear why that's needed?



[bpm] See above.



- The difference between Option 1 and Option 2 is the inclusion of

additional physical gear in Option 2 - it's not clear why that's

needed, or why the tester can't simply directly connect the test

equipment to the DUT and remove extraneous devices from potential

influence on results?



[bpm] See above.



- Section 4.2, the table for NGFW features - I'm not sure what the

difference is between RECOMMENDED and OPTIONAL? (I realize that you

might be saying that RECOMMENDED is the "must have enabled"

features, where as optional is at your discretion, but would

suggest that you make that clear)



[bpm] The definition for OPTIONAL and RECOMMENDED is described in,

and recommended, RFC2119. We already referenced this under the

section

2 "Requirements".





SB// Thanks!



- Proscribing a list of features that have to be enabled for the

test, or at least more than 1, feels like a strange choice here -

I'd have expected tests cases that either test the specific

features one at a time, or suggest several combinations, but that

ultimately, we'd tell the tester to document WHICH features were

enabled, to make the test cases repeatable? This allows the tester

to apply a same set of apples to apples configurations to different

vendor gear, and omit the 1 feature that doesn't exist on a

different NGFW (for example), but

hold a baseline that could be tested.



- Table 2: With the assumption that NGIPS/IDS are required to have

the features under "recommended", I disagree with this list. For

example, some customers break and inspect at the tap/agg layer of

the network - in this case, the feed into the NGIDS might be

decrypted, and there's no need to enable SSL inspection, for example.



[bpm] IDS is being removed.



SB// OK...I'm not sure this addresses the feedback though :) A NGFW

for sure will do break/inspect as well, right?





- Table 3: I disagree that an NGIDS IS REQUIRED to decrypt SSL.

This behaviour might be suitable for an NGIPS, but the NGIDS is not

a bump on the wire, and often isn't decrypting and re-encrypting the

traffic.



[bpm] IDS is being removed.



SB// See comment above.





- Table 3: An NGIDS IMO is still a passive device - it wouldn't be

blocking anything, but agree that it might tell you that it

happened

after the fact.



[bpm] IDS is being removed.

SB// Thanks!





- Table 3: Anti-evasion definition - define "mitigates".



[bpm] Not sure why you are asking this as mitigate is not an

uncommon term/word.



- Table 3: Web-filtering - not a function of an NGIDS.



[bpm] IDS is being removed.



- Table 3: DLP: Not applicable for an NGIDS.



[bpm] IDS is being removed.



- Can you expand on "disposition of all flows of traffic are logged"

- what's meant here specifically, and why do they have to be logged?

(Logging, particularly under high loads, will impact it's own

performance marks, and colours output)



[bpm] We intentionally recommended enabling logging which will

impact the performance. The draft is not aiming to get high

performance number with minimal DUT/SUT configuration. In contrast,

it aims to get reasonable performance number with realistic DUT

configuration.

The realistic configuration can vary based on DUT/SUT deployment

scenario.



[bpm] In most of the DUT/SUT deployment scenarios or customer

environments, logging is enabled as default configuration.



[bpm] "Disposition of all flows of traffic are logged": means that

the DUT/SUT need to log all the traffic at the flow level not each

packet.



[bpm] We will add more clarification for the meaning of

"disposition of all flows of traffic are logged".





SB// Thanks!



- ACLs wouldn't apply to an IDS because IDS's aren't blocking

traffic

:)



[bpm] IDS is being removed.



- It might be helpful to testers to say something like "look,

here's one suggested set of ACLs. If you're using them, great,

reference that, but otherwise, make note of the ACLs you use, and

use the same ones for repeatable testing".



[bpm] The draft gives guidance how to choose the ACL rules. We

describe here a methodology to create ACL.



- 4.3.1.1 The doc proscribes specific MSS values for v4/v6 with no

discussion around why they're chosen - that color could be useful

to the reader.



[bpm] We will add some more clarification that these are the

default number used in most of the client operating systems currently.





SB// Thanks!



- 4.3.1.1 - there's a period on the 3rd to last line "(SYN/ACL, ACK).

and"

that should be changed.



[bpm] Thank you.



- 4.3.1.1 - As a tester with long time experience with major test

equipment manufacturers, I can't possibly begin to guess which ones

of them would conform to this - or even if they'd answer these

questions.

How helpful is this section to the non test houses? I suggest

expansion here, ideally with either covering the scope of what you

expect to cover, or hopefully which (open source/generally

available) test tools or emulators could be considered for use as

examples.



[bpm] We extensively discussed with Ixia and Spirent about this

section.

This section was developed with significant input from these test

tools vendors in addition to others.



SB// OK, that's really good to know, but there are plenty of us

working with and looking for more cost effective options to Ixia and

Spirent. :) I think the expansion would be good here.





- 4.3.1.3 - Do the emulated web browser attributes really apply to

testing the NGIPS?



[bpm] Yes, we performed many PoC tests with test tools. Ixia and

Spirent confirmed this.



- 4.3.2.3 - Do you expect to also leverage TLS 1.3 as a

configuration option here?



[bpm] Yes



- 4.3.4 - I'm surprised to see the requirement that all sessions

establish a distinct phase before moving on to the next. You might

clarify why this is a requirement, and why staggering them is

specifically rejected?



[bpm] This draft doesn't describe that all sessions establish a

distinct phase before moving on to the next. We will remove the

word "distinct" from the 1st paragraph in section 4.3.4.



SB// Thanks!





[bpm] Unlike Layer 2/3 testing, Layer 7 testing requires several

phases in the traffic load profile. The traffic load profile

described in the draft is the common profile mostly used for Layer

7

testing.



- 5.1 - I like the sentence, but it leaves a world of possibilities

open as to how one confirmed that the ancillary switching, or

routing functions didn't limit the performance, particularly the

virtualized

components?



[bpm] The sentence says, "Ensure that any ancillary switching or

routing functions between the system under test and the test

equipment do not limit the performance of the traffic generator."



[bpm] Here we discuss the traffic generator performance, and this

can be confirmed by doing reference test.



[bpm] The section 5 recommends reference test to ensure that the

maximum desired traffic generator's performance. Based on the

reference test results it can be identified, if the external device

added any impact on traffic generator's performance.



[bpm] We will add more content in section 5 to provide more details

about reference test.





SB// Thanks!



- 5.3 - this is a nice assertion but again, how do I reasonably

make the assertion?



[bpm] We will change the word from "Assertion" to "Ensure". Also,

we will add more clarity about reference testing.





SB// Thanks!





- 6.1 - I would suggest that the test report include the

configuration of ancillary devices on both client/server side as

well



[bpm] We believe that adding configuration of the ancillary devices

doesn't add more value in the report. Instead of this, we will

recommend documenting the configuration of the ancillary devices by

doing reference test. We will add this under the section 5 "Test

bed

consideration".





SB// I think including them assists greatly in the repeatability of

the testing, for what it's worth.



- 6.3 - Nothing on drops anywhere?



[bpm] Are you referring to packet drops? If you are, there is no

packet loss in stateful traffic. Instead of packet loss, the

stateful traffic has retransmissions.



- 7.1.3.2 - Where are these numbers coming from? How are you

determining the "initial inspected throughput"? Maybe I missed that

in the document overall, but it's not clear to me where these KPIs

are collected? I suggest this be called out.



[bpm] We will add more clarification in the next version. Thank you.



SB// Thanks!





- 7.1.3.3 - what is a "relevant application traffic mix" profile?



[bpm] This is described in section7.1.1  (2nd paragraph). We will

add the word "relevant" in the 1st sentence of the 2nd pragraph.so

the sentence will be "Based on customer use case, users can choose

the relevant application traffic mix for this test.  The details

about the traffic mix MUST be documented in the report.  At least

the following traffic mix details MUST be documented and reported

together

with the test results:



SB// A set of example(s) could be helpful. Not required, just helpful.





- 7.1.3.4 - where does this monitoring occur?



[bpm] The monitoring or measurement must occur in the test equipment.

Section 4.3.4 describes this.



- 7.1.3.4 - This looks a bit like conformance testing -  Why does

item

(b) require a specific number/threshold?



[bpm] These numbers are synonymous with the zero-packet loss

criteria for [RFC2544] Throughput and recognize the additional

complexity of application layer performance. This was agreed by the

IETF BMWG.



- 9: Why is the cipher squite recommendation for a real deployment

outside the scope of this document?



[bpm] Because new cipher suites are frequently developed. Given

that the draft will not be easily updated once it is accepted as an

RFC we wanted to ensure there was flexibility to use future

developed cipher

suites.



Brian Monkman on behalf of....



Alex Samonte (Fortinet), Amritam Putatunda (Ixia/Keysight), Bala

Balarajah (NetSecOPEN), Carsten Rossenhoevel (EANTC), Chris Brown

(UNH-IOL), Mike Jack (Spirent), Ryan Liles (Cisco), Tim Carlin

(UNH-IOL), Tim Otto (Juniper)











--

Carsten Rossenhövel

Managing Director, EANTC AG (European Advanced Networking Test Center)

Salzufer 14, 10587 Berlin, Germany

office +49.30.3180595-21, fax +49.30.3180595-10, mobile +49.177.2505721

cross@eantc.de<mailto:cross@eantc.de>, https://www.eantc.de<https://urldefense.com/v3/__https:/www.eantc.de__;!!BhdT!x_nyyuYbLuR_bxaZQzRebn-62Pq05wFObCEJ0-gdObGoaHM0WyFnsSV1q7Jm$>



Place of Business/Sitz der Gesellschaft: Berlin, Germany

Chairman/Vorsitzender des Aufsichtsrats: Herbert Almus

Managing Directors/Vorstand: Carsten Rossenhövel, Gabriele Schrenk

Registered: HRB 73694, Amtsgericht Charlottenburg, Berlin, Germany

EU VAT No: DE812824025