Re: [Tsv-art] Tsvart early review of draft-ietf-ippm-ioam-flags-06

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Tue, 14 June 2022 06:33 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA08CC13C2C9; Mon, 13 Jun 2022 23:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8kHULa7w1nD; Mon, 13 Jun 2022 23:33:39 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0383C13C2C2; Mon, 13 Jun 2022 23:33:39 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id y196so7752254pfb.6; Mon, 13 Jun 2022 23:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rj5SDzujlkm+qcnN5QhimR1QploGGQpA6B/IOXdYKJA=; b=qo5/VGSlGfxHrawgRsxaxvoiTf01d/6H5MUjG9a84Zjt/155xg3ao9Osv/stvznxxm hfClnMZYJOh9DTigpvVaoz4FA0Dk3VmwW9hHscnqnhuf0gqbZw1v4pK/cpsjMfMRVoSE X5Zwy36BTnMP2A92Rp70l3pSN/qXSPaAtPDRAG0IP511/agezNQ6g2GttCvsd+iKjBhA Kr/oyR4Y+ZXKjztHllw1zdKasRnpCUzQwaTDcoWeGMFnVpoP8wz0K0kWbMARNx6VNTta kLCQTahv/P7qx7ymfkm9etl0oa3kFb67S+UhjKXvNRrj7dbUwqb45Ve/Qa2a+RoiOxcZ IGGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rj5SDzujlkm+qcnN5QhimR1QploGGQpA6B/IOXdYKJA=; b=4ZYtWYOdgrncBw3jlSCWO9V/qe774XzXbrge6px9VHywZW3muxBrFYO9RDQbLyDQ6C r+BrQ71/QR+Jd78hJdhygrxrIsE5sGprCQhz02deUk7VHL4TuTIVvEe8x0HHhuQ9DXJa gbPdHfTBIpo3q9LQJg+1RvDVUotld1OlISWKKq6MSIZOv68Mw2317sjsQ/T3Wkge81bP k3aWHT6Td4aJu4lKsykLUBgHjR8tWzDzshNXRS4Fwumk/AOX2OP1snhMh98xWSHFOuSV YNLlS/Q+JohWUGOfGk/ZQrCVdJjao4/1t/CT8D8sMYQIDHNcUZHdcxAWDBioovQoTID6 xknw==
X-Gm-Message-State: AJIora821PfyvV7texJdWQxU/Lbx0LjM0tw3ylaJMJMQnYbzQ88k8FL8 Yf4EnXz5Uz2JHDC5ZlHIf+Wr3aUxhyriDH3vjvJRxXLAMwUGYQD8
X-Google-Smtp-Source: AGRyM1v3P5qVL7Nub7WvkDiXkSHP+leMemIfBArUkEzXJ6pMD774p555iLsuHphY/7OhScPSJ6zLg9pIYX4nbHqj8M0=
X-Received: by 2002:a05:6a00:1c5c:b0:505:7469:134a with SMTP id s28-20020a056a001c5c00b005057469134amr2888172pfw.16.1655188418789; Mon, 13 Jun 2022 23:33:38 -0700 (PDT)
MIME-Version: 1.0
References: <163063564823.15336.14662092029682255691@ietfa.amsl.com> <CABUE3XkMnySVLtKx5EDaKGCt39tYhk03a4-8yOkm7Vwgffo1rg@mail.gmail.com>
In-Reply-To: <CABUE3XkMnySVLtKx5EDaKGCt39tYhk03a4-8yOkm7Vwgffo1rg@mail.gmail.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Tue, 14 Jun 2022 09:33:27 +0300
Message-ID: <CABUE3Xkqx83FBtPh-frCLO8AC_-PURyHfn7wu74HnXY_Y9=i6w@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, IPPM Chairs <ippm-chairs@ietf.org>
Cc: tsv-art@ietf.org, draft-ietf-ippm-ioam-flags.all@ietf.org, Martin Duke <martin.h.duke@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/i_N-gucW1aL1ixGP7jXwJQtcKtE>
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-ippm-ioam-flags-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2022 06:33:40 -0000

Hi,

Revisiting this old thread since the document is in IETF last call.
To the best of our knowledge the TSVART comments have been addressed.
Please see the current version of the draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-08

