Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

[[e-mail]]

> From: 神明達哉 <[e-mail]>
>>    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 <[e-mail]>