Subject: [Last-Call] FW: [ippm] Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard

From: Haoyu Song <[email-masked]>
Date: Tue, 24 Nov 2020 19:08:08 +0000

I agree most parts of the draft is relatively mature and below are some comments. 

1. In the abstract, " In-situ OAM data fields can be encapsulated into a variety of
   protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension
   header), or IPv4."  Given none of these has been standardized, it seems improper to
give such a statement. 

2. When applying IOAM for multicast traffic, we identified some issues that are not handled well
by the current IOAM specification and may need some modifications to it. Details can be found in  https://tools.ietf.org/html/draft-song-multicast-telemetry-06

Best regards,
Haoyu

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of The IESG
Sent: Tuesday, November 24, 2020 10:24 AM
To: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [ippm] Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard

The IESG has received a request from the IP Performance Measurement WG (ippm) to consider the following document: - 'Data Fields for In-situ OAM'
  <draft-ietf-ippm-ioam-data-11.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2020-12-08. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in the packet while the packet
   traverses a path between two points in the network.  This document
   discusses the data fields and associated data types for in-situ OAM.
   In-situ OAM data fields can be encapsulated into a variety of
   protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension
   header), or IPv4.  In-situ OAM can be used to complement OAM
   mechanisms based on e.g.  ICMP or other types of probe packets.

The file can be obtained via
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-data%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbbb0146bf7a147e51d6508d890a658ec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637418391415318993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2BUFaTczHikH8kYqdi%2F3CmLMgYbtpHp8%2Ferd0ihEbnIU%3D&amp;reserved=0

The following IPR Declarations may be related to this I-D:

   https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2F3526%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbbb0146bf7a147e51d6508d890a658ec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637418391415318993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ncOk8%2F%2FAswOanSp3FQSnquqZJasbhwPGNUiAjK%2FPbTY%3D&amp;reserved=0

_______________________________________________
ippm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbbb0146bf7a147e51d6508d890a658ec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637418391415318993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6PjMoFSxmg4YogDTNuSP%2FgUjfWyqNruCs%2BWCfchz%2BSk%3D&amp;reserved=0

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Nov 2020 13:30:31 -0800

Dear All,
I have several comments related to the security aspects of this
specification:

   - although this draft does not define network-specific encapsulation of
   IAOM data, it would the right place to introduce a generic method of IAOM
   data integrity protection. As noted in the Security Considerations section,
   IOAM trace options and collected information may become the target of a
   malicious attack. Protecting the integrity of data with HMAC seems like the
   right option. It seems reasonable that the text used to calculate HMAC
   includes in addition to the IOAM trace option header and an IOAM node data
   field that uniquely identify the source of the packet that includes IOAM
   trace. For example, in an IP network, the IP source address can be
   concatenated with the IAOM trace option header. The integrity of each IAOM
   node data record can also be protected by HMAC. The data record can be
   concatenated with, for example, the IOAM option header to form the text
   used in the calculation of the HMAC. While the detailed construction of the
   text used in HMAC calculation could be provided in network-specific
   documents, it seems appropriate to require the optional use of HMAC for the
   integrity protection of the IOAM option header and IOAM data record in this
   document.
   - I have some concern over using the Checksum Complement in the IPv6
   network. RFC 6936 provided us with the most detailed analysis for using
   zero UDP checksum in the IPv6 network. As I understand the purpose of the
   Checksum Complement, its security impact is similar to the one of using
   zero UDP checksum. I think that the use of Checksum Complement in the IPv6
   network should be explicitly discussed in the document. I'd recommend
   adding the reference to RFC 6936 and provide arguments supporting the use
   of the Checksum Complement in the IPv6 network.

Regards,
Greg

On Tue, Nov 24, 2020 at 10:25 AM The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the IP Performance Measurement WG
> (ippm)
> to consider the following document: - 'Data Fields for In-situ OAM'
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-12-08. Exceptionally, comments
> may
> be sent to [email-masked] instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
>
>
>    https://datatracker.ietf.org/ipr/3526/
>
>
>
>
>
>
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 25 Nov 2020 11:56:13 +0200

Hi Greg,

Thanks for the comments.
Please see my comments below, marked [TM].

Thanks,
Tal.

On Tue, Nov 24, 2020 at 11:30 PM Greg Mirsky <[email-masked]> wrote:
>
> Dear All,
> I have several comments related to the security aspects of this specification:
>
> although this draft does not define network-specific encapsulation of IAOM data, it would the right place to introduce a generic method of IAOM data integrity protection. As noted in the Security Considerations section, IOAM trace options and collected information may become the target of a malicious attack. Protecting the integrity of data with HMAC seems like the right option. It seems reasonable that the text used to calculate HMAC includes in addition to the IOAM trace option header and an IOAM node data field that uniquely identify the source of the packet that includes IOAM trace. For example, in an IP network, the IP source address can be concatenated with the IAOM trace option header. The integrity of each IAOM node data record can also be protected by HMAC. The data record can be concatenated with, for example, the IOAM option header to form the text used in the calculation of the HMAC. While the detailed construction of the text used in HMAC calculation could be provided in network-specific documents, it seems appropriate to require the optional use of HMAC for the integrity protection of the IOAM option header and IOAM data record in this document.

