[ippm] Re: IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts

[Greg Mirsky <[e-mail]>]

Hi Tal,
thank you for your suggestions and references to the comprehensive security
analysis of IOAM and related use cases.
The new STAMP extension defined in the draft might be used, as it is noted
in Section 4, as a new DDoS attack vector. Among potential scenarios are
those listed below:

   - Spoofed STAMP test packets that include Reflected Test Packet Control
   and Return Path (RFC 9503) TLVs. To mitigate that risk, we note that HMAC
   TLV can be required if the domain is not trusted.
   - Attacking MiM might be intercepting STAMP test packets and altering
   content of Reflected Test Packet Control TLV. That seems similar to the
   scenario above, that can be mitigated by including HMAC TLV as well.
   - Human error, e.g., requesting too many and/or too frequent reflected
   STAMP test packets. We added the requirement that an implementation must
   control rate of reflected packets and if the parameters in Reflected Test
   Packet Control TLV exceed limits then the Session-Reflector acts as
   described in Section 2:

      If a

      Session-Reflector that recognizes the Reflected Test Control TLV

      cannot sustain the transmission of reflected test packets at the

      interval requested in the Interval Between the Reflected Packets

      field on the received TLV, the Session-Reflector MUST set the U

      flag [RFC8972] to 1, and MUST transmit a single reflected packet.

      Otherwise, the Session-Reflector MUST set the U flag to 0 in each

      of reflected test packets.


   - And here we come to the question of mitigating the risk of excessive
   packet reflection. We consider that the task of controling the reflection
   process is the task of a Session-Reflector, not the Session-Sender. We
   propose adding the following text in Security Consideration as a second
   paragraph:

   Furthermore, a DoS attack using the Reflected Test Packet Control TLV
   might target the STAMP Session-Reflector by overloading it with test
   packet reflection, e.g., extremely small intervals and/or too many
   concurrent test sessions.  To mitigate that, an implementation that
   supports the new TLV MUST control the rate and volume of reflection
   of STAMP test packets by the Session-Reflector.


What are your thoughts?

Regards,
Greg


On Thu, Apr 11, 2024 at 6:56 AM Tal Mizrahi <[e-mail]>
wrote:

> Hi,
>
> I believe that an asymmetric exchange in STAMP has value, and
> therefore I support the adoption of this document.
> I share the concerns raised on this thread regarding the potential of
> amplification attacks, and I believe this will need to be resolved,
> but not necessarily before WG adoption.
>
> I have the following suggestions about mitigating the amplification
> concerns:
> - The security considerations section should be more detailed and
> discuss the potential for amplification and DDoS attacks, including an
> upper bound on the order of magnitude of amplification.
> - The "Number of the Reflected Packets" and "Interval Between the
> Reflected Packets" should be reconsidered. Maybe consider a way to
> limit them to a sufficiently small "Number" and large "Interval".
> - Regarding amplification and how to mitigate it, you may want to take
> a look at RFC9322 and RFC9326, as we had many discussions about
> amplification when we were working on these documents.
>
> Cheers,
> Tal.
>
> On Tue, Apr 9, 2024 at 7:37 PM Tommy Pauly
> <tpauly=[e-mail]> wrote:
> >
> > Hello IPPM,
> >
> > This email starts an adoption call for
> draft-mirsky-ippm-asymmetrical-pkts. This is a document we’ve discussed
> several times, and is a normative dependency for another document we
> discussed adopting at IETF 119, draft-gandhi-ippm-stamp-ext-hdr.
> >
> > You can find the draft here:
> > https://datatracker.ietf.org/doc/draft-mirsky-ippm-asymmetrical-pkts/
> >
> https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-04.html#name-reflected-test-packet-control
> >
> > Please review the draft and respond to this email to indicate if you
> think IPPM should adopt this document as a working group item.
> >
> > This call will last for 3 weeks. Please reply by Tuesday, April 30.
> >
> > Best,
> > Tommy & Marcus
> > _______________________________________________
> > ippm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>