Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS)
xiao.min2@zte.com.cn Fri, 28 October 2022 03:12 UTC
Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A12C1524DC; Thu, 27 Oct 2022 20:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVH4l9dupgJx; Thu, 27 Oct 2022 20:12:25 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04654C1524B7; Thu, 27 Oct 2022 20:12:24 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4Mz6zW2GNJz8R03x; Fri, 28 Oct 2022 11:12:23 +0800 (CST)
Received: from njxh01app01.zte.com.cn ([10.41.132.205]) by mse-fl1.zte.com.cn with SMTP id 29S3CAU6051439; Fri, 28 Oct 2022 11:12:10 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxh01app01[null]) by mapi (Zmail) with MAPI id mid201; Fri, 28 Oct 2022 11:12:12 +0800 (CST)
Date: Fri, 28 Oct 2022 11:12:12 +0800
X-Zmail-TransId: 2af9635b488cffffffffd462dd19
X-Mailer: Zmail v1.0
Message-ID: <202210281112120380509@zte.com.cn>
In-Reply-To: <CAHw9_iJurptaF991KLP5CS+J7C++XcRU5_ef-nmZ3yP6p1pVXw@mail.gmail.com>
References: 166681530275.46711.14052349083997392055@ietfa.amsl.com, 202210271443035690400@zte.com.cn, CAHw9_iJurptaF991KLP5CS+J7C++XcRU5_ef-nmZ3yP6p1pVXw@mail.gmail.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: warren@kumari.net
Cc: iesg@ietf.org, draft-ietf-ippm-ioam-conf-state@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 29S3CAU6051439
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 635B4897.000 by FangMail milter!
X-FangMail-Envelope: 1666926743/4Mz6zW2GNJz8R03x/635B4897.000/10.5.228.132/[10.5.228.132]/mse-fl1.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 635B4897.000/4Mz6zW2GNJz8R03x
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/402ATF5qU1gca-OyGl62Mse8-gs>
Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Fri, 28 Oct 2022 03:12:29 -0000
Hi Warren, Thank you for clearing your DISCUSS position. Please check inline my response. Best Regards, Xiao Min Original From: WarrenKumari <warren@kumari.net> To: 肖敏10093570; Cc: iesg@ietf.org <iesg@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>; Date: 2022年10月27日 21:39 Subject: Re: Warren Kumari's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS) Comments inline, but the summary is: Thank you, very much for the proposed changes, and for replying so quickly. I will clear my DISCUSS position…. On Thu, Oct 27, 2022 at 2:43 AM, <xiao.min2@zte.com.cn> wrote: Hi Warren, Thank you for the review and thoughtful comments. Please check inline the proposed changes that will be incorporated into the next revision. Best Regards, Xiao Min This is a meta point - a number of (recent) documents contain statements similar to: "A deployment MUST ensure that border filtering drops inbound echo requests with a IOAM Capabilities Container Header from outside of the domain, [...]", but this assumes that routers actually have this sort of capability. The filtering logic on modern routers is quite limited (in order to allow filtering in hardware / not require multiple branch decisions), and just because the IETF puts a "deployments MUST ensure that border filtering drops <some new feature>" doesn't actually cause router filters to support this. E.g: set firewall family inet6 filter ioam_echo_capability term example from extension-header ? Possible completions: <range> Range of values [ Open a set of values ah Authentication header any Any extension header dstopts Destination options esp Encapsulating security payload fragment Fragment hop-by-hop Hop by hop options mobility Mobility routing Routing [edit] I don't have an e.g IPv6 / SRv6 / BIER / MPLS / <whatever> IOAM echo capability container matching term... Again, I'm clearing this discuss, but I did want to mention this larger concern and disconnect between what a document specifies as a MUST in operational requirements, and what is actually implementable / deployable… [XM]>>> Understood. Thank you for the education and thoughts sharing. I learned it. W From: WarrenKumariviaDatatracker <noreply@ietf.org> To: The IESG <iesg@ietf.org>; Cc: draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>; Date: 2022年10月27日 04:15 Subject: Warren Kumari's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS) Warren Kumari has entered the following ballot position for draft-ietf-ippm-ioam-conf-state-07: 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-ioam-conf-state/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you very much for writing this document. Please see: https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ My concerns are closely related to Roman's DISCUSS point: The document says: "A deployment can increase security by using border filtering of incoming and outgoing echo requests/replies." I'm unclear why this is just a "can increase security", and not something much much stronger -- but, also, I'm unclear how exactly an operator would be expected to filter these. [XM]>>> Roman Danyliw has provided some change on the text you quoted as below. Does that change works for you? NEWA deployment MUST ensure that border filtering drops inbound echo requests witha IOAM Capabilities Container Header from outside of the domain, and dropsoutbound echo request/replies with IOAM Capabilities Headers leaving the domain. As to the exact way an operator may take to do filter, I assume the operator can do filter on all incoming and outgoing echo requests/replies, or can do filter on some incoming and outgoing echo requests/replies with an IOAM Capabilities Container Header, an instantiation of the IOAM Capabilities Container Header has been described in draft-xiao-6man-icmpv6-ioam-conf-state.
- [ippm] Warren Kumari's Discuss on draft-ietf-ippm… Warren Kumari via Datatracker
- Re: [ippm] Warren Kumari's Discuss on draft-ietf-… xiao.min2
- Re: [ippm] Warren Kumari's Discuss on draft-ietf-… Warren Kumari
- Re: [ippm] Warren Kumari's Discuss on draft-ietf-… xiao.min2