People are praising the transparency of this report, but I am not sure I agree because of this point. when I read the report, I had to stop to think when I read the part about packet size to conclude that they had to be talking about an IPv6 packet using the hop-by-hop extension for fragmented packets. That is a special case, because you don't actually know the length of the packet until you receive the last fragment.

As a consequence, fragmented ipv6 packets are error for use in DoS attacks. This is not a "weird" occurrence, but rather an expected one, and since end points are not required to accept such huge packets, I am surprised Cloud flare want already doing all it could to advertise to upstream sources that IPv6 fragments longer than a much smaller than 90K should be dropped, at least if rooted to their DNS. I am also surprised that when their software came up with that kind of a response without first validating that it wouldn't cause the exact memory problem it did. Rules on v6 fragmented packets that can't match on a single fragment are inherently dangerous. It is only reasonable to have safe guards already in place for them.

I am also not sure this is really a bug in Juniper software. I imagine the memory problem only shows up with high traffic and in the midst of a DoS attack. That is kind of a given when you put a rule like that in that kind of a situation.

Yes but they were still seeing packets bigger than the MTU of Ethernet (or Sonet or whatever other layer 1/2 tech they're connected to the rest of the net with). It doesn't matter what higher level protocols can handle.

They could've been fragmented IPv6 packets. Or it could've been a bug in their profiler.

which is precisely why it seems like lunacy to roll out such an asinine firewall rule to every router. if there was ever a time to "spot check" a change, this was it.

they didn't. and they paid the price. good on 'em for the quick and honest post-mortem. regardless, it was a dumb move.

You are joking right? The packet size at the higher layer is what they were matching against. The size of the layer 2 packets is irrelevant.

Maybe, but nothing in the the rule they showed hinted it was not at layer 3 (For IPv4 )

It is at layer 3. IPv6 is layer 3.

If it was IPv6, I'd assume the routing rule on their blog contained IPv6 addreses, not IPv4 addresses, even if the blog faked the IP addresses.

Perhaps then you aren't aware that IPv6 stacks can reach IPv4 addresses, nor that IPv6 packets are a popular way to compromise systems that support both IPv6 and IPv4, because the IPv6 stacks are not as well hardened.