[ippm] Tsvart early review of draft-ietf-ippm-ioam-flags-06
Bernard Aboba via Datatracker <email@example.com> Fri, 03 September 2021 02:20 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0D23A1D71; Thu, 2 Sep 2021 19:20:48 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Bernard Aboba via Datatracker <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org
Reply-To: Bernard Aboba <email@example.com>
Date: Thu, 02 Sep 2021 19:20:48 -0700
Subject: [ippm] Tsvart early review of draft-ietf-ippm-ioam-flags-06
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2021 02:20:49 -0000
Reviewer: Bernard Aboba Review result: Ready with Issues Transport Area Review Team (TSV-ART) Document: draft-ietf-ppm-ioam-flags-06 Reviewer: Bernard Aboba Verdict: Ready with Issues Overall comment The review request indicated: "Please review this document, specifically for security considerations around amplification attacks or similar concerns." Indeed, the amplification attacks do appear to be an important potential issue with the document. In Section 8 it is stated: " IOAM is assumed to be deployed in a restricted administrative domain, thus limiting the scope of the threats above and their affect. This is a fundamental assumtion with respect to the security aspects of" While this is a common argument, it does not impress me, particularly now that security breaches have become so common. So I'd prefer to start from the assumption that the administrative domain will eventually be breached. For example, one might start from the assumption that: 1. An attacker can find a way to inject packets with one or more of the flags defined in the document set to a value of their choosing. 2. An attacker can compromise the firmware load of an IOAM encapsulating node so as to affect execution of the algorithms defined in the document. Then based on these assumptions, see what mitigations can be added to minimize the damage. For example, one might minimize the damage by adding a mandatory-to-implement "circuit breaker". Overall, it seems like the aspect of most concern is the Loopback Flag, which seems like it offers significant magnification potential. Comments on individual sections Section 4.1 The reason for allowing a single data field per hop is to minimize the impact of amplification attacks. [BA] This will be effective if we can assume that nodes are running compliant firmware. But what if an attacker can run firmware of their choosing? What are the mitigations that can be applied by a node if it detects that another node is adding more than one data field per hop? Section 4.1.1 If an IOAM encapsulating node incorporates the Loopback flag into all the traffic it forwards it may lead to an excessive amount of looped back packets, which may overload the network and the encapsulating node. Therefore, an IOAM encapsulating node that supports the Loopback flag MUST support the ability to incorporate the Loopback flag selectively into a subset of the packets that are forwarded by it. [BA] This MUST is a fairly basic capability (e.g. a lot of damage can be done even by nodes obeying this requirement). It seems like more should be required. Various methods of packet selection and sampling have been previously defined, such as [RFC7014] and [RFC5475]. Similar techniques can be applied by an IOAM encapsulating node to apply Loopback to a subset of the forwarded traffic. The subset of traffic that is forwarded or transmitted with a Loopback flag SHOULD NOT exceed 1/N of the interface capacity on any of the IOAM encapsulating node's interfaces. It is noted that this requirement applies to the total traffic that incorporates a Loopback flag, including traffic that is forwarded by the IOAM encapsulating node and probe packets that are generated by the IOAM encapsulating node. In this context N is a parameter that can be configurable by network operators. If there is an upper bound, M, on the number of IOAM transit nodes in any path in the network, then it is recommended to use an N such that N >> M. The rationale is that a packet that includes the Loopback flag triggers a looped back packet from each IOAM transit node along the path for a total of M looped back packets. Thus, if N >> M then the number of looped back packets is significantly lower than the number of data packets forwarded by the IOAM encapsulating node. If there is no prior knowledge about the network topology or size, it is recommended to use N>100. [BA] This is OK as far as it goes. But what happens if a node detects that amplification is occurring somewhere (e.g. another node isn't obeying the SHOULD NOT) Is a circuit breaker triggered? Section 4.2 An IOAM node that supports the reception and processing of the Loopback flag MUST support the ability to limit the rate of the looped back packets. The rate of looped back packets SHOULD be limited so that the number of looped back packets is significantly lower than the number of packets that are forwarded by the device. The looped back data rate SHOULD NOT exceed 1/N of the interface capacity on any of the IOAM node's interfaces. It is recommended to use N>100. Depending on the IOAM node's architecture considerations, the loopback response rate may be limited to a lower number in order to avoid loading the IOAM node. [BA] Here the SHOULD does not seem strong enough to me. If for example, another node is forwarding more than 1/N, and this is detected, shouldn't some mandatory circuit breaker be triggered? Section 5 If the volume of traffic that incorporates the Active flag is large, it may overload the network and the IOAM node(s) that process the active measurement packet. Thus, the rate of the traffic that includes the Active flag rate SHOULD NOT exceed 1/N of the interface capacity on any of the IOAM node's interfaces. It is recommended to use N>100. Depending on the IOAM node's architecture considerations, the rate of Active-enabled IOAM packets may be limited to a lower number in order to avoid loading the IOAM node. [BA] Again, the SHOULD NOT does not seem strong enough to me. I'd suggest that some kind of mandatory circuit breaker should be required. NITs Abstract a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically the the s/the the/the/ Section 8 IOAM is assumed to be deployed in a restricted administrative domain, thus limiting the scope of the threats above and their affect. This is a fundamental assumtion with respect to the security aspects of s/assumtion/assumption/ IOAM, as further discussed in [I-D.ietf-ippm-ioam-data].
- [ippm] Tsvart early review of draft-ietf-ippm-ioa… Bernard Aboba via Datatracker
- Re: [ippm] Tsvart early review of draft-ietf-ippm… Tal Mizrahi