[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    [IPv6] icmpv6-ioam-conf-state amplification attack security considerations
From:       David 'equinox' Lamparter <equinox () diac24 ! net>
Date:       2023-07-27 21:25:30
Message-ID: ZMLgylKRj4yGApsL () eidolon ! nox ! tf
[Download RAW message or body]

Hi Xiao, hi Greg,


I just raised this comment at the mic, here's the text version:

IOAM Capabilities Query is at risk of being used for traffic
amplification with spoofed source addresses.  To clarify the scenario
first:

- some attacker is able to send ICMPv6 with false source addresses of
  the victim.
- they can send, for example, 10 GBit of IOAM Information Query to some
  large number of systems supporting it.  (Spreading it out is a common
  attack detail to work around rate limits.)
- the IOAM Information Reply will be quite a bit larger, let's just
  assume 5x size of query.  This is sent to the victim because the
  attacker sent a false source address.
- there is now 50 GBit of attack traffic hitting the victim.  The
  attacker only needed 10 GBit and got 40 GBit for "free".  (You're
  paying for it.)

If the operator correctly sets up filtering, this attack is prevented,
but sadly I think we can all agree not everyone operates their network
to the security standard they should.  Rate limits help but can be
worked around by using as many reflection/amplification hosts as
possible.  The protocol itself should be resilient where it can be.

All protocols that reply with a large packet to a small packet without
needing state are susceptible to this attack, it is most famous in DNS
as DNS amplification DoS.

A good way to address this issue is to simply make the query packet
larger, so there is no gain from it.  I would suggest doing this here.

- change the information query packet to allow filling it with zeros at
  the end.  Maybe some text like "the Query packet SHOULD be padded to
  1280 bytes minimum."

- when processing a query to create a response, add a requirement:
  "The IOAM Information Reply packet MUST NOT be larger than the IOAM
  Information Query packet that it is a reply to."

It is possible to do more, e.g. when the limit is exceeded - the basic
choice is to not reply at all, but that's rather poor.  It is also
possible to add a "reply truncated" flag, and just cut off the reply.
The original sender could then send a larger query.  But it doesn't know
how large it should be...

I'm not sure what level is appropriate here, it is simple inquiry
mechanism that I wouldn't want to make much more complicated.  But it is
OAM and debug tools may warrant some extra effort...


Cheers,


-equi
(David)

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]