Hi, 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. /js On Thu, Dec 10, 2020 at 09:08:53AM +0100, Christian M. Amsüss wrote: > Hello Jürgen, > > On Mon, Nov 30, 2020 at 03:00:02PM -0800, Jürgen Schönwälder via Datatracker wrote: > > - 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 > > * 14 octets Ethernet header > * 40 octets IP header > * 8 octets UDP header > * 4 octets CoAP header > * 8 octets of token > > 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 > looking 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. > > On Tue, Dec 01, 2020 at 01:22:45AM +0100, Carsten Bormann wrote: > > The number to be explained is not so much the 152 (the exact value of > > which I don’t really understand), but the three. > > That's the factor that QUIC is accepting[1]: > > > Prior to validating the client address, servers MUST NOT send more > > than three times as many bytes as the number of bytes they have > > received. This limits the magnitude of any amplification attack that > > can be mounted using spoofed source addresses. > > [1]: https://tools.ietf.org/html/draft-ietf-quic-transport-32#page-50 > > I've aked back at the QUIC authors about where they took their three > from -- either we can reference that; otherwise, just cite the WIP QUIC > as best currently available source. > > > - The difference between Figure 2 and Figure 3 is rather subtle. > > > > I actually diffed the figures to find it. My understanding is that > > it is really only the labels t0 and t1 and e0 and e1. One could > > perhaps change the figures to make it more explicit when t0 (e0) > > take place, perhaps also clarifying the text a bit. There is perhaps > > some confusion caused by the notion of time t0, t1, the notion of > > events e0, e1, and the notion of tag values labeled (t0) and (e0). > > The text says "The server verifies freshness by checking that e0 > > equals e1, where e0 is the cached value when the Echo option value > > was generated, and e1 is the cached value at the reception of the > > request." I found this confusing. It think what you are trying to > > say is that the tag value cached at event e0 is the same as the tag > > value received at event e1, no? > > That's good input; we're going through a few versions among the authors > for the precise visual alignment and wording. > > Best regards > Christian > > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
