[bmwg] NGFW Security Features Text

Timothy Carlin <tjcarlin@iol.unh.edu> Tue, 02 June 2020 16:45 UTC

Return-Path: <tjcarlin@iol.unh.edu>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F323A0B28 for <bmwg@ietfa.amsl.com>; Tue, 2 Jun 2020 09:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAYfz876Wpek for <bmwg@ietfa.amsl.com>; Tue, 2 Jun 2020 09:45:29 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45923A0B21 for <bmwg@ietf.org>; Tue, 2 Jun 2020 09:45:29 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id x13so4113530wrv.4 for <bmwg@ietf.org>; Tue, 02 Jun 2020 09:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:from:date:message-id:subject:to; bh=256qdDYnQA8OKrcKMsKoEBJfMRQ8VZDTS2P2droVcVQ=; b=G6HhfkIsFIXe1Mv8mnoqhOx6I23qco9upAvsL7MHcky6ydhlaaHSuGuVvDHqZ3gnJZ BJ1DwBptKyY6Kl7rtPe85bqmsIi+YwpLIU0PClgrmXKi4gbVITHQ9kenWj3zKhM7lO3m bRNfA7hPRIDlc5Ff3U2XUDQxsyatMH3xzIP+g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=256qdDYnQA8OKrcKMsKoEBJfMRQ8VZDTS2P2droVcVQ=; b=k7tkwFdLMF1PuCs1lq6zGXmDJbzzEOWGTYHroEeuYrp1FxyLimInU4SghSGGB8TiMg luFJgSi3cjKb78ZGYtBUFjpqwG1fN/t6dGqYuGRWctAlW03G5QO8S60hbunjAKj4ybey 4zEq/IVhOEUuox67/CHELvjRdoxCRgJx27Yg5jvGgwLF0mTxmwSVy3CYiNd3xSMe/5yy /OW2Z4APS2JBnq1v28D7pjXUkBhJmpOgKJQ1tGeBwmsiuEcrckpujbh46GD4QD6l1IvO qj36ZHnY7qAK1xDVa7vM6Rd6kyMDQfuvGA5hs79EXGqJQ9F0xX3PFoJhaBXzlogfXgAX ETMw==
X-Gm-Message-State: AOAM533jhJJrMYEJZgGaBCUUAz1TQBGb8qlA1HkT3f4u52Oh9ZMqYLWS XhbT19H2tjazWwAeytHJNVIxHpGkV4qtWrVwef3oohvDCc8=
X-Google-Smtp-Source: ABdhPJxZ3oLTFENL7TIiGVsVt2HyhungmUKM0CdmsR7blp4HoGKP6+uLzzlr/e2AedphvwcCDhvbfd9glHDeJusYwyo=
X-Received: by 2002:adf:f2c2:: with SMTP id d2mr19871505wrp.424.1591116327510; Tue, 02 Jun 2020 09:45:27 -0700 (PDT)
MIME-Version: 1.0
From: Timothy Carlin <tjcarlin@iol.unh.edu>
Date: Tue, 2 Jun 2020 12:44:51 -0400
Message-ID: <CAB-aFv8W=bJUgtLNmXxjipk1zCGh_roBBSXC_FvFQDUPduPEuA@mail.gmail.com>
To: bmwg@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007f72f405a71ca3be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/0I3vlw67G9cqhDDJ9OuHZp8K1cM>
Subject: [bmwg] NGFW Security Features Text
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 16:45:32 -0000

Hi all,

I wanted to mention that I have read draft-ietf-bmwg-ngfw-performance-03
and I support it.

I have additional text I would like to suggest be included to help to
clarify an ambiguity with regards to security feature processing.
Specifically, in the case that a DUT discontinues processing a security
feature (for example, SSL Inspection), traffic should still be processed by
the remainder of the applicable security features.  Said another way, the
traffic should NOT "fail open".

Here is some proposed text to add to Section 4.2, in the itemized list as
the 2nd item (below "All security inspection enabled"):

==
* All applicable traffic MUST be processed by the configured security
feature(s) in table 1.  In the case that applicable traffic can no longer
be processed for a given security feature (e.g. due to processing or
throughput limits, etc.), the portion of traffic which exceeds the limit
SHOULD be blocked and this MAY be configurable.
==

Please let us know if you have any questions or comments.

Best Regards,
Tim C.
UNH-IOL