Re: Fast Address Validation - about

[Jana Iyengar <[e-mail]>]

Qing,

Thank you for writing up the draft.

As several others have noted, the RTT spent with Retry is not unnecessary,
it is fundamental to the purpose of Retry. If the server is willing to
maintain state, it doesn't need to send a Retry packet at all. If the
server is willing to maintain state and therefore does not send a Retry at
all, what is the value of your proposal?

- jana

On Fri, Nov 1, 2019 at 10:34 AM Töma Gavrichenkov <[e-mail]> wrote:

> 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
>