Walk through the code with the current MD5 spec. You need to terminate
the TCP session, check the MD5, then do the next checks. That is why
we're doing TTL check for GTSM and other classifying/queuing before the
TCP session termination. In the big equipment that ranges from
specialized ASIC checks, to raw queue classifiers, to ACLs .... All
before the packet gets punted out of the forwarding chip to the Route
Processor. In other equipment you do the check on the Line Card's CPU
after the punt - compartmentizing the impact of an attack. There is even
code in the 'coding queue' to do the check on CPU routers before you
terminate (still get the CPU clock cycle hit for dropping the packet).
Granted, you need to put this in context of how vendors should be
building security into their devices - layered - with a combination of
classification (i.e. ACLs), queuing (containing the impact), and systems
practices.
So go back to the instigating presentation:
http://www.nanog.org/mtg-0302/gill.html
Also check on one vendor's roadmap:
ftp://ftp-eng.cisco.com/cons/isp/security/BGP-Security/GTSM.pdf
So lets keep focused on the right issue - can you TTL filter before the
TCP session terminates vs worrying over the order of the multitude of
checks which take up processing the TCP packet.