> From: 神明達哉 <jin...@wide.ad.jp> >> 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.
Thanks very much. > 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. I agree and need to consider how to update. > - 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. I will consider the comment. > - 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. DNS forwarders and stub resolvers may be target of cache poisoning attacks. Then, path MTU attack targets are DNS responders (auth/resolver servers). > - general: since this is about off-path cache poisoning attacks, you > may also want to refer to DNS cookies (RFC7873) as a possible measure. I agree. > - 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 ^^^^^^^^^^^^^ on-path fragmentation ? > 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). If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU value ? Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ? I observed many fragmented IPv6 DNS responses whose packet size are 1496 or 1500. # What I was interested in was that many implementations accept # crafted "ICMPv6 Packet Too Big". > - 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? I will add texts. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop