search

core-wg / echo-request-tag

Other
0 stars 0 forks source link

Better wording for the 152 allowed bytes #64

Closed chrysn closed 3 years ago

chrysn commented 3 years ago

In the response to https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-11-opsdir-lc-schoenwaelder-2020-11-30/ I promised better wording for the 152 bytes -- but let's see whether anything gets back there first.

  • The number of 152 bytes mentioned in section 2.4:

    3*152 would be 456 octets, I am not sure why this is the "typical size of a frame on the wire sent across the Internet". Either explain how you obtained this number of consider removing it in case it does depend on assumptions that are not guaranteed to be always true. One option could also be to simply drop this sentence.

As Carsten pointed out, this is the derived number from the "three times" part, also accounting for the remainder of the UDP packet.

Assuming an attacker wants to maximize the amplification possible by the factor 3, they will send

allowsing the server to send Σ * 3 = 222 octets. Subtracting everything in the response including the UDP header, that gives 160 octets of UDP data. Given the token is variable length data of up to 8 octets the server implementer can't easily take into account, that leaves 152 octets. (Granted, that last step doesn't follow from the wording, and I'm looing to sharpen that).

Having some hard number there (and I'm happy to use better ways to come up with one) is important because for generic server applications, the transports may not be known and the implementer would have to make assumptions; we can't do much more, but at least ours get solid review.

chrysn commented 3 years ago

In the course of this, we'll also have to give a citation for the "x 3" (currently https://tools.ietf.org/html/draft-ietf-quic-transport-32#page-50)

chrysn commented 3 years ago

Follow-up note to be factored into the resolution:

I have no strong opinion whether having a fixed number is good or bad, I can see reaons both ways. But if the WG decides to include an absolute number and you want people to implement that number, you should in my view include the calculation (perhaps in a short appendix) so that people recall how the number was determined. For example, you assume IPv4 (and not IPv6), you assume Ethernet (and not some other link layers or VLANs etc.). This may be OK but I think it is fair to document the assumptions.