Re:Re: Fast Address Validation - about

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

The proposal is to, if server chooses not to send a Retry, for first connection, define how to use new_token frame to deliver token to client for future connection.



 ------------------Original Mail ------------------
Sender:Jana Iyengar <[e-mail]>
Send Date:Sat Nov 2 05:36:30 2019
Recipients:Qing An <[e-mail]>
CC:quic <[e-mail]>, 刘大鹏(鹏成) <[e-mail]>
Subject:Re: Fast Address Validation - about

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