draft-ietf-bmwg-ngfw-performance-03.txt   draft-ietf-bmwg-ngfw-performance-04.txt 
Benchmarking Methodology Working Group B. Balarajah Benchmarking Methodology Working Group B. Balarajah
Internet-Draft Internet-Draft
Intended status: Informational C. Rossenhoevel Intended status: Informational C. Rossenhoevel
Expires: September 10, 2020 EANTC AG Expires: March 13, 2021 EANTC AG
B. Monkman B. Monkman
NetSecOPEN NetSecOPEN
March 9, 2020 September 9, 2020
Benchmarking Methodology for Network Security Device Performance Benchmarking Methodology for Network Security Device Performance
draft-ietf-bmwg-ngfw-performance-03 draft-ietf-bmwg-ngfw-performance-04
Abstract Abstract
This document provides benchmarking terminology and methodology for This document provides benchmarking terminology and methodology for
next-generation network security devices including next-generation next-generation network security devices including next-generation
firewalls (NGFW), intrusion detection and prevention solutions (IDS/ firewalls (NGFW), intrusion detection and prevention solutions (IDS/
IPS) and unified threat management (UTM) implementations. This IPS) and unified threat management (UTM) implementations. This
document aims to strongly improve the applicability, reproducibility, document aims to strongly improve the applicability, reproducibility,
and transparency of benchmarks and to align the test methodology with and transparency of benchmarks and to align the test methodology with
today's increasingly complex layer 7 application use cases. The main today's increasingly complex layer 7 application use cases. The main
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on March 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Testbed Configuration . . . . . . . . . . . . . . . . . . 4 4.1. Testbed Configuration . . . . . . . . . . . . . . . . . . 4
4.2. DUT/SUT Configuration . . . . . . . . . . . . . . . . . . 5 4.2. DUT/SUT Configuration . . . . . . . . . . . . . . . . . . 5
4.3. Test Equipment Configuration . . . . . . . . . . . . . . 9 4.3. Test Equipment Configuration . . . . . . . . . . . . . . 10
4.3.1. Client Configuration . . . . . . . . . . . . . . . . 10 4.3.1. Client Configuration . . . . . . . . . . . . . . . . 10
4.3.2. Backend Server Configuration . . . . . . . . . . . . 11 4.3.2. Backend Server Configuration . . . . . . . . . . . . 12
4.3.3. Traffic Flow Definition . . . . . . . . . . . . . . . 12 4.3.3. Traffic Flow Definition . . . . . . . . . . . . . . . 13
4.3.4. Traffic Load Profile . . . . . . . . . . . . . . . . 13 4.3.4. Traffic Load Profile . . . . . . . . . . . . . . . . 14
5. Test Bed Considerations . . . . . . . . . . . . . . . . . . . 14 5. Test Bed Considerations . . . . . . . . . . . . . . . . . . . 15
6. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Key Performance Indicators . . . . . . . . . . . . . . . 16 6.1. Key Performance Indicators . . . . . . . . . . . . . . . 17
7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 17 7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 18
7.1. Throughput Performance With NetSecOPEN Traffic Mix . . . 17 7.1. Throughput Performance With NetSecOPEN Traffic Mix . . . 18
7.1.1. Objective . . . . . . . . . . . . . . . . . . . . . . 17 7.1.1. Objective . . . . . . . . . . . . . . . . . . . . . . 18
7.1.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 18 7.1.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 18
7.1.3. Test Parameters . . . . . . . . . . . . . . . . . . . 18 7.1.3. Test Parameters . . . . . . . . . . . . . . . . . . . 18
7.1.4. Test Procedures and expected Results . . . . . . . . 20 7.1.4. Test Procedures and Expected Results . . . . . . . . 20
7.2. TCP/HTTP Connections Per Second . . . . . . . . . . . . . 21 7.2. TCP/HTTP Connections Per Second . . . . . . . . . . . . . 21
7.2.1. Objective . . . . . . . . . . . . . . . . . . . . . . 21 7.2.1. Objective . . . . . . . . . . . . . . . . . . . . . . 21
7.2.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 21 7.2.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 21
7.2.3. Test Parameters . . . . . . . . . . . . . . . . . . . 21 7.2.3. Test Parameters . . . . . . . . . . . . . . . . . . . 22
7.2.4. Test Procedures and Expected Results . . . . . . . . 22 7.2.4. Test Procedures and Expected Results . . . . . . . . 23
7.3. HTTP Throughput . . . . . . . . . . . . . . . . . . . . . 24 7.3. HTTP Throughput . . . . . . . . . . . . . . . . . . . . . 24
7.3.1. Objective . . . . . . . . . . . . . . . . . . . . . . 24 7.3.1. Objective . . . . . . . . . . . . . . . . . . . . . . 24
7.3.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 24 7.3.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 24
7.3.3. Test Parameters . . . . . . . . . . . . . . . . . . . 24 7.3.3. Test Parameters . . . . . . . . . . . . . . . . . . . 25
7.3.4. Test Procedures and Expected Results . . . . . . . . 26 7.3.4. Test Procedures and Expected Results . . . . . . . . 27
7.4. TCP/HTTP Transaction Latency . . . . . . . . . . . . . . 27 7.4. TCP/HTTP Transaction Latency . . . . . . . . . . . . . . 28
7.4.1. Objective . . . . . . . . . . . . . . . . . . . . . . 27 7.4.1. Objective . . . . . . . . . . . . . . . . . . . . . . 28
7.4.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 27 7.4.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 28
7.4.3. Test Parameters . . . . . . . . . . . . . . . . . . . 27 7.4.3. Test Parameters . . . . . . . . . . . . . . . . . . . 28
7.4.4. Test Procedures and Expected Results . . . . . . . . 29 7.4.4. Test Procedures and Expected Results . . . . . . . . 30
7.5. Concurrent TCP/HTTP Connection Capacity . . . . . . . . . 30 7.5. Concurrent TCP/HTTP Connection Capacity . . . . . . . . . 31
7.5.1. Objective . . . . . . . . . . . . . . . . . . . . . . 30 7.5.1. Objective . . . . . . . . . . . . . . . . . . . . . . 31
7.5.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 31 7.5.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 32
7.5.3. Test Parameters . . . . . . . . . . . . . . . . . . . 31 7.5.3. Test Parameters . . . . . . . . . . . . . . . . . . . 32
7.5.4. Test Procedures and expected Results . . . . . . . . 32 7.5.4. Test Procedures and Expected Results . . . . . . . . 33
7.6. TCP/HTTPS Connections per second . . . . . . . . . . . . 33 7.6. TCP/HTTPS Connections per Second . . . . . . . . . . . . 34
7.6.1. Objective . . . . . . . . . . . . . . . . . . . . . . 33 7.6.1. Objective . . . . . . . . . . . . . . . . . . . . . . 34
7.6.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 34 7.6.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 35
7.6.3. Test Parameters . . . . . . . . . . . . . . . . . . . 34 7.6.3. Test Parameters . . . . . . . . . . . . . . . . . . . 35
7.6.4. Test Procedures and expected Results . . . . . . . . 36 7.6.4. Test Procedures and Expected Results . . . . . . . . 36
7.7. HTTPS Throughput . . . . . . . . . . . . . . . . . . . . 37 7.7. HTTPS Throughput . . . . . . . . . . . . . . . . . . . . 38
7.7.1. Objective . . . . . . . . . . . . . . . . . . . . . . 37 7.7.1. Objective . . . . . . . . . . . . . . . . . . . . . . 38
7.7.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 37 7.7.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 38
7.7.3. Test Parameters . . . . . . . . . . . . . . . . . . . 37 7.7.3. Test Parameters . . . . . . . . . . . . . . . . . . . 38
7.7.4. Test Procedures and Expected Results . . . . . . . . 40 7.7.4. Test Procedures and Expected Results . . . . . . . . 40
7.8. HTTPS Transaction Latency . . . . . . . . . . . . . . . . 41 7.8. HTTPS Transaction Latency . . . . . . . . . . . . . . . . 41
7.8.1. Objective . . . . . . . . . . . . . . . . . . . . . . 41 7.8.1. Objective . . . . . . . . . . . . . . . . . . . . . . 41
7.8.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 41 7.8.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 41
7.8.3. Test Parameters . . . . . . . . . . . . . . . . . . . 41 7.8.3. Test Parameters . . . . . . . . . . . . . . . . . . . 41
7.8.4. Test Procedures and Expected Results . . . . . . . . 43 7.8.4. Test Procedures and Expected Results . . . . . . . . 43
7.9. Concurrent TCP/HTTPS Connection Capacity . . . . . . . . 44 7.9. Concurrent TCP/HTTPS Connection Capacity . . . . . . . . 44
7.9.1. Objective . . . . . . . . . . . . . . . . . . . . . . 44 7.9.1. Objective . . . . . . . . . . . . . . . . . . . . . . 44
7.9.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 44 7.9.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 44
7.9.3. Test Parameters . . . . . . . . . . . . . . . . . . . 45 7.9.3. Test Parameters . . . . . . . . . . . . . . . . . . . 45
7.9.4. Test Procedures and expected Results . . . . . . . . 46 7.9.4. Test Procedures and Expected Results . . . . . . . . 46
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 47 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 12.1. Normative References . . . . . . . . . . . . . . . . . . 48
13.1. Normative References . . . . . . . . . . . . . . . . . . 48 12.2. Informative References . . . . . . . . . . . . . . . . . 49
13.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. NetSecOPEN Basic Traffic Mix . . . . . . . . . . . . 49 Appendix A. NetSecOPEN Basic Traffic Mix . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
15 years have passed since IETF recommended test methodology and 15 years have passed since IETF recommended test methodology and
terminology for firewalls initially ([RFC2647], [RFC3511]). The terminology for firewalls initially ([RFC2647], [RFC3511]). The
requirements for network security element performance and requirements for network security element performance and
effectiveness have increased tremendously since then. Security effectiveness have increased tremendously since then. Security
function implementations have evolved to more advanced areas and have function implementations have evolved to more advanced areas and have
skipping to change at page 6, line 15 skipping to change at page 6, line 15
feature list which SHOULD be configured on the DUT/SUT. feature list which SHOULD be configured on the DUT/SUT.
Based on customer use case, users MAY enable or disable SSL Based on customer use case, users MAY enable or disable SSL
inspection feature for "Throughput Performance with NetSecOPEN inspection feature for "Throughput Performance with NetSecOPEN
Traffic Mix" test scenario described in Section 7.1 Traffic Mix" test scenario described in Section 7.1
To improve repeatability, a summary of the DUT configuration To improve repeatability, a summary of the DUT configuration
including description of all enabled DUT/SUT features MUST be including description of all enabled DUT/SUT features MUST be
published with the benchmarking results. published with the benchmarking results.
+------------------------+ +------------------------+
| NGFW | | NGFW |
+-------------- +-------------+----------+ +-------------- +-------------+----------+
| | | | | | | |
|DUT Features | RECOMMENDED | OPTIONAL | |DUT Features | RECOMMENDED | OPTIONAL |
| | | | | | | |
+----------------------------------------+ +----------------------------------------+
|SSL Inspection | x | | |SSL Inspection | x | |
+----------------------------------------+ +----------------------------------------+
|IDS/IPS | x | | |IDS/IPS | x | |
+----------------------------------------+ +----------------------------------------+
|Web Filtering | | x | |Anti Spyware | x | |
+----------------------------------------+ +----------------------------------------+
|Antivirus | x | | |Antivirus | x | |
+----------------------------------------+ +----------------------------------------+
|Anti Spyware | x | | |Anti Botnet | x | |
+----------------------------------------+ +----------------------------------------+
|Anti Botnet | x | | |Web Filtering | | x |
+----------------------------------------+ +----------------------------------------+
|DLP | | x | |DLP | | x |
+----------------------------------------+ +----------------------------------------+
|DDoS | | x | |DDoS | | x |
+----------------------------------------+ +----------------------------------------+
|Certificate | | x | |Certificate | | x |
|Validation | | | |Validation | | |
+----------------------------------------+ +----------------------------------------+
|Logging and | x | | |Logging and | x | |
|Reporting | | | |Reporting | | |
+-------------- +------------------------+ +-------------- +------------------------+
|Application | x | | |Application | x | |
|Identification | | | |Identification | | |
+---------------+-------------+----------+ +---------------+-------------+----------+
Table 1: DUT/SUT Feature List Table 1: DUT/SUT Feature
The following table provides a brief description of the security
features.
+------------------+------------------------------------------------+
| DUT/SUT Features | Description |
+------------------+------------------------------------------------+
| SSL Inspection | DUT/SUT intercept and decrypt inbound HTTPS |
| | traffic between servers and clients. Once the |
| | content inspection has been completed, DUT/SUT |
| | MUST encrypt the HTTPS traffic with ciphers |
| | and keys used by the clients and servers. |
+------------------+------------------------------------------------+
| IDS/IPS | DUT MUST detect and block exploits targeting |
| | known and unknown vulnerabilities across the |
| | monitored network. |
+------------------+------------------------------------------------+
| Anti Malware | DUT MUST detect and prevent the transmission of|
| | malicious executable code and any associated |
| | communications across the monitored network. |
| | This includes data exfiltration as well as |
| | command and control channels. |
+------------------+------------------------------------------------+
| Web Filtering | DUT MUST detect and block malicious websites |
| | including defined classifications of website |
| | across the monitored network. |
+------------------+------------------------------------------------+
| DLP | DUT MUST detect and block the transmission of |
| | Personally Identifiable Information (PII) and |
| | specific files across the monitored network. |
+------------------+------------------------------------------------+
| Certificate | DUT MUST validate certifcates used in encrypted|
| Validation | comunications across the monitored network. |
+------------------+------------------------------------------------+
| Logging and | DUT MUST be able to log and report all traffic |
| Reporting | at the flow level across the monitored network.|
+------------------+------------------------------------------------+
| Application | DUT MUST detect known applications as defined |
| Identification | within the traffic mix selected across the |
| | monitored network. |
+------------------+------------------------------------------------+
Table 2: NGFW Security Feature Description
In summary, DUT/SUT SHOULD be configured as follows: In summary, DUT/SUT SHOULD be configured as follows:
o All security inspection enabled o All security inspection enabled
o Disposition of all flows of traffic are logged - Logging to an o Disposition of all flows of traffic are logged - Logging to an
external device is permissible external device is permissible
o Detection of Common Vulnerabilities and Exposures (CVE) matching o Detection of Common Vulnerabilities and Exposures (CVE) matching
the following characteristics when searching the National the following characteristics when searching the National
skipping to change at page 7, line 36 skipping to change at page 8, line 31
o Geographical location filtering and Application Identification and o Geographical location filtering and Application Identification and
Control configured to be triggered based on a site or application Control configured to be triggered based on a site or application
from the defined traffic mix from the defined traffic mix
In addition, a realistic number of access control rules (ACL) MUST be In addition, a realistic number of access control rules (ACL) MUST be
configured on the DUT/SUT. However, this is applicable only for the configured on the DUT/SUT. However, this is applicable only for the
security devices where ACL's are configurable. This document security devices where ACL's are configurable. This document
determines the number of access policy rules for four different determines the number of access policy rules for four different
classes of DUT/SUT. The classification of the DUT/SUT MAY be based classes of DUT/SUT. The classification of the DUT/SUT MAY be based
on its maximum supported firewall throughput performance number on its maximum supported firewall throughput performance number
defined in the vendor data sheet. This document classifies the DUT/ defined in the vendor datasheet. This document classifies the DUT/
SUT in four different categories; namely Extra Small, Small, Medium, SUT in four different categories; namely Extra Small, Small, Medium,
and Large. and Large.
The RECOMMENDED throughput values for the following classes are: The RECOMMENDED throughput values for the following classes are:
Extra Small (XS) - supported throughput less than 1Gbit/s Extra Small (XS) - supported throughput less than 1Gbit/s
Small (S) - supported throughput less than 5Gbit/s Small (S) - supported throughput less than 5Gbit/s
Medium (M) - supported throughput greater than 5Gbit/s and less than Medium (M) - supported throughput greater than 5Gbit/s and less than
10Gbit/s 10Gbit/s
Large (L) - supported throughput greater than 10Gbit/s Large (L) - supported throughput greater than 10Gbit/s
The Access Control Rules (ACL) defined in Table 2 MUST be configured
The Access Control Rules (ACL) defined in Table 3 MUST be configured
from top to bottom in the correct order as shown in the table. The from top to bottom in the correct order as shown in the table. The
ACL entries MUST be configured in Forward Information Base (FIB) ACL entries MUST be configured in Forward Information Base (FIB)
table of the DUT/SUT. (Note: There will be differences between how table of the DUT/SUT. (Note: There will be differences between how
security vendors implement ACL decision making.) The configured ACL security vendors implement ACL decision making.) The configured ACL
MUST NOT block the security and performance test traffic used for the MUST NOT block the security and performance test traffic used for the
benchmarking test scenarios. benchmarking test scenarios.
+---------------------------------------------------+---------------+ +---------------+
| | DUT/SUT | | DUT/SUT |
| | Classification| | Classification|
| | #rules | | # Rules |
+-----------+-----------+------------------+------------+---+---+---+ +-----------+-----------+------------------+------------+---+---+---+
| | Match | | | | | | | | | Match | | | | | | |
| Rules Type| Criteria | Description | Action | XS| S | M | L | | Rules Type| Criteria | Description | Action | XS| S | M | L |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
|Application|Application| Any application | block | 5 | 10| 20| 50| |Application|Application| Any application | block | 5 | 10| 20| 50|
|layer | | traffic NOT | | | | | | |layer | | traffic NOT | | | | | |
| | | included in the | | | | | | | | | included in the | | | | | |
| | | test traffic | | | | | | | | | test traffic | | | | | |
+-----------------------+ ------------------------------------------+ +-----------------------+ ------------------------------------------+
|Transport |Src IP and | Any src IP subnet| block | 25| 50|100|250| |Transport |Src IP and | Any src IP subnet| block | 25| 50|100|250|
skipping to change at page 9, line 46 skipping to change at page 9, line 48
| | | test traffic. One| | | | | | | | | test traffic. One| | | | | |
| | | rule per subnet | | | | | | | | | rule per subnet | | | | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
|IP layer |Src IP | The rest of the | allow | 1| 1| 1| 1| |IP layer |Src IP | The rest of the | allow | 1| 1| 1| 1|
| | | src IP subnet | | | | | | | | | src IP subnet | | | | | |
| | | range used in the| | | | | | | | | range used in the| | | | | |
| | | test. One rule | | | | | | | | | test. One rule | | | | | |
| | | per subnet | | | | | | | | | per subnet | | | | | |
+-----------+-----------+------------------+--------+---+---+---+---+ +-----------+-----------+------------------+--------+---+---+---+---+
Table 2: DUT/SUT Access List Table 3: DUT/SUT Access List
4.3. Test Equipment Configuration 4.3. Test Equipment Configuration
In general, test equipment allows configuring parameters in different In general, test equipment allows configuring parameters in different
protocol layers. These parameters thereby influence the traffic protocol layers. These parameters thereby influence the traffic
flows which will be offered and impact performance measurements. flows which will be offered and impact performance measurements.
This section specifies common test equipment configuration parameters This section specifies common test equipment configuration parameters
applicable for all test scenarios defined in Section 7. Any test applicable for all test scenarios defined in Section 7. Any test
scenario specific parameters are described under the test setup scenario specific parameters are described under the test setup
skipping to change at page 10, line 35 skipping to change at page 10, line 41
client delayed Ack MUST NOT exceed 10 times the MSS before a forced client delayed Ack MUST NOT exceed 10 times the MSS before a forced
ACK. Up to 3 retries SHOULD be allowed before a timeout event is ACK. Up to 3 retries SHOULD be allowed before a timeout event is
declared. All traffic MUST set the TCP PSH flag to high. The source declared. All traffic MUST set the TCP PSH flag to high. The source
port range SHOULD be in the range of 1024 - 65535. Internal timeout port range SHOULD be in the range of 1024 - 65535. Internal timeout
SHOULD be dynamically scalable per RFC 793. Client SHOULD initiate SHOULD be dynamically scalable per RFC 793. Client SHOULD initiate
and close TCP connections. TCP connections MUST be closed via FIN. and close TCP connections. TCP connections MUST be closed via FIN.
4.3.1.2. Client IP Address Space 4.3.1.2. Client IP Address Space
The sum of the client IP space SHOULD contain the following The sum of the client IP space SHOULD contain the following
attributes. The IP blocks SHOULD consist of multiple unique, attributes.
discontinuous static address blocks. A default gateway is permitted.
The IPv4 Type of Service (ToS) byte or IPv6 traffic class should be o The IP blocks SHOULD consist of multiple unique, discontinuous
set to '00' or '000000' respectively. static address blocks.
o A default gateway is permitted.
o The IPv4 Type of Service (ToS) byte or IPv6 traffic class should
be set to '00' or '000000' respectively.
The following equation can be used to determine the required total The following equation can be used to determine the required total
number of client IP addresses. number of client IP addresses.
Desired total number of client IP = Target throughput [Mbit/s] / Desired total number of client IP = Target throughput [Mbit/s] /
Throughput per IP address [Mbit/s] Throughput per IP address [Mbit/s]
Based on deployment and use case scenario, the value for "Throughput Based on deployment and use case scenario, the value for "Throughput
per IP address" can be varied. per IP address" can be varied.
skipping to change at page 11, line 24 skipping to change at page 11, line 33
(Option 2) 80 % IPv4, 20% IPv6 (Option 2) 80 % IPv4, 20% IPv6
(Option 3) 50 % IPv4, 50% IPv6 (Option 3) 50 % IPv4, 50% IPv6
(Option 4) 20 % IPv4, 80% IPv6 (Option 4) 20 % IPv4, 80% IPv6
(Option 5) no IPv4, 100% IPv6 (Option 5) no IPv4, 100% IPv6
4.3.1.3. Emulated Web Browser Attributes 4.3.1.3. Emulated Web Browser Attributes
The emulated web browser contains attributes that will materially The emulated web client contains attributes that will materially
affect how traffic is loaded. The objective is to emulate modern, affect how traffic is loaded. The objective is to emulate modern,
typical browser attributes to improve realism of the result set. typical browser attributes to improve realism of the result set.
For HTTP traffic emulation, the emulated browser MUST negotiate HTTP For HTTP traffic emulation, the emulated browser MUST negotiate HTTP
1.1. HTTP persistency MAY be enabled depending on test scenario. 1.1. HTTP persistence MAY be enabled depending on the test scenario.
The browser MAY open multiple TCP connections per Server endpoint IP The browser MAY open multiple TCP connections per Server endpoint IP
at any time depending on how many sequential transactions are needed at any time depending on how many sequential transactions are needed
to be processed. Within the TCP connection multiple transactions MAY to be processed. Within the TCP connection multiple transactions MAY
be processed if the emulated browser has available connections. The be processed if the emulated browser has available connections. The
browser SHOULD advertise a User-Agent header. Headers MUST be sent browser SHOULD advertise a User-Agent header. Headers MUST be sent
uncompressed. The browser SHOULD enforce content length validation. uncompressed. The browser SHOULD enforce content length validation.
For encrypted traffic, the following attributes SHALL define the For encrypted traffic, the following attributes SHALL define the
negotiated encryption parameters. The test clients MUST use TLSv1.2 negotiated encryption parameters. The test clients MUST use TLSv1.2
or higher. TLS record size MAY be optimized for the HTTPS response or higher. TLS record size MAY be optimized for the HTTPS response
object size up to a record size of 16 KByte. The client endpoint object size up to a record size of 16 KByte. The client endpoint
MUST send TLS Extension Server Name Indication (SNI) information when SHOULD send TLS Extension Server Name Indication (SNI) information
opening a security tunnel. Each client connection MUST perform a when opening a security tunnel. Each client connection MUST perform
full handshake with server certificate and MUST NOT use session reuse a full handshake with server certificate and MUST NOT use session
or resumption. Cipher suite and key size are defined in the reuse or resumption.
parameter section of the specific test scenarios.
The following ciphers and keys are RECOMMENDED to use for HTTPS based
benchmarking tests defined in Section 7.
1. ECHDE-ECDSA-AES128-GCM-SHA256 with Prime256v1 (Signature Hash
Algorithm: ecdsa_secp256r1_sha256 and Supported group: sepc256r1)
2. ECDHE-RSA-AES128-GCM-SHA256 with RSA 2048 (Signature Hash
Algorithm: rsa_pkcs1_sha256 and Supported group: sepc256)
3. ECDHE-ECDSA-AES256-GCM-SHA384 with Secp521 (Signature Hash
Algorithm: ecdsa_secp384r1_sha384 and Supported group: sepc521r1)
4. ECDHE-RSA-AES256-GCM-SHA384 with RSA 4096 (Signature Hash
Algorithm: rsa_pkcs1_sha384 and Supported group: secp256)
Note: The above ciphers and keys were those commonly used enterprise
grade encryption cipher suites . It is recognised that these will
evolve over time. Individual certification bodies SHOULD use ciphers
and keys that reflect evolving use cases. These choices MUST be
documented in the resulting test reports with detailed information on
the ciphers and keys used along with reasons for the choices.
4.3.2. Backend Server Configuration 4.3.2. Backend Server Configuration
This section specifies which parameters should be considered while This section specifies which parameters should be considered while
configuring emulated backend servers using test equipment. configuring emulated backend servers using test equipment.
4.3.2.1. TCP Stack Attributes 4.3.2.1. TCP Stack Attributes
The TCP stack on the server side SHOULD be configured similar to the The TCP stack on the server side SHOULD be configured similar to the
client side configuration described in Section 4.3.1.1. In addition, client side configuration described in Section 4.3.1.1. In addition,
server initial congestion window MUST NOT exceed 10 times the MSS. server initial congestion window MUST NOT exceed 10 times the MSS.
Delayed ACKs are permitted and the maximum server delayed ACK MUST Delayed ACKs are permitted and the maximum server delayed ACK MUST
NOT exceed 10 times the MSS before a forced ACK. NOT exceed 10 times the MSS before a forced ACK.
4.3.2.2. Server Endpoint IP Addressing 4.3.2.2. Server Endpoint IP Addressing
The server IP blocks SHOULD consist of unique, discontinuous static The sum of the server IP space SHOULD contain the following
address blocks with one IP per Server Fully Qualified Domain Name attributes.
(FQDN) endpoint per test port. The IPv4 ToS byte and IPv6 traffic
class bytes should be set to '00' and '000000' respectively. o The server IP blocks SHOULD consist of unique, discontinuous
static address blocks with one IP per Server Fully Qualified
Domain Name (FQDN) endpoint per test port.
o A default gateway is permitted. The IPv4 ToS byte and IPv6
traffic class bytes should be set to '00' and '000000'
respectively.
o The server IP addresses SHOULD be distributed between IPv4 and
IPv6 with a ratio identical to the clients distribution ratio.
4.3.2.3. HTTP / HTTPS Server Pool Endpoint Attributes 4.3.2.3. HTTP / HTTPS Server Pool Endpoint Attributes
The server pool for HTTP SHOULD listen on TCP port 80 and emulate The server pool for HTTP SHOULD listen on TCP port 80 and emulate
HTTP version 1.1 with persistence. The Server MUST advertise server HTTP version 1.1 with persistence. The Server MUST advertise server
type in the Server response header [RFC2616]. For HTTPS server, TLS type in the Server response header [RFC2616]. For HTTPS server, TLS
1.2 or higher MUST be used with a maximum record size of 16 KByte and 1.2 or higher MUST be used with a maximum record size of 16 KByte and
MUST NOT use ticket resumption or Session ID reuse . The server MUST MUST NOT use ticket resumption or Session ID reuse . The server MUST
listen on port TCP 443. The server SHALL serve a certificate to the listen on port TCP 443. The server SHALL serve a certificate to the
client. It is REQUIRED that the HTTPS server also check Host SNI client. The HTTPS server MUST check Host SNI information with the
information with the FQDN. Cipher suite and key size are defined in FQDN if the SNI is in use. Cipher suite and key size on the server
the parameter section of the specific test scenarios. side MUST be configured smilar to the client side configuration
described in Section 4.3.1.3.
4.3.3. Traffic Flow Definition 4.3.3. Traffic Flow Definition
This section describes the traffic pattern between client and server This section describes the traffic pattern between client and server
endpoints. At the beginning of the test, the server endpoint endpoints. At the beginning of the test, the server endpoint
initializes and will be ready to accept connection states including initializes and will be ready to accept connection states including
initialization of the TCP stack as well as bound HTTP and HTTPS initialization of the TCP stack as well as bound HTTP and HTTPS
servers. When a client endpoint is needed, it will initialize and be servers. When a client endpoint is needed, it will initialize and be
given attributes such as a MAC and IP address. The behavior of the given attributes such as a MAC and IP address. The behavior of the
client is to sweep though the given server IP space, sequentially client is to sweep through the given server IP space, sequentially
generating a recognizable service by the DUT. Thus, a balanced, mesh generating a recognizable service by the DUT. Thus, a balanced, mesh
between client endpoints and server endpoints will be generated in a between client endpoints and server endpoints will be generated in a
client port server port combination. Each client endpoint performs client port server port combination. Each client endpoint performs
the same actions as other endpoints, with the difference being the the same actions as other endpoints, with the difference being the
source IP of the client endpoint and the target server IP pool. The source IP of the client endpoint and the target server IP pool. The
client SHALL use Fully Qualified Domain Names (FQDN) in Host Headers client MUST use the servers IP address or Fully Qualified Domain
and for TLS Server Name Indication (SNI). Names (FQDN) in Host Headers.For TLS the client MAY use Server Name
Indication (SNI).
4.3.3.1. Description of Intra-Client Behavior 4.3.3.1. Description of Intra-Client Behavior
Client endpoints are independent of other clients that are Client endpoints are independent of other clients that are
concurrently executing. When a client endpoint initiates traffic, concurrently executing. When a client endpoint initiates traffic,
this section describes how the client steps though different this section describes how the client steps though different
services. Once the test is initialized, the client endpoints SHOULD services. Once the test is initialized, the client endpoints SHOULD
randomly hold (perform no operation) for a few milliseconds to allow randomly hold (perform no operation) for a few milliseconds to allow
for better randomization of start of client traffic. Each client for better randomization of the start of client traffic. Each client
will either open a new TCP connection or connect to a TCP persistence will either open a new TCP connection or connect to a TCP persistence
stack still open to that specific server. At any point that the stack still open to that specific server. At any point that the
service profile may require encryption, a TLS encryption tunnel will service profile may require encryption, a TLS encryption tunnel will
form presenting the URL request to the server. The server will then form presenting the URL or IP address request to the server. If
perform an SNI name check with the proposed FQDN compared to the using SNI, the server will then perform an SNI name check with the
domain embedded in the certificate. Only when correct, will the proposed FQDN compared to the domain embedded in the certificate.
server process the HTTPS response object. The initial response Only when correct, will the server process the HTTPS response object.
object to the server MUST NOT have a fixed size; its size is based on The initial response object to the server MUST NOT have a fixed size;
benchmarking tests described in Section 7. Multiple additional sub- its size is based on benchmarking tests described in Section 7.
URLs (response objects on the service page) MAY be requested Multiple additional sub-URLs (response objects on the service page)
simultaneously. This MAY be to the same server IP as the initial MAY be requested simultaneously. This MAY be to the same server IP
URL. Each sub-object will also use a conical FQDN and URL path, as as the initial URL. Each sub-object will also use a conical FQDN and
observed in the traffic mix used. URL path, as observed in the traffic mix used.
4.3.4. Traffic Load Profile 4.3.4. Traffic Load Profile
The loading of traffic is described in this section. The loading of The loading of traffic is described in this section. The loading of
a traffic load profile has five distinct phases: Init, ramp up, a traffic load profile has five distinct phases: Init, ramp up,
sustain, ramp down, and collection. sustain, ramp down, and collection.
1. During the Init phase, test bed devices including the client and 1. During the Init phase, test bed devices including the client and
server endpoints should negotiate layer 2-3 connectivity such as server endpoints should negotiate layer 2-3 connectivity such as
MAC learning and ARP. Only after successful MAC learning or ARP/ MAC learning and ARP. Only after successful MAC learning or ARP/
skipping to change at page 15, line 27 skipping to change at page 16, line 17
3. Summary of testbed software and Hardware details 3. Summary of testbed software and Hardware details
A. DUT Hardware/Virtual Configuration A. DUT Hardware/Virtual Configuration
+ This section SHOULD clearly identify the make and model of + This section SHOULD clearly identify the make and model of
the DUT the DUT
+ The port interfaces, including speed and link information + The port interfaces, including speed and link information
MUST be documented. MUST be documented.
+ If the DUT is a virtual VNF, interface acceleration such + If the DUT is a virtual Netwerk Function (VNF), interface
as DPDK and SR-IOV MUST be documented as well as cores acceleration such as DPDK and SR-IOV MUST be documented as
used, RAM used, and the pinning / resource sharing well as cores used, RAM used, and the pinning / resource
configuration. The Hypervisor and version MUST be sharing configuration. The Hypervisor and version MUST be
documented. documented.
+ Any additional hardware relevant to the DUT such as + Any additional hardware relevant to the DUT such as
controllers MUST be documented controllers MUST be documented
B. DUT Software B. DUT Software
+ The operating system name MUST be documented + The operating system name MUST be documented
+ The version MUST be documented + The version MUST be documented
skipping to change at page 18, line 39 skipping to change at page 19, line 30
Traffic distribution ratio between IPv4 and IPv6 defined in Traffic distribution ratio between IPv4 and IPv6 defined in
Section 4.3.1.2 Section 4.3.1.2
Target throughput: It can be defined based on requirements. Target throughput: It can be defined based on requirements.
Otherwise it represents aggregated line rate of interface(s) used Otherwise it represents aggregated line rate of interface(s) used
in the DUT/SUT in the DUT/SUT
Initial throughput: 10% of the "Target throughput" Initial throughput: 10% of the "Target throughput"
One of the following ciphers and keys are RECOMMENDED to use for One of the ciphers and keys defined in Section 4.3.1.3 are
this test scenarios. RECOMMENDED to use for this test scenarios.
1. ECHDE-ECDSA-AES128-GCM-SHA256 with Prime256v1 (Signature Hash
Algorithm: ecdsa_secp256r1_sha256 and Supported group:
sepc256r1)
2. ECDHE-RSA-AES128-GCM-SHA256 with RSA 2048 (Signature Hash
Algorithm: rsa_pkcs1_sha256 and Supported group: sepc256)
3. ECDHE-ECDSA-AES256-GCM-SHA384 with Secp521 (Signature Hash
Algorithm: ecdsa_secp384r1_sha384 and Supported group:
sepc521r1)
4. ECDHE-RSA-AES256-GCM-SHA384 with RSA 4096 (Signature Hash
Algorithm: rsa_pkcs1_sha384 and Supported group: secp256)
7.1.3.3. Traffic Profile 7.1.3.3. Traffic Profile
Traffic profile: Test scenario MUST be run with a single application Traffic profile: Test scenario MUST be run with a single application
traffic mix profile (see Appendix A for details about traffic mix). traffic mix profile (see Appendix A for details about traffic mix).
The name of the NetSecOPEN traffic mix MUST be documented. The name of the NetSecOPEN traffic mix MUST be documented.
7.1.3.4. Test Results Validation Criteria 7.1.3.4. Test Results Validation Criteria
The following test Criteria is defined as test results validation The following test Criteria is defined as test results validation
skipping to change at page 20, line 4 skipping to change at page 20, line 29
d. Maximum value of Time to First Byte (TTFB) MUST be less than X d. Maximum value of Time to First Byte (TTFB) MUST be less than X
7.1.3.5. Measurement 7.1.3.5. Measurement
Following KPI metrics MUST be reported for this test scenario. Following KPI metrics MUST be reported for this test scenario.
Mandatory KPIs: average Throughput, TTFB (minimum, average and Mandatory KPIs: average Throughput, TTFB (minimum, average and
maximum), TTLB (minimum, average and maximum) and average Application maximum), TTLB (minimum, average and maximum) and average Application
Transactions Per Second Transactions Per Second
Note: TTLB MUST be reported along with min, max and avg object size Note: TTLB MUST be reported along with min, max and avg object size
used in the traffic profile. used in the traffic profile.
Optional KPIs: average TCP Connections Per Second and average TLS Optional KPIs: average TCP Connections Per Second and average TLS
Handshake Rate Handshake Rate
7.1.4. Test Procedures and expected Results 7.1.4. Test Procedures and Expected Results
The test procedures are designed to measure the throughput The test procedures are designed to measure the throughput
performance of the DUT/SUT at the sustaining period of traffic load performance of the DUT/SUT at the sustaining period of traffic load
profile. The test procedure consists of three major steps. profile. The test procedure consists of three major steps.
7.1.4.1. Step 1: Test Initialization and Qualification 7.1.4.1. Step 1: Test Initialization and Qualification
Verify the link status of the all connected physical interfaces. All Verify the link status of the all connected physical interfaces. All
interfaces are expected to be in "UP" status. interfaces are expected to be in "UP" status.
skipping to change at page 21, line 51 skipping to change at page 22, line 28
requirements defined in Section 4.3. Following parameters MUST be requirements defined in Section 4.3. Following parameters MUST be
documented for this test scenario: documented for this test scenario:
Client IP address range defined in Section 4.3.1.2 Client IP address range defined in Section 4.3.1.2
Server IP address range defined in Section 4.3.2.2 Server IP address range defined in Section 4.3.2.2
Traffic distribution ratio between IPv4 and IPv6 defined in Traffic distribution ratio between IPv4 and IPv6 defined in
Section 4.3.1.2 Section 4.3.1.2
Target connections per second: Initial value from product data sheet Target connections per second: Initial value from product datasheet
(if known) (if known)
Initial connections per second: 10% of "Target connections per Initial connections per second: 10% of "Target connections per
second" (an optional parameter for documentation) second" (an optional parameter for documentation)
The client SHOULD negotiate HTTP 1.1 and close the connection with The client SHOULD negotiate HTTP 1.1 and close the connection with
FIN immediately after completion of one transaction. In each test FIN immediately after completion of one transaction. In each test
iteration, client MUST send GET command requesting a fixed HTTP iteration, client MUST send GET command requesting a fixed HTTP
response object size. response object size.
The RECOMMENDED response object sizes are 1, 2, 4, 16, 64 KByte The RECOMMENDED response object sizes are 1, 2, 4, 16, 64 KByte
skipping to change at page 24, line 46 skipping to change at page 25, line 28
requirements defined in Section 4.3. Following parameters MUST be requirements defined in Section 4.3. Following parameters MUST be
documented for this test scenario: documented for this test scenario:
Client IP address range defined in Section 4.3.1.2 Client IP address range defined in Section 4.3.1.2
Server IP address range defined in Section 4.3.2.2 Server IP address range defined in Section 4.3.2.2
Traffic distribution ratio between IPv4 and IPv6 defined in Traffic distribution ratio between IPv4 and IPv6 defined in
Section 4.3.1.2 Section 4.3.1.2
Target Throughput: Initial value from product data sheet (if known) Target Throughput: Initial value from product datasheet (if known)
Initial Throughput: 10% of "Target Throughput" (an optional parameter Initial Throughput: 10% of "Target Throughput" (an optional parameter
for documentation) for documentation)
Number of HTTP response object requests (transactions) per Number of HTTP response object requests (transactions) per
connection: 10 connection: 10
RECOMMENDED HTTP response object size: 1 KByte, 16 KByte, 64 KByte, RECOMMENDED HTTP response object size: 1 KByte, 16 KByte, 64 KByte,
256 KByte and mixed objects defined in the table 256 KByte and mixed objects defined in the table
+---------------------+---------------------+ +---------------------+---------------------+
| Object size (KByte) | Number of requests/ | | Object size (KByte) | Number of requests/ |
| | Weight | | | Weight |
+---------------------+---------------------+ +---------------------+---------------------+
| 0.2 | 1 | | 0.2 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
| 6 | 1 | | 6 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
| 8 | 1 | | 8 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
skipping to change at page 25, line 32 skipping to change at page 26, line 29
+---------------------+---------------------+ +---------------------+---------------------+
| 26 | 1 | | 26 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
| 35 | 1 | | 35 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
| 59 | 1 | | 59 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
| 347 | 1 | | 347 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
Table 3: Mixed Objects Table 4: Mixed Objects
7.3.3.3. Test Results Validation Criteria 7.3.3.3. Test Results Validation Criteria
The following test Criteria is defined as test results validation The following test Criteria is defined as test results validation
criteria. Test results validation criteria MUST be monitored during criteria. Test results validation criteria MUST be monitored during
the whole sustain phase of the traffic load profile the whole sustain phase of the traffic load profile
a. Number of failed Application transactions (receiving any HTTP a. Number of failed Application transactions (receiving any HTTP
response code other than 200 OK) MUST be less than 0.001% (1 out response code other than 200 OK) MUST be less than 0.001% (1 out
of 100,000 transactions) of attempt transactions. of 100,000 transactions) of attempt transactions.
skipping to change at page 31, line 34 skipping to change at page 32, line 34
requirements defined in Section 4.3. Following parameters MUST be requirements defined in Section 4.3. Following parameters MUST be
noted for this test scenario: noted for this test scenario:
Client IP address range defined in Section 4.3.1.2 Client IP address range defined in Section 4.3.1.2
Server IP address range defined in Section 4.3.2.2 Server IP address range defined in Section 4.3.2.2
Traffic distribution ratio between IPv4 and IPv6 defined in Traffic distribution ratio between IPv4 and IPv6 defined in
Section 4.3.1.2 Section 4.3.1.2
Target concurrent connection: Initial value from product data Target concurrent connection: Initial value from product datasheet
sheet (if known) (if known)
Initial concurrent connection: 10% of "Target concurrent Initial concurrent connection: 10% of "Target concurrent
connection" (an optional parameter for documentation) connection" (an optional parameter for documentation)
Maximum connections per second during ramp up phase: 50% of Maximum connections per second during ramp up phase: 50% of
maximum connections per second measured in test scenario TCP/HTTP maximum connections per second measured in test scenario TCP/HTTP
Connections per second (Section 7.2) Connections per second (Section 7.2)
Ramp up time (in traffic load profile for "Target concurrent Ramp up time (in traffic load profile for "Target concurrent
connection"): "Target concurrent connection" / "Maximum connection"): "Target concurrent connection" / "Maximum
skipping to change at page 32, line 40 skipping to change at page 33, line 40
connections) of total initiated TCP connections connections) of total initiated TCP connections
c. During the sustain phase, traffic SHOULD be forwarded constantly c. During the sustain phase, traffic SHOULD be forwarded constantly
7.5.3.4. Measurement 7.5.3.4. Measurement
Following KPI metric MUST be reported for this test scenario: Following KPI metric MUST be reported for this test scenario:
average Concurrent TCP Connections average Concurrent TCP Connections
7.5.4. Test Procedures and expected Results 7.5.4. Test Procedures and Expected Results
The test procedure is designed to measure the concurrent TCP The test procedure is designed to measure the concurrent TCP
connection capacity of the DUT/SUT at the sustaining period of connection capacity of the DUT/SUT at the sustaining period of
traffic load profile. The test procedure consists of three major traffic load profile. The test procedure consists of three major
steps. This test procedure MAY be repeated multiple times with steps. This test procedure MAY be repeated multiple times with
different IPv4 and IPv6 traffic distribution. different IPv4 and IPv6 traffic distribution.
7.5.4.1. Step 1: Test Initialization and Qualification 7.5.4.1. Step 1: Test Initialization and Qualification
Verify the link status of the all connected physical interfaces. All Verify the link status of the all connected physical interfaces. All
skipping to change at page 33, line 45 skipping to change at page 34, line 45
meet all validation criteria. meet all validation criteria.
Follow step 3, if the KPI metrics do not meet the validation Follow step 3, if the KPI metrics do not meet the validation
criteria. criteria.
7.5.4.3. Step 3: Test Iteration 7.5.4.3. Step 3: Test Iteration
Determine the maximum and average achievable concurrent TCP Determine the maximum and average achievable concurrent TCP
connections capacity within the validation criteria. connections capacity within the validation criteria.
7.6. TCP/HTTPS Connections per second 7.6. TCP/HTTPS Connections per Second
7.6.1. Objective 7.6.1. Objective
Using HTTPS traffic, determine the maximum sustainable SSL/TLS Using HTTPS traffic, determine the maximum sustainable SSL/TLS
session establishment rate supported by the DUT/SUT under different session establishment rate supported by the DUT/SUT under different
throughput load conditions. throughput load conditions.
Test iterations MUST include common cipher suites and key strengths Test iterations MUST include common cipher suites and key strengths
as well as forward looking stronger keys. Specific test iterations as well as forward looking stronger keys. Specific test iterations
MUST include ciphers and keys defined in Section 7.6.3.2. MUST include ciphers and keys defined in Section 7.6.3.2.
skipping to change at page 34, line 44 skipping to change at page 35, line 44
requirements defined in Section 4.3. Following parameters MUST be requirements defined in Section 4.3. Following parameters MUST be
documented for this test scenario: documented for this test scenario:
Client IP address range defined in Section 4.3.1.2 Client IP address range defined in Section 4.3.1.2
Server IP address range defined in Section 4.3.2.2 Server IP address range defined in Section 4.3.2.2
Traffic distribution ratio between IPv4 and IPv6 defined in Traffic distribution ratio between IPv4 and IPv6 defined in
Section 4.3.1.2 Section 4.3.1.2
Target connections per second: Initial value from product data sheet Target connections per second: Initial value from product datasheet
(if known) (if known)
Initial connections per second: 10% of "Target connections per Initial connections per second: 10% of "Target connections per
second" (an optional parameter for documentation) second" (an optional parameter for documentation)
RECOMMENDED ciphers and keys: RECOMMENDED ciphers and keys defined in Section 4.3.1.3
1. ECHDE-ECDSA-AES128-GCM-SHA256 with Prime256v1 (Signature Hash
Algorithm: ecdsa_secp256r1_sha256 and Supported group: sepc256r1)
2. ECDHE-RSA-AES128-GCM-SHA256 with RSA 2048 (Signature Hash
Algorithm: rsa_pkcs1_sha256 and Supported group: sepc256)
3. ECDHE-ECDSA-AES256-GCM-SHA384 with Secp521 (Signature Hash
Algorithm: ecdsa_secp384r1_sha384 and Supported group: sepc521r1)
4. ECDHE-RSA-AES256-GCM-SHA384 with RSA 4096 (Signature Hash
Algorithm: rsa_pkcs1_sha384 and Supported group: secp256)
The client MUST negotiate HTTPS 1.1 and close the connection with FIN The client MUST negotiate HTTPS 1.1 and close the connection with FIN
immediately after completion of one transaction. In each test immediately after completion of one transaction. In each test
iteration, client MUST send GET command requesting a fixed HTTPS iteration, client MUST send GET command requesting a fixed HTTPS
response object size. The RECOMMENDED object sizes are 1, 2, 4, 16, response object size. The RECOMMENDED object sizes are 1, 2, 4, 16,
64 KByte. 64 KByte.
7.6.3.3. Test Results Validation Criteria 7.6.3.3. Test Results Validation Criteria
The following test Criteria is defined as test results validation The following test Criteria is defined as test results validation
criteria: criteria:
skipping to change at page 36, line 5 skipping to change at page 36, line 39
almost at the same rate almost at the same rate
7.6.3.4. Measurement 7.6.3.4. Measurement
Following KPI metrics MUST be reported for this test scenario: Following KPI metrics MUST be reported for this test scenario:
average TCP Connections Per Second, average TLS Handshake Rate (TLS average TCP Connections Per Second, average TLS Handshake Rate (TLS
Handshake Rate can be measured in the test scenario using 1KB object Handshake Rate can be measured in the test scenario using 1KB object
size) size)
7.6.4. Test Procedures and expected Results 7.6.4. Test Procedures and Expected Results
The test procedure is designed to measure the TCP connections per The test procedure is designed to measure the TCP connections per
second rate of the DUT/SUT at the sustaining period of traffic load second rate of the DUT/SUT at the sustaining period of traffic load
profile. The test procedure consists of three major steps. This profile. The test procedure consists of three major steps. This
test procedure MAY be repeated multiple times with different IPv4 and test procedure MAY be repeated multiple times with different IPv4 and
IPv6 traffic distribution. IPv6 traffic distribution.
7.6.4.1. Step 1: Test Initialization and Qualification 7.6.4.1. Step 1: Test Initialization and Qualification
Verify the link status of all connected physical interfaces. All Verify the link status of all connected physical interfaces. All
skipping to change at page 38, line 4 skipping to change at page 38, line 45
Test equipment configuration parameters MUST conform to the Test equipment configuration parameters MUST conform to the
requirements defined in Section 4.3. Following parameters MUST be requirements defined in Section 4.3. Following parameters MUST be
documented for this test scenario: documented for this test scenario:
Client IP address range defined in Section 4.3.1.2 Client IP address range defined in Section 4.3.1.2
Server IP address range defined in Section 4.3.2.2 Server IP address range defined in Section 4.3.2.2
Traffic distribution ratio between IPv4 and IPv6 defined in Traffic distribution ratio between IPv4 and IPv6 defined in
Section 4.3.1.2 Section 4.3.1.2
Target Throughput: Initial value from product data sheet (if known)
Target Throughput: Initial value from product datasheet (if known)
Initial Throughput: 10% of "Target Throughput" (an optional parameter Initial Throughput: 10% of "Target Throughput" (an optional parameter
for documentation) for documentation)
Number of HTTPS response object requests (transactions) per Number of HTTPS response object requests (transactions) per
connection: 10 connection: 10
RECOMMENDED ciphers and keys defined in Section 4.3.1.3
RECOMMENDED ciphers and keys:
1. ECHDE-ECDSA-AES128-GCM-SHA256 with Prime256v1 (Signature Hash
Algorithm: ecdsa_secp256r1_sha256 and Supported group: sepc256r1)
2. ECDHE-RSA-AES128-GCM-SHA256 with RSA 2048 (Signature Hash
Algorithm: rsa_pkcs1_sha256 and Supported group: sepc256)
3. ECDHE-ECDSA-AES256-GCM-SHA384 with Secp521 (Signature Hash
Algorithm: ecdsa_secp384r1_sha384 and Supported group: sepc521r1)
4. ECDHE-RSA-AES256-GCM-SHA384 with RSA 4096 (Signature Hash
Algorithm: rsa_pkcs1_sha384 and Supported group: secp256)
RECOMMENDED HTTPS response object size: 1 KByte, 2 KByte, 4 KByte, 16 RECOMMENDED HTTPS response object size: 1 KByte, 2 KByte, 4 KByte, 16
KByte, 64 KByte, 256 KByte and mixed object defined in the table KByte, 64 KByte, 256 KByte and mixed object defined in the table
below. below.
+---------------------+---------------------+ +---------------------+---------------------+
| Object size (KByte) | Number of requests/ | | Object size (KByte) | Number of requests/ |
| | Weight | | | Weight |
+---------------------+---------------------+ +---------------------+---------------------+
| 0.2 | 1 | | 0.2 | 1 |
skipping to change at page 39, line 30 skipping to change at page 39, line 35
+---------------------+---------------------+ +---------------------+---------------------+
| 26 | 1 | | 26 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
| 35 | 1 | | 35 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
| 59 | 1 | | 59 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
| 347 | 1 | | 347 | 1 |
+---------------------+---------------------+ +---------------------+---------------------+
Table 4: Mixed Objects Table 5: Mixed Objects
7.7.3.3. Test Results Validation Criteria 7.7.3.3. Test Results Validation Criteria
The following test Criteria is defined as test results validation The following test Criteria is defined as test results validation
criteria. Test results validation criteria MUST be monitored during criteria. Test results validation criteria MUST be monitored during
the whole sustain phase of the traffic load profile. the whole sustain phase of the traffic load profile.
a. Number of failed Application transactions (receiving any HTTP a. Number of failed Application transactions (receiving any HTTP
response code other than 200 OK) MUST be less than 0.001% (1 out response code other than 200 OK) MUST be less than 0.001% (1 out
of 100,000 transactions) of attempt transactions. of 100,000 transactions) of attempt transactions.
skipping to change at page 42, line 7 skipping to change at page 42, line 7
Test equipment configuration parameters MUST conform to the Test equipment configuration parameters MUST conform to the
requirements defined in Section 4.3. Following parameters MUST be requirements defined in Section 4.3. Following parameters MUST be
documented for this test scenario: documented for this test scenario:
Client IP address range defined in Section 4.3.1.2 Client IP address range defined in Section 4.3.1.2
Server IP address range defined in Section 4.3.2.2 Server IP address range defined in Section 4.3.2.2
Traffic distribution ratio between IPv4 and IPv6 defined in Traffic distribution ratio between IPv4 and IPv6 defined in
Section 4.3.1.2 Section 4.3.1.2
RECOMMENDED cipher suites and key size: ECDHE-ECDSA-AES256-GCM-SHA384 RECOMMENDED cipher suites and key sizes defined in Section 4.3.1.3
with Secp521 bits key size (Signature Hash Algorithm:
ecdsa_secp384r1_sha384 and Supported group: sepc521r1)
Target objective for scenario 1: 50% of the maximum connections per Target objective for scenario 1: 50% of the maximum connections per
second measured in test scenario TCP/HTTPS Connections per second second measured in test scenario TCP/HTTPS Connections per second
(Section 7.6) (Section 7.6)
Target objective for scenario 2: 50% of the maximum throughput Target objective for scenario 2: 50% of the maximum throughput
measured in test scenario HTTPS Throughput (Section 7.7) measured in test scenario HTTPS Throughput (Section 7.7)
Initial objective for scenario 1: 10% of Target objective for Initial objective for scenario 1: 10% of Target objective for
scenario 1" (an optional parameter for documentation) scenario 1" (an optional parameter for documentation)
skipping to change at page 45, line 28 skipping to change at page 45, line 28
requirements defined in Section 4.3. Following parameters MUST be requirements defined in Section 4.3. Following parameters MUST be
documented for this test scenario: documented for this test scenario:
Client IP address range defined in Section 4.3.1.2 Client IP address range defined in Section 4.3.1.2
Server IP address range defined in Section 4.3.2.2 Server IP address range defined in Section 4.3.2.2
Traffic distribution ratio between IPv4 and IPv6 defined in Traffic distribution ratio between IPv4 and IPv6 defined in
Section 4.3.1.2 Section 4.3.1.2
RECOMMENDED cipher suites and key size: ECDHE-ECDSA-AES256-GCM- RECOMMENDED cipher suites and key sizes defined in Section 4.3.1.3
SHA384 with Secp521 bits key size (Signature Hash Algorithm:
ecdsa_secp384r1_sha384 and Supported group: sepc521r1)
Target concurrent connections: Initial value from product data Target concurrent connections: Initial value from product
sheet (if known) datasheet (if known)
Initial concurrent connections: 10% of "Target concurrent Initial concurrent connections: 10% of "Target concurrent
connections" (an optional parameter for documentation) connections" (an optional parameter for documentation)
Connections per second during ramp up phase: 50% of maximum Connections per second during ramp up phase: 50% of maximum
connections per second measured in test scenario TCP/HTTPS connections per second measured in test scenario TCP/HTTPS
Connections per second (Section 7.6) Connections per second (Section 7.6)
Ramp up time (in traffic load profile for "Target concurrent Ramp up time (in traffic load profile for "Target concurrent
connections"): "Target concurrent connections" / "Maximum connections"): "Target concurrent connections" / "Maximum
skipping to change at page 46, line 38 skipping to change at page 46, line 38
connections) of total initiated TCP connections connections) of total initiated TCP connections
c. During the sustain phase, traffic SHOULD be forwarded constantly c. During the sustain phase, traffic SHOULD be forwarded constantly
7.9.3.4. Measurement 7.9.3.4. Measurement
Following KPI metric MUST be reported for this test scenario: Following KPI metric MUST be reported for this test scenario:
average Concurrent TCP Connections average Concurrent TCP Connections
7.9.4. Test Procedures and expected Results 7.9.4. Test Procedures and Expected Results
The test procedure is designed to measure the concurrent TCP The test procedure is designed to measure the concurrent TCP
connection capacity of the DUT/SUT at the sustaining period of connection capacity of the DUT/SUT at the sustaining period of
traffic load profile. The test procedure consists of three major traffic load profile. The test procedure consists of three major
steps. This test procedure MAY be repeated multiple times with steps. This test procedure MAY be repeated multiple times with
different IPv4 and IPv6 traffic distribution. different IPv4 and IPv6 traffic distribution.
7.9.4.1. Step 1: Test Initialization and Qualification 7.9.4.1. Step 1: Test Initialization and Qualification
Verify the link status of all connected physical interfaces. All Verify the link status of all connected physical interfaces. All
skipping to change at page 47, line 45 skipping to change at page 47, line 45
MUST meet all validation criteria. MUST meet all validation criteria.
Follow step 3, if the KPI metrics do not meet the validation Follow step 3, if the KPI metrics do not meet the validation
criteria. criteria.
7.9.4.3. Step 3: Test Iteration 7.9.4.3. Step 3: Test Iteration
Determine the maximum and average achievable concurrent TCP Determine the maximum and average achievable concurrent TCP
connections within the validation criteria. connections within the validation criteria.
8. Formal Syntax 8. IANA Considerations
9. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
10. Security Considerations 9. Security Considerations
The primary goal of this document is to provide benchmarking The primary goal of this document is to provide benchmarking
terminology and methodology for next-generation network security terminology and methodology for next-generation network security
devices. However, readers should be aware that there is some overlap devices. However, readers should be aware that there is some overlap
between performance and security issues. Specifically, the optimal between performance and security issues. Specifically, the optimal
configuration for network security device performance may not be the configuration for network security device performance may not be the
most secure, and vice-versa. The Cipher suites recommended in this most secure, and vice-versa. The Cipher suites recommended in this
document are just for test purpose only. The Cipher suite document are just for test purpose only. The Cipher suite
recommendation for a real deployment is outside the scope of this recommendation for a real deployment is outside the scope of this
document. document.
11. Acknowledgements 10. Acknowledgements
Acknowledgements will be added in the future release. Acknowledgements will be added in the future release.
12. Contributors 11. Contributors
The authors would like to thank the many people that contributed The authors would like to thank the many people that contributed
their time and knowledge to this effort. their time and knowledge to this effort.
Specifically, to the co-chairs of the NetSecOPEN Test Methodology Specifically, to the co-chairs of the NetSecOPEN Test Methodology
working group and the NetSecOPEN Security Effectiveness working group working group and the NetSecOPEN Security Effectiveness working group
- Alex Samonte, Aria Eslambolchizadeh, Carsten Rossenhoevel and David - Alex Samonte, Aria Eslambolchizadeh, Carsten Rossenhoevel and David
DeSanto. DeSanto.
Additionally, the following people provided input, comments and spent Additionally, the following people provided input, comments and spent
time reviewing the myriad of drafts. If we have missed anyone the time reviewing the myriad of drafts. If we have missed anyone the
fault is entirely our own. Thanks to - Amritam Putatunda, Chao Guo, fault is entirely our own. Thanks to - Amritam Putatunda, Chao Guo,
Chris Chapman, Chris Pearson, Chuck McAuley, David White, Jurrie Van Chris Chapman, Chris Pearson, Chuck McAuley, David White, Jurrie Van
Den Breekel, Michelle Rhines, Rob Andrews, Samaresh Nair, and Tim Den Breekel, Michelle Rhines, Rob Andrews, Samaresh Nair, and Tim
Winters. Winters.
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 12.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall [RFC2647] Newman, D., "Benchmarking Terminology for Firewall
Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999, Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999,
<https://www.rfc-editor.org/info/rfc2647>. <https://www.rfc-editor.org/info/rfc2647>.
skipping to change at page 50, line 28 skipping to change at page 50, line 28
o Hundreds of FQDNs each client connects to o Hundreds of FQDNs each client connects to
o Hundreds of unique certificates for HTTPS/TLS o Hundreds of unique certificates for HTTPS/TLS
o Thousands of different object sizes per client in orders matching o Thousands of different object sizes per client in orders matching
applications applications
The following is a description of what a popular application in an The following is a description of what a popular application in an
enterprise traffic mix contains. enterprise traffic mix contains.
Table 5 lists the FQDNs, number of transactions and bytes transferred Table 6 lists the FQDNs, number of transactions and bytes transferred
as an example, client interactions with Office 365 Outlook, Word, as an example, client interactions with Office 365 Outlook, Word,
Excel, PowerPoint, SharePoint and Skype. Excel, PowerPoint, SharePoint and Skype.
+---------------------------------+------------+-------------+ +---------------------------------+------------+-------------+
| Office365 FQDN | Bytes | Transaction | | Office365 FQDN | Bytes | Transaction |
+============================================================+ +============================================================+
| r1.res.office365.com | 14,056,960 | 192 | | r1.res.office365.com | 14,056,960 | 192 |
+---------------------------------+------------+-------------+ +---------------------------------+------------+-------------+
| s1-word-edit-15.cdn.office.net | 6,731,019 | 22 | | s1-word-edit-15.cdn.office.net | 6,731,019 | 22 |
+---------------------------------+------------+-------------+ +---------------------------------+------------+-------------+
skipping to change at page 51, line 38 skipping to change at page 51, line 38
+---------------------------------+------------+-------------+ +---------------------------------+------------+-------------+
| graph.microsoft.com | 2,289 | 2 | | graph.microsoft.com | 2,289 | 2 |
+---------------------------------+------------+-------------+ +---------------------------------+------------+-------------+
| nam.loki.delve.office.com | 1,812 | 5 | | nam.loki.delve.office.com | 1,812 | 5 |
+---------------------------------+------------+-------------+ +---------------------------------+------------+-------------+
| login.microsoftonline.com | 464 | 2 | | login.microsoftonline.com | 464 | 2 |
+---------------------------------+------------+-------------+ +---------------------------------+------------+-------------+
| login.windows.net | 232 | 1 | | login.windows.net | 232 | 1 |
+---------------------------------+------------+-------------+ +---------------------------------+------------+-------------+
Table 5: Office365 Table 6: Office365
Clients MUST connect to multiple server FQDNs in the same order as Clients MUST connect to multiple server FQDNs in the same order as
real applications. Connections MUST be made when the client is real applications. Connections MUST be made when the client is
interacting with the application and MUST NOT first setup up all interacting with the application and MUST NOT first setup up all
connections. Connections SHOULD stay open per client for subsequent connections. Connections SHOULD stay open per client for subsequent
transactions to the same FQDN similar to how a web browser behaves. transactions to the same FQDN similar to how a web browser behaves.
Clients MUST use different URL Paths and Object sizes in orders as Clients MUST use different URL Paths and Object sizes in orders as
they are observed in real Applications. Clients MAY also setup they are observed in real Applications. Clients MAY also setup
multiple connections per FQDN to process multiple transactions in a multiple connections per FQDN to process multiple transactions in a
sequence at the same time. Table 6 has a partial example sequence of sequence at the same time. Table 7 has a partial example sequence of
the Office 365 Word application transactions. the Office 365 Word application transactions.
+---------------------------------+----------------------+----------+ +---------------------------------+----------------------+----------+
| FQDN | URL Path | Object | | FQDN | URL Path | Object |
| | | size | | | | size |
+===================================================================+ +===================================================================+
| company1-my.sharepoint.com | /personal... | 23,132 | | company1-my.sharepoint.com | /personal... | 23,132 |
+---------------------------------+----------------------+----------+ +---------------------------------+----------------------+----------+
| word-edit.officeapps.live.com | /we/WsaUpload.ashx | 2 | | word-edit.officeapps.live.com | /we/WsaUpload.ashx | 2 |
+---------------------------------+----------------------+----------+ +---------------------------------+----------------------+----------+
skipping to change at page 53, line 18 skipping to change at page 53, line 18
| | WordEditorIntl.js | | | | WordEditorIntl.js | |
+---------------------------------+----------------------+----------+ +---------------------------------+----------------------+----------+
| s1-word-edit-15.cdn.office.net | /we/s/.../ | 1,978,712| | s1-word-edit-15.cdn.office.net | /we/s/.../ | 1,978,712|
| | WordEditorExp.js | | | | WordEditorExp.js | |
+---------------------------------+----------------------+----------+ +---------------------------------+----------------------+----------+
| s1-word-edit-15.cdn.office.net | /we/s/.../jSanity.js | 10,912 | | s1-word-edit-15.cdn.office.net | /we/s/.../jSanity.js | 10,912 |
+---------------------------------+----------------------+----------+ +---------------------------------+----------------------+----------+
| word-edit.officeapps.live.com | /we/OneNote.ashx | 145,708 | | word-edit.officeapps.live.com | /we/OneNote.ashx | 145,708 |
+---------------------------------+----------------------+----------+ +---------------------------------+----------------------+----------+
Table 6: Office365 Word Transactions Table 7: Office365 Word Transactions
For application identification the HTTPS/TLS traffic MUST include For application identification the HTTPS/TLS traffic MUST include
realistic Certificate Subject Common Name (CN) data as well as Server realistic Certificate Subject Common Name (CN) data as well as Server
Name Indications (SNI). For example, a DUT MAY detect Facebook Chat Name Indications (SNI). For example, a DUT MAY detect Facebook Chat
traffic by inspecting the certificate and detecting *.facebook.com in traffic by inspecting the certificate and detecting *.facebook.com in
the certificate subject CN and subsequently detect the word chat in the certificate subject CN and subsequently detect the word chat in
the FQDN 5-edge-chat.facebook.com and identify traffic on the the FQDN 5-edge-chat.facebook.com and identify traffic on the
connection to be Facebook Chat. connection to be Facebook Chat.
Table 7 includes further examples in SNI and CN pairs for several Table 8 includes further examples in SNI and CN pairs for several
FQDNs of Office 365. FQDNs of Office 365.
+------------------------------+----------------------------------+ +------------------------------+----------------------------------+
|Server Name Indication (SNI) | Certificate Subject | |Server Name Indication (SNI) | Certificate Subject |
| | Common Name (CN) | | | Common Name (CN) |
+=================================================================+ +=================================================================+
| r1.res.office365.com | *.res.outlook.com | | r1.res.office365.com | *.res.outlook.com |
+------------------------------+----------------------------------+ +------------------------------+----------------------------------+
| login.windows.net | graph.windows.net | | login.windows.net | graph.windows.net |
+------------------------------+----------------------------------+ +------------------------------+----------------------------------+
skipping to change at page 54, line 26 skipping to change at page 54, line 26
+------------------------------+----------------------------------+ +------------------------------+----------------------------------+
| webdir.online.lync.com | *.online.lync.com | | webdir.online.lync.com | *.online.lync.com |
+------------------------------+----------------------------------+ +------------------------------+----------------------------------+
| graph.microsoft.com | graph.microsoft.com | | graph.microsoft.com | graph.microsoft.com |
+------------------------------+----------------------------------+ +------------------------------+----------------------------------+
| outlook.office365.com | outlook.com | | outlook.office365.com | outlook.com |
+------------------------------+----------------------------------+ +------------------------------+----------------------------------+
| appsforoffice.microsoft.com | appsforoffice.microsoft.com | | appsforoffice.microsoft.com | appsforoffice.microsoft.com |
+------------------------------+----------------------------------+ +------------------------------+----------------------------------+
Table 7: Office365 SNI and CN Pairs Examples Table 8: Office365 SNI and CN Pairs Examples
NetSecOPEN has provided a reference enterprise perimeter traffic mix NetSecOPEN has provided a reference enterprise perimeter traffic mix
with dozens of applications, hundreds of connections, and thousands with dozens of applications, hundreds of connections, and thousands
of transactions. of transactions.
The enterprise perimeter traffic mix consists of 70% HTTPS and 30% The enterprise perimeter traffic mix consists of 70% HTTPS and 30%
HTTP by Bytes, 58% HTTPS and 42% HTTP by Transactions. By HTTP by Bytes, 58% HTTPS and 42% HTTP by Transactions. By
connections with a single connection per FQDN the mix consists of 43% connections with a single connection per FQDN the mix consists of 43%
HTTPS and 57% HTTP. With multiple connections per FQDN the HTTPS HTTPS and 57% HTTP. With multiple connections per FQDN the HTTPS
percentage is higher. percentage is higher.
Table 8 is a summary of the NetSecOPEN enterprise perimeter traffic Table 9 is a summary of the NetSecOPEN enterprise perimeter traffic
mix sorted by bytes with unique FQDNs and transactions per mix sorted by bytes with unique FQDNs and transactions per
applications. applications.
+------------------+-------+--------------+-------------+ +------------------+-------+--------------+-------------+
| Application | FQDNs | Transactions | Bytes | | Application | FQDNs | Transactions | Bytes |
+=======================================================+ +=======================================================+
| Office365 | 26 | 558 | 52,931,947 | | Office365 | 26 | 558 | 52,931,947 |
+------------------+-------+--------------+-------------+ +------------------+-------+--------------+-------------+
| Box | 4 | 90 | 23,276,089 | | Box | 4 | 90 | 23,276,089 |
+------------------+-------+--------------+-------------+ +------------------+-------+--------------+-------------+
skipping to change at page 58, line 15 skipping to change at page 58, line 15
+------------------+-------+--------------+-------------+ +------------------+-------+--------------+-------------+
| Bing | 1 | 52 | 697,514 | | Bing | 1 | 52 | 697,514 |
+------------------+-------+--------------+-------------+ +------------------+-------+--------------+-------------+
| ADP | 1 | 30 | 508,654 | | ADP | 1 | 30 | 508,654 |
+------------------+-------+--------------+-------------+ +------------------+-------+--------------+-------------+
| | | | | | | | | |
+------------------+-------+--------------+-------------+ +------------------+-------+--------------+-------------+
| Grand Total | 983 | 10021 | 569,819,095 | | Grand Total | 983 | 10021 | 569,819,095 |
+------------------+-------+--------------+-------------+ +------------------+-------+--------------+-------------+
Table 8: Summary of NetSecOPEN Enterprise Perimeter Traffic Mix Table 9: Summary of NetSecOPEN Enterprise Perimeter Traffic Mix
Authors' Addresses Authors' Addresses
Balamuhunthan Balarajah Balamuhunthan Balarajah
Email: bm.balarajah@gmail.com Email: bm.balarajah@gmail.com
Carsten Rossenhoevel Carsten Rossenhoevel
EANTC AG EANTC AG
Salzufer 14 Salzufer 14
 End of changes. 65 change blocks. 
205 lines changed or deleted 242 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/