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
>
>
> 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?
>
> NEW
>
> A deployment MUST ensure that border filtering drops inbound echo requests with
> a IOAM Capabilities Container Header from outside of the domain, and drops
>
> outbound 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.
>


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…

W


> 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 echo
> request/reply mechanisms, which can be used within an In situ
> Operations, Administration, and Maintenance (IOAM) domain, allowing
> the IOAM encapsulating node to discover the enabled IOAM capabilities
> of each IOAM transit and IOAM decapsulating node.  The generic format
> is 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.
>
>