Re: [Last-Call] Artart telechat review of draft-ietf-dnsop-avoid-fragmentation-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Barry Leiba via Datatracker wrote on 2023-12-29 19:40:
Reviewer: Barry Leiba
Review result: Ready with Nits

Thanks for addressing most comments from my earlier review.  One remains, and I
didn’t see an email response about it, so I don’t know whether there was a
reason not to make a change or if it just got overlooked:

— Section 7.2 —

    If a UDP response packet is dropped (for any reason), it increases
    the attack window for poisoning the requestor's cache.

But Section 3.2 says this:

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

…which seems to be contradictory.  Can you clarify this apparent contradiction
in one place or both?

the requirements are in conflict, and this is a good catch. in 7.2 we should say "dropped in transit, up to and including the network stack of the initiator" since if it's dropped by the initiator (in user mode) the attack window will be closed thereby.

in 3.2 we should say "SHOULD" not "MAY", per mr. wouters' earlier comments. in addition we should say "SHOULD detect reassembled DNS/UDP responses in the DNS response processing logic, since the fragments thereof would have been subject to off-path cache poisoning attacks."

it's a very subtle point and has been wordsmithed more than once here. we don't want the initiator's window of willingness to receive a response to be any longer than possible, because of off-path (TID guessing) attacks. and we don't want to reassemble, because of off-path (fragment replacement) attacks. so we really do not want fragmentation to occur because it makes both of those attacks easier to launch. TID guessing is made easier if the network drops fragments or drops oversized packets. fragment replacement is made easier if there were in fact ever any fragments.

by recommending that the initiator detect when fragments are present (or were present, if the network stack reassembled them first) and drop them, we reduce the chance of bad fragments getting through, because no fragments will get through. we also disincentivize the generation of fragments in the first place, because they'll be silently dropped by (a growing number of) initiators.

as you can see i've fought the words and lost.

--
P Vixie

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux