Subject: [DNSOP] FYI: draft-andrews-dnsop-defeat-frag-attack

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jul 2019 16:21:11 +1000

I’ve written up a method to defeat UDP fragmentation attacks using TSIG.

https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00

If we are going to discuss methods to defeat such attacks this should be
considered.

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

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 10 Jul 2019 15:50:28 +0800

> If we are going to discuss methods to defeat such attacks this should be

+1

As an alternative, I also point to the following draft from 2015:
https://tools.ietf.org/html/draft-muks-dns-message-checksums-00

A BIND implementation of it is here:
https://github.com/muks/bind9/tree/dns-message-checksums

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Wed, 10 Jul 2019 18:00:54 +0000

i like marka's proposed solution below, a lot. and muks' is also clever, 
though requiring wire protocol changes. however, fujiwara-san's proposal 
describes a broader array of fragmentation problems than just integrity, and 
we should be looking at that broader array when making our plans.

i think there's a broader question about fragmentation itself. at the outset, 
i knew, when creating EDNS0, that fragmentation was considered harmful:

https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf

noting, jeff mogul and chris kanterjiev (kent), authors of the above tech 
report, were two of my mentors and bosses at d|i|g|i|t|a|l from 1988 to 1993, 
so, i read all of their work, and i discussed my questions and objections with 
them. fragmentation was, in ipv4, harmful. there can be no argument at this 
late date. i sinned egregiously in EDNS0 by opening the door to fragmentation, 
and the results have been predictably painful and expensive for everybody.

however, IPv6 intended to, promised to, and claimed to, fix V4 fragmentation's 
many defects. i must have been thinking optimistic thoughts about the IPv6 
time line, and IPv6's promises and intentions, when i opened the fragmentation 
door in EDNS0. what actually then happened was that ICMPv6 as required for 
PMTUD6 was not secure and could not be implemented, which means any 
fragmentation done in IPv6 (which unlike IPv4, is an endpoint-only activity) 
will be uninformed about path MTU. thus we make pessimistic assumptions like 
1500 and 1220. and if that's the kind of fragmentation we can actually get, 
then it's a negative value, and fragmentation in IPv6 is as bad, for different 
reasons, than in IPv4.

therefore, for the reasons set out by fujiwara-san in his recent draft posted 
here, and especially for the reasons spelled out by his extensive references, 
DNS should not use fragmentation. while some of kazunori's examples have to do 
with message integrity and attacks such as the shulman method, the case 
against fragmentation in DNS's use of UDP is immensely strong. solving for the 
integrity problems doesn't change our conclusion, and adds more complexity.

i have two final notes, which may help inform those who witnessed the sham 
consensus railroaded (soviet-style) through the recent DNS-OARC meeting in 
bangkok, and heard me speak against outlawing fragmentation as a 2020 Flag Day 
goal, and are now hearing me contradict myself.

---

first, we need fragmentation to work, which means we need path MTU discovery 
to work, which means we need ICMP to be secure, at least in IPv6. while use of 
fragmentation for DNS UDP has a high cost, the intentional investment of that 
cost would be a beneficial forcing function on fixing fragmentation itself. 
notably, TCP avoids fragmentation through its MSS signaling, which defaults to 
MIN(myMTU, herMTU) minus some fudge factor for protocol headers. which means 
lack of fragmentation does not hurt the web, and so nobody cares about it. but 
we should, all, care about it. i'll explain further in an upcoming article 
which i'll link here, but briefly, 1500 is the wrong LAN MTU for FastE, and is 
insanely small for 1GE, unthinkably wrong for 10GE, laughable for 40GE, and 
engineering malpractice for 100GE. for a test, do a bunch of NFS and SMB 
tests, over both UDP and TCP for each protocol, using jumbo grams (9K MTU) and 
then again using standard (1500 MTU) sized data grams. watch for transfer 
speed, CPU utilization, and network utilization (as bits, not as packets).

i will at some point teach FreeBSD TCP how to fragment its first TCP segment 
after synchronization, but only for IPv6. my goal is to force IPv4 fallback if 
IPv6 with all of its promised PMTUD and endpoint-only fragmentation does not 
work. let every network operator whose key performance indicators include IPv6 
deployment levels, begin to fear that without its PMTUD promises, IPv6 is not 
good enough to replace IPv4, and they will have to plan on investments in 
dual-stack, _forever_.

---

second, all mass is energy, and state in the network should be thought of as 
having mass. PMTUD has some scale problems regarding endpoint state 
requirements, and so, has to work well enough for fast LRU purges of state 
required for endpoint MTU information, which will lead to rapid rediscovery. 
but, TCP protocol control blocks are also state, and state has mass. a world 
in which every recursive iterating server has long-running TCP/853 (DoT) 
connections open to hundreds or thousands of authority servers is not going to 
be inexpensive, either for the initators or the responders. the web works this 
way, but can require tens of gigabytes of kernel memory for the TCP state 
alone. that's not a good ratio or mass to value. importantly, fragmentation 
has another state mass cost, which is transmitting the fragments with enough 
inter-packet gap to avoid microbursts which overflow the switch port buffers, 
and receiving fragments which must be reassembled before they can be 
delivered. all of this is wrong.