Thanks Bernard for the thorough review.

Cheers,
Tal.

On Sun, Oct 3, 2021 at 3:40 PM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
>
> Dear Bernard,
>
> Many thanks for the thorough review.
>
> Please see the responses and text update suggestions below, marked with [TM].
> Please let us know if there are any further comments.
>
>
> On Fri, Sep 3, 2021 at 5:20 AM Bernard Aboba via Datatracker
> <noreply@ietf.org> wrote:
> >
> > 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".
> >
>
> [TM] You make a valid point regarding the basic assumption and how it
> is described.
> The following text edit is proposed:
> OLD:
>    An attacker may attempt to overload network devices by injecting
>    synthetic packets that include an IOAM Trace Option with one or more
>    of the flags defined in this document.  Similarly, an on-path
>    attacker may maliciously set one or more of the flags of transit
>    packets.
> ...
>    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
>    IOAM, as further discussed in [I-D.ietf-ippm-ioam-data].
> NEW:
>    IOAM is assumed to be deployed in a restricted administrative domain,
>    thus limiting the scope of the threats above and their effect.  This
>    is a fundamental assumption with respect to the security aspects of
>    IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. However,
>    despite this assumption, security threats should still be
>    considered and mitigated. Specifically,
>    an attacker may attempt to overload network devices by injecting
>    synthetic packets that include an IOAM Trace Option with one or more
>    of the flags defined in this document.  Similarly, an on-path
>    attacker may maliciously set one or more of the flags of transit
>    packets.
> ...
> END
>
> Then, the rest of this section (marked by "..." above), as currently
> structured, provides more details about the threats and mitigations.
> The "circuit breaker" sounds like it may create a DoS threat. The
> currently proposed mitigation methods are intended to limit the impact
> of a potential attack, but not to "break" anything.
>
> > 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?
> >
>
> [TM] Right. Suggested text:
> OLD:
>    An IOAM trace option that has the Loopback flag set MUST have the
>    value '1' in the most significant bit of IOAM-Trace-Type, and '0' in
>    the rest of the bits of IOAM-Trace-Type.  Thus, every transit node
>    that processes this trace option only adds a single data field, which
>    is the Hop_Lim and node_id data field.  The reason for allowing a
>    single data field per hop is to minimize the impact of amplification
>    attacks.
> NEW:
>    An IOAM trace option that has the Loopback flag set MUST have the
>    value '1' in the most significant bit of IOAM-Trace-Type, and '0' in
>    the rest of the bits of IOAM-Trace-Type.  Thus, every transit node
>    that processes this trace option only adds a single data field, which
>    is the Hop_Lim and node_id data field. A transit node that receives
>    a packet with an IOAM trace option that has the Loopback flag set
>    and the IOAM-Trace-Type is not equal to '1' in the most significant
>    bit and '0' in the rest of the bits, MUST NOT loop back a copy of
>    the packet. The reason for allowing a
>    single data field per hop is to minimize the impact of amplification
>    attacks.
>
>
> > 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.
>
> [TM] Right, and the rest of Section 4.1.1. indeed specifies more
> functionality that mitigates these amplification attacks.
>
> >
> >    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?
> >
>
> [TM] In order for a node to detect that another node is malfunctioning
> some stateful monitoring functionality is required. We currently do
> not require this functionality, although an operator may choose to use
> various counters with threshold-based notifications to the management
> plane in specific locations in the network in order to detect such
> functionality. Not sure it would be useful to describe this in the
> document, as it seems like common practice.
>
> > 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.
>
>
> [TM] Regarding the last two comments, as mentioned above, we do not
> require an IOAM transit node to be able to detect when another IOAM
> node does not limit its rate. The assumption is that given that there
> *is* an attacker, the current node limits its rate in order to limit
> the impact of the attack and avoid amplifying the attack. However, the
> current node does not necessarily implement any monitoring or
> intrusion detection that reports potential attacks.
>
> >
> > 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/
>
> [TM] Will be fixed.
>
> >
> > 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/
>
> [TM] Will be fixed.
>
> >
> >    IOAM, as further discussed in [I-D.ietf-ippm-ioam-data].
> >
> >
> >
>
> Thanks,
> Tal.