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

[神明達哉 <[e-mail]>]

At Fri, 01 Mar 2019 21:14:48 +0900 (JST),
[e-mail] 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