[dns-operations] [Ext] DNS Flag Day 2020 will become effective on 2020-10-01

[Mark Andrews]

There are a number of issues.

Stupid firewalls that block fragments.  99.9% of the time they are just in front of the client and can be fixed.  Occasionally they are just in front of the server.  The core of the network actually passes fragmented packets fine.

Stupid firewalls that block PTB messages.  Solution, fragment at network MTU.
Stupid middle boxes (load balancers) that can’t process PTBs.  Solution, fragment at network MTU.

Retries from the client not hitting the same server instance so PTB’s are not effective at reducing transmission sizes.  Solution, fragment at network MTU.

There is rate limiting of PTB generation.  Solution, fragment at network MTU.

Fragmentation reassembly attacks.  They really aren’t achievable with IPv6 if the server doesn’t use predictable fragmentation ids (no id++).  TSIG can defeat reassembly attacks in both IPv4 and IPv6.  Using a well known TSIG will defeat off path fragmentation reassembly attacks.  IPv6 went to 32 bit fragmentation ids for a reason.

Firewalls can also be much smarter about dynamically generated rules for fragments.  You don’t have to allow all fragments through to get reply traffic through.  You have the source, destination and transport to filter on for non zero offset packets.  You can reject zero offset packets that don’t have a complete headers. 

There is still early adaptor bias in the IPv6 measurements.  Time will fix that.

Reflection attacks are controlled by response rate limiting and DNS COOKIE.

Servers need to be fixed to that their reply traffic doesn’t trigger PTB messages.

Servers need to honour the EDNS buffer size the client advertises.  Don’t second guess.

Client should default to a size that won’t trigger fragmentation with fixed servers.

Mark 

> On 16 Sep 2020, at 12:08, Paul Ebersman <list-dns-operations at dragon.net> wrote:
> 
> bsomers> My argument goes something like this.  When a DNS request is
> bsomers> sent, the client (whether a stub or a resolver) is the most
> bsomers> qualified to know specifics about the "connection" and is also
> bsomers> the target of fragmentation attacks.
> 
> I'd go the other end of the spectrum. I'd argue that neither client nor
> server has any clue of what horrible network crap lies in the
> path. There are so many badly implemented boxes built on the assumption
> that they have some right to muck with packets passing through them but
> with no skin in the game that end to end has to work.
> 
> If you buy that assumption, smaller default is less operational risk.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org