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

From: [email-masked]
Date: Fri, 01 Mar 2019 21:14:48 +0900 (JST)

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 think it is time to consider to avoid IP Fragmentation in DNS.
It is possible to avoid IP fragmentation as much as possible.

It is not good that DNS is the biggest user of IP fragmentation.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

A new version of I-D, draft-fujiwara-dnsop-fragment-attack-01.txt
has been successfully submitted by Kazunori Fujiwara and posted to the
IETF repository.

Name:		draft-fujiwara-dnsop-fragment-attack
Revision:	01
Title:		Measures against cache poisoning attacks using IP fragmentation in DNS
Document date:	2019-03-01
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-fragment-attack-01.txt
Status:         https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-fragment-attack/
Htmlized:       https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-fragment-attack
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fujiwara-dnsop-fragment-attack-01

Abstract:
   Researchers proposed practical DNS cache poisoning attacks using IP
   fragmentation.  This document shows feasible and adequate measures at
   full-service resolvers and authoritative servers against these
   attacks.  To protect resolvers from these attacks, avoid
   fragmentation (limit requestor's UDP payload size to 1220/1232), drop
   fragmented UDP DNS responses and use TCP at resolver side.  To make a
   domain name robust against these attacks, limit EDNS0 Responder's
   maximum payload size to 1220, set DONTFRAG option to DNS response
   packets and use good random fragmentation ID at authoritative server
   side.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 2 Mar 2019 07:00:24 +1100

Or one can use TSIG with a well known key to get a cryptograph hash of the response.  Below is how
how the servers for the Alexa to 1 Million handle unexpected TSIG.  It’s well under a day to add
this to a recursive server that supports TSIG already.  It’s a couple of minutes of configuration
time to add it to a authoritative server that supports TSIG already.

Count, without WKK, with WWK.  https://ednscomp.isc.org/compliance/alexa1m-tsig-wkk.txt

2019-02-24T00:00:05Z
      2 dns=ok                 dnswkk=eof
     39 dns=failed             dnswkk=failed
    348 dns=ok                 dnswkk=formerr,notsig
     65 dns=timeout            dnswkk=formerr,notsig
     10 dns=nosoa,noaa         dnswkk=formerr,notsig
      7 dns=servfail           dnswkk=formerr,notsig
      3 dns=formerr            dnswkk=formerr,notsig
      3 dns=nosoa,noaa,rd      dnswkk=formerr,notsig
      3 dns=refused            dnswkk=formerr,notsig
      2 dns=noaa               dnswkk=formerr,notsig
      1 dns=nxdomain           dnswkk=formerr,notsig
      9 dns=ok                 dnswkk=formerr,notsig,opt (non RFC compliant: OPT record in response)
      2 dns=refused            dnswkk=formerr,notsig,opt (non RFC compliant: OPT record in response)
    786 dns=ok                 dnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response)
     33 dns=refused            dnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response)
      6 dns=servfail           dnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response)
      3 dns=noaa               dnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response)
      3 dns=timeout            dnswkk=formerr,tsig-bad-sig (non RFC compliant: TSIG record in response)
      1 dns=ok                 dnswkk=formerr,tsig-bad-sig,proxy (non RFC compliant: TSIG record in response)
      9 dns=rd                 dnswkk=formerr,tsig-bad-sig,rd (non RFC compliant: TSIG record in response)
    156 dns=refused            dnswkk=malformed (non RFC compliant: malformed)
    135 dns=ok                 dnswkk=malformed (non RFC compliant: malformed)
     38 dns=servfail           dnswkk=malformed (non RFC compliant: malformed)
     13 dns=malformed          dnswkk=malformed (non RFC compliant: malformed)
     13 dns=timeout            dnswkk=malformed (non RFC compliant: malformed)
     10 dns=nosoa              dnswkk=malformed (non RFC compliant: malformed)
      8 dns=nxdomain,ad        dnswkk=malformed (non RFC compliant: malformed)
      3 dns=nosoa,noaa         dnswkk=malformed (non RFC compliant: malformed)
      4 dns=ok                 dnswkk=noerror,badkey,nosoa,noaa (non RFC compliant: rcode != NOTAUTH)
      4 dns=ok                 dnswkk=noerror,badkey,tsig-wrong-alg,nosoa,noaa (non RFC compliant: rcode != NOTAUTH)
      3 dns=ok                 dnswkk=noerror,badkey,tsig-wrong-alg,tsig-bad-time,nosoa,noaa (non RFC compliant: rcode != NOTAUTH)
 142252 dns=ok                 dnswkk=notauth,badkey
   2483 dns=refused            dnswkk=notauth,badkey
    694 dns=servfail           dnswkk=notauth,badkey
    369 dns=timeout            dnswkk=notauth,badkey
    295 dns=nosoa,noaa         dnswkk=notauth,badkey
    176 dns=rd                 dnswkk=notauth,badkey
     43 dns=nosoa              dnswkk=notauth,badkey
      9 dns=noaa               dnswkk=notauth,badkey
      2 dns=nxdomain           dnswkk=notauth,badkey
      2 dns=opt                dnswkk=notauth,badkey
      2 dns=refused,rd         dnswkk=notauth,badkey
      5 dns=opt                dnswkk=notauth,badkey,opt (non RFC compliant: OPT record in response)
    318 dns=ok                 dnswkk=notauth,badkey,proxy
      6 dns=refused            dnswkk=notauth,badkey,proxy
      3 dns=servfail           dnswkk=notauth,badkey,proxy
      2 dns=nosoa,noaa         dnswkk=notauth,badkey,proxy
      2 dns=timeout            dnswkk=notauth,badkey,proxy
      1 dns=rd                 dnswkk=notauth,badkey,rd,proxy (non RFC compliant: RD=1 in response)
   8238 dns=ok                 dnswkk=notauth,badkey,tsig-bad-time
    159 dns=refused            dnswkk=notauth,badkey,tsig-bad-time
    118 dns=servfail           dnswkk=notauth,badkey,tsig-bad-time
     37 dns=nosoa,noaa         dnswkk=notauth,badkey,tsig-bad-time
     30 dns=rd                 dnswkk=notauth,badkey,tsig-bad-time
     17 dns=timeout            dnswkk=notauth,badkey,tsig-bad-time
      3 dns=noaa               dnswkk=notauth,badkey,tsig-bad-time
      2 dns=nosoa              dnswkk=notauth,badkey,tsig-bad-time
     31 dns=ok                 dnswkk=notauth,badkey,tsig-bad-time,proxy
      2 dns=nosoa,noaa         dnswkk=notauth,badkey,tsig-bad-time,proxy
      1 dns=refused            dnswkk=notauth,badkey,tsig-bad-time,proxy
     27 dns=ok                 dnswkk=notauth,badkey,tsig-bad-time,tsig-bad-fudge
    105 dns=ok                 dnswkk=notauth,badkey,tsig-wrong-alg
      5 dns=nosoa,noaa         dnswkk=notauth,badkey,tsig-wrong-alg
      1 dns=ok                 dnswkk=notauth,badkey,tsig-wrong-alg,proxy
     30 dns=ok                 dnswkk=notauth,badkey,tsig-wrong-alg,tsig-bad-time
  11401 dns=ok                 dnswkk=notauth,notsig (non RFC compliant: NOTAUTH without TSIG)
    278 dns=refused            dnswkk=notauth,notsig (non RFC compliant: NOTAUTH without TSIG)
     82 dns=timeout            dnswkk=notauth,notsig (non RFC compliant: NOTAUTH without TSIG)
     18 dns=nosoa,noaa         dnswkk=notauth,notsig (non RFC compliant: NOTAUTH without TSIG)
      5 dns=servfail           dnswkk=notauth,notsig (non RFC compliant: NOTAUTH without TSIG)
      2 dns=nxdomain           dnswkk=notauth,notsig (non RFC compliant: NOTAUTH without TSIG)
      2 dns=reset              dnswkk=notauth,notsig (non RFC compliant: NOTAUTH without TSIG)
      1 dns=nosoa              dnswkk=notauth,notsig (non RFC compliant: NOTAUTH without TSIG)
    445 dns=ok                 dnswkk=notimp,notsig
     45 dns=refused            dnswkk=notimp,notsig
      2 dns=notimp             dnswkk=notimp,notsig
      2 dns=timeout            dnswkk=notimp,notsig
  41201 dns=ok                 dnswkk=notsig
    284 dns=timeout            dnswkk=notsig
     33 dns=servfail           dnswkk=notsig
     15 dns=opt                dnswkk=notsig
      6 dns=refused            dnswkk=notsig
      4 dns=noaa               dnswkk=notsig
      2 dns=malformed          dnswkk=notsig
      1 dns=cd                 dnswkk=notsig
      1 dns=nosoa,noaa,rd      dnswkk=notsig
      3 dns=cd                 dnswkk=notsig,cd
      1 dns=ok                 dnswkk=notsig,cd
     54 dns=noaa               dnswkk=notsig,noaa
     13 dns=ok                 dnswkk=notsig,noaa
      4 dns=opt                dnswkk=notsig,noaa
      3 dns=noaa,rd            dnswkk=notsig,noaa,rd
    123 dns=nosoa              dnswkk=notsig,nosoa
      3 dns=nosoa,noaa,rd      dnswkk=notsig,nosoa
      2 dns=nosoa,noaa         dnswkk=notsig,nosoa
    311 dns=nosoa,noaa         dnswkk=notsig,nosoa,noaa
     78 dns=nosoa,noaa,rd      dnswkk=notsig,nosoa,noaa,rd
      8 dns=ok                 dnswkk=notsig,nosoa,noaa,rd
      3 dns=nosoa              dnswkk=notsig,nosoa,noaa,rd
      5 dns=nosoa,rd           dnswkk=notsig,nosoa,rd
     15 dns=opt                dnswkk=notsig,opt
      1 dns=timeout            dnswkk=notsig,opt
      1 dns=opt,cd             dnswkk=notsig,opt,cd
      1 dns=nosoa,noaa         dnswkk=notsig,opt,nosoa,noaa
     27 dns=rd                 dnswkk=notsig,rd
      6 dns=timeout            dnswkk=notsig,rd
     21 dns=nxdomain           dnswkk=nxdomain,notsig
      3 dns=ok                 dnswkk=ok
    121 dns=ok                 dnswkk=refused,badkey (non RFC compliant: rcode != NOTAUTH)
     20 dns=servfail           dnswkk=refused,badkey (non RFC compliant: rcode != NOTAUTH)
     19 dns=refused            dnswkk=refused,badkey (non RFC compliant: rcode != NOTAUTH)
      1 dns=nosoa,noaa         dnswkk=refused,badkey (non RFC compliant: rcode != NOTAUTH)
      1 dns=timeout            dnswkk=refused,badkey (non RFC compliant: rcode != NOTAUTH)
      5 dns=refused            dnswkk=refused,badkey,tsig-bad-time (non RFC compliant: rcode != NOTAUTH)
    996 dns=refused            dnswkk=refused,notsig
      2 dns=ok                 dnswkk=refused,notsig (non RFC compliant: REFUSED when plain DNS not REFUSED)
     33 dns=refused            dnswkk=refused,tsig-bad-sig (likely non RFC compliant)
      1 dns=ok                 dnswkk=reset
      1 dns=reset              dnswkk=reset
   1258 dns=ok                 dnswkk=servfail,notsig (non RFC compliant: SERVFAIL when plain DNS not SERVFAIL)
    139 dns=servfail           dnswkk=servfail,notsig
     21 dns=refused            dnswkk=servfail,notsig (non RFC compliant: SERVFAIL when plain DNS not SERVFAIL)
     10 dns=nosoa,noaa         dnswkk=servfail,notsig (non RFC compliant: SERVFAIL when plain DNS not SERVFAIL)
     10 dns=timeout            dnswkk=servfail,notsig (non RFC compliant: SERVFAIL when plain DNS not SERVFAIL)
      2 dns=nxdomain,soa       dnswkk=servfail,notsig (non RFC compliant: SERVFAIL when plain DNS not SERVFAIL)
      1 dns=noaa               dnswkk=servfail,notsig (non RFC compliant: SERVFAIL when plain DNS not SERVFAIL)
      1 dns=rd                 dnswkk=servfail,notsig (non RFC compliant: SERVFAIL when plain DNS not SERVFAIL)
     48 dns=ok                 dnswkk=servfail,tsig-bad-sig (non RFC compliant: SERVFAIL when plain DNS not SERVFAIL)
      9 dns=servfail           dnswkk=servfail,tsig-bad-sig
  17621 dns=timeout            dnswkk=timeout
   1305 dns=ok                 dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
     22 dns=refused            dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
      6 dns=servfail           dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
      5 dns=malformed          dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
      4 dns=rd                 dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
      2 dns=nosoa              dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
      2 dns=nosoa,noaa         dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
      2 dns=nosoa,noaa,rd      dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
      1 dns=nosoa,rd           dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
      1 dns=opt                dnswkk=timeout (non RFC compliant: timeout on request containing TSIG)
     46 dns=ok                 dnswkk=tsig-bad-sig
      4 dns=timeout            dnswkk=tsig-bad-sig
      4 dns=update             dnswkk=tsig-bad-sig
      7 dns=nosoa              dnswkk=tsig-bad-sig,nosoa
      1 dns=timeout            dnswkk=tsig-bad-sig,nosoa
      1 dns=nosoa,noaa         dnswkk=tsig-bad-sig,nosoa,noaa
      1 dns=ok                 dnswkk=tsig-not-last,tsig-bad-sig (non RFC compliant: TSIG not last record in additional section)

> On 1 Mar 2019, at 11:14 pm, [email-masked] wrote:
> 
> Dear DNSOP,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Fri, 1 Mar 2019 13:40:22 -0800

> 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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 1 Mar 2019 18:33:20 -0800

Mark Andrews wrote on 2019-03-01 12:00:
> Or one can use TSIG with a well known key to get a cryptograph hash
> of the response. ...

i prefer this approach. no matter how bad fragmentation was in V4 and no 
matter how much worse it is in V6, we must not lock ourselves into 
packets whose size is computed from the analog properties of 10Mbit 
ethernet (1500) minus a whole bunch of witch-craft fudge factors. i 
expect to live until around 2050, and by that time i'd like to use a LAN 
max packet size that's only 1/15000th of capacity (as 10Mbit ethernet 
had), and to either use smaller packets when forwarding through a WAN 
gateway, or make fragmentation possible, which V6 has unintentionally 
made presently impossible.

-- 
P Vixie

---

From: [email-masked]
Date: Mon, 04 Mar 2019 20:43:14 +0900 (JST)

> From: 神明達哉 <[email-masked]>

Thanks very much.

>   but I think this difference is worth noting in the draft explicitly.

I agree and need to consider how to update.

>   it should be obvious that it's about a resolver with the cache from

I will consider the comment.

