In message <[email protected]>, Nicholas
Weaver writes:
>
> On Jun 18, 2013, at 8:22 AM, Mark Andrews <[email protected]> wrote:
> >> 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.
> >
> > 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.
>
> This is practically every box on IPv6. Fragments REALLY don't work on
> IPv6.
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
> > 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.
>
> 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.
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
