Subject: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.

From: joel jaeggli <[email-masked]>
Date: Sat, 15 Jun 2013 15:28:56 +0200

I'm interested in the intersection between the requested payload size 
and the use of the v6 fragmentation header, 6891 I think is missing some 
advice to implementers that might reasonably prevent fragmented replies 
from being dropped and limit the degree of amplification that can be 
achieved with large RRsets.

Are there thoughts about this based on experience?

thanks
joel

---

From: Mark Andrews <[email-masked]>
Date: Mon, 17 Jun 2013 16:15:03 +1000

> achieved with large RRsets.

Fragments get dropped because of badly configured/designed firewalls
and PMTUD.  Setting IPV6_USE_MIN_MTU to 1 helps with the latter
though it may result in a addition fragment being sent.

If one really wants to play games you set IPV6_USE_MIN_MTU to 1 for
DNS UDP responses bigger than 1432 octets and leave it at -1 for
mesages 1432 octets and less.  1432 octets allows for both a IPv4
and IPv6 header over ethernet without fragmenting.  There is still
a lot of 6in4 and 6to4 tunnels.

TCP should always set IPV6_USE_MIN_MTU to 1 as PMTUD takes too long
for DNS and is unreliable. Except for a zone transfers the most it
will add is 5 additional packets (+ possible acks) to the transaction
and usually no more than 1.

> _______________________________________________
> 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: Erik Kline <[email-masked]>
Date: Mon, 17 Jun 2013 11:33:44 -0700

> though it may result in a addition fragment being sent.

Unfortunately the former are far too prevalent.  It's undoubtedly too
late, but unfortunately it might have been better to do the
fragmentation within the UDP payload (i.e. inside DNS) somehow (c.f.
http://tools.ietf.org/html/rfc5405#section-3.2).

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Jun 2013 10:49:05 +1000

> http://tools.ietf.org/html/rfc5405#section-3.2).

It is *never* too late.  For IPv6 we are still in the very
early days.

Firewalls could just as <src,dest,next header udp,frag!=0> when
they add <src,dest,udp,port,port> tuple today for reply traffic.
This make the hole for fragments a slit rather than wide open.

One could extend IPv6 to add a ignorable hop-by-hop option that
contains a copy the UDP header and add that when fragmentation is
done.  This would reduce the slit to a point.  If the firewall is
reassembling this would be used to protect the reassembly queue.

Mark

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 17 Jun 2013 21:31:56 -0400

> It is *never* too late.  For IPv6 we are still in the very

but, what about the 'vast install base'  ?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Jun 2013 12:19:29 +1000

> but, what about the 'vast install base'  ?

There isn't a "vast install base" of firewalls (border routers).
If there was we would have 99% IPv6 traffic instead of 1.6% IPv6
traffic.

The key is to get the functionality into firewalls/load balancer
etc. ASAP.  Hosts can happen as they are replaced as part of normal
refresh cycles or apps can use raw sockets if they need the
functionality sooner.  The IPv6 layer will fragment the raw packets
with the hop-by-hop header fine.

Mark

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 17 Jun 2013 23:41:14 -0400

> If there was we would have 99% IPv6 traffic instead of 1.6% IPv6

I forgot my :) in my comment.
anyways...

-chris

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 17 Jun 2013 20:44:17 -0700

Lets just say if you think the IPv4 fragmentation problem is bad, IPv6 makes it look positively benign by comparison on the IPv6 kit deployed today.

Basically, use a 1400B EDNS0 mtu, and failover to TCP.

---

From: [email-masked]
Date: Tue, 18 Jun 2013 10:47:53 +0200 (CEST)

> If there was we would have 99% IPv6 traffic instead of 1.6% IPv6

I'm afraid I have to disagree. There is a significant installed base
of border routers doing *stateless* firewall functions for various
reasons. Some of these border routers already have IPv6 turned on,
and many more of them *will* have IPv6 turned on in the near future.

Changes to IPv6 handling that require new software for these routers
is certainly possible - you "only" need to sell such a change to the
vendors. 

Changes that require hardware replacement (and therefore significant
capex) are obviously much harder.

Steinar Haug, AS 2116

---

From: joel jaeggli <[email-masked]>
Date: Tue, 18 Jun 2013 11:00:05 +0200

>> If there was we would have 99% IPv6 traffic instead of 1.6% IPv6
So I like the assumption that I should limit edns0 responses to 
something  I don't have to fragment.

My goal as it were was to look at if fragmentation were expected to work 
that I don't really want to expose myself to reciving a 4k response (via 
UDP) because the risk of an amplification attack becomes very large 
indeed. Even if I filter fragments (because I have to or as a product of 
limitations such an attack my be targeted at the infrastructure rather 
than the endpoint that's the notional target.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Jun 2013 01:22:47 +1000

> than the endpoint that's the notional target.

Yet fragmented packets work fine if you don't put a middle box in the
middle that has a conniption when it sees a fragmented packet.

As for being exposed you really can't prevent being exposed.

As for not replying with fragmented packets, that it self causes
operational problems as you move the traffic to TCP which unless
you have taken measures to reduce the sement sizes runs the risk
of PMTUD problems.  Some of the ORG servers limit the UDP size then
don't do PMTUD well which is a real pain if you are behind a tunnel.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 18 Jun 2013 08:27:53 -0700

> middle that has a conniption when it sees a fragmented packet.

This is practically every box on IPv6.  Fragments REALLY don't work on IPv6.

> don't do PMTUD well which is a real pain if you are behind a tunnel.

IPv6 is much better on PMTU discovery than IPv4, and with IPv6, you can always just set to use the minimum IPv6 (1200B) MTU and bypass all PMTU discovery anyway.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Jun 2013 08:43:15 +1000

> This is practically every box on IPv6.  Fragments REALLY don't work on

Which is not correct given the successful IPv6 reassembly counters
on my IPv6 boxes which are recursive servers.  Yes there is a IPv6
firewall in front of and on these boxes.

Hop-by-hop also cross the Internet fine.

Remember most of the firewalls are dropping fragmented UDP because
they can't identify if the fragment is part of a packet they are
allowing through.  Give the firewalls a way to identify that a UDP
fragments is part of a such a packet and they will be allowed through
/ reassembled and allowed through if dpi is being done and dpi is
often turned off on firewalls for DNS packets even when it defaults
to on.

6 to 8 extra octets per fragment would allow this.

Assuming this is the only hop-by-hop option and the fragment header
is next one would add the following and the next header option in
the IPv6 header would be zero.

	<44><0><tbd,4,src-port,dst-port>

and tbd would start with 000 <skip if unknown=00> and <unchanging=0>.

Mark

ip6:
	1883580 total packets received
	2604 fragments received
	0 fragments dropped (dup or out of space)
	68 fragments dropped after timeout
	0 fragments that exceeded limit
	1266 packets reassembled ok
	976983 packets for this host
	342821 packets not forwardable
	1643642 packets sent from this host
	32050 output packets discarded due to no route
	254 output datagrams fragmented
	508 fragments created
	12 packets that violated scope rules
	342753 multicast packets which we don't join
	Input histogram:
		hop by hop: 1055
		TCP: 934449
		UDP: 47301
		fragment: 2604
		ICMP6: 898170
	Mbuf statistics:
		319754 one mbuf
		two or more mbuf:
			lo0= 264312
		1299514 one ext mbuf

ip6:
	805638 total packets received
	831 fragments received
	0 fragments dropped (dup or out of space)
	11 fragments dropped after timeout
	0 fragments that exceeded limit
	410 packets reassembled ok
	380419 packets for this host
	409513 packets forwarded
	4502 packets not forwardable
	389337 packets sent from this host
	4485 multicast packets which we don't join
	Input histogram:
		hop by hop: 271
		TCP: 748570
		UDP: 12234
		fragment: 1060
		ICMP6: 43503
	Mbuf statistics:
		575 one mbuf
		805063 one ext mbuf
	source addresses on an outgoing I/F
		159 node-locals
		222 link-locals
		30757 globals
	source addresses on a non-outgoing I/F
		2 globals
	source addresses of same scope
		159 node-locals
		222 link-locals
		30759 globals
	568305 forward cache hit
	232283 forward cache miss

> IPv6 is much better on PMTU discovery than IPv4, and with IPv6, you can
> always just set to use the minimum IPv6 (1200B) MTU and bypass all PMTU
> discovery anyway.
>