7 ms·

http://en.wikipedia.org/wiki/Jumbogram http://en.wikipedia.org/wiki/Jumbogram > An optional feature of IPv6, the jumbo payload option, allows the exchange of p

by naww 14y ago

http://en.wikipedia.org/wiki/Jumbogram http://en.wikipedia.org/wiki/Jumbogram > An optional feature of IPv6, the jumbo payload option, allows the exchange of packets with payloads of up to one byte less than 4 GiB

mprovost 14y ago
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.
- bdonlan 14y ago
  They could've been fragmented IPv6 packets. Or it could've been a bug in their profiler.
  - pyvpx 14y ago
    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.
- cbsmith 14y ago
  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.
  - noselasd 14y ago
    Maybe, but nothing in the the rule they showed hinted it was not at layer 3 (For IPv4 )
    - cbsmith 14y ago
      It is at layer 3. IPv6 is layer 3.
      - noselasd 14y ago
        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.
        cbsmith 14y ago
        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.
cbsmith 14y ago
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.

by naww 14y ago

mprovost 14y ago

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.

bdonlan 14y ago
They could've been fragmented IPv6 packets. Or it could've been a bug in their profiler.
- pyvpx 14y ago
  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.
cbsmith 14y ago
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.
- noselasd 14y ago
  Maybe, but nothing in the the rule they showed hinted it was not at layer 3 (For IPv4 )
  - cbsmith 14y ago
    It is at layer 3. IPv6 is layer 3.
    - noselasd 14y ago
      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.
      - cbsmith 14y ago
        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.

cbsmith 14y ago

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.