From nobody Thu Mar 25 14:09:48 2021 Return-Path: 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 BE8593A00D3; Thu, 25 Mar 2021 14:09:42 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK3SmXRtGLlC; Thu, 25 Mar 2021 14:09:40 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 991303A00C4; Thu, 25 Mar 2021 14:09:39 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id c17so3326231ilj.7; Thu, 25 Mar 2021 14:09: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=5gDZkRBpGh5XrzjPh5vO/bBOeglWiD6bmJ0/16g9FrI=; b=m81i8dc2iCf12+DDCJxyNWM5HDMcgSHesM5ZNSlO98g37FebQSh/JcI+WjSI1Kbm2l Y5qr5yngYN8G3LI5z03nFPX/VaY/Bg0QPaiI2Sg7hsB/BbzsLcg3/VxRwgaENFKh6ucc +2Cc9UXJMDsekK5nPL1i632hP+pyMtkjoHquU/X5+v+rxMxkzNVbeoinf9v2bLaqiWVJ PPQxhQ+nCnjtuhmm/PgkUS3k0oosLo4cFLIpurYz30IHjmZbyalLs3KeMZu53rWugEWs cBjhAUo8sMSIPFalu/1vxpCmDWTXG06YuD8cNK7xoWZ/eDEeVIzjAsJSllUnNHXnHudj B56w== 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=5gDZkRBpGh5XrzjPh5vO/bBOeglWiD6bmJ0/16g9FrI=; b=Wzkmj4EkWAh6XlxLI/P4PzFAUHmekK1ZFdiD2xUjsTco63jK8yW0auncwQOkpdLknA 5fQ0iO55zkzAiX1BF6vQzM/EcOcpOOSrKrJ4GRQQqeDoanCJ0yqNFwvRqObtnk+SQB/k 1zINoZhgJfJL2gzBVdwvYcSfxHkIKyUkq5dT3uGKxKrCAvdnyIXAHg0lIcEo1N9RtI/B IClGxdx6AdKndJjpdUsHqoiqgm1J7tlh/HGS0l8i1AuEr7ihOfPH4etom/yuN5VY9Z0F 0lNkGnIORTz6lu6e+Kv2uyGHfW2g/5jF8cNMmvK03odQCjEPX7nyscW8JcxonvHUPmg/ Ak0Q== X-Gm-Message-State: AOAM533psmHXVzPKfzHT43sEfuWcsdQXDX3pEdkeEgPDEOlhLilPwDIs uwh6/80jklN3QkjKJkJRIgc8pTBEiTyL6cAm5+Y= X-Google-Smtp-Source: ABdhPJxkDj/uXIO46ulxKObxrT06/LeylGa7O/+EGIbmNI2w7h/gjnNdTeyvihV5ZwHIb74zgvFbdfP4QrOgXymvLrs= X-Received: by 2002:a92:ca4b:: with SMTP id q11mr8335348ilo.272.1616706577962; Thu, 25 Mar 2021 14:09:37 -0700 (PDT) MIME-Version: 1.0 References: <161659835537.18895.9718541717885407286@ietfa.amsl.com> In-Reply-To: <161659835537.18895.9718541717885407286@ietfa.amsl.com> From: Martin Duke Date: Thu, 25 Mar 2021 14:09:27 -0700 Message-ID: To: Roman Danyliw Cc: The IESG , "MORTON, ALFRED C (AL)" , IPPM Chairs , draft-ietf-ippm-ioam-data@ietf.org, IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000491eb405be62d529" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 21:09:43 -0000 --000000000000491eb405be62d529 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One minor correction: the Direct Export draft has, in fact, been adopted by IPPM: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ On Wed, Mar 24, 2021 at 8:06 AM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > 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. > =E2=80=A6 > 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: =E2=80=A6 > 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. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Shawn Emery for the SECDIR review. > > I support Ben Kaduk=E2=80=99s DISCUSS position. > > ** Section 4. Per the scope of =E2=80=9CIOAM is a network domain focused= feature, > with > =E2=80=98network domain=E2=80=99 being a set of network devices or entiti= es within a single > administration=E2=80=9D and the implicit trust model, the more precise te= xt seems > to be > a s/a set of network devices/a set of trusted network devices/. > > ** Section 10. To the end of the first paragraph, =E2=80=9CAll nodes in = the path > of a > IOAM carrying packet can perform such an attack=E2=80=9D. > > ** 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. > > ** 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=E2=80=99t clear. Perhaps= the > intent of > the second sentence is that configurations should only managed by > authorized > processes or users? > > ** Section 10. Please note that IOAM fields could introduce the > possibility of > a per-packet cover channel > > ** Editorial nits: > Section 4. Typo. s/using,for/using, for/ > > Section 10. Editorial. s/Section Section 5.5/Section 5.5/ > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000491eb405be62d529 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One minor correction: the Direct Export draft has, in fact= , been adopted by IPPM: https://datatracker.ietf.org/doc/draft-ietf-i= ppm-ioam-direct-export/

On Wed, Mar 24, 2021 at 8:06 AM Roman Danyliw vi= a Datatracker <noreply@ietf.org&= gt; wrote:
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/s= tatement/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-ie= tf-ippm-ioam-data/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please clarify what constitutes the edge or boundary of the IOAM domain. Consider:

(a) Section 4.
IOAM is a
=C2=A0 =C2=A0network domain focused feature, with "network domain"= ; being a set of
=C2=A0 =C2=A0network devices or entities within a single administration. =E2=80=A6
Designers of
=C2=A0 =C2=A0protocol encapsulations for IOAM specify mechanisms to ensure = that
=C2=A0 =C2=A0IOAM data stays within an IOAM domain.=C2=A0 In addition, the = operator of
=C2=A0 =C2=A0such a domain is expected to put provisions in place to ensure= that
=C2=A0 =C2=A0IOAM data does not leak beyond the edge of an IOAM domain.

(b) Section 5.3.
Namespace identifiers allow devices which are IOAM capable to
=C2=A0 =C2=A0determine: =E2=80=A6
whether IOAM-Option-Type(s) has to be removed from the packet,
=C2=A0 =C2=A0 =C2=A0 e.g. at a domain edge or domain boundary.

(a) suggests that the filtering occurs on the basis of the single
administrative domain.=C2=A0 However, (b) suggests that namespace identifie= rs are
part of the filtering decision; which suggests that sub-domains can be crea= ted
in a given domain which should be partitioned from each other.

The Security Considerations should be clearer on who does the IOAM informat= ion
filtering, on what criteria and on what boundary.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Shawn Emery for the SECDIR review.

I support Ben Kaduk=E2=80=99s DISCUSS position.

** Section 4.=C2=A0 Per the scope of =E2=80=9CIOAM is a network domain focu= sed feature, with
=E2=80=98network domain=E2=80=99 being a set of network devices or entities= within a single
administration=E2=80=9D 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/.

** Section 10.=C2=A0 To the end of the first paragraph, =E2=80=9CAll nodes = in the path of a
IOAM carrying packet can perform such an attack=E2=80=9D.

** Section 10.=C2=A0 It is not clear why the "Direct Exporting" m= ode, a reference an
unadopted I-D, is being referenced here and then consideration for it is no= ted
as out of scope.

** Section 10
=C2=A0 =C2=A0At the management plane, attacks can be set up by misconfiguri= ng or
=C2=A0 =C2=A0by maliciously configuring IOAM-enabled nodes in a way that en= ables
=C2=A0 =C2=A0other attacks.=C2=A0 Thus, IOAM configuration has to be secure= d in a way
=C2=A0 =C2=A0that authenticates authorized users and verifies the integrity= of
=C2=A0 =C2=A0configuration procedures.

The link to authenticating authorized users isn=E2=80=99t clear.=C2=A0 Perh= aps the intent of
the second sentence is that configurations should only managed by authorize= d
processes or users?

** Section 10.=C2=A0 Please note that IOAM fields could introduce the possi= bility of
a per-packet cover channel

** Editorial nits:
Section 4. Typo. s/using,for/using, for/

Section 10.=C2=A0 Editorial. s/Section Section 5.5/Section 5.5/



_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--000000000000491eb405be62d529--