[TM] Integrity protection is an important security consideration.
Thanks to your previous comments about this issue we have added the
following text to the security considerations section:

   In particular, these threats are applicable by compromising
   the integrity of IOAM data, either by maliciously modifying IOAM
   options in transit, or by injecting packets with maliciously
   generated IOAM options

Specifically, implementing HMAC by hardware devices such as switches
and routers in wire speed may be challenging.
My feeling is that even if we decided to define an HMAC, it would end
up being something that is not implemented by most vendors.

I would suggest to consider a new IOAM option that incorporates an
HMAC, which can be used alongside the conventional trace options. This
would allow an optional integrity protection capability for those
specific implementations that require it. This new option could be
defined in a new draft, allowing the data draft to proceed to
publication.

> I have some concern over using the Checksum Complement in the IPv6 network. RFC 6936 provided us with the most detailed analysis for using zero UDP checksum in the IPv6 network. As I understand the purpose of the Checksum Complement, its security impact is similar to the one of using zero UDP checksum. I think that the use of Checksum Complement in the IPv6 network should be explicitly discussed in the document. I'd recommend adding the reference to RFC 6936 and provide arguments supporting the use of the Checksum Complement in the IPv6 network.

[TM] The Checksum Complement is a field that simplifies the checksum
update for hardware switches/routers. Unlike zero checksum, the
destination *does* verify the checksum when a checksum complement is
used. Therefore, in my opinion the zero checksum considerations are
not relevant in this context.
>From a security perspective, I do not think a Checksum Complement has
any security implications. I believe it was phrased well in RFC 7820
(OWAMP/TWAMP Checksum Complement):

   It is important to emphasize that the scheme described in this
   document does not increase the protocol's vulnerability to MITM
   attacks; a MITM attacker who maliciously modifies a packet and its
   Checksum Complement is logically equivalent to a MITM attacker who
   modifies a packet and its UDP Checksum field.

>> The IESG has received a request from the IP Performance Measurement WG (ippm)
>> [email-masked] mailing lists by 2020-12-08. Exceptionally, comments may
>> be sent to [email-masked] instead. In either case, please retain the beginning

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 26 Nov 2020 12:14:42 -0800

Hi Tal,
thank you for your careful consideration of my comments and detailed
responses. Please find my follow-up notes in-line below under the GIM>> tag.

Regards,
Greg

On Wed, Nov 25, 2020 at 1:56 AM Tal Mizrahi <[email-masked]>
wrote:

> > although this draft does not define network-specific encapsulation of
GIM>> I appreciate the proposed text but am not convinced that the
limitations of the current HW platforms are a factor that should limit our
definition of the comprehensive and secure protocol. I agree, there's
always a difference between the specification of a protocol and its
implementation. How a vendor decides to implement and how an operator
chooses to deploy the protocol is outside of our control as a group the
defines the protocol specification. But I believe that the proper protocol
specification must include security mechanisms that protect data integrity.
Whether the protocol also protects the privacy of the data or relies on the
security mechanisms outside of the protocol, in my opinion, is an open
question but it should be explained in the protocol specification.

> defined in a new draft, allowing the data draft to proceed to
GIM>> I think that proceeding without addressing the essential security
issue of the protocol might be premature and may produce implementations
that are vulnerable to attacks.

>
>
> > I have some concern over using the Checksum Complement in the IPv6
GIM>> As I recall, one of the reasons RFC 7820 was published as
Experimental was concern about the security impact of the proposed
mechanism. If my recollection of the discussion of the security impact RFC
7820 may have in a network is accurte, I'll maintain my concern regarding
the Checksum Complement option in IOAM.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 27 Nov 2020 21:11:14 -0800

Hi Greg, Tal,

> that are vulnerable to attacks.

Thanks for raising this topic.

Based on the discussion so far and skimming the first few sections of the
draft, I expect that I would put a discuss ballot in to ensure the
availability of a security mechanism such as this, which in effect would
negate the intent to "allow the data draft to proceed to publication".
That said, my stance could change as the thread continues or when I take a
closer look at the whole document, so it is okay (from my point of view) if
you (Tal) choose to wait and see if this does end up being a discuss point.
That said, I'd of course prefer if you and Greg can find a solution and get
it into place now :)

Thanks,

Ben