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

[Tal Mizrahi <[e-mail]>]

Hi Greg,

Thanks for considering my comments.
Your suggestions make sense and address the concerns I noted.

Cheers,
Tal.

On Tue, May 14, 2024 at 9:07 PM Greg Mirsky <[e-mail]> wrote:
>
> 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