[DNSOP]Re: draft-ietf-dnsop-avoid-fragmentation-17.txt - implementer notes

[Petr Špaček <[e-mail]>]

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