Re: [ippm] Progressing draft-ietf-ippm-ioam-conf-state

["Chengli (Cheng Li)" <[e-mail]>]

I would like to echo with the security part, cause I have the same considerations with Frank's. 

The most important question should be answered by the authors should be: how to use this mechanism is what environment? And how to ensure the security? 

P2P IPSec connection needs to be built among your network, so N nodes will need N*(N-1)/2*2 connections are needed(full-mesh and bidirectional). Is it worth to do it only for getting iOAM capabilities info? Or may be we can collect it by a controller via NETCONF/YANG or BGP-LS?  Why do we do it in data plane?


Respect,
Cheng


'''
* Security: Revision -02 does not seem to update the security section. IMHO, section 6 on security considerations should be enhanced to clearly articulate that we're dealing with very sensitive information. Consider loaning from e.g., https://datatracker.ietf.org/doc/html/rfc6241#section-9. As part of the discussion, it would be good to see an explanation where you'd expect  draft-ietf-ippm-ioam-conf-state to be used. Given the discussion in the Introduction section, you seem to assume an environment that does not have a central network management station / controller in place. Or in other terms, you seem to target a deployment, which isn't a limited domain per RFC 8799. In that case, I would expect that we have normative language that requires the use of strong authentication and encryption between the nodes (i.e., MUST use ICMP with AH and ESP..).
'''





-----Original Message-----
From: ippm [mailto:[e-mail]] On Behalf Of Frank Brockners (fbrockne)
Sent: Thursday, December 16, 2021 8:54 PM
To: [e-mail]; [e-mail]
Subject: Re: [ippm] Progressing draft-ietf-ippm-ioam-conf-state

Hi Xiao Min,

Thanks for posting draft-ietf-ippm-ioam-conf-state-02. I read through the updated version and looked at the diff to the 01 version (https://www.ietf.org/rfcdiff?url1=draft-ietf-ippm-ioam-conf-state-01&url2=draft-ietf-ippm-ioam-conf-state-02). Different from what you state below, I don't see any of my comments reflected. 
The two main points I mentioned in the last WG meeting were about (a) alignment with draft-ietf-ippm-ioam-yang and (b) enhancements to the security section, reflecting that the protocol you are defining is a network management protocol, and needs to be secured as such. 

More specifically: 
* Alignment with draft-ietf-ippm-ioam-yang: 
The IPPM WG is in the process of defining a YANG module for IOAM: draft-ietf-ippm-ioam-yang. We should have a single, comprehensive model for config information for IOAM. That model can then be rendered into different transports (be it JSON, XML, or yet another format - to then be carried over a e.g. ICMP in your case). Right now draft-ietf-ippm-ioam-conf-state heads down a path of defining a new set of management objects - many are similar to what draft-ietf-ippm-ioam-yang already defines, some they are less comprehensive, some hint at additional information that draft-ietf-ippm-ioam-yang does not cover yet: E.g.,  you define a "Pre-allocated Tracing Capabilities Object" where draft-ietf-ippm-ioam-yang  has a "Preallocated Tracing Profile" defined. You define ingress interface fields, which is information, which is more comprehensively defined by the ioam-filter grouping. You define specific fields to describe the timestamp format used by a node, which is information that should be described as part of the ioam-info container - and which is currently missing in draft-ietf-ippm-ioam-yang; point well taken :-). It is interesting to note that draft-ietf-ippm-ioam-conf-state does not even reference draft-ietf-ippm-ioam-yang.
From my perspective we should have one single data model for IOAM configuration - and that is the YANG module defined in draft-ietf-ippm-ioam-yang. Let's make sure that this model covers all the information required to properly manage IOAM. Then draft-ietf-ippm-ioam-conf-state would be solely focused on defining how that YANG module (from draft-ietf-ippm-ioam-yang) would be rendered into e.g., ICMP as a carrier protocol. 

* Security: Revision -02 does not seem to update the security section. IMHO, section 6 on security considerations should be enhanced to clearly articulate that we're dealing with very sensitive information. Consider loaning from e.g., https://datatracker.ietf.org/doc/html/rfc6241#section-9. As part of the discussion, it would be good to see an explanation where you'd expect  draft-ietf-ippm-ioam-conf-state to be used. Given the discussion in the Introduction section, you seem to assume an environment that does not have a central network management station / controller in place. Or in other terms, you seem to target a deployment, which isn't a limited domain per RFC 8799. In that case, I would expect that we have normative language that requires the use of strong authentication and encryption between the nodes (i.e., MUST use ICMP with AH and ESP..).

In addition to the above, I struggle to understand the "Operational Guide" in section 4: Could you shed a bit more light on how you expect things to work - and what a target deployment environment would look like? It seems that you assume that you don't know the network nor the destination addresses in your network: Do you expect that you would do regular "ICMP echo sweeps" in your network? Do you expect that, while doing the expanding ring search, an ICMP time exceeded message would also carry the "IOAM Capabilities Response Container Header", so that the capabilities container would not only be carried in the echo reply message but also in the time exceeded message? 

Thanks, Frank

(BTW - Note that due to the upcoming holiday season, replies might be delayed).

> -----Original Message-----
> From: ippm <[e-mail]> On Behalf Of [e-mail]
> Sent: Friday, 10 December 2021 08:01
> To: [e-mail]
> Subject: [ippm] Progressing draft-ietf-ippm-ioam-conf-state
> 
> Hi IPPM WG,
> 
> The -02 version of draft-ietf-ippm-ioam-conf-state has been posted.
> There are mainly two changes, one is on IOAM Tracing Capabilities 
> Objects to make them applicable to ICMPv6 extensions, another one is 
> on IOAM Proof-of- Transit Capabilities Object to make it aligned with 
> the updated IOAM-Data document.
> Also note that I've had an offline discussion with wg chairs and Frank 
> Brockners, my conclusion is that Frank's concern raised at IETF 112 
> has been addressed. If that's not the case, please speak up.
> With that said, I think this draft is ready for WGLC.
> 
> Best Regards,
> Xiao Min
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm