Early Review of draft-ietf-ippm-ioam-direct-export-06
review-ietf-ippm-ioam-direct-export-06-tsvart-early-perkins-2021-09-03-00

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.