Re: [Ippm-ioam-ix-dt] IOAM DEX: Suggested Text to Address Security Concerns

[Greg Mirsky <[e-mail]>]

Hi Tal,
thank you for preparing and sharing the updated text. I have several
comments to the proposed new text. Please kindly find them in-lined below
under the GIM>> tag.

Regards,
Greg

On Mon, Apr 5, 2021 at 6:26 AM Tal Mizrahi <[e-mail]>
wrote:

> Hi,
>
> In response to the security concerns that were raised in IETF 110, I
> would like to propose the text edits below. I am raising this for
> discussion before I actually update the document.
>
> Comments will be welcomed.
>
> Thanks,
> Tal.
>
> OLD:
> <t>As in <xref target="I-D.ietf-ippm-ioam-data"/>, the DEX option
> may be incorporated into all or a subset of the traffic that is
> forwarded by the encapsulating node. Moreover, IOAM nodes MAY
> export data for all traversing packets that carry the DEX
> option, or MAY selectively export data only for a subset of these
> packets.</t>
>
> NEW:
> <t>As in <xref target="I-D.ietf-ippm-ioam-data"/>, the DEX option
> can be incorporated into all or a subset of the traffic that is
>
GIM>> I agree that DEX, like any other IOAM Trace-Option, can be applied
"into all or a subset of the traffic". By stressing that for the DEX, would
the document leave outside other IAOM Trace Options?

> forwarded by the encapsulating node, as further discussed in
> <xref target="SelectionSec"/> below. Moreover, IOAM nodes either
> export data for all traversing packets that carry the DEX
> option, or selectively export data only for a subset of these
> packets, as further discussed in <xref target="ExportSec"/> below.</t>
>
GIM>> I think that the input from the discussion at IETF-110 was that an
intermediate IOAM node MUST control the rate of exported packets with IOAM
telemetry information. If my understanding is correct, shouldn't the new
text express that?

>
>
> OLD:
>
> NEW:
>
> <section anchor="SelectionSec" title="DEX Packet Selection">
>
> <t>If an IOAM encapsulating node incorporates the DEX option into all
> the traffic it forwards it may lead to an excessive amount of exported
> data, which may overload the network and the receiving entity.
>
GIM>> I think that this is technically accurate for not only DEX but IOAM
in general as a hybrid measurement method. Would you agree? In fact, the
impact of using DEX could be mitigated by using lower CoS when exporting
IOAM telemetry information.

> Therefore, IOAM nodes SHOULD incorporate the DEX option selectively
> into a subset of the packets that are forwarded through them.</t>
>
> <t>Various methods of packet selection or sampling have been previously
> defined, such as <xref target="RFC7014"/> or <xref target="RFC5475"/>.
> Similar techniques can be applied by an IOAM encapsulating node to
> apply DEX to a subset of the forwarded traffic.</t>
>
> <t>The subset of traffic that is forwarded or transmitted with a DEX
> option SHOULD not exceed 1/N of the interface capacity on any of
> the IOAM encapsulating node's interface. It is noted that this
> requirement applies to the total traffic that incorporates a DEX option,
> 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 MAY be configurable by network
> operators. If M is an upper bound 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. If there is no prior knowledge about
> the network topology or size, it is RECOMMENDED to use N>100.</t>
>
GIM>> I agree with the proposed text. I think that it should be part of
draft-ietf-ippm-ioam-data and the DEX will just inherit it. What do you
think?

> </section>
>
>
> OLD:
> <t>The DEX option specifies which data fields should be exported,
> as specified in <xref target="OptionSec"/>.
> The format and encapsulation of the packet that contains the exported
> data is not within the scope of the current document. For example,
> the export format can be based on
> <xref target="I-D.spiegel-ippm-ioam-rawexport"/>.</t>
>
> NEW:
>
> <section anchor="ExportSec" title="Exporting">
>
> <t>The DEX option specifies which data fields should be exported,
> as specified in <xref target="OptionSec"/>.
> The format and encapsulation of the packet that contains the exported
> data is not within the scope of the current document. For example,
> the export format can be based on
> <xref target="I-D.spiegel-ippm-ioam-rawexport"/>.</t>
>
> <t>An IOAM node that performs DEX exporting MUST send the exported data
> to a pre-configured trusted receiving entity.</t>
>
GIM>> This requirement might be too restrictive. An exporting node and the
collector could use methods to protect the privacy and integrity of the
IOAM information. Exporting to a trusted system could be one of several
solutions. The text could mention it as an example. The requirement is to
protect the privacy and integrity of IOAM data.

>
> <t>An IOAM node that performs DEX exporting SHOULD limit the rate of the
> exported packets so that it does not exceed 1/N of the interface capacity
> on any of the IOAM node's interfaces. As in the previous section, it
> is RECOMMENDED to use N>100.</t>
>
GIM>> I think that the support of a rate-limiting mechanism is a
requirement rather than a recommendation.

>
> <t>Exported packets SHOULD not be exported over a path or a tunnel that is
> subject to IOAM direct exporting. This requirement is intended to prevent
> nested exporting and/or exporting loops.</t>
>
GIM>> I think that this recommendation is based on the assumption that
exported traffic uses the same resource as data. Besides, I couldn't find
the definition of "IOAM direct exporting". Will much appreciate it if you
can refer me to where it is defined.

> </section>
>
> --
> Ippm-ioam-ix-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm-ioam-ix-dt
>