> From: 神明達哉 <[email protected]>
>> 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 <[email protected]>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
