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.
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.
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.
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.