Subject: [bmwg] Benjamin Kaduk's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 03 Feb 2022 07:25:33 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bmwg-ngfw-performance-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bmwg-ngfw-performance/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is probably a minor point, but I'm putting it in the Discuss section
because one of the possible answers would be very problematic and I can't
rule that scenario out with just the information at hand.  As such (and
per
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/)
a response is greatly appreciated, to help clarify the intended meaning
and thus what (if any) changes to the document should be made in response.

In Section 4.2 we have a couple tables listing RECOMMENDED and OPTIONAL
features for different types of DUT/SUT.  Do these recommendations relate
to what features should be tested, what features should be enabled for use
in normal operation, what features should be implemented in devices, or
something else?  The latter options seem a bit far afield from the stated
scope of this document, and the particular recommendations listed probably
do not have IETF Consensus as to general applicability (most notably for
SSL Inspection).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Roman's Discuss (which you have already begun to resolve, thank
you).

Perhaps it is time to retire the term "SSL" in favor of the current
protocol name, "TLS".

Section 4.1

   In some deployment scenarios, the network security devices (Device
   Under Test/System Under Test) are connected to routers and switches,
   which will reduce the number of entries in MAC or ARP tables of the
   Device Under Test/System Under Test (DUT/SUT).  If MAC or ARP tables
   have many entries, this may impact the actual DUT/SUT performance due
   to MAC and ARP/ND (Neighbor Discovery) table lookup processes.  This

I understand the motivation for benchmarking the maximum performance from
the device under controlled circumstances, but it also seems that if a
device really will exhibit degraded performance due to the number of
entries in its MAC/ARP table, that would be useful information to have.
Perhaps a remark about how future work could include repeating
benchmarking results with different numbers of other devices on the local
network segment is in order.

Section 4.2

   Table 1 and Table 2 below describe the RECOMMENDED and OPTIONAL sets
   of network security feature list for NGFW and NGIPS respectively.

I agree with the IoTdir reviewer that Certificate Validation should surely
be a recommended feature for NGFWs.  But see also the DISCUSS point.

    | SSL Inspection | DUT/SUT intercepts and decrypts inbound HTTPS  |
    |                | traffic between servers and clients.  Once the |
    |                | content inspection has been completed, DUT/SUT |
    |                | encrypts the HTTPS traffic with ciphers and    |
    |                | keys used by the clients and servers.          |

This description could stand to be more clear, especially in light of the
fundamental differences between TLS 1.2 and TLS 1.3.
First, the description starts off with "intercepts and decrypts" and then
goes on to say that once inspection is over, the DUT/SUT "encrypts the
HTTPS traffic".  Does this mean that the DUT/SUT specifically needs to
re-encrypt after decrypting, or is it permissible to retain the original
ciphertext and just relay that ciphertext onward?
Second, in TLS 1.3, it is by construction impossible for a single set of
traffic encryption keys to be shared by all three of client, server, and
DUT/SUT -- RSA key transport is forbidden and ephemeral key exchange is
required.  In order to perform content inspection, such a middlebox needs
to be able to impersonate the server to the client (i.e., holding a
certificate and private key that is trusted by the client and represents
the identity of the real server, which is expected to require specific
configuration on the client to enable) and complete separate TLS
connections to client and to server.  In this scenario the middlebox must
remain as a "machine in the middle" for the duration of the entire
connection and decrypt/reencrypt all content using the different keys for
the client/middlebox and middlebox/server connections.

   *  Geographical location filtering, and Application Identification
      and Control SHOULD be configured to trigger based on a site or
      application from the defined traffic mix.

Do we have a sense for how sensitive the performance results are going to
be with respect to the proportion of traffic that triggers these classes
of filtering/control?  Would it be appropriate to require that this
breakdown be included in the report?

Section 4.3.1.3

   validation.  Depending on test scenarios and selected HTTP version,
   HTTP header compression MAY be set to enable or disable.  This

I didn't think it was possible to fully disable header compression for
HTTP/2 and HTTP/3 (just to set the dynamic table size to zero).

   [RFC8446] defines the following cipher suites for use with TLS 1.3.
   [...]

TLS_AES_128_CCM_8_SHA256 is marked as Recommended=N in the registry; I
think we should indicate that there is little need to benchmark it except
for those special circumstances where the cipher is appropriate.
Even TLS_AES_128_CCM_SHA256 (with full-length authentication tag) is
mostly only going to be used in IoT environments and is likely not needed
for a target of "enterprise grade encryption cipher suites".

Section 4.3.2.3

   server, TLS 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

Why is TLS resumption prohibited?
(As a technical matter, TLS 1.3 resumption uses a different mechanism than
the two TLS 1.2 resumption mechanisms, and it may be prudent to
specifically note whether TLS 1.3 resumption is also forbidden.)

   server SHALL serve a certificate to the client.  The HTTPS server
   MUST check host SNI information with the FQDN if SNI is in use.

What does "check host SNI information with the FQDN" mean?  Where is the
FQDN in question obtained from?  (In §4.3.3.1 we say that the proposed
(SNI) FQDN is compared to "the domain embedded in the certificate".  Note
that, of course, the certificate can contain more than one domain name,
e.g., via the now-quite-common use of subjectAltName.)

Section 6.1

       e.  Key test parameters

           *  Used cipher suites and keys

Do we really need to report the specific *keys* used (as opposed to
cryptographic parameters of the TLS connection like the group used for key
exchange, algorithm and key size of the server certificate, etc.)?

           *  Percentage of encrypted traffic and used cipher suites and
              keys (The RECOMMENDED ciphers and keys are defined in
              Section 4.3.1.3)

For what it's worth, trends in generic web traffic are rapidly converging
towards near-universal HTTPS usage.  I am not really sure that measuring
unencrypted traffic is going to be very interesting to many users (though
I concede that some will still be using it and find the corresponding
benchmarking results useful).

Section 7.3.3.2

   RECOMMENDED HTTP response object size: 1, 16, 64, 256 KByte, and
   mixed objects defined in Table 4.

With the explosion of video use on the modern Web, it might be worth
revisiting these recommended object sizes.  Is there likely to be value in
having very large objects for any of the tests?

Section 7.6.1, 7.7.1

   Test iterations MUST include common cipher suites and key strengths
   as well as forward looking stronger keys.  Specific test iterations

How/where would an implementor obtain more guidance on "common cipher suites
and key strengths" and "forward looking stronger keys"?  (With
understanding that this guidance will change over time and cannot be
permanently enshrined in this RFC-to-be.)

(Why does Section 7.8.1 not have similar language?)

Section 9

Hmm, I thought we typically had some language about how if the
benchmarking techniques specified in this document were used outside a
laboratory isolated test environment, security and other risks could arise
(e.g., due to DoS of nearby nodes/services).

Appendix A

I agree with Roman that the text around "CVEs" is imprecise and should be
talking about exploits that are identified by CVEs.