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

bmonkman@netsecopen.org Thu, 08 April 2021 10:51 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 774E63A1154 for <bmwg@ietfa.amsl.com>; Thu, 8 Apr 2021 03:51:09 -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=unavailable 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 GQetmhNOAqaa for <bmwg@ietfa.amsl.com>; Thu, 8 Apr 2021 03:51:05 -0700 (PDT)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 1D8AB3A1158 for <bmwg@ietf.org>; Thu, 8 Apr 2021 03:51:05 -0700 (PDT)
Received: by mail-qv1-xf29.google.com with SMTP id h3so600140qvr.10 for <bmwg@ietf.org>; Thu, 08 Apr 2021 03:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netsecopen-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=T/tYPKMXDhJ2zOrxTmT546KLOEJxCZxYBxNk8MDhCe4=; b=AOJ4apbc6Q+/n/IzZ0v2pLXOWK/U/kUuzKQXNZ/MUsbotpSWJxyH8QwQ2HDkcylYyc QBuSqoLLo3AEDYNk2mOxNHzQfXR4SIS5ofEVXPGDwhkkBVPulMO5dlQOH3qety9VzkeE iSUU6oFyCvLs+fIHHRVC+ojL26ME3+/c5kFWMQWnnaOKE3gIY8vPIhdfvQBtEPNj0M8d 70k0R/gNK3FsofM7hMuneuCFMRFnoaHQ9uVrAUw39SD4RI8C3yzkaFHgjY1kw83z610R OVgx8JFChK3dO/XOm7XGQvhPkPtF2akbAMUDNR85EJ78V6p6SzShKmCpvmpu0mt6+XVN eMVA==
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:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=T/tYPKMXDhJ2zOrxTmT546KLOEJxCZxYBxNk8MDhCe4=; b=Yff9g1HNbJCDJ8EEwu3eT15+p2cG6T9pdDQKfVLvATlMgfs/zzkiAVtqoo2ljTfaCQ GJXRUsoEyd27BjM6lLDzoHJjCj34Fb4Sx4x5Q5BCqpogAEwpLHthbnnCXdccZOrZ4PFV v9vlgE4G3KV2hDaWZDDuHDNcETPvEykxc3kwYZzj3qQy3tLNOehmX7brRi5kSgM6IbOC mXJrnQKzkZ5kxERIPnvxVaHvdJk9mHqzU/x/q+jcKhf1SuRsMVLRHStkx8gzHtZx5zOQ lI8UM5IJa2f63m2wytQKE4YL1E4UHQvdQvByahbCTBdLA9i+zHn0V7mrLoupxaPGVKAT 0O/g==
X-Gm-Message-State: AOAM531R8xXXDw80Yse30PxqmV5Qvuy9FmYHY92y3Kva3R69LK25XfFz W1sceSwU5hfJZ3r5Ndt0CsTxrw==
X-Google-Smtp-Source: ABdhPJw1zjr/s5dTELji6NvEIQRPnVKoBezHTm0OcY5NGxbFWytYU2IL5VlIAe3TbyTL3rA27rGK7w==
X-Received: by 2002:a0c:d7d2:: with SMTP id g18mr8069644qvj.42.1617879061595; Thu, 08 Apr 2021 03:51:01 -0700 (PDT)
Received: from DESKTOP42TMNEU (c-98-235-212-118.hsd1.pa.comcast.net. [98.235.212.118]) by smtp.gmail.com with ESMTPSA id 14sm587774qkf.119.2021.04.08.03.51.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Apr 2021 03:51:00 -0700 (PDT)
From: <bmonkman@netsecopen.org>
To: "'Redkin Petr'" <Petr.Redkin=40infotecs.ru@dmarc.ietf.org>
Cc: "'MORTON, ALFRED C \(AL\)'" <acm@research.att.com>, <bmwg@ietf.org>, "'Bala Balarajah'" <bm.balarajah@gmail.com>
References: <ba3c7a76fccd4875bb5b432550293bf6@infotecs.ru> <4D7F4AD313D3FC43A053B309F97543CF0147CF7D7E@njmtexg5.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF0147CF7D7E@njmtexg5.research.att.com>
Date: Thu, 8 Apr 2021 06:50:59 -0400
Message-ID: <014101d72c65$101fd680$305f8380$@netsecopen.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0142_01D72C43.890EF9D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKBv6dX8qJpWcUn31IK2H1NzaBMYgHl1HoDqUYbz1A=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/9YNRdx9KmXNlEk7Cja501OTtIRA>
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 10:51:09 -0000

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> 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>rg>; 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

a.	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

b.	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?).

 

2.	New connections in sustain phase

a.	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.

b.	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

3.	Client source port

a.	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.

b.	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"