Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

Martin Duke <martin.h.duke@gmail.com> Tue, 27 April 2021 21:18 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0381B3A20F8; Tue, 27 Apr 2021 14:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3auH2r4R8d5; Tue, 27 Apr 2021 14:18:40 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7983A20F9; Tue, 27 Apr 2021 14:18:39 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id z14so8515116ioc.12; Tue, 27 Apr 2021 14:18:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QY1+QsiFNFDJO2N5v8HO/tblN/pmqxNdJ17695rgmFQ=; b=nnjFIJ/SzDxVf76XiTS1qFrt6EHALZEOtHbfeyFZpts8NmmsHRM97SUZF6xKfSHJ04 VvlAXa47bPJ4OTucxK8i9gO0LsVWJ+tppKuiSJ7x2MQfW3DM+ZACcy51AHElspjEP7ar QX/tXUDI8dGvUBd9SAFapf6WIyPK9mx5518Jyn1c6Q/3zX5+AfraS2HzUQ1Qgj+gz43f jV5HcXCf7P0F0tABqBQM8cPHhSHtAzZiYSu/7KqoF6YKKq3ya59xI8MxSoC4zY7k5iNT Vh17HNkqM9opU19z+fLHqcmwxkn1U40FtdZHpUzxdDS5emikc/TK2XSmfS5yxAppS0AI d0yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QY1+QsiFNFDJO2N5v8HO/tblN/pmqxNdJ17695rgmFQ=; b=AyaOa43pUaONJA24WHDNRc8eLXBH4p0u6W0dm9kP3sAIak8/O7mfVl4eOdXpjnrswf SF8h6nIGm2vfx3646QMlzA7m6UX9HcgwyVoScqSabW9jqziVfQSoXpkZS5hIL72o9m9N iJVNAzS7RKuH1bgQWNJUjYN9Rd9tednloXT49VFKQpjipEdhFZprAzcLWWFSVn26RbdB jOMa8q4n3LoTXcTLiE16nRqqcdCwpfDTgQ+ElXMdVQ5AzI1VopN4CU01uI5dijhRyMtd aIfiNO+JJdVA55icMfzolnNPL/2r8cROXPF5gym9/qbME3QvRoxGsTpubSk16lgUhWfo fnvA==
X-Gm-Message-State: AOAM530R0af4MlIbBjE5RDVVRask+mmdWotl/b3IL6w/2OGZCpO/JJPa zhd9n/Gb5GMeX5IZtYmCqpnm/sscS7u35S1e7k8=
X-Google-Smtp-Source: ABdhPJzscb/e3PvNTBzA9obAL9y0QBVuD89SQJ49ieOvXzj+x3IGttUnbYC9dTsfzoCTXy7VyB0WYc1CFpbHrej0re4=
X-Received: by 2002:a02:9f01:: with SMTP id z1mr23962574jal.95.1619558316480; Tue, 27 Apr 2021 14:18:36 -0700 (PDT)
MIME-Version: 1.0
References: <161659835537.18895.9718541717885407286@ietfa.amsl.com> <BYAPR11MB25840FD7338E2C066DD9312CDA429@BYAPR11MB2584.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB25840FD7338E2C066DD9312CDA429@BYAPR11MB2584.namprd11.prod.outlook.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 27 Apr 2021 14:18:26 -0700
Message-ID: <CAM4esxRrqSdr_amnz1Qxyjsm4Hh2HbChHkP_fRYuGq8L06gkow@mail.gmail.com>
To: "Frank Brockners (fbrockne)" <fbrockne=40cisco.com@dmarc.ietf.org>
Cc: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>, Al Morton <acm@research.att.com>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000025a06505c0face6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/FnQcS0gx2ggvvpj40cDb2J0Z368>
Subject: Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2021 21:18:44 -0000

I guess the question is whether the ops draft should be a normative
reference?

On Mon, Apr 26, 2021 at 8:38 AM Frank Brockners (fbrockne) <fbrockne=
40cisco.com@dmarc.ietf.org> wrote:

> Hi Roman,
>
> Thanks a lot for your review - and sorry for the delay in responding.
> Please see inline ("..FB").
>
> > -----Original Message-----
> > From: Roman Danyliw via Datatracker <noreply@ietf.org>
> > Sent: Mittwoch, 24. März 2021 16:06
> > To: The IESG <iesg@ietf.org>
> > Cc: draft-ietf-ippm-ioam-data@ietf.org; ippm-chairs@ietf.org;
> ippm@ietf.org;
> > Al Morton <acm@research.att.com>om>; acm@research.att.com
> > Subject: Roman Danyliw's Discuss on draft-ietf-ippm-ioam-data-12: (with
> > DISCUSS and COMMENT)
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-ippm-ioam-data-12: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Please clarify what constitutes the edge or boundary of the IOAM domain.
> > Consider:
> >
> > (a) Section 4.
> > IOAM is a
> >    network domain focused feature, with "network domain" being a set of
> >    network devices or entities within a single administration.
> > …
> > Designers of
> >    protocol encapsulations for IOAM specify mechanisms to ensure that
> >    IOAM data stays within an IOAM domain.  In addition, the operator of
> >    such a domain is expected to put provisions in place to ensure that
> >    IOAM data does not leak beyond the edge of an IOAM domain.
> >
> > (b) Section 5.3.
> > Namespace identifiers allow devices which are IOAM capable to
> >    determine: …
> > whether IOAM-Option-Type(s) has to be removed from the packet,
> >       e.g. at a domain edge or domain boundary.
> >
> > (a) suggests that the filtering occurs on the basis of the single
> administrative
> > domain.  However, (b) suggests that namespace identifiers are part of the
> > filtering decision; which suggests that sub-domains can be created in a
> given
> > domain which should be partitioned from each other.
> >
> > The Security Considerations should be clearer on who does the IOAM
> > information filtering, on what criteria and on what boundary.
>
>
> ...FB: Eric already suggested in his review that we refer to RFC 8799 and
> an IOAM domain classifies as a "Limited Domain" per RFC 8799, which we plan
> to do for the next revision.
> And per your comment, namespaces can indeed be used for further
> segmentation of the single administrative domain.
>
> Given that draft-ietf-ippm-ioam-data is focused on the definition of
> data-fields, we created a "sister" document, which is to discuss all
> deployment related aspects of IOAM: draft-brockners-opsawg-ioam-deployment
> (we're working on an updated version as we speak). Domains and nodes are
> discussed in section 3, see
> https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment-02#section-3.
> With regards to filtering at the edge of the administrative domain,
> draft-brockners-opsawg-ioam-deployment states the following
>
>    The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating
>    node is always performed within a specific IOAM-Namespace.  This
>    means that an IOAM node which is e.g. an IOAM-decapsulating node for
>    IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove
>    the IOAM-Option-Types for IOAM-Namespace "A" from the packet.  An
>    IOAM decapsulating node situated at the edge of an IOAM domain
>    removes all IOAM-Option-Types and associated encapsulation headers
>    for all IOAM-Namespaces from the packet.
>
> Does this clarify things? And if so, are you ok to keep "data fields
> definition" and "deployment aspects" separated in the two different
> documents? Otherwise, we would need to create redundancies between the
> documents, which are a bit hard to keep in synch.
>
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you to Shawn Emery for the SECDIR review.
> >
> > I support Ben Kaduk’s DISCUSS position.
> >
> > ** Section 4.  Per the scope of “IOAM is a network domain focused
> feature, with
> > ‘network domain’ being a set of network devices or entities within a
> single
> > administration” and the implicit trust model, the more precise text
> seems to be a
> > s/a set of network devices/a set of trusted network devices/.
>
> ...FB: Thanks. We'll include the update in the next revision.
>
> >
> > ** Section 10.  To the end of the first paragraph, “All nodes in the
> path of a
> > IOAM carrying packet can perform such an attack”.
>
>
> ...FB: Thanks. We'll include this addition in the next revision.
>
> >
> > ** Section 10.  It is not clear why the "Direct Exporting" mode, a
> reference an
> > unadopted I-D, is being referenced here and then consideration for it is
> noted as
> > out of scope.
>
> ...FB: The reference to "direct exporting" draft is outdated. Sorry. The
> draft is already WG adopted in IPPM:
> https://tools.ietf.org/html/draft-ietf-ippm-ioam-direct-export-03
>
> >
> > ** Section 10
> >    At the management plane, attacks can be set up by misconfiguring or
> >    by maliciously configuring IOAM-enabled nodes in a way that enables
> >    other attacks.  Thus, IOAM configuration has to be secured in a way
> >    that authenticates authorized users and verifies the integrity of
> >    configuration procedures.
> >
> > The link to authenticating authorized users isn’t clear.  Perhaps the
> intent of the
> > second sentence is that configurations should only managed by authorized
> > processes or users?
>
> ....FB: The sentence indeed sounds a bit confusing and is difficult to
> decode. It is to say exactly what you describe.
> Suggest that we update to "IOAM configurations should only managed by
> authorized processes or users" in the next revision.
>
> >
> > ** Section 10.  Please note that IOAM fields could introduce the
> possibility of a
> > per-packet cover channel[] .
>
> ...FB: Good point. We'll add this to the next revision.
>
> >
> > ** Editorial nits:
> > Section 4. Typo. s/using,for/using, for/
> >
> > Section 10.  Editorial. s/Section Section 5.5/Section 5.5/
> >
>
> ...FB: Thanks. Good catches.
>
> Thanks again for your review, Frank
>
>