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

From: Tal Mizrahi <[email-masked]>
Date: Mon, 5 Apr 2021 16:26:13 +0300

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
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>

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.
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>
</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>

<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>

<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>
</section>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 5 Apr 2021 16:45:23 +0000

Hi Tal,

Thanks for preparing the updates! I only have a few questions on the parameter N.
If we want to provide a parameter N, we may need to describe how it can be enforced. For example, 1/N may be a time average capacity, but what's the time interval then? If the time interval is large, then the DEX export traffic may still raise the concerns of  overload due to the bursts.
Also, you suggest N >> M and N >100 if M is unknown. What's the rationale behind these selections?  How much is considered ">>"?

I think another way to avoid network/bandwidth overload due to DEX is that a node can decide by itself to process or not process a packet with DEX option based on its local traffic condition. This can certainly cause the loss of some export data for some packet with DEX option, but it's adaptive to the local condition. Combining this with the head node selection rate limiting, we can fully address the overloading concern.  

Thanks!
Haoyu
-----Original Message-----
From: Ippm-ioam-ix-dt <[email-masked]> On Behalf Of Tal Mizrahi
Sent: Monday, April 5, 2021 6:26 AM
To: [email-masked]
Subject: [Ippm-ioam-ix-dt] IOAM DEX: Suggested Text to Address Security Concerns

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.

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 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>

OLD:

NEW:

<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.
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> </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:

<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>

<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>

<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> </section>

--
Ippm-ioam-ix-dt mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm-ioam-ix-dt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C35045da009b547e7607d08d8f8366d9f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637532259948289136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hEyvdsOekNwNchLUGJ%2B%2BgYdShhkz6nV%2BU2bKHiyOq%2B0%3D&amp;reserved=0

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 6 Apr 2021 19:39:34 -0700

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

> 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?

> 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?

> 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.

> 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?

> 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.

> 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.

> 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.

> https://www.ietf.org/mailman/listinfo/ippm-ioam-ix-dt
>