nanog mailing list archives

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


From: Fernando Gont <fgont () si6networks com>
Date: Fri, 13 Jan 2017 16:35:36 -0300

On 01/12/2017 11:14 PM, Mark Andrews wrote:
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?

Because of the extra IPv6+ICMPv6 headers that you need for sending the
ICMP error, even if the original packet did have the entire IPv6 header
chain, you might be unable to include it in the ICMPv6 payload.

Yes, in practice you'd be fine dropping ICMP errors that don't embed a
full payload. Whether vendors do it or not, is a different question.

FWIW, it took me 6 years to publish RFC5927. And, because folks
*opposed* to it in tcpm wg, it was published as Informational, rather
than Std Track. RFC4443 points to it, still as informational thing that
you might want to do.

If we don't convey the right message in specs, not sure we can expect
good implementations, and even less flame the folk that tries to run his
network in the best possible way with "what he gets".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont () si6networks com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





Current thread: