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

Brian Monkman <bmonkman@netsecopen.org> Thu, 08 April 2021 11:31 UTC

Return-Path: <bmonkman@netsecopen.org>
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 EE9A33A1314 for <bmwg@ietfa.amsl.com>; Thu, 8 Apr 2021 04:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netsecopen-org.20150623.gappssmtp.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 gQI9yk3KM3_p for <bmwg@ietfa.amsl.com>; Thu, 8 Apr 2021 04:31:55 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF8C3A130F for <bmwg@ietf.org>; Thu, 8 Apr 2021 04:31:54 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id c6so1092385qtc.1 for <bmwg@ietf.org>; Thu, 08 Apr 2021 04:31:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netsecopen-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=qwgI9OKM8nzVqcwY5BQT8NpNBmp0AFMm8M8+vsBhTDI=; b=n3KMbDJokheKmtHxRt1GPNGpTFJX4iWkuujZGrLbKAEIGEmwwT40S+/bwWUiIe69b5 sx/UC5BNaVMVPxzBzDOW/lGsT7im4BL7k/GGyeNn6mdx+BUSm+n2GzDyTL4maEDkgjwO OGT8Vf3lHHw2hN8tcerAQM2iWsAwgZfC0enTcI1RW8Hmdst/fQ13igNWxpayDK4Ygzqd J+SlnW86pCy4kRAJTjLBjMSOsJ3Voy9b5s10qrE6ETrxdqp5BtrbWeELd3LIEUTIKvkF sDjcky6Z53v0g96t6A4WScwGtMQ3d5PUi7dU2khTpTVO73zG5yTSvKrZ3tlgXcqgXlRb 0P9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=qwgI9OKM8nzVqcwY5BQT8NpNBmp0AFMm8M8+vsBhTDI=; b=TYeNEQvhSQzlvLX5ECpURvAdK9KVjTyQPcaj3tfyZQANUaXMi/99ToQo0bg0ReGIrh OEaslq0vPPGQdKmE9XLQIQOjNX/unmRGomlz2p4cztAcNGiLW3dK7rndSadg8vFH/3S6 3URBZ2WRbbYbRiPjAdacuF+h7AvSIEuVBLDHfUKjJA+X7e6evzfCrwXiEcatvdbt3s5N +EfJl+B7xOBE6ji1Paby5KytB2g4wDgRQCW+mrfbKP3L5IJPTAQTV9itfbLDKNHSOI0l xKVb8Wpl8ArNp1o7vjuNEf8KgGf94YuOTdsAkpmS3wZEfqImSWK6k2d4qQSFJBEQ6TSN 6R1A==
X-Gm-Message-State: AOAM533N1ldY0k0Y4o+VN6EqVw6DT2b9GVjQyp8PR0z83d4O515irqhZ rB4R+Bvv2W+9Ks0+AT3BBlpIoA==
X-Google-Smtp-Source: ABdhPJzLVGK907Y36BsTVqns/IN/YaRth3dwzpR1dGDNg8E6Ihp4JP+wew6E4Yl6/krKg7tbUX31pg==
X-Received: by 2002:ac8:740c:: with SMTP id p12mr6864898qtq.153.1617881511732; Thu, 08 Apr 2021 04:31:51 -0700 (PDT)
Received: from MN2PR19MB3711.namprd19.prod.outlook.com ([2603:1036:302:40cb::5]) by smtp.gmail.com with ESMTPSA id p186sm20653212qka.66.2021.04.08.04.31.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Apr 2021 04:31:51 -0700 (PDT)
From: Brian Monkman <bmonkman@netsecopen.org>
To: Redkin Petr <Petr.Redkin@infotecs.ru>
CC: "'MORTON, ALFRED C (AL)'" <acm@research.att.com>, "bmwg@ietf.org" <bmwg@ietf.org>, 'Bala Balarajah' <bm.balarajah@gmail.com>
Thread-Topic: [bmwg] Several inconsistencies in current draft-ietf-bmwg-ngfw-performance
Thread-Index: AdcrnSntzTiMhigzR7qWQaczOhz46gAJHB6wACjdN4AAAWNkAAAABj/Q
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 8 Apr 2021 11:31:50 +0000
Message-ID: <MN2PR19MB3711921A1899AAC0AEBB31E5FE749@MN2PR19MB3711.namprd19.prod.outlook.com>
References: <ba3c7a76fccd4875bb5b432550293bf6@infotecs.ru> <4D7F4AD313D3FC43A053B309F97543CF0147CF7D7E@njmtexg5.research.att.com> <014101d72c65$101fd680$305f8380$@netsecopen.org>, <926bef65cb6c4784a9fffdc0e36b911e@infotecs.ru>
In-Reply-To: <926bef65cb6c4784a9fffdc0e36b911e@infotecs.ru>
Accept-Language: en-US
Content-Language: en-CA
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB3711921A1899AAC0AEBB31E5FE749MN2PR19MB3711namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/hhC5YgUO0bbQB1iWJ7PFT0u6QQg>
Subject: Re: [bmwg] Several inconsistencies in current 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: Thu, 08 Apr 2021 11:32:00 -0000

