ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

Fri Jan 13 22:58:21 UTC 2017

In message <af5a2b92-5b08-ed5f-ca7c-a94ff1de3d9c at si6networks.com>, Fernando Gont writes:
> On 01/12/2017 11:07 PM, Mark Andrews wrote:
> > In message <CAG6TeAt9eodf-OihH0vow25GFC-P__P+NO9yKMycBsUQhOpYuA at mail.gmail.com>
> > , Fernando Gont writes:
> >> El 12/1/2017 16:28, "Mark Andrews" <marka at isc.org> escribi=C3=B3:
> >>
> >>> In message <11ff128d-2fba-7c26-4a9c-5611433d85d2 at si6networks.com>, Fernando Gont writes:
> >>>> Hi, Saku,
> >>>>
> >>>> On 01/12/2017 11:43 AM, Saku Ytti wrote:
> >>>>> On 12 January 2017 at 13:19, Fernando Gont <fgont at si6networks.com>
> >>> wrote:
> >>>>>
> >>>>> Hey,
> >>>>>
> >>>>>> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280
> >>>>>> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are
> >>>>>> welcome).
> >>>>>
> >>>>> Generally may be understood differently by different people. If
> >>>>> generally is defined as single most typical behaviour/configuration,
> >>>>> then generally people don't protect their infrastructure in any way at
> >>>>> all, but fully rely vendor doing something reasonable.
> >>>>>
> >>>>> I would argue BCP is to have 'strict' CoPP. Where you specifically
> >>>>> allow what you must then have ultimate rule to deny everything. If you
> >>>>> have such CoPP, then this attack won't work, as you clearly didn't
> >>>>> allow any fragments at all (as you didn't expect to receive BGP
> >>>>> fragments from your neighbours).
> >>>>
> >>>> That's the point: If you don't allow fragments, but your peer honors
> >>>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector.
> >>>
> >>> And fragments are a *normal* part of IP for both IPv4 and IPv6.
> >>> This obsession with dropping all fragments (and yes it is a obsession)
> >>> is breaking the internet.
> >>
> >> Vendors got the frag reassembly code wrong so many times , that I
> >> understand the folk that decides to drop them if deemed unnecessary.
> > 
> > Most of them literally decades ago. 
> 
> Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been
> several one-packet crashes disclosed for Cisco's (an the list continues).

And they would have issued fixes for them.  Machines get attacked
from inside firewalls.  Only idiots do not apply security fixes.

> > 20+ years ago while you waited
> > for you vendor to fix the bug it made some sense as most of your
> > boxes were vulnerable.  It was a new threat back then.  It doesn't
> > make sense today.
> 
> Let's face it: The quality of many IPv6 implementations is that of IPv4
> implementations in the '90s. Sad, but true.

Not really.  For most of them the two stacks are in basically similar
states.  Most of the code is shared.

> > Packet bigger than 1500 are a part of todays internet.  Have a look
> > a the stats for dropped fragments.  They aren't for the most part
> > attack traffic.  Its legitmate reply traffic that has been requested.
> 
> I don't disagree with you wrt the need for fragmentation in some
> scenarios. I'm just saying that when you only employ TCP-based services,
> it may make sense to drop fragments targeted *at you*.
> 
> Fragmentation is only needed for non-TCP services. and if your system
> does not use non-tcp services, it may be a sensible thing to drop
> fragments targetted at you.

Firstly framentation happens with TCP and IPv6 today.  Just set
IPV6_USE_MIN_MTU on the socket.  It shouldn't happen as TCP is
supposed to use the MTU information on the socket but it doesn't
in many implementations.

Secondly there is no site that doesn't use protocols that send
fragmentent packets.  They will all be using DNS and DNS sends
fragmented UDP in its replies.  This has been the case since the
late 1990's.

Mark

> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org