Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Authors,

Just a note/reminder that I am stepping down as an AD in March.  I don’t think that I’ve seen any reply to my DISCUSS comments (perhaps the authors and/or WG are still discussing the resolution), but if you are able to speed this up at all so that I can clear my discuss before I step down that would be preferable.  Actually, if you manage to clear all the DISCUSSes on this doc before March, so that Warren can approve it before the new IESG is seated, that would probably make both yours and Warren’s lives slightly easier at the transition.

Regards,
Rob


From: DNSOP <[e-mail]> on behalf of Robert Wilton via Datatracker <[e-mail]>
Date: Tuesday, 2 January 2024 at 15:41
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)
Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for this document.

I'm echoing Paul's and the SECDIR review comments here on the use of MAY in
recommendations (since everywhere you see MAY it is equally valid for an
interpretation to treat it as "MAY NOT"), but I think that this makes the
document, as a proposed BCP, unclear enough that I'm raising this to level of a
DISCUSS.

(1) p 3, sec 3.1.  Recommendations for UDP responders

   At the time of writing, most DNS server software did not set the DF
   bit for IPv4, and many OS kernel constraints make it difficult to set
   the DF bit in all cases.  Best Current Practice documents should not
   specify what is currently impossible, so R2, which is setting the DF
   bit, is "MAY" rather than "SHOULD".

I think that this recommendation, particularly because it is using RFC 2119
language, is unclear.  I would suggest rephasing this to something like:

   R2.  Where supported, UDP responders SHOULD set IP "Don't Fragment
   flag (DF) bit" [RFC0791] on IPv4.

(2) p 3, sec 3.2.  Recommendations for UDP requestors

   R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
   size to the RECOMMENDED size of 1400 or a smaller size.

I find this recommendation to be unclear because it mixes both a "SHOULD" and
"RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies to.  Is
the recommendation (i) that UDP requestors should limit the maximum UDP
payload.  Or (ii) is the recommendation that a limit of 1400 be used, or (iii)
perhaps both.  Maybe rewording this to something like the following would help:

   R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
   size to 1400 bytes, but MAY limit the maximum UDP payload size to a
   smaller size on small MTU (less than 1500 bytes) networks.

   or,

   R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
   size.  It is RECOMMENDED to use a limit of 1400 bytes, but a smaller
   limit MAY be used.

(3) p 3, sec 3.2.  Recommendations for UDP requestors

   R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
   reassembly to avoid cache poisoning attacks.

As written, I don't think that this is really a recommendation.  Either it is a
just a statement or fact (in which case it is not a recommendation), or it
should be upgraded to a SHOULD.

(4) p 4, sec 3.2.  Recommendations for UDP requestors

   R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
   reassembly to avoid cache poisoning attacks.
   R8.  DNS responses may be dropped by IP fragmentation.  Upon a
   timeout, to avoid resolution failures, UDP requestors MAY retry using
   TCP or UDP with a smaller EDNS requestor's maximum UDP payload size
   per local policy.

Again, I think that this document would be clearer if this was a SHOULD rather
than a MAY.

Regards,
Rob





_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop