Re:Re: Fast Address Validation - about

["Qing An" <[e-mail]>]

Thanks for the elaborate explanation.

The security & privacy approaches I listed are just some examples. In today’s network, it would be hard to defend those attacks you mentioned just relying one specific approach. How to prevent those attacks may be a broader story, not just specific to QUIC.

And based on the my company’s deployment experience, forcing to use Retry for address validation does cause some experience flaw in client side. Therefore, it is recommended to allow an approach that can accelerate the first connection establishment.

Qing



 ------------------Original Mail ------------------
Sender:Töma Gavrichenkov <[e-mail]>
Send Date:Sat Nov 2 01:34:31 2019
Recipients:Qing An <[e-mail]>
CC:QUIC <[e-mail]>, quic <[e-mail]>, jri.ietf <[e-mail]>, mt <[e-mail]>, mikkelfj <[e-mail]>, 刘大鹏(鹏成) <[e-mail]>
Subject:Re: Fast Address Validation - about
Peace,

On Fri, Nov 1, 2019 at 3:37 PM Qing An <[e-mail]> wrote:
> I submitted the draft, https://datatracker.ietf.org/doc/draft-an-fast-address-validation/

A quick review goes below:

> The server remembers the value it sends to
> clients and validates the token sent back from a client.

As discussed before, this description of the Retry mechanism is
inaccurate to the point it defeats its very purpose.

> Address validation is used by QUIC to avoid being used for a traffic
> amplification attack.

This is also inaccurate; the lower bound for the Initial packet size
prevents amplification.  Retry token is there to mitigate Initial
packet floods.  Neither prevent trivial reflection, if you will.

> If server chooses to
> accept the cost brought by token exchanging in Handshake
> [..]
> Adding token field to Handshake packet does not add new security
> concerns.

At least one security concern I see here is what data the server is
expected to derive its decision to accept the cost from.

E.g. with the aforementioned 300 Mpps Initial packet flood, what is
the approximate cost of keeping the state, per second?  If you would
just be storing 16 octets of an IPv6 address plus 2 octets of the
client's ephemeral port for any Rx packet, that'd be more than 5
Gbytes of RAM consumed *per second* of the attack, not including the
pointers, hashes etc.  Next, I haven't exactly done the math, but I
think that the draft implies that the state kept would be hardly less
than an order of magnitude bigger than that.  Also, the cost of
processing every spoofed packet through the whole handshake pipeline,
and so on.  I believe this is where the authors need to come up with
benchmarks and implementation hints on garbage collection methods etc.

I know the amount of RAM available is destined to grow but the floods
are not expected to shrink any time soon just as well.

--
Töma