william simpson, perry metzger, and paul vixie (me) worked together about ten 
years ago to create TCP enhancements which would have permitted an unlimited 
number of quiescent but open TCP connections, at a per-connection state cost 
precisely equal to the cost of resisting a SYN flood attack. so, highly 
compressed state, because state mass is a high cost at the network-wide level. 
we also supported payloads large enough for DNS or WWW queries in the 
synchronization phase, fixed the security problems around RST, expanded the 
option header space, and saved the window size during periods of connection 
quiescence, allowing back-to-back-to-back transmissions once cookies had been 
exchanged. the result was RFC 6013, which was entirely ignored by the people 
who brought us TCPFO, which has the same incompressible state as TCP, adds no 
security, and reduces only the problem of round trip costs. the other document 
besides RFC 6013 that may be of interest is here:

https://www.usenix.org/system/files/login/articles/126-metzger.pdf

metzger, simpson, and vixie (me) are all notoriously difficult to work with, 
and this stems from correctable personality defects and unforced human 
protocols errors for which we should each be periodically upbraided. however, 
ignoring our work because we're somewhat irritating runs the risk of taking 
the internet itself down a blind alley from which a later return won't earn us 
thanks from the grandchildren.

---

in summary, the network needs working fragmentation so that it can have a 
future that isn't constrained by the physics of thickwire ten megabit 
ethernets, and if the DNS community were willing to join the fight, it would 
be a shorter fight. however, DNS, and UDP itself, is better off without 
fragmentation, because of state mass and complexity costs, regardless of 
whether we can solve fragmentation's integrity and substitution weaknesses.

-- 
Paul

---

From: Bob Harold <[email-masked]>
Date: Wed, 10 Jul 2019 16:45:52 -0400

> If we are going to discuss methods to defeat such attacks this should be

 Looks like a useful workaround.

2. The Well Known Key

The well known key has a owner name of "." and uses HMAC-SHA256
[RFC4635] as its algorithm with a key of 256 zero bits.

-- but later:

A.1. BIND 9

Add the following to named.conf. Some end-of-life versions do not
support HMAC-SHA256.

key "." {
algorithm hmac-sha256;
secret "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
};

-- Does a key of 256 zeros translate to a string of "A" characters?  I am
not an expert on HMAC-SHA256.

-- 
Bob Harold

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Jul 2019 07:12:29 +1000

AAAA is the base64 encoding of 3 zero octet.  If named was using a hex encoding it would be 000000. 

-- 
Mark Andrews

> On 11 Jul 2019, at 06:45, Bob Harold <[email-masked]> wrote:
> 
> 
> -- Does a key of 256 zeros translate to a string of "A" characters?  I am not an expert on HMAC-SHA256.
> 
> -- 
> Bob Harold

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Jul 2019 13:16:47 +1000

> On 11 Jul 2019, at 4:00 am, Paul Vixie <[email-masked]> wrote:
> 

IPv6 moved fragmentation to the originating node from the router to allow for
faster routers.

As for PMTUD and DNS/UDP it was clear in 1998 that DNS servers would need a
mechanism to avoid PMTUD issues so I proposed draft-ietf-ipngwg-bsd-frag (1998)
which got incorporated into RFC 3542 (2003) as IPV6_USE_MIN_MTU.  Named uses
that mechanism when the OS supports it.

Limiting transmitted EDNS/UDP responses just moves PMTUD issues to TCP unless
care is taken to limit MSS sizes.  This can be done by a number of mechanisms
but is not universally achievable.  DNS/TCP is not a panacea for DNS/UDP
fragmentation issues.

PMTUD is a issue for a number of reasons.  Routers still have PTB generation on
the slow path which means that it ends up getting rate limited.  PTB generation
should have been moved into ASICs a decade ago.  Firewalls that block PTB packets.
Packet load balancers that fail to look into the ICMP payload when forwarding PTB
messages.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Bob Harold <[email-masked]>
Date: Thu, 11 Jul 2019 10:28:26 -0400

Thanks for explaining that.  I leave it up to you if a comment to that
affect in the draft would avoid the same question in the future.

-- 
Bob Harold

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 15 Jul 2019 09:35:33 -0400

The chairs felt that fujiwara-san's draft was one that needed in person
discussion
in Montreal.

Also, if folks did not see his presentation at OARC, here are the slides:

https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf

Tim

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jul 2019 14:49:20 +0000

On Monday, 15 July 2019 13:35:33 UTC Tim Wicinski wrote:
> discussion in Montreal.

hopefully kazunori will suggest a bar bof for monday night. i leave tuesday 
morning and so will miss the WG meeting. my own concern is more for packet 
size than for fragmentation itself. i'd like to explain my concerns to 
$somebody.

> https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/

possibly to be argued, but to be not dismissed. as i wrote up-thread, the 
state mass of fragmentation, harshest on receivers but also present on 
transmitters, means the original EDNS0 spec ought to have said "SHOULD be of a 
size that allows the full packet with all headers to fit the local interface 
MTU and next-hop MTU" and possibly also "MAY set the DF bit if capable of 
hearing and interpreting ICMP messages".

-- 
Paul

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 15 Jul 2019 10:50:29 -0400

The chairs can work with kazunori on a Monday night discussion (okay, I'll
sign up).