the core of the hack is the realisation that one can generate arbitrary tcp or udp packets from a browser by exploiting ip packet fragmentation (embed the evil packet in a large http post request that gets fragmented at just the right place).
and worst of all: i don't see a quick way to mitigate this. afaict, router firmware will need to be updated to check the fragment offset, right?
http://screenshots.portforward.com/routers/Arris/NVG468MQ_-_...
Does Disable mean disable the ALG? Or disable the passthrough and thus enable the ALG? You'll have to observe the traffic to find out.
(The internet generally believes it's the former. Me, I put mine into bridged mode because I use my own router anyway.)
... except these arbitrary tcp/udp packets will be in IP fragments and therefore invalid.
The whole thing hinges on the NAT code NOT reassembling IP packets before passing them to ALG and the ALG also not observing IP fragmentation. These are bugs, and pretty severe at that, so the mitigation is just to patch the code.
But, as gnfargbl points out, the TCP case can be caught by looking at the sequence number, or perhaps some conntrack state.
Go to your router's panel and disable sip support / alg. Even if you use sip, it's still going to work. (Apart from some really weird edge case network setups)
On OpenBSD, PF will reassemble fragmented packets by default.
Your question still stands, is this sufficient to prevent this attack? Perhaps someone who has a greater understanding of PF and of this exploit can respond.