[193356] in North American Network Operators' Group
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
daemon@ATHENA.MIT.EDU (Fernando Gont)
Thu Jan 12 14:53:18 2017
X-Original-To: nanog@nanog.org
In-Reply-To: <CAAeewD96awiO=AVS-FUVNH=zgKM4ETj5Z9rjngE2OoizJMnG9g@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Date: Thu, 12 Jan 2017 16:53:13 -0300
To: Saku Ytti <saku@ytti.fi>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Many (most?) Implementations don't even check the embedded port
numbers...do tye attacker does not even need to guess the client port.
besides, becaude of ipv6 ehs, you're not really guaranteed to receive e.g.
the tcp header in the embedded payload (the embedded payload could easily
be fixed ipv6 header + ehs).
Cheers,
Fernando
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.
>
> --
> ++ytti
>