Thanks for you suggestion.

Brian

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Redkin Petr <Petr.Redkin@infotecs.ru>
Sent: Thursday, April 8, 2021 7:30:44 AM
To: bmonkman@netsecopen.org <bmonkman@netsecopen.org>
Cc: 'MORTON, ALFRED C (AL)' <acm@research.att.com>om>; bmwg@ietf.org <bmwg@ietf.org>rg>; 'Bala Balarajah' <bm.balarajah@gmail.com>
Subject: RE: [bmwg] Several inconsistencies in current draft-ietf-bmwg-ngfw-performance


I think that the proposed changes (for all comments) will make the text of the document more understandable and eliminate potential differences in interpretations. Thanks.



I also suggest revise the document in the context of supporting non-inline products (NGFW or NGIDS/NGIPS device in monitor-only mode) in performance tests or restrict it to only inline mode as in security effectiveness test. The estimation approach based on traffic degradation is not applicable in this case.





Best Regards,

Petr Redkin



Performance research expert,

JSC "InfoTeCS"



From: bmonkman@netsecopen.org <bmonkman@netsecopen.org>
Sent: Thursday, April 8, 2021 1:51 PM
To: Redkin Petr <Petr.Redkin@infotecs.ru>
Cc: 'MORTON, ALFRED C (AL)' <acm@research.att.com>om>; bmwg@ietf.org; 'Bala Balarajah' <bm.balarajah@gmail.com>
Subject: RE: [bmwg] Several inconsistencies in current draft-ietf-bmwg-ngfw-performance



Petr,



Here’s our response to each item….



Response for Comment 1:

The confusion or inconsistency has occurred since we use SNI as mandatory for a test scenario (traffic mix test) and as optional for other test scenarios.

We will revise the text and provide more clarity in the next version.



  Response for Comment 2:

The sentence doesn't describe that the client must keep the connections open during the sustain phase. However, we can change the sentence as follows

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

This means that the clients/client endpoints are established their required target connection (based on configured load). It is obvious that the clients will close the connections once they received all contents from the server. Also, the clients will establish new connections during the sustain phase. Otherwise, there is no traffic in the sustain phase and the test equipment can't keep the desired load.



  Response for Comment 3:

The endpoints perform the same action. However, the IPs (SRC and DST) and also ports (random source port from the range) are different. we can change the text if more clarity required.

"Thus, a balanced mesh between client endpoints and server endpoints will be generated in a client IP/port server IP/port combination.



Brian and Bala



From: bmwg <bmwg-bounces@ietf.org<mailto:bmwg-bounces@ietf.org>> On Behalf Of MORTON, ALFRED C (AL)
Sent: Wednesday, April 7, 2021 11:31 AM
To: Redkin Petr <Petr.Redkin=40infotecs.ru@dmarc.ietf.org<mailto:Petr.Redkin=40infotecs.ru@dmarc.ietf.org>>; bmwg@ietf.org<mailto:bmwg@ietf.org>
Subject: Re: [bmwg] Several inconsistencies in current draft-ietf-bmwg-ngfw-performance



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

(as document shepherd)



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



Hello,



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.

[acm]

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"