[ippm] Warren Kumari's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)
Warren Kumari via Datatracker <noreply@ietf.org> Wed, 13 July 2022 00:41 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1B6C14F72C; Tue, 12 Jul 2022 17:41:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-rfc8321bis@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, tpauly@apple.com, tpauly@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <165767291717.5123.13652670730872623488@ietfa.amsl.com>
Date: Tue, 12 Jul 2022 17:41:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/lsmz_BYM4MLkTlg2LOJtYXzP64c>
Subject: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2022 00:41:57 -0000
Warren Kumari has entered the following ballot position for draft-ietf-ippm-rfc8321bis-02: 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/about/groups/iesg/statements/handling-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-ippm-rfc8321bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 7.1 says: "The Alternate Marking Method is an example of a solution limited to a controlled domain [RFC8799]. A controlled domain is a managed network that selects, monitors, and controls access by enforcing policies at the domain boundaries, in order to discard undesired external packets entering the domain and check internal packets leaving the domain. [...] It must be possible to control the domain boundaries, and use specific precautions if traffic traverses the Internet." "Controlled domain" isn't a magic incantation you invoke to make all security issues disappear. Your definition of controlled domain sounds suspiciously like "the network should magically stop bad packets, and evil people wanting to do bad things!!!!". RFC8799 does not define what makes a domain, nor how the boundary is protected. Instead, it "it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes." and notes that "the Internet does not have a well-defined concept of limited domains" and further that "Domain boundaries that are defined administratively (e.g., by address filtering rules in routers) are prone to leakage caused by human error, especially if the limited domain traffic appears otherwise normal to the boundary routers. In this case, the network operator needs to take active steps to protect the boundary." The document states that "For security reasons, the Alternate Marking Method is RECOMMENDED only for controlled domains." - but you have not defined how a network operator is expected to define and enforce the domain boundary; simply saying that the network should select, monitor, and control access by enforcing policies at the domain boundaries, in order to discard undesired external packets doesn't explain how the network should do this. How exactly does the network know what packets are marked? How does the operator filter these? What matching rule can be applied at the boundary to make sure that marked packets do not enter or exit the network?
- [ippm] Warren Kumari's Discuss on draft-ietf-ippm… Warren Kumari via Datatracker
- Re: [ippm] Warren Kumari's Discuss on draft-ietf-… Giuseppe Fioccola