At Fri, 01 Mar 2019 21:14:48 +0900 (JST), fujiw...@jprs.co.jp wrote: > Dear DNSOP, > > I submitted draft-fujiwara-dnsop-fragment-attack-01. > > https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 > > It summarized DNS cache poisoning attack using IP fragmentation > and countermeasures. > > If the draft is interested, I will request timeslot at IETF 104.
I've read the draft. I think it's generally well written and contains useful information. Some specific comments follow: - general: I wonder whether the effect of this problem can be substantially different between IPv6 and IPv4. As the draft itself discusses, IPv6 has a much larger ID space for fragmentation (the existence of implementations that generate predictable IDs is an implementation issue; in the case of IPv4 it's a protocol issue). IPv6 also has a much larger minimum MTU. In practice, I suspect most (unsigned) important responses can fit in the minimum MTU, substantially affecting the practical severity of the attack. I'm not saying that we don't have to take any measure for the IPv6 case, but I think this difference is worth noting in the draft explicitly. - general: the draft the term "full-service resolver" in Abstract and throughout the document. It may be only me, but I always feel this term is confusing and misleading, even after the publication of RFC8499. It's not very clear to me whether "full-service" excludes "forwarding only" resolvers. RFC8499 refers to RFC1123, and its definition is also unclear to me in this sense. If this confusion is not only mine, I think the use of the term is rather harmful, since the issue discussed in this draft shouldn't exclude forwarding only resolvers. What matters here is a resolver with a cache, and in that sense I'd rather suggest just saying "(recursive) resolver"; it should be obvious that it's about a resolver with the cache from the context. - general: on a related point, I suspect the discussion about authoritative servers is not actually specific to authoritative servers; consider the case of a recursive server that takes queries from forwarding only resolvers. It should be generally applicable to any DNS "responder", and I'd suggest revising the draft accordingly. - general: since this is about off-path cache poisoning attacks, you may also want to refer to DNS cookies (RFC7873) as a possible measure. - Section 3 Linux 2.6.32, Linux 4.18.20 and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and path MTU decreased to 1280. I suspect this often doesn't matter much in practice. Since IPv6 doesn't allow fragmentation and PMTU discovery isn't very effective for DNS responders, the server implementation should set IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations actually set this option; some others don't, but they are just lucky to not encounter the problem or receive complaints about it). - Section 4.2 Limiting EDNS0 requestor's UDP payload size [RFC6891] to 1220/1232 on IPv6 is a measure of path MTU attacks on IPv6 because minimal MTU size of IPv6 is 1280 and most of implementations ignore ICMPv6 packet too big packets whose MTU size is smaller than 1280. I suggest removing "and most of implementations..." since even if an implementation accepts ICMPv6 PMTU with MTU < 1280, it doesn't mean they fragment packets at that size. - Section 4.8 Some operators that support [RFC8078] said that they use TCP only for transport to avoid cache poisoning attacks. It's not clear (to me at least) how RFC8078 is related to a TCP-only operation. Some more explanation may help. - Section 5 o Full-service resolvers may retry name resolution by TCP. I don't get exactly what this means...in which case does it suggest the retry with TCP? -- JINMEI, Tatuya
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
