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

Fri Jan 13 02:14:50 UTC 2017

In message <CAG6TeAt5pZJzoU0qDeTHgWEETnnib3hOLg-=bCv_1MBZJbew1g at mail.gmail.com>
, Fernando Gont writes:
> El 12/1/2017 16:32, "Saku Ytti" <saku at ytti.fi> escribi=C3=B3:
> 
> On 12 January 2017 at 17:02, Fernando Gont <fgont at si6networks.com> wrote:
> > That's the point: If you don't allow fragments, but your peer honors
> > ICMPv6 PTB<1280, then dropping fragments creates the attack vector.
> 
> Thanks. I think I got it now. Best I can offer is that B could try to
> verify the embedded original packet? Hopefully attacker won't have
> access to that information. An if attacker has access to that
> information, they may as well do TCP RST, right?
> 
> Didn't we have same issues in IPv4 with ICMP unreachable and frag
> neeeded, DF set? And vendors implemented more verification if the ICMP
> message should be accepted.
> 
> 
> Yes and no.
> 
> 1) there was no way in v4 to trigger use of fragmentation for an arbitrary
> flow.
> 
> 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload.
> In ipv6, you aren't (think ipv6 EHs)

So drop the packet if you don't get to the end of the extension
headers in the ICMPv6 payload.  Has anyone, except in testing, seen
a extension header chain that was not fully containable in the
ICMPv6 payload?

Mark

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