Re: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)

Hi Robert,

The I-D submission tool reopens and I've posted -08 revision. Link as below.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-08

Much appreciated if you would check it over to see whether your DISCUSS point has been addressed.

P.S. I just realize that I used a wrong email address while firstly replying to your comments, sorry for the inconvenience.

Best Regards,

Xiao Min

Original

From: 肖敏10093570
To: noreply@ietf.org <noreply@ietf.org>;
Cc: ippm-chairs@ietf.org <ippm-chairs@ietf.org>;iesg@ietf.org <iesg@ietf.org>;ippm@ietf.org <ippm@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;
Date: 2022年10月28日 10:45
Subject: Re: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

Hi Robert,

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

From: RobertWiltonviaDatatracker <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日 15:23
Subject: Robert Wilton's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)

Robert Wilton 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:
----------------------------------------------------------------------

Hi,

I support Roman and Warren's discuss, and again, I have a similar, but slightly
separate concern:

(1) p 14, sec 6.  Security Considerations

   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.

I'm concerned that performing a source address filtering isn't necessarily that
secure, compared with use NETCONF or RESTCONF that can provide AAA access
controls.  Hence, I think that the security considerations should REQUIRE that
IOAM daemons do not respond to these capability requests unless explicitly
configured to do so, specifically to avoid implementations potentially leaking
information if they are not aware of this functionality (e.g., if it was
enabled by default).
 [XM]>>> OK. Propose to add a new paragraph into the security section as below.

NEW

   A deployment MUST support the configuration option to enable/disable the IOAM Capabilities Discovery feature defined in this document. By default, the IOAM Capabilities Discovery feature MUST be disabled.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(2) p 2, sec 1.  Introduction

   *  When NETCONF/YANG is used in this scenario, each IOAM
      encapsulating node (including the host when it takes the role of
      an IOAM encapsulating node) needs to implement a NETCONF Client,
      each IOAM transit and IOAM decapsulating node (including the host
      when it takes the role of an IOAM decapsulating node) needs to
      implement a NETCONF Server, the complexity can be an issue.
      Furthermore, each IOAM encapsulating node needs to establish
      NETCONF Connection with each IOAM transit and IOAM decapsulating
      node, the scalability can be an issue.

Isn't it quite likely that the network devices in question has already
implement NETCONF servers, and hence really the additional code would only be
NETCONF client code.  There is also a separate option that RESTCONF could be
used instead of NETCONF, which is a somewhat lighter protocol.  I believe that
one big advantage to using NETCONF over these loopback mechanisms is that they
are properly secure, and NACM can be used to limit access to the IOAM
capabilities to only those devices/individuals which should be allowed to
access the data.

[XM]>>> I understand this paragraph might be undesirable to you (as NETCONF AD), so I believe it's helpful to retrospect the journey of this paragraph.

As I recall it, there were two wg adoption calls for this draft before it's adopted, this paragraph was added between the two calls, because the proposal to use NETCONF was raised during the first adoption call. There were some heated discussions on whether to use NETCONF or Echo Request/Reply, and the wg (rough) consensus was that Echo Request/Reply is more appropriate. Since then this paragraph remains there.

From my personal perspective I'm unwilling to reopen this discussion at this point.

If you have any suggestions on changing the text of this paragraph, or even removing it, please let me know :-)

Regards,
Rob