Checking the fragment offset is the right way to run the ALG but the router really shouldn't be running a SIP ALG by default either. Not only do most home users not use SIP but most SIP users don't need the ALG. Browsers could also block the ports but that's a hack to work around the issue not a proper fix.

i have good news, the routers spectrum began sending out this year not only have SIP ALG enabled but no way to disable it. in fact, just about the only thing you can change is DNS, and only via a smartphone app(!)

My new-ish TP-Link router also has SIP ALG enabled by default.

Could be worse. You could have a router with a quantum ALG.

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

But is it vulnerable to ignoring fragmentation offset?

> arbitrary tcp and udp packets

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

It only depends on IP fragmentation to forge UDP datagrams. It forges TCP segments by padding the previous segment.

But, as gnfargbl points out, the TCP case can be caught by looking at the sequence number, or perhaps some conntrack state.

Which won't happen in almost 100 procent of devices.

> i don't see a quick way to mitigate this

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)

Browsers can add the SIP port (5060) to the restricted ports blacklist.

Preventing one specific implementation of the attack concept without actually solving the problem.

Am I safe with "scrub in all fragment reassemble" in my PF config on my router box?

Which OS are you running with PF?

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.

PF doesn't implement any ALGs by default. To my knowledge, it doesn't even have any ALG capability. So, this type of attack would not work through a NAT implemented by PF unless you have separately added an ALG via hooks (like ftpsesame).