Hi Donald, First off, thanks for the review, and thanks to Med for the updates in response. Continuing inline... On Sat, Mar 27, 2021 at 11:42:56PM -0400, Donald Eastlake wrote: > Hi, > > Thanks for adopting so many of my suggestions. > > See below where I have trimmed to points where we disagree that I > think I have something to add. > > On Tue, Mar 23, 2021 at 9:51 AM <mohamed.boucadair@xxxxxxxxxx> wrote: > > Hi Donald, > > > >... > > > > De : Donald Eastlake [mailto:d3e3e3@xxxxxxxxx] > > Envoyé : mardi 23 mars 2021 05:53 > > À : iesg@xxxxxxxx; last-call@xxxxxxxx > > Cc : draft-ietf-dots-rfc8782-bis.all@xxxxxxxx; secdir <secdir@xxxxxxxx> > > Objet : SECDIR Review draft-ietf-dots-rfc8782-bis-05 > > > > ... > > > > Minor Issues / Nits: > > > >... > > > > General/Global: All six occurrences of "as a reminder" should be > > deleted from the draft. They just add useless words. > > > > [Med] Except the one about IPv4/IPv6, those were added to address comments that we received in the past. I prefer to maintain them. > > Perhaps I was not clear. I have no problem with the substantive > material you have included AFTER the words "as a reminder,". I was > mearly suggesting that the literal three word sequence "as a reminder" > is three superfluous words that should be removed. Thanks for reiterating the intent of the suggestion. I think I am okay leaving them in for now, and seeing if the rest of the IESG has an opinion. > > > > ... > > > > Section 4.4.1: > > > > The following draft text uses "the trailing "=" " which implies that a > > base 64 encoding ends with exactly one equal sign. But I believe there > > can be zero, one, or two equal signs. I suggest the following: > > OLD > > The truncated output is > > base64url encoded (Section 5 of [RFC4648]) with the trailing > > "=" removed from the encoding, and the resulting value used as > > the 'cuid'. > > NEW > > The truncated output is > > base64url encoded (Section 5 of [RFC4648]) with any trailing > > equal signs ("=") removed from the encoding, and the > > resulting value used as the 'cuid'. > > > > [Med] We meant “any trailing”. Fixed by updating to “two trailing "="” > > That still seems wrong to me. The initial wording ("the trainling > "="") implied exactly one equal sign. The new wording ("the two > training "="") implies exactly two equal signs. But there can be zero, > one, or two. If you mean "any training "="", which would be good, why > don't you say that (or, alternatively, "all trailing")? In this case the quantity in question is always a 16-byte binary quantity that's being base64-encoded, so there always will be two padding characters to remove. > > > >... > > > > Section 7.3: Since the PMTU can change and could be lower that the > > values suggested to be assumed in the first paragraph of Section 7.3, > > it is essentially impossible to conform to the first sentence as > > written. I suggest the following change: > > OLD > > To avoid DOTS signal message fragmentation and the subsequent > > decreased probability of message delivery, DOTS agents MUST ensure > > that the DTLS record fits within a single datagram. > > > > [Med] We are echoing the following from Section 4.1.1 of 6347: > > > > “Each DTLS record MUST fit within a single datagram.” > > I don't agree that you are "echoing" RFC 6347. If you were, you would say > > "To avoid DOTS signal message fragmentation and the subsequent > decreased probability of message delivery, the DTLS records MUST fit > within a single datagram." > > If you had said that, I would not have complained. It is a true > statement of the bad effects DTLS records not fitting in a datagram. I think I see your point. Since RFC 6347 already has a "MUST fit" requirement, we could just rely on that and avoid using new normative language (I think your point is that "MUST ensure" is not something that can reliably be achieved, since the DOTS agent may not know about MTU changes). Perhaps we can say something like: To avoid DOTS signal message fragmentation and the subsequent decreased probability of message delivery, the DLTS records need to fit within a single datagram [RFC6347]. > > NEW > > To avoid DOTS signal message fragmentation and the subsequent > > decreased probability of message delivery, DOTS agents MUST NOT > > send datagrams exceeding the limits discussed in this Section. > > > > ... > > > > The way this sentence talks about moving around "mitigation efficacy" > > reads very strangely to me. I suggest the following re-wording: > > OLD > > A compromised DOTS client can collude with a DDoS attacker to send > > mitigation request for a target resource, get the mitigation efficacy > > from the DOTS server, and convey the mitigation efficacy to the DDoS > > attacker to possibly change the DDoS attack strategy. > > NEW > > A compromised DOTS client can be commanded by a DDoS attacker to > > abuse mitigation requests for a target resource. This could use the > > "mitigation" abilities of the DOTS server for the benefit of the > > attacker possibly leading to a changed and more effective DDoS > > attack strategy. > > > > [Med] Thanks. I prefer the OLD wording. > > I think I understand what you mean by "efficacy" more clearly now but > I still think you should fix the grammar by changing "request" in the > 2nd line to "requests" (or, if you really mean this to be singular, > change the wording to "a mitigation request"). (I think it's supposed to be singular. Yes, there's a cardinality mismatch.) Thanks again, Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
