While I haven't done a rigorous comparison of this idea to fwknop yet, a few initial thoughts come to mind. Sure, a single SYN is kind of cool, but:
- Obviously their architecture is highly Linux-specific, non-portable, and even requires userspace modification for any application that wishes to use it. None of these statements is true for fwknop (by design).
- Their use of a single round of MD5 against a shared secret and a few parameters like the destination IP and destination port doesn't really provide "stealth" (perhaps I missed their definition of this?). I mean, of their own admission, replay attacks aren't protected against, so presumably this means that each ISN sent through their code for each destination IP/port pair is identical unless the shared secret is manually changed. On the assumption that modern TCP stacks randomize ISN's (or at least follow some +N rule), it would not be difficult to write a detector for TCP connections that are gated by the 'knock' patch.
- Once 'knock' communications are detected, compromise of the source network implies complete compromise of 'knock' without knowledge of the key because there is no built-in defense against replay attacks. I suppose this is mostly damaging in the context of NAT from the source network - i.e. the specific end point system behind a NAT does not have to be compromised in order to also compromise 'knock' past the NAT. This is not true for fwknop.
- If stealth isn't really achieved (see above), then what is the advantage of patching the kernel as opposed to pursuing a userspace implementation? Further, if there isn't a really compelling reason to patch the kernel, there are a lot of reasons _not_ to patch the kernel.
- It seems that working with NAT can and should also imply some ability to support server-side NAT. This is fully supported by fwknop (iptables only for now, but ipfw and pf will follow).