Re: [bmwg] NGFW Security Features Text

"MORTON, ALFRED C (AL)" <> Tue, 02 June 2020 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1CAE3A1094 for <>; Tue, 2 Jun 2020 15:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OfIsEBVu-HLo for <>; Tue, 2 Jun 2020 15:25:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7940A3A1092 for <>; Tue, 2 Jun 2020 15:25:57 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 052MCVTI037570; Tue, 2 Jun 2020 18:25:57 -0400
Received: from ( []) by with ESMTP id 31d8hg1n17-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Jun 2020 18:25:56 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 052MPtdH120917; Tue, 2 Jun 2020 17:25:55 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 052MPojl120832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jun 2020 17:25:50 -0500
Received: from ( []) by (Service) with ESMTP id 17EE44005C32; Tue, 2 Jun 2020 22:25:50 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTP id 03A8C4005C18; Tue, 2 Jun 2020 22:25:50 +0000 (GMT)
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 052MPn1s008599; Tue, 2 Jun 2020 17:25:49 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 052MPiVY008421; Tue, 2 Jun 2020 17:25:44 -0500
Received: from ( []) by (Postfix) with ESMTPS id 6816D10AF919; Tue, 2 Jun 2020 18:25:43 -0400 (EDT)
Received: from ([fe80::b09c:ff13:4487:78b6]) by ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Tue, 2 Jun 2020 18:25:43 -0400
From: "MORTON, ALFRED C (AL)" <>
To: Timothy Carlin <>, "" <>
Thread-Topic: [bmwg] NGFW Security Features Text
Thread-Index: AQHWOP1DfELIDH7Y+E+/JSrLhgr8EKjF5orA
Date: Tue, 2 Jun 2020 22:25:42 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF0108A5F083njmtexg5resea_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-02_15:2020-06-02, 2020-06-02 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 cotscore=-2147483648 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 clxscore=1011 adultscore=0 spamscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006020156
Archived-At: <>
Subject: Re: [bmwg] NGFW Security Features Text
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Benchmarking Methodology Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jun 2020 22:25:59 -0000

Hi Tim,

Thanks for doing your volunteer work with this review, much appreciated!

May I make a small suggestion on your proposed text?
I think we achieve some clarity if we add “limit” near the end:

s/ this MAY be configurable../ this limit MAY be configurable./

assuming that’s what you meant!

thanks again and regards,

From: bmwg [] On Behalf Of Timothy Carlin
Sent: Tuesday, June 2, 2020 12:45 PM
Subject: [bmwg] NGFW Security Features Text

Hi all,

I wanted to mention that I have read draft-ietf-bmwg-ngfw-performance-03 and I support it.

I have additional text I would like to suggest be included to help to clarify an ambiguity with regards to security feature processing.  Specifically, in the case that a DUT discontinues processing a security feature (for example, SSL Inspection), traffic should still be processed by the remainder of the applicable security features.  Said another way, the traffic should NOT "fail open".

Here is some proposed text to add to Section 4.2, in the itemized list as the 2nd item (below "All security inspection enabled"):

* All applicable traffic MUST be processed by the configured security feature(s) in table 1.  In the case that applicable traffic can no longer be processed for a given security feature (e.g. due to processing or throughput limits, etc.), the portion of traffic which exceeds the limit SHOULD be blocked and this MAY be configurable..

Please let us know if you have any questions or comments.

Best Regards,
Tim C.