This document has been reviewed as part of the transport area review team’s ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document’s authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.

IOAM collects operational metrics and telemetry data within packets as they traverse the network. This draft defines an optional extension to IOAM that can either either the local collection of metrics or the export of metrics to some external monitoring device. 

A mechanism to trigger local collection of metrics has the potential to cause denial of service on the collecting devices, by exhausting local resources, potentially disrupting operation of that device and forwarding on a particular path, but should not have broader implications.

A mechanism to trigger export of metrics to another device via the network has the potential to enable distributed denial of service and traffic amplification attacks. The draft notes this as potential concern and includes some discussion of the problem and some mechanisms to limit the scope of amplification.

In particular, the draft mandates that rate limiting is implemented on the exported packets, limiting the exporting data rate to 1/N of the interface bandwidth (where N can be configured, but defaults to 100). This limits the amount of traffic that can be generated, but still appears to allow for a significant amplification attack where a single injected IOAM packet can trigger flows up to 1% of link capacity (in the default setting) from on path routers. The provision of a rate limit is therefore important, but I’m concerned that it’s not sufficient to prevent abuse. 

It may be worth considering to require the exporting mechanism to perform an authenticated handshake with the destination to which it will export data, to gain explicit consent to export the data to that destination, before starting to send exported data.  It may also be worth considering to add authentication of IOAM DEX triggers, to ensure they come from a known and trusted source, before acting on export requests.