Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 19 Nov 2020 09:00:17 +0000

Hi Min,

I am not going to block your adoption☺.  I am saying that there are some security and privacy risks of this solution. Personally I don’t like the solution, but adopt it or not dependent on the consensus.

Like you mentioned, filter may be needed, but it is hard to filter ICMP packet with this extensions. Because you can not check the ICMP Echo request to see if the TLVs are carried or not. You may only drop all the ICMP Echo request packets, and I think this may be inappropriate. Therefore, I think there are some critical security risks hidden in this solution. Hope we can solve them.

Also, I think there are multiple challenges for IOAM in multiple domain scenarios. If we can not get the IOAM capabilities via ICMP PING in these scenarios, then we should do it via in control or management plane, right? Why not just use those methods directly for intra domain and inter domain?

Above are my concerns. At the end, I think the IOAM capabilities are important, but this is my personal opinion.

Thanks,
Cheng

发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2020年11月19日 13:50
收件人: Chengli (Cheng Li) <[email-masked]>
抄送: [email-masked]; [email-masked]; fbrockne=[email-masked]; tpauly=[email-masked]
主题: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Cheng,

We co-authors have discussed the example you provided, and we agree that this is a valid concern that needs to be addressed.

As what's been documented in draft-ietf-ippm-ioam-ipv6-options-04, leaking of IOAM-over-IPv6 packets outside the IOAM domain may happen in the case of device misconfiguration or device failure. It's similar here, leaking of  IOAM-Capabilities-over-ICMPv6 packets outside the IOAM domain may happen, but in my view IOAM-Capabilities-over-ICMPv6 packets are much less sensitive than IOAM-over-IPv6 packets, and the operator can add authentication to ICMPv6 packets if needed, so it's explicitly not a blocking issue.

The Security Consideration section of this draft will be enhanced in the next revision.

Thanks for your good comments.

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;
抄送人：[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]<mailto:[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]>;
日 期 ：2020年11月18日 17:01
主 题 ：RE: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
Hi Min,

Thanks for your reply.

Simple example, Domain A is an IOAM domain, Domain B is another IOAM domain. Logically, the IOAM capabilities info of nodes in domain B MUST NOT be leaked out side the domain, therefore, the node 1 in domain A should not get the info of nodes in domain B.

In your solution, I guess we can use the ICMPv6 to request the capabilities info within the IOAM domain or outside the domain, if I understand it correctly.
Nothing to stop anyone to get the IOAM capability info of any node from any corner in the world. Right?

The solution of preventing information leaking needs to be considered. That is my concern.

IGP/BGP/BGP-LS solution may have other issues like you mentioned, but they can be controlled within the trusted domain.
Also, I see many capabilities are advertised via these protocols.  But this is another topic.

Best,
Cheng

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, November 18, 2020 3:57 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Cc: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>; tpauly=[email-masked]<mailto:tpauly=[email-masked]>
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Cheng,

I don't really understand your concern.

ICMPv6 is a mature protocol mechanism, and IOAM function is limited in a trusted domain, then using ICMPv6 to discover IOAM capabilities wouldn't introduce any big challenge on security and privacy.

I don't think IGP is better than ICMPv6 in this case. Firstly, flooding IOAM capabilities throughout the IGP domain is too heavy and unnecessary in my view. Secondly, IGP domain and IOAM domain don't always have the same coverage, one example is that when the IOAM encapsulating node is a host IGP flooding doesn't work for it.

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：Chengli (Cheng Li);肖敏10093570;
抄送人：[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]<mailto:[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]>;
日期：2020年11月17日 17:53
主题：RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
I meantI don’t think we can detect the (Non Routing ) capabilities of a node in another domain. Sorry for the typo.

