Re: [bmwg] Several inconsistencies in current draft-ietf-bmwg-ngfw-performance

"MORTON, ALFRED C (AL)" <> Wed, 07 April 2021 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B06A43A1D45; Wed, 7 Apr 2021 08:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RrEdISb411Kx; Wed, 7 Apr 2021 08:31:17 -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 8A91E3A1D41; Wed, 7 Apr 2021 08:31:17 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 137FLHDX030405; Wed, 7 Apr 2021 11:31:17 -0400
Received: from ( []) by with ESMTP id 37sfaa87rg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Apr 2021 11:31:16 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 137FVEEW015606; Wed, 7 Apr 2021 10:31:15 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 137FVD44015574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Apr 2021 10:31:13 -0500
Received: from ( []) by (Service) with ESMTP id 4DA0A401B727; Wed, 7 Apr 2021 15:31:13 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTP id 1D6F1401B722; Wed, 7 Apr 2021 15:31:13 +0000 (GMT)
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 137FVCoH008141; Wed, 7 Apr 2021 10:31:12 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 137FV4tZ006451; Wed, 7 Apr 2021 10:31:05 -0500
Received: from ( []) by (Postfix) with ESMTP id 7BD7810A18F4; Wed, 7 Apr 2021 11:31:04 -0400 (EDT)
Received: from ([fe80::b09c:ff13:4487:78b6]) by ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0513.000; Wed, 7 Apr 2021 11:31:24 -0400
From: "MORTON, ALFRED C (AL)" <>
To: Redkin Petr <>, "" <>
Thread-Topic: Several inconsistencies in current draft-ietf-bmwg-ngfw-performance
Thread-Index: AdcrnSntzTiMhigzR7qWQaczOhz46gAJHB6w
Date: Wed, 7 Apr 2021 15:31:23 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF0147CF7D7Enjmtexg5resea_"
MIME-Version: 1.0
X-Proofpoint-ORIG-GUID: UOAZ7lIPEPxYdzBWC1T8QlCCTAk6q4g0
X-Proofpoint-GUID: UOAZ7lIPEPxYdzBWC1T8QlCCTAk6q4g0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-07_08:2021-04-07, 2021-04-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 suspectscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 priorityscore=1501 clxscore=1011 impostorscore=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104070108
Archived-At: <>
Subject: Re: [bmwg] Several inconsistencies in current draft-ietf-bmwg-ngfw-performance
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: Wed, 07 Apr 2021 15:31:22 -0000

Hi Petr,

Thanks for your comments on the NGFW draft.  Please subscribe to bmwg-list to ensure that you see all replies.

A few replies below, [acm]
(as document shepherd)

From: bmwg <> On Behalf Of Redkin Petr
Sent: Wednesday, April 7, 2021 7:01 AM
Subject: [bmwg] Several inconsistencies in current draft-ietf-bmwg-ngfw-performance


Please, pay attention at several inconsistencies in current netsecopen draft (saw in 6-7 versions).

  1.  TLS SNI

     *   in part of the document SNI is mandatory
The client endpoint SHOULD send TLS Extension Server Name Indication (SNI) information when opening a security tunnel

     *   in part of the document SNI is optional
For TLS the client MAY use Server Name Indication (SNI).
If using SNI, the server will then perform an SNI name check with the proposed FQDN compared to the domain embedded in the certificate.
I want to note our Requirements language, which says that only terms like MUST and SHALL indicate mandatory requirements.  SHOULD is a strong recommendation, and MAY is optional of course, so there are two different requirement levels being used as you point out. I'll let the authors explain their rationale for different requirements levels for SNI (in different tests, perhaps?).

  1.  New connections in sustain phase

     *   From this sentence engineer may assume, that no new connections are established in sustain phase because all clients & connections (it is different concepts) must be established at a ramp up

Sustain phase starts when all required clients (connections) are active and operating at their desired load condition.

     *   But it is not, otherwise we cannot measure CPS metric in sustain phase, for example in traffic mix test
Optional KPIs: TCP Connections Per Second and TLS Handshake Rate

  1.  Client source port

     *   In part of the document source port is variable in range and varies per client connection
The source port range SHOULD be in the range of 1024 - 65535.
The behavior of the client is to sweep through the given server IP space, sequentially generating a recognizable service by the DUT.  Thus, a balanced, mesh between client endpoints and server endpoints will be generated in a client port server port combination.

     *   But it is not clear from this sentence
Each client endpoint performs the same actions as other endpoints, with the difference being the source IP of the client endpoint and the target server IP pool.

Best Regards,
Petr Redkin

Performance research expert,
JSC "InfoTeCS"