On 07. 05. 24 2:54, C. M. Heard wrote:
On Mon, May 6, 2024 at 6:59 AM Petr Špaček wrote:
Warren asked implementers to provide feedback on the current text, so
I'm doing just that.
[ ... ]
3.1. Recommendations for UDP responders
R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200].
Operational impact of this recommendation is unclear.
Why? Because clients belong to several sets:
- One set clients cannot receive fragmented answers,
- another set of clients cannot use TCP to overcome unfragmented UDP
size limitations,
- yet another set of clients actually depend on large answers to
function (say because they DNSSEC validate, or need to follow huge NS
sets generated by MS AD, or they need large RRs to deliver e-mail, or ...).
It's unclear what proportion of clients belong to intersection of these
three sets. Banning fragmentation on the **outgoing** side might break
these clients, and it's extremely hard to measure and debug from the
server side.
This complaint is really unclear. The recommendation is specifically
for responders, i.e., servers. It's not a priori whether the term
"outgoing" means the requestor to responder direction or the responder
to requestor direction. I presume the latter, but it would be better
if this was made obvious by using the same terminology as the draft.
What I think you are saying is that clients that cannot re-send
truncated queries using TCP will be hurt by the recommendation. Aren't
such clients non-conformant with current DNS standards? If so, are they
sufficiently prevalent that it is necessary to continue using
workarounds to accommodate them?
I said:
"Operational impact of this recommendation is unclear."
That means that answer to your question is unknown.
This recommendation is not backed with data. If the data exist they are
not linked. To the best of my knowledge there is no significant
operational experience with it. If the experience exists I have not seen
it published.
On paper the recommendation does not sound bad. Maybe it's good enough
as aspirational, forward-looking recommendation...
But that's not what the document does. Version 17 currently says it's:
- Best
- Current
- Practice
As I implementer I claim these three words are either not supported by
data or outright incorrect:
- Best - impact is unknown, experience is lacking
- Current - not deployed at scale
- Practice - well, not even implementable with current OS APIs!
> Wasn't the whole point of DNS Flag Day
to break what was broken and get it fixed?
There was not a flag day for TCP support (yet?).
If you are up for organizing one I'm happy to share first-hand
experience from organizing previous two DNS Flag Days!
[ ... ]
R6. UDP requestors SHOULD drop fragmented DNS/UDP responses without IP
reassembly to avoid cache poisoning attacks.
AFAIK this is impossible to do using normal socket API. The application
has no access to information about UDP reassembly.
Having said that, even if it was implementable it's IMHO not the best
advice for requestor.
IF the requestor is able to detect that a fragment was received then it
would be MUCH better to trigger retry using different protocol right
away. Just dropping the packet:
a] causes timeouts
b] leaves a time window open for another attack attempt
I wondered about this after I read the draft (which was after WG last
call, or I would have commented). I'm not aware of any stack that
allows the application to disable IP reassembly, nor any that indicates
whether a received UDP datagram was received in a single IP datagram or
in multiple IP fragments. If that is indeed the case, this
recommendation should be removed, since it is not actionable.
Additionally, my understanding of the motivation for this is to prevent
off-path cache poisoning attacks. If I correctly understand what I
have read, these are a problem for IPv4 (which has only a 16-bit
datagram ID) or for IPv6 stacks that emit predictable datagram IDs.
It seems to me that the advice to avoid reassembly would need to be
more nuanced, even if it were actionable.
Generally I agree. Having said that, paradoxically I think R6 advice is
much better than R1... **if** it were practically implementable. Again,
this can be aspirational forward-looking recommendation.
If we can get API to detect fragmented (even partial) datagrams we can
harden the client side and most of other recommendations will be moot.
Example: The requestor could treat any fragmented answer as equivalent
to TC=1 answer with no data inside. That should take care of all known
fragmentation-based attacks (I think) and it does not depend on
responder side at all.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