From: ippm [mailto:[email-masked]]On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, November 17, 2020 4:09 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>;tpauly=[email-masked]<mailto:tpauly=[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

That is also my understanding. IOAM is limited in a trusted domain.

But ICMP can be used in the global Internet? I don’t think we can detect the capabilities of a node in another node. Privacy and security will be a big challenge.

So personally I prefer IGP/BGP/BGP-LS or NETCONF/YANG way.

Thanks,
Cheng

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:52 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Cc: fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>;tpauly=[email-masked]<mailto:tpauly=[email-masked]>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Cheng,

I noticed that Frank has submitted an In-situ OAM deployment draft within OPSAWG, in section 3 of that draft it says:

"

IOAM is a network domain specific feature, with "network domain"

   being a set of network devices or entities within a single

   administration.  IOAM is not targeted for a deployment on the global

   Internet.  The part of the network which employs IOAM is referred to

   as the "IOAM-Domain".

"

To my understanding, the IOAM data is collected only within a trusted domain, of course, Frank can correct me if I'm wrong.

For your convenience, the link for this quoted draft is provided as below.

https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：Frank Brockners (fbrockne);Tommy Pauly;IETF IPPM WG ([email-masked]<mailto:[email-masked]>);
抄送人：IPPM Chairs;
日期：2020年11月16日 17:28
主题：Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm
I have one simple question like I mentioned in the meeting: Is it secure to discover the non-routing capabilities info from the data plane?

For instance, a packet may travel several network domains, and the trusted scope is only within each domain. When we use ICMP Ping, we can get the non-routing info from other domains. Is it OK to do it?  I think we should consider more about security and privacy.

Furthermore, can we collect the IOAM data in multiple domain scenarios? Or only within a trusted domain?

Thanks,
Cheng

From: ippm [mailto:[email-masked]]On Behalf OfFrank Brockners (fbrockne)
Sent: Monday, November 16, 2020 3:13 PM
To: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: IPPM Chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

per what I mentioned during the IPPM WG meeting today, I don’t think we should adopt the document before we have a couple of key questions resolved:

* Why can’t we use Netconf/YANG (with the existing capabilities discovery process – a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as a NC client) could retrieve the IOAM capabilities from other IOAM nodes  (acting as a NC server). Plus there is already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG is not suitable for the scenario that the authors have in mind. The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00) that were presented in the IPPM WG meeting today, mention “Changed from “IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former is too associated with NETCONF/YANG.” IMHO we need a bit more than just wordsmithing.

* While the draft uses IOAM capabilities discovery as the use-case, in more general terms, it proposes to add management/ops capabilities to echo-request/reply protocols like ICMP, which is a much broader topic. The TLV structures which are proposed to be added to echo-requests and echo-replies could obviously be leveraged for other use-cases. Does the work really fit the scope of the IPPM WG?

Thanks, Frank

From: ippm <[email-masked]<mailto:[email-masked]>>On Behalf OfTommy Pauly
Sent: Freitag, 30. Oktober 2020 19:46
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: IPPM Chairs <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

This email starts a Working Group call for adoption for draft-xiao-ippm-ioam-conf-state. This document has been presented several times and discussed within the working group in the context of our overall IOAM work.

The document can be found here:

https://tools.ietf.org/html/draft-xiao-ippm-ioam-conf-state-07<https://tools.ietf.org/html/draft-zhou-ippm-ioam-yang-08>

Please provide your feedback on these document, and state whether or not you believe the IPPM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Fri, 20 Nov 2020 16:45:42 +0800 (CST)

Hi Cheng,

Aha, thank you for not going to block WG adoption of this draft.

We co-authors have discussed your comments, please see inline my response tagged with <XM>.

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)
收件人：肖敏10093570;
抄送人：[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked];
日 期 ：2020年11月19日 17:00
主 题 ：re: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

I am not going to block your adoptionJ.

I am saying that there are some security and privacy risks of this solution. Personally I don’t like the solution, but adopt it or not dependent on the consensus.

<XM>  We think it's good to point to the need addressing security and privacy for a method that retrieves capabilities information from a system. We'd suggest to introduce HMAC TLV or sub-TLV to address your concerns. We'll work on improving Security Considerations section.

Like you mentioned, filter may be needed, but it is hard to filter ICMP packet with this extensions. Because you can not check the ICMP Echo request
 to see if the TLVs are carried or not. You may only drop all the ICMP Echo request packets, and I think this may be inappropriate. Therefore, I think there are some critical security risks hidden in this solution. Hope we can solve them.

<XM> We agree, filtering might be not the most effiecient method to secure the proposed mechanism. Propose using HMAC, for example, SHA-256. It may not require to protect the whole ICMPv6 packet but some the most critical fields to avoid tampering, spoofing. Which fields? We believe that we can figure out later.

Also, I think there are multiple challenges for IOAM in multiple domain scenarios. If we can not get the IOAM capabilities via ICMP PING in these
 scenarios, then we should do it via in control or management plane, right? Why not just use those methods directly for intra domain and inter domain?

<XM> We believe that IOAM is not intended for multi-domain use. We believe that draft-brockners-opsawg-ioam-deployment and others explicitly state that IOAM is applicable in a small domain, specifically a single administrative domain. We understand that rules out the multi-domain scenario.

<XM> Glad to know you think the IOAM capabilities are important. We greatly appreciate any discussion and constructive comments.

Thanks,

Cheng

 

发送时间: 2020年11月19日
 13:50

Hi Cheng,

As what's been documented in draft-ietf-ippm-ioam-ipv6-options-04, leaking of IOAM-over-IPv6 packets outside the IOAM domain may happen in the case of device misconfiguration or device
 failure. It's similar here, leaking of  IOAM-Capabilities-over-ICMPv6 packets outside the IOAM domain may happen, but in my view IOAM-Capabilities-over-ICMPv6 packets are much less sensitive than IOAM-over-IPv6 packets, and the operator can add authentication
 to ICMPv6 packets if needed, so it's explicitly not a blocking issue.

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

收件人：肖敏10093570;

抄送人：[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked];

日 期 ：2020年11月18日 17:01

Hi Min,

Thanks for your reply.

Simple example, Domain A is an IOAM domain, Domain B is another IOAM domain. Logically,
 the IOAM capabilities info of nodes in domain B MUST NOT be leaked out side the domain, therefore, the node 1 in domain A should not get the info of nodes in domain B.

In your solution, I guess we can use the ICMPv6 to request the capabilities info within
 the IOAM domain or outside the domain, if I understand it correctly.

Nothing to stop anyone to get the IOAM capability info of any node from any corner in
 the world. Right?

 

IGP/BGP/BGP-LS solution may have other issues like you mentioned, but they can be controlled
 within the trusted domain.

Also, I see many capabilities are advertised via these protocols.  But this is another
 topic.

Best,

Cheng

 

