[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?