Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS)

xiao.min2@zte.com.cn Thu, 27 October 2022 06:43 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 A4735C14792F; Wed, 26 Oct 2022 23:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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_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 V_zzbTpRogCa; Wed, 26 Oct 2022 23:43:14 -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 B0F16C14792A; Wed, 26 Oct 2022 23:43:11 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (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 4Mybj92bkZz8R03x; Thu, 27 Oct 2022 14:43:09 +0800 (CST)
Received: from njxh01app02.zte.com.cn ([10.41.132.206]) by mse-fl2.zte.com.cn with SMTP id 29R6h1u9087288; Thu, 27 Oct 2022 14:43:01 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxh01app01[null]) by mapi (Zmail) with MAPI id mid201; Thu, 27 Oct 2022 14:43:03 +0800 (CST)
Date: Thu, 27 Oct 2022 14:43:03 +0800
X-Zmail-TransId: 2af9635a287703d26017
X-Mailer: Zmail v1.0
Message-ID: <202210271443035690400@zte.com.cn>
In-Reply-To: <166681530275.46711.14052349083997392055@ietfa.amsl.com>
References: 166681530275.46711.14052349083997392055@ietfa.amsl.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-fl2.zte.com.cn 29R6h1u9087288
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 635A287D.000 by FangMail milter!
X-FangMail-Envelope: 1666852989/4Mybj92bkZz8R03x/635A287D.000/10.5.228.133/[10.5.228.133]/mse-fl2.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 635A287D.000/4Mybj92bkZz8R03x
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/93f6B7Xb3zwj-WVqhe_ygbhAjKk>
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: Thu, 27 Oct 2022 06:43:16 -0000

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







Original



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.




The Abstract says: "This document describes an

extension to the echo request/reply mechanisms used in [...]", but from what I
can tell, it is more "here are some containers that you could use in some other
protocols".

[XM]>>> Alvaro Retana has provided some change on the Abstract as below. Does that change works for you?


NEW

   This document describes a generic format for use in echorequest/reply mechanisms, which can be used within an In situOperations, Administration, and Maintenance (IOAM) domain, allowingthe IOAM encapsulating node to discover the enabled IOAM capabilitiesof each IOAM transit and IOAM decapsulating node.  The generic formatis intended to be used with a variety of data planes such as IPv6,MPLS, Service Function Chain (SFC)   and Bit Index Explicit Replication (BIER).


It seems like, instead of only relying on the network for filtering (which
doesn't yet seem to be implemented), the: "To protect against unauthorized
sources using echo request messages to obtain IOAM Capabilities information, it
is RECOMMENDED that implementations provide a means of checking the source
addresses of echo request messages against an access list before accepting the
message." should be made stronger. Implementations need to be created to
understand IOAM, and so requiring that they have the capability to only accept
configured source addresses seems simple.
 [XM]>>> OK. Propose to change the text you quoted as below.

OLD


 To protect against unauthorized sources using echo request messages
 to obtain IOAM Capabilities information, it is RECOMMENDED that
 implementations provide a means of checking the source addresses of
 echo request messages against an access list before accepting the
 message. NEW

 To protect against unauthorized sources using echo request messages
 to obtain IOAM Capabilities information, 
 implementations MUST provide a means of checking the source addresses of
 echo request messages against an access list before accepting the
 message.