Subject: Re: [ippm] Adoption call for IOAM deployment and integrity documents

From: Haoyu Song <[email-masked]>
Date: Thu, 12 Aug 2021 17:17:50 +0000

IPPM WG,

After reviewing the drafts, I don't think the integrity draft is ready to be adopted. The reasons are as follows:

  1.  According to the IOAM data draft, IOAM is intended to be used in a limited domain managed by a single operator. If so, the integrity is not necessary. I don't think the discussion is consistent between the docs and clear.

"The current [I-D.ietf-ippm-ioam-data] assumes that IOAM is deployed
   in limited domains, where an operator has means to select, monitor,
   and control the access to all the networking devices, making the
   domain a trusted network.  As such, IOAM tracing data is carried in
   the packets in clear and there are no protections against any node or
   middlebox tampering with the data.  As a consequence, IOAM tracing
   data collected in an untrusted or semi-trusted environments cannot be
   trusted for critical operational decisions.  Any rogue or
   unauthorized change to IOAM data fields in a user packet cannot be
   detected."

  1.  Is there any real implementation and evaluation on the performance impact of the method, especially for the HBH trace option? My experience told me this is not a simple task. Without solid evidence, we may end up with a proposal nobody can actually use.  The purpose of IOAM is to faithfully capture the user-traffic's forwarding behavior and performance. If added functions significantly change the forwarding performance, what's the point to apply it? For this, I suggest to get expert review  from ASIC/NP vendors to give evaluation on feasibility and performance impact.
  2.  The draft suggests to sample packet to apply the integrity protection to mitigate the potential performance impact. This is problematic: (1) depending on the performance difference on the packets with or without protection, significant jitter and out-of-order packet delivery may occur, which is detrimental to the user traffic flow (again, we need evaluation on this); (2) More important, the sampling itself defies the purpose. Antagonists can easily just tamper the unprotected packets. Is it necessary to introduce a heavy method to just provide inadequate and easy-to-elude protection?
  3.  If data integrity becomes a concern, why not data confidentiality? To me, that's more important. At least there are already multiple checksums in the packet to make data tampering difficult. But leaking the data is a more serious threat. Of course, if we insist IOAM would be used just in a limited domain, then none is necessary. My point is: either both are needed or none.
  4.  I'm not sure if it's already done, I suggest to engage some security experts to review this draft. Because this is not a light mechanism, it is very important to make it right before going any further.

Best regards,
Haoyu

From: ippm [mailto:[email-masked]] On Behalf Of Tommy Pauly

Sent: Wednesday, August 4, 2021 12:29 AM

To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:&lt;[email-masked]&gt;>

Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

As discussed in our meeting last week, we will be starting an adoption call for two IOAM-related documents that have been raised as important dependencies during the IESG review of IOAM-data.

This email begins a Working Group adoption call for two documents:

Integrity of In-situ OAM Data Fields

https://datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/

https://www.ietf.org/archive/id/draft-brockners-ippm-ioam-data-integrity-03.html

In-situ OAM Deployment

https://datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/

https://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-03

This call will last until Wednesday, August 18. Please reply to this email with your comments, and if you think these documents should be taken on by IPPM.

Best,

Tommy & Ian