>   to any DNS "responder", and I'd suggest revising the draft

DNS forwarders and stub resolvers may be target of cache poisoning attacks.
Then, path MTU attack targets are DNS responders (auth/resolver servers).

>   may also want to refer to DNS cookies (RFC7873) as a possible measure.

I agree.

>   doesn't allow fragmentation and PMTU discovery isn't very effective for
                  ^^^^^^^^^^^^^
		  on-path fragmentation ?

>   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".

>   I don't get exactly what this means...in which case does it suggest

I will add texts.

---

From: [email-masked]
Date: Mon, 04 Mar 2019 20:52:30 +0900 (JST)

> From: Mark Andrews <[email-masked]>

Do you mean adding new method like DNS Cookies ?

I have a question.

If a resolver want to take measures,
does the resolver configure TSIG to communicate all authoritative servers ?

---

From: 神明達哉 <[email-masked]>
Date: Mon, 4 Mar 2019 11:10:30 -0800

> >   doesn't allow fragmentation and PMTU discovery isn't very effective
for

Oops, sorry for the confusing text.  I meant "IPv6 doesn't allow
fragmentation at intermediate nodes" (or, yes, I meant "on-path
fragmentation").

> If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU
value ?

Yes.  Or more accurately, if IPV6_USE_MIN_MTU is set the path MTU
value (if known) is just ignored.

> Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ?

Yes (if IPV6_USE_MIN_MTU is specified).

> I observed many fragmented IPv6 DNS responses whose packet size are

Those should be sent from a server that doesn't set IPV6_USE_MIN_MTU
or from a system that doesn't support the option (sadly a very widely
deployed OS doesn't support it: Linux).

> # crafted "ICMPv6 Packet Too Big".

Sure, but unless it matters in the larger context of the draft, it's
just a distraction.

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Tue, 5 Mar 2019 08:21:21 +1100

You specify a well known TSIG key (e.g. name=“.”, algorithm=hmac-sha256, key=<32-zero-bytes>)
then you use it when you don’t have a more specific key.  If the server support the WKK you
will get back a TSIG signed response that can’t have been forged by a off path attacker if it
matched the response.  There should be enough entropy in a TSIG query without add more but one
can add more by putting random data in the other field prior to generating the request’s hmac.
Otherwise you should get back a BADKEY error if the server supports TSIG and FORMERR, NOTIMP
(without a TSIG record) or a non-TSIG response if the server does not implement TSIG.  Clients
can remember of they get a TSIG response and reject non-TSIG responses in the future or treat
each transaction as independent.  I would expect public DNS resolvers to formally state when
they support this.

The pairwise table I generated was to show what current servers do when presented with a
unknown, unexpected TSIG key.  There are a number of mis-implementation of TSIG shown.  A
few underspecified parts of the TSIG specification which I raise earlier.  There are firewalls
that unnecessarily block requests with TSIG present and there are mis-implementations of STD 13
shown.

If we proceed down this path we will need to get CVE’s issues against all the firewalls and
nameserver implementation that block/drop requests with TSIG presents they should be issued 
for firewalls anyway as it they break the ability to use TSIG.  Servers that mis-implement
TSIG or STD 13 need to be identified and fixed.  A date for removal of workarounds for the
mis-implementations needs to be set (+5 years from publishing should be enough time) along
with a campaign to find at inform the server operators of broken servers.  Tests for WKK
behaviour should be added to delegated server tests and if we don’t go down this path vendors
that implement TSIG at least should be add BADKEY tests to their QA procedures, similarly
vendors that don’t implement TSIG need to add TSIG queries to their QA procedures.

The raw data for the table is available at https://ednscomp.isc.org and is regenerated towards
the end of the month.

Mark

> On 4 Mar 2019, at 10:52 pm, [email-masked] wrote:
>