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

[Robert Wilton via Datatracker <[e-mail]>]

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).


----------------------------------------------------------------------
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.

Regards,
Rob