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
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
