RE: key change for TCP-MD5

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

So go back to the instigating presentation:

Also check on one vendor's roadmap:

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.