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

[[e-mail]]

Éric,

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

Brian

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Thursday, February 3, 2022 10:17 AM
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: Carsten Rossenhoevel <[e-mail]>; The IESG <[e-mail]>; Al Morton <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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:
> 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/2rCa7yESyR7lDErcB2
> 3fpFPH8ig/
> 
> 
> On 03/02/2022, 14:14, "iesg on behalf of Carsten Rossenhoevel" <[e-mail] on behalf of [e-mail]> wrote:
> 
>     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
> 
> 
>     Am 03.02.2022 um 10:16 schrieb Éric Vyncke via Datatracker:
>     > É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" ?
>     >
>     >
>     >
>     -- 
>     Carsten Rossenhövel
>     Managing Director, EANTC AG (European Advanced Networking Test Center)
>     Salzufer 14, 10587 Berlin, Germany
>     office +49.30.3180595-21, fax [phone], mobile [phone]
>     [e-mail], 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
> 
> 

--
---
[e-mail]