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.