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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 03 Feb 2022 01:16:50 -0800

Éric Vyncke 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:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (probably easy to address but
really important), some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Thanks to Toerless for his deep and detailed IoT directorate review, I have
seen as well that the authors are engaged in email discussions on this review:
https://datatracker.ietf.org/doc/review-ietf-bmwg-ngfw-performance-13-iotdir-telechat-eckert-2022-01-30/

Special thanks to Al Morton for the shepherd's write-up including the section
about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics

The document obsoletes RFC 3511, but it does not include any performance
testing of IP fragmentation (which RFC 3511 did), which is AFAIK still a
performance/evasion problem. What was the reason for this lack of IP
fragmentation support ? At the bare minimum, there should be some text
explaining why IP fragmentation can be ignored.

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

One generic comment about the lack of testing with IPv6 extension headers as
they usually reduce the performance (even for NGFW/NGIPS). There should be some
words about this lack of testing.

## Section 4.1

Please always use "ARP/ND" rather than "ARP".

## Section 4.2

Any reason why "SSL" is used rather than "TLS" ?

Suggest to replace "IP subnet" by "IP prefix".

## Section 4.3.1.2 (and other sections)

"non routable Private IPv4 address ranges" unsure what it is ? RFC 1918
addresses are routable albeit private, or is it about link-local IPv4 address ?
169.254.0.0/16 or 198.18.0.0/15 ?

## Section 4.3.1.3

Suggest to add a date information (e.g., 2022) in the sentence "The above
ciphers and keys were those commonly used enterprise grade encryption cipher
suites for TLS 1.2".

In "[RFC8446] defines the following cipher suites for use with TLS 1.3." is
this about a SHOULD or a MUST ?

## Section 6.1

In "Results SHOULD resemble a pyramid in how it is reported" I have no clue how
a report could resemble a pyramid. Explanations/descriptions are welcome in the
text.

## Section 7.8.4 (and other sections)

In "This test procedure MAY be repeated multiple times with different IP types
(IPv4 only, IPv6 only and IPv4 and IPv6 mixed traffic distribution)" should it
be a "SHOULD" rather than a "MAY" ?

---

From: Carsten Rossenhoevel <[email-masked]>
Date: Thu, 3 Feb 2022 14:13:52 +0100

Dear Éric,

 From our point of view, testing of IP fragmentation does not belong 
into a network security test plan these days.

1) IP fragmentation was indeed an issue across the industry in the early 
2000s.  If I remember correctly, Path MTU discovery sometimes did not 
work well back in those days, and MTUs had to be fixed per hop 
occasionally.  To my knowledge, this is not usually the case today 
anymore.  This test case is genuinely obsoleted by technical progress.

2) In case there are still any MTU issues, they would be better covered 
in a network-level (IPv4 / IPv6) test plan because IP fragmentation is a 
function of the IP layer, not related to security nor applications.

3) The IP fragmentation test in RFC3511 wasn't even a real benchmark 
because it mainly inspected incorrect configuration. The KPI was not 
"measure throughput when fragmentation is misconfigured" (this KPI is 
rather useless) but rather an ordinal pass/fail "check that the 
bandwidth is not reduced by incorrect IP fragmentation in any way."

For all these reasons we do not consider the IP fragmentation test case 
in RFC3511 applicable specifically for network security devices today.  
Since this is due to technical progress and lack of applicability for 
network security testing, I am not sure if a statement is needed in the 
new document?  If so, please suggest some wording.

Best regards, Carsten

-- 
Carsten Rossenhövel
Managing Director, EANTC AG (European Advanced Networking Test Center)
Salzufer 14, 10587 Berlin, Germany
office +49.30.3180595-21, fax +49.30.3180595-10, mobile +49.177.2505721
[email-masked], https://www.eantc.de

Place of Business/Sitz der Gesellschaft: Berlin, Germany
Chairman/Vorsitzender des Aufsichtsrats: Herbert Almus
Managing Directors/Vorstand: Carsten Rossenhövel, Gabriele Schrenk
Registered: HRB 73694, Amtsgericht Charlottenburg, Berlin, Germany
EU VAT No: DE812824025

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 3 Feb 2022 14:27:59 +0000

Dear Carsten

[thank you for writing Éric BTW :-)  -- and we chatted years ago at the MPLS World Congress ]

While I do not disagree with your arguments, I still think that some text (perhaps verbatim from your explanation below) is required in the document to justify the absence of fragmentation-related text (as RFC 3511 had some text).

BTW, like all IESG ballot/review, there is no need to reply before the telechat[1] of course, it can be done in a later stage.

Regards

-éric

[1] like always, every IETF participant is welcome to listen to the IESG telechat 'live' (i.e., in 30 minutes) see https://mailarchive.ietf.org/arch/msg/ietf-announce/2rCa7yESyR7lDErcB23fpFPH8ig/

On 03/02/2022, 14:14, "iesg on behalf of Carsten Rossenhoevel" <[email-masked] on behalf of [email-masked]> wrote:

    Dear Éric,

    Best regards, Carsten

---

From: Carsten Rossenhoevel <[email-masked]>
Date: Thu, 3 Feb 2022 15:40:30 +0100

Dear Éric, sure I remember our talks :)

Yes, we can write a note regarding the reasons why IP fragmentation test 
case was obsoleted.

Best regards, Carsten

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Feb 2022 16:16:37 +0100

a) FYI in support of Carstens assesment:
 I think to remember that one common occurance for fragmented IP traffic where
 routers between inside and outside tunneling traffic and then often creating
 fragmented traffic. But some time after 2003 more and more routers with
 hardware acceleration started to support tunneling, but then of course with a
 much bigger performance drop when fragmenting themselves. Hence practices changed
 to only supporte reduced tunneled traffic MTU and prohibiting fragmentation. 
 And in parallel of course host stacks PMTUD improved.

b) In a section summarizing differences over rfc3511, absence of IP fragementation
measurement might be explained with a simple statment like:

Measurement of performance for processing of IP fragmented traffic (RFC3511, section 5.9)
was removed in this document because IP fragmentation does today not commonly occur in
traffic anymore, unlike it might have been at the time when RFC3511 was written.

c) It might also be useful to add something like the following at the end of
the security section:

Security assessment of an NGFW/NGIPS product could also include an analysis
whether any type of uncommon traffic characteristics would have significant
impact on performance. Such performance impacts would allow an attacker to use such
specifically crafted traffic as a DoS attack to reduce the remaining performance
available to other traffic through the NGFW/NGIPS. Such uncommon traffic characteristic
might include for example IP fragmented traffic, specific type of application
traffic or uncommonly high HTTP transaction rate traffic.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: <[email-masked]>
Date: Wed, 9 Feb 2022 10:58:12 -0500

Éric,

Do you have any feedback to the responses from Carsten and Toerless?

Brian

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Thursday, February 3, 2022 10:17 AM
To: Eric Vyncke (evyncke) <[email-masked]>
Cc: Carsten Rossenhoevel <[email-masked]>; The IESG <[email-masked]>; Al Morton <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

a) FYI in support of Carstens assesment:
 I think to remember that one common occurance for fragmented IP traffic where  routers between inside and outside tunneling traffic and then often creating  fragmented traffic. But some time after 2003 more and more routers with  hardware acceleration started to support tunneling, but then of course with a  much bigger performance drop when fragmenting themselves. Hence practices changed  to only supporte reduced tunneled traffic MTU and prohibiting fragmentation. 
 And in parallel of course host stacks PMTUD improved.

b) In a section summarizing differences over rfc3511, absence of IP fragementation measurement might be explained with a simple statment like:

Measurement of performance for processing of IP fragmented traffic (RFC3511, section 5.9) was removed in this document because IP fragmentation does today not commonly occur in traffic anymore, unlike it might have been at the time when RFC3511 was written.

c) It might also be useful to add something like the following at the end of the security section:

Security assessment of an NGFW/NGIPS product could also include an analysis whether any type of uncommon traffic characteristics would have significant impact on performance. Such performance impacts would allow an attacker to use such specifically crafted traffic as a DoS attack to reduce the remaining performance available to other traffic through the NGFW/NGIPS. Such uncommon traffic characteristic might include for example IP fragmented traffic, specific type of application traffic or uncommonly high HTTP transaction rate traffic.

Cheers
    Toerless

On Thu, Feb 03, 2022 at 02:27:59PM +0000, Eric Vyncke (evyncke) wrote:
> [1] like always, every IETF participant is welcome to listen to the 
> IESG telechat 'live' (i.e., in 30 minutes) see 
> https://mailarchive.ietf.org/arch/msg/ietf-announce/2rCa7yESyR7lDErcB2
> 3fpFPH8ig/
> 
> 

--
---
[email-masked]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 9 Feb 2022 16:06:25 +0000

Hello Brian,

My absence of reply to Carsten's email is because his reply (below) seemed OK to me. So, as soon as some text is added about why fragmentation is no more part of the -bis document, I am clearing my DISCUSS. 

Action from Carsten per his email : "Yes, we can write a note regarding the reasons why IP fragmentation test case was obsoleted."

But you are right: I should have replied saying so, please accept my apologies for not doing so.

Regards

-éric

On 09/02/2022, 16:58, "[email-masked]" <[email-masked]> wrote:

    Éric,

    Brian

    -----Original Message-----
    From: [email-masked] <[email-masked]> 
    Sent: Thursday, February 3, 2022 10:17 AM
    To: Eric Vyncke (evyncke) <[email-masked]>
    Cc: Carsten Rossenhoevel <[email-masked]>; The IESG <[email-masked]>; Al Morton <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
    Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

    Cheers
        Toerless

    --
    ---
    [email-masked]

---

From: <[email-masked]>
Date: Wed, 9 Feb 2022 11:09:33 -0500

Thanks a lot. I just wanted to make sure. Does the Discuss status get changed once a new draft with the change is posted?

Brian

-----Original Message-----
From: Eric Vyncke (evyncke) <[email-masked]> 
Sent: Wednesday, February 9, 2022 11:06 AM
To: [email-masked]; [email-masked]
Cc: 'Carsten Rossenhoevel' <[email-masked]>; 'The IESG' <[email-masked]>; 'Al Morton' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

Hello Brian,

Regards

-éric

    Éric,

    Brian

    -----Original Message-----
    From: [email-masked] <[email-masked]> 
    Sent: Thursday, February 3, 2022 10:17 AM
    To: Eric Vyncke (evyncke) <[email-masked]>
    Cc: Carsten Rossenhoevel <[email-masked]>; The IESG <[email-masked]>; Al Morton <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
    Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

    Cheers
        Toerless

    --
    ---
    [email-masked]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 9 Feb 2022 16:13:42 +0000

I will have to manually check the I-D and the 'absence of fragmentation' text, then update manually my ballot. It will take max 30 minutes but I live Europe/Brussels TZ ;)

-éric

On 09/02/2022, 17:10, "[email-masked]" <[email-masked]> wrote:

    Brian

    -----Original Message-----
    From: Eric Vyncke (evyncke) <[email-masked]> 
    Sent: Wednesday, February 9, 2022 11:06 AM
    To: [email-masked]; [email-masked]
    Cc: 'Carsten Rossenhoevel' <[email-masked]>; 'The IESG' <[email-masked]>; 'Al Morton' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
    Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

    Hello Brian,

    Regards

    -éric

        Éric,

        Brian

        -----Original Message-----
        From: [email-masked] <[email-masked]> 
        Sent: Thursday, February 3, 2022 10:17 AM
        To: Eric Vyncke (evyncke) <[email-masked]>
        Cc: Carsten Rossenhoevel <[email-masked]>; The IESG <[email-masked]>; Al Morton <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
        Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

        Cheers
            Toerless

        --
        ---
        [email-masked]

---

From: <[email-masked]>
Date: Wed, 9 Feb 2022 11:16:12 -0500

Thanks again. I'm new to the process, so I just wanted to make sure I knew what to expect.

Brian

-----Original Message-----
From: Eric Vyncke (evyncke) <[email-masked]> 
Sent: Wednesday, February 9, 2022 11:14 AM
To: [email-masked]; [email-masked]
Cc: 'Carsten Rossenhoevel' <[email-masked]>; 'The IESG' <[email-masked]>; 'Al Morton' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

-éric

    Brian

    -----Original Message-----
    From: Eric Vyncke (evyncke) <[email-masked]> 
    Sent: Wednesday, February 9, 2022 11:06 AM
    To: [email-masked]; [email-masked]
    Cc: 'Carsten Rossenhoevel' <[email-masked]>; 'The IESG' <[email-masked]>; 'Al Morton' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
    Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

    Hello Brian,

    Regards

    -éric

        Éric,

        Brian

        -----Original Message-----
        From: [email-masked] <[email-masked]> 
        Sent: Thursday, February 3, 2022 10:17 AM
        To: Eric Vyncke (evyncke) <[email-masked]>
        Cc: Carsten Rossenhoevel <[email-masked]>; The IESG <[email-masked]>; Al Morton <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
        Subject: Re: Éric Vyncke's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

        Cheers
            Toerless

        --
        ---
        [email-masked]