Re: [ippm] Is loopback/direct export amplification worse than linear?

[Greg Mirsky <[e-mail]>]

Hi Martin,
thank you for highlighting some troublesome characteristics of using the
Loopback flag in IOAM. I agree that draft-ietf-ippm-ioam-flags could
tighten up the description of scenarios when the Loopback flag is used.
Also, it seems that the behavior of Direct Export
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/?include_text=1>
can
benefit from more clarifications. Now I've read both drafts taking notes
and present them to you below:
*draft-ietf-ippm-ioam-flags:*

   - draft-ietf-ippm-ioam-data defined IOAM as a method to record
   "operational and telemetry information in the packet while the packet
   traverses a path between two points in the network". It is an example of a
   hybrid measurement method, per RFC 7799 classification. The introduction of
   the Loopback and Active flags clearly makes IOAM into an active method and
   thus it should be discussed as a protocol that originates test packets,
   including potential security threats it may be used to create.
   - If the purpose of the Loopback flag is producing a series of
   responses from traversed nodes, then it might be much easier to use not a
   copy of the original packet but a different packet to respond to the sender
   (similar to CFM's LTM/LTR). That will avoid any risk of reverse-path
   amplification.
   - It is not clear what kind of path is expected in "a return path from
   transit nodes and destination nodes towards the source (encapsulating node)
   exists"? For example, if IOAM is used in an SFC environment, would Loopback
   require the use of an SFP to the sender?
   - It is not clear what establishes "the identity of the [IOAM]
   encapsulating node". Some examples would be helpful.
   - There seems to be a disconnect in handling unexpected looped IOAM
   packet:

In the second paragraph Section 4 it is stated:
"If an encapsulating node receives a looped back packet that was not
originated from the current encapsulating node, the packet is dropped."

But in the second from the last paragraph of the same section is noted that:
"If there is no match in the Node ID, the packet is processed like a
conventional IOAM-encapsulated packet."


   - The following probably may be expressed using the definitions from the
   IANA registry:

   An IOAM trace option that has the loopback bit 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.

like that:
   An IOAM Trace Option that has the Loopback bit set MUST have the
   "hop_Lim and node_id in short format" bit set IOAM-Trace-Type, and MUST
   have all other bits of IOAM-Trace-Type cleared.


   - What is the value of collecting "hop_Lim and node_id in short format"
   on the return path of a packet looped back by an intermediate node? As I
   understand it, only that information can be collected if the Loopback flag
   is set. Please correct me if that is not the case.
   - Can you point where it is specified that when using the Loopback "the
   packet does not have any payload"? Earlier in Section 4 action of an
   intermediate node is explained:

   A loopback bit that is set indicates to the transit nodes processing
   this option that they are to create a copy of the received packet and
   send the copy back to the source of the packet.

One can understand that the looped back packet is a carbon copy of the
original packet less the Loopback flag being cleared. And the actions of
the encapsulating node are described as:
   The encapsulating node either generates synthetic packets with an
   IOAM trace option that has the loopback flag set, or sets the loopack
   flag in a subset of the in-transit data packets.

Which suggests that, at least in the latter case, the packet with the
Loopback flag set does have a payload.


   - One of the essential aspects of defining an active measurement
   protocol is the specification of the expected rates that test packets be
   generated for the intended purpose of the protocol. Some protocols provide
   a mechanism to negotiate that rate either through its control-plane
   component or as part of bringing the test session to Up state. I couldn't
   find any discussion of the expected purpose of using the Active flag, nor
   sufficient information that would help to set reasonable limits on
   processing packets with the Active flag set. Also, even though the document
   is on the Standards track, I find normative language in relation to the
   security impact of Loopback and Active flags being underused.
   - Applying rate limits throughout the IOAM domain might be cumbersome. I
   think that stronger security methods must be defined making using the
   Loopback and Active options more secure. For example, using authentication
   to ensure the identity of the encapsulating IOAM node that imposed the
   Loopback or Active option.

*draft-ietf-ippm-ioam-direct-export*

   - Section 3.1 includes very important assumption:

  The option [DEX] can be read but not modified by transit nodes.

That brings the question What protects the DEX option in particular and
IOAM-Option-Types in general?


   - The description of the processing of the DEX option by encapsulating,
   transit, and decapsulating nodes in an IOAM domain in all cases states "MAY
   export the requested IOAM data". What are other possible behaviors of nodes
   processing the DEX option?
   - In the last paragraph of Section 3.1 stated:

  A transit IOAM node that does not support the DEX option SHOULD ignore it.

What are other allowed behaviors of a node, whether transit or
decapsulating? Report an error? Discard the packet with the DEX option?


   - Though considerations for performance impact at a collector(s) is
   sensible, it seems that the impact on the node exporting telemetry
   information triggered by the DEX should also be considered.
   - Applying rate limits throughout the IOAM domain might be cumbersome. I
   think that there could be other methods to improve the security of the DEX
   option.
   - I can understand that the identity of a collector(s) of exported
   information can be provisioned via the management or control plane. But I
   also believe that there must be a discussion of why the Loopback option is
   not a special case of the DEX option.

Regards,
Greg

On Sun, Nov 15, 2020 at 9:45 PM Martin Duke <[e-mail]> wrote:

> I recognize that the loopback and direct export drafts discuss potential
> amplification results, as a path of length N will generate N packets for
> each IOAM packet -- a linear relationship. As these are discussed in the
> draft with proposed mitigation, in an editorial sense the job is done.
> Whether giving people this kind of foot gun is a good idea is a separate
> question, but reasonable people can disagree.
>
> However, if I understand correctly, certain pathological combinations of
> IOAM namespaces could result in amplification far worse than linear.
>
> 1) Loopback loops
> Imagine there is an IOAM namespace that covers the path from Hop A to Hop
> D. There is a separate namespace entirely contained in A-D, from hop B from
> hop C. Both namespaces enable loopback.
>                            A
> --------------------------------------------------------D
>
>  B-------------------------------C
>
> So a user packet is traveling from A to D. There will be (D-A) loopback
> packets headed towards A. The (D - C) loopback packets that generated
> between C and D will travel through the encapsulating node at C and then
> trigger further loopbacks to C. Thus the total number of packets generated
> by the single user packet is
> (D - A) + (D - C)(C - B)
> and obviousy there could be several of these smaller namespaces, or nested
> namespaces, that aggravate the amplification further.
>
> 2) Direct Export
> Direct Export potentially has even worse properties. Suppose namespace A,
> N_A hops across, direct exports to a node that is reachable across
> namespace B. Namespace B, N_B hops across, direct exports to a node
> reachable across namespace A.
>
> Thus a single user packet sent over namespace A will generate N_A packets
> that traverse Namespace B. This will, in turn, generate N_A * N_B packets
> that traverse namespace A, which in turn triggers N_A ^ 2 * N_B packets,
> and so on.
>
> In fact, if the namespaces direct export with probability exactly,1/N_A
> and 1/N_B, the same level of traffic will ping-pong infinitely. Any more
> than that, and the traffic will steadily increase to infinity. If the
> probability is 1, the growth is exponential.
>
> ****************
>
> This analysis, if correct, raises three questions that I can think of:
> - Are these corner cases plausible?
> - If so, and they occurred, would the namespace administrators necessarily
> be aware of each other? If not, I'm concerned that this is unsafe to deploy.
> - Do phenomena like this indicate that the design is brittle and putting
> in some "considerations" doesn't really mitigate the dangers here?
>
> Martin
>
>
>
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>