From:[email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 18, 2020 3:57 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Chengli (Cheng Li) <[email-masked]>;[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Cheng,

ICMPv6 is a mature protocol mechanism, and IOAM function is limited in a trusted domain, then using ICMPv6 to discover IOAM capabilities wouldn't introduce any big challenge on security
 and privacy.

I don't think IGP is better than ICMPv6 in this case. Firstly, flooding IOAM capabilities throughout the IGP domain is too heavy and unnecessary in my view. Secondly, IGP domain and
 IOAM domain don't always have the same coverage, one example is that when the IOAM encapsulating node is a host IGP flooding doesn't work for it.

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

抄送人：[email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked];

日期：2020年11月17日 17:53

I meantI don’t think we can detect the (Non Routing ) capabilities of a node in another
 domain. Sorry for the typo.

From:
 ippm [mailto:[email-masked]]On
 Behalf Of Chengli (Cheng Li)
Sent: Tuesday, November 17, 2020 4:09 PM
To: [email-masked]
Cc: [email-masked];[email-masked];fbrockne=[email-masked];tpauly=[email-masked]
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Min,

 

But ICMP can be used in the global Internet? I don’t think we can detect the capabilities
 of a node in another node. Privacy and security will be a big challenge.

 

Thanks,

Cheng

 

From:[email-masked]
 [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:52 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: fbrockne=[email-masked];tpauly=[email-masked];[email-masked];[email-masked]
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello Cheng,

"

IOAM is a network domain specific feature, with "network domain"   being a set of network devices or entities within a single   administration.  IOAM is not targeted for a deployment on the global   Internet.  The part of the network which employs IOAM is referred to   as the "IOAM-Domain"."

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

收件人：Frank Brockners (fbrockne);Tommy Pauly;IETF IPPM WG ([email-masked]);

抄送人：IPPM Chairs;

日期：2020年11月16日 17:28

[email-masked]

 

For instance, a packet may travel several network domains, and the trusted scope is only within each domain. When we use ICMP Ping, we can
 get the non-routing info from other domains. Is it OK to do it?  I think we should consider more about security and privacy.

 

Thanks,

Cheng

 

 

 

From: ippm [mailto:[email-masked]]On
 Behalf OfFrank Brockners (fbrockne)
Sent: Monday, November 16, 2020 3:13 PM
To: Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG ([email-masked])
 <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

per what I mentioned during the IPPM WG meeting today, I don’t think we should adopt the document before we have a couple of key questions
 resolved:

* Why can’t we use Netconf/YANG (with the existing capabilities discovery process– a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as a NC client) could retrieve the IOAM capabilities from other IOAM nodes  (acting as a NC server). Plus there is already a YANG model
 in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG is not suitable for the scenario that the authors have in mind. The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00)
 that were presented in the IPPM WG meeting today, mention “Changed from“IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former is too associated with NETCONF/YANG.” IMHO we need a bit more than just wordsmithing.

* While the draft uses IOAM capabilities discovery as the use-case, in more general terms, it proposes to add management/ops capabilities to echo-request/reply
 protocols like ICMP, which is a much broader topic. The TLV structures which are proposed to be added to echo-requests and echo-replies could obviously be leveraged for other use-cases. Does the work really fit the scope of the IPPM WG?

Thanks, Frank

From: ippm <[email-masked]>On
 Behalf OfTommy Pauly
Sent: Freitag, 30. Oktober 2020 19:46
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hello IPPM,

https://tools.ietf.org/html/draft-xiao-ippm-ioam-conf-state-07

Please provide your feedback on these document, and state whether or not you believe the IPPM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday,
 November 16.

Best,
Tommy & Ian

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 20 Nov 2020 10:30:02 +0000

Hi Min,

Using HMAC is almost impossible to filter ICMP packets, it is used for all the packets from a node.

Also, using HMAC is NOT a good idea at all. Like we have millions of nodes in the word, which will send the packet to visit a node (No only ICMP packets for IOAM capabilities).

How to filter the ICMP packets and normal data packets? Even you can distinguish that, how to specify a normal ping or ping for IOAM capabilities?  Really difficult.
If you cannot filter it, then you may need millions of connections to filter the nodes in the white list, since HMAC is for P2P connection.

So if you want to use HMAC to allow some nodes to visit a node, then you may be wrong in this case. But anyway, good luck.

Hope the IOAM capabilities info is not important, then we don’t really need to care about that. Otherwise, this is not a good idea.

Thanks,
Cheng

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 20, 2020 4:46 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: [email-masked]; [email-masked]; fbrockne=[email-masked]; tpauly=[email-masked]
Subject: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;

I am not going to block your adoption☺.
I am saying that there are some security and privacy risks of this solution. Personally I don’t like the solution, but adopt it or not dependent on the consensus.
<XM>  We think it's good to point to the need addressing security and privacy for a method that retrieves capabilities information from a system. We'd suggest to introduce HMAC TLV or sub-TLV to address your concerns. We'll work on improving Security Considerations section.

Also, I think there are multiple challenges for IOAM in multiple domain scenarios. If we can not get the IOAM capabilities via ICMP PING in these scenarios, then we should do it via in control or management plane, right? Why not just use those methods directly for intra domain and inter domain?
<XM> We believe that IOAM is not intended for multi-domain use. We believe that draft-brockners-opsawg-ioam-deployment<https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment> and others explicitly state that IOAM is applicable in a small domain, specifically a single administrative domain. We understand that rules out the multi-domain scenario.

Thanks,
Cheng

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送时间: 2020年11月19日 13:50
收件人: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>; tpauly=[email-masked]<mailto:tpauly=[email-masked]>
主题: Re:[ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;

Thanks for your reply.

Best,
Cheng

Cc: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>;tpauly=[email-masked]<mailto:tpauly=[email-masked]>

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)

Hi Min,

Thanks,
Cheng

Hello Cheng,

"

   as the "IOAM-Domain".

"

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)

Thanks,
Cheng

Hello IPPM,

* Why can’t we use Netconf/YANG (with the existing capabilities discovery process– a la RFC 6241) to retrieve the IOAM capabilities of IOAM nodes? E.g. the encapsulating node (as a NC client) could retrieve the IOAM capabilities from other IOAM nodes  (acting as a NC server). Plus there is already a YANG model in flight for IOAM (draft-zhou-ippm-ioam-yang-08). At a minimum I would have expected that the draft discusses why NC/YANG is not suitable for the scenario that the authors have in mind. The slides (https://datatracker.ietf.org/meeting/109/materials/slides-109-ippm-echo-requestreply-for-enabled-ioam-capabilities-00) that were presented in the IPPM WG meeting today, mention “Changed from“IOAM Configuration Data” to “Enabled IOAM Capabilities” since the former is too associated with NETCONF/YANG.” IMHO we need a bit more than just wordsmithing.

Thanks, Frank

Hello IPPM,

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Mon, 23 Nov 2020 15:33:01 +0800 (CST)

Hi Cheng,

We co-authors have discussed your comments, please see inline my response tagged with <XM2>.

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)
收件人：肖敏10093570;
日 期 ：2020年11月20日 18:30

Hi Min,

<XM2> No, that's incorrect. HMAC can be used interchangably on a per packet basis.

<XM2> As said before, IOAM can be deployed only in a single administrative domain, IOAM capabilities discovery through ICMPv6 happens only within one IOAM domain.

<XM2> No, that's incorrect. HMAC can be used on a per packet basis, even on a per set of fields basis, that is to say, some specific fields (e.g. Source IP address and IOAM Capabilities TLV) can be selected as the text used to produce the HMAC.

 <XM2> Note that HMAC protects the data integrity but not privacy. Hope that clarifies things a bit.

 

 

Thanks,

Cheng

 

 

 

Hi Cheng,

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

收件人：肖敏10093570;

日 期 ：2020年11月19日 17:00

Hi Min,

 

 

 

 

Thanks,

Cheng

 

 

Hi Cheng,

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

收件人：肖敏10093570;

日 期 ：2020年11月18日 17:01

Hi Min,

Thanks for your reply.

 

 

 

 

Best,

Cheng

 

 

Hi Cheng,

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

日期：2020年11月17日 17:53

 

 

Hi Min,

 

 

 

Thanks,

Cheng

 

 

Hello Cheng,

"

IOAM is a network domain specific feature, with "network domain"    being a set of network devices or entities within a single    administration.  IOAM is not targeted for a deployment on the global    Internet.  The part of the network which employs IOAM is referred to    as the "IOAM-Domain". "

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

抄送人：IPPM Chairs;

日期：2020年11月16日 17:28

 

 

 

Thanks,

Cheng

 

 

 

 To: Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>

Hello IPPM,

 

 

 

Thanks, Frank

From: ippm <[email-masked]>On Behalf OfTommy Pauly

Hello IPPM,

 

 Best,
 Tommy & Ian

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 23 Nov 2020 07:43:16 +0000

I may not state clear?

I am not saying that the HMAC cannot be used for some fields. I am saying the SA of HMAC is for P2P.

Also, I agree with that IOAM should be deployed within a domain, but hackers can get info from the domain.

Cheng

Sent: Monday, November 23, 2020 3:33 PM

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;

Thanks,
Cheng

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>; tpauly=[email-masked]<mailto:tpauly=[email-masked]>

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;

Thanks,
Cheng

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;

Thanks for your reply.

Best,
Cheng

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)

Hi Min,

Thanks,
Cheng

Hello Cheng,

"

   as the "IOAM-Domain".

"

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)

Thanks,
Cheng

Hello IPPM,

Thanks, Frank

Hello IPPM,

Best,
Tommy & Ian

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 23 Nov 2020 07:52:37 +0000

Also, I agree with that IOAM should be deployed within a domain, but hackers can get info out of the domain.

From: ippm [mailto:[email-masked]] On Behalf Of Chengli (Cheng Li)
Sent: Monday, November 23, 2020 3:43 PM
To: [email-masked]
Cc: tpauly=[email-masked]; [email-masked]; fbrockne=[email-masked]; [email-masked]
Subject: Re: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

I may not state clear?

Cheng

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;

Thanks,
Cheng

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;

Thanks,
Cheng

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)
收件人：肖敏10093570;

Thanks for your reply.

Best,
Cheng

Hi Cheng,

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)

Hi Min,

Thanks,
Cheng

Hello Cheng,

"

   as the "IOAM-Domain".

"

Best Regards,

Xiao Min
原始邮件
发件人：Chengli(ChengLi)

Thanks,
Cheng

Hello IPPM,

Thanks, Frank

Hello IPPM,

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Tue, 24 Nov 2020 14:46:44 +0800 (CST)

Hi Cheng,

I don't really understand your statement "the SA of HMAC is for P2P", as explained before, HMAC can be used on a per packet basis, but not on a per node basis.

Among the work of draft-ietf-ippm-stamp-option-tlv, an HMAC TLV is introduced into STAMP Test packets. If needed, similar mechanism can be applied in this use case, the difference is that for STAMP the HMAC is produced by the session-sender and verified by the session-reflector, and for this use case the HMAC is produced by the IOAM encapsulating node and verified by the IOAM transit/decapsulating node.

As to the possibility that hackers may get info out of the IOAM domain, as said before, that's a general issue for IOAM, not specific to this draft. Besides, in my view the IOAM data itself is much more sensitive than the IOAM Capabilities data.

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)
收件人：Chengli (Cheng Li);肖敏10093570;
抄送人：tpauly=[email-masked];[email-masked];fbrockne=[email-masked];[email-masked];
日 期 ：2020年11月23日 15:53
主 题 ：RE: [ippm] Call for adoption: draft-xiao-ippm-ioam-conf-state

 

 

 

I may not state clear?

 

 

Cheng

 

 

Hi Cheng,

 

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

收件人：肖敏10093570;

日 期 ：2020年11月20日 18:30

Hi Min,

 

 

 

 

 

Thanks,

Cheng

 

 

 

Hi Cheng,

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

收件人：肖敏10093570;

日 期 ：2020年11月19日 17:00

Hi Min,

 

 

 

 

Thanks,

Cheng

 

 

Hi Cheng,

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

收件人：肖敏10093570;

日 期 ：2020年11月18日 17:01

Hi Min,

Thanks for your reply.

 

 

 

 

Best,

Cheng

 

 

Hi Cheng,

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

日期：2020年11月17日 17:53

 

 

Hi Min,

 

 

 

Thanks,

Cheng

 

 

Hello Cheng,

"

Best Regards,

Xiao Min

原始邮件

发件人：Chengli(ChengLi)

抄送人：IPPM Chairs;

日期：2020年11月16日 17:28

 

 

 

Thanks,

Cheng

 

 

 

 

Hello IPPM,

 

 

 

Thanks, Frank

 

Hello IPPM,

 

 Best,
 Tommy & Ian