[193366] in North American Network Operators' Group
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
daemon@ATHENA.MIT.EDU (Mark Andrews)
Thu Jan 12 21:15:03 2017
X-Original-To: nanog@nanog.org
To: Fernando Gont <fgont@si6networks.com>
From: Mark Andrews <marka@isc.org>
In-reply-to: Your message of "Thu, 12 Jan 2017 17:19:42 -0300."
<CAG6TeAt5pZJzoU0qDeTHgWEETnnib3hOLg-=bCv_1MBZJbew1g@mail.gmail.com>
Date: Fri, 13 Jan 2017 13:14:50 +1100
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
In message <CAG6TeAt5pZJzoU0qDeTHgWEETnnib3hOLg-=bCv_1MBZJbew1g@mail.gmail.com>
, Fernando Gont writes:
> El 12/1/2017 16:32, "Saku Ytti" <saku@ytti.fi> escribi=C3=B3:
>
> On 12 January 2017 at 17:02, Fernando Gont <fgont@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@isc.org
