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