Cryptographic protocols like IPsec (RFC 4301, RFC 4303) require duplicated packets to be detected and dropped. It is a necessity, as packet replay attacks can exploit weaknesses in the underlying protocols that the encryption is trying to protect.
The Synogate Anti-Replay Core implements such a packet replay detection as a RTL design capable of handling 200G line rate on suitable FPGAs. For a number of connections, it stores and manages a bitmap that keeps track of seen and yet unseen packages. Checks and updates are very fast, allowing the core to sustain a guaranteed throughput of one packet per clock cycle.
The IP-core is provided as a configurable generator which outputs vhdl code as well as sdc/xdc files, tcl scripts for easy integration, and dynamic documentation for the specific configuration. The generator can output vhdl code with vendor specific macros for Intel and Xilinx devices, or vendor agnostic vhdl code.
Feel free to download and evaluate the core. Contact us if you have questions or want to license it.
|Number of connections||Configurable|
|Sequence number size||Configurable|
|Storage type||On-chip or external fixed-latency memory mapped interface (e.g. for external QDR eSRAM)|
|Throughput||One query&update operation per clock cycle at a fixed but configurable latency. This equates to > 200G line rate on suitable FPGAs.|
|Input/Output||Avalon Streams with configurable signals for payload (e.g. network packets) commands and results piggybacked to input/output streams.|
|Price for evaluation and non-commercial use||Free|
|Price for commercial use||20000 €|
|Connections||Window size||Pipelining||Storage||Device||Fmax [MHz]||ALM||FF||M20K|
The IP-core can sustain one check/update per clock cycle and synthesizes at up to 500MHz on modern FPGAs resulting in a throughput of hundreds of millions of packets per second. Since the throughput is fixed, the IP-core can not be DOSed by saturating with specifically crafted traffic.
The IP-Core is shipped as a generator that allows configuration of all relevant aspects. This allows to adjust the IP-core to your specific needs and, if need be, readjust it if requirements change during the
Adjust capacities, payloads and channels, storage types, or even pipelining amount simply by rerunning the generator. This allows you to adapt the IP-core to changing requirements even after purchase.
With this IP-core, you are not committing to a specific target device or even device vendor.
The generator exports the RTL design as regular vhdl 2008 code that can be used in common tool chains. Project files and tcl scripts for easy testing/integration can also be provided by the generator. Optionally, the generator can be configured to use vendor specific macros in the vhdl code.
The generator can be configured to use on-chip storage (e.g. block rams) or provide a memory mapped interface for connecting external storage such as QDR eSRAM.
The latency of the external memory can be configured in the generator which will automatically build the necessary read-during-write and read-modify-write hazard logic.
Since you can change configurations even after purchase, you gain the flexibility to free up on-chip resources if later stages of your development reveal that you need them.
Since the IP-core is often used as part of a packet processing pipeline, a packet based interface is provided with Avalon packet input and output streams onto which the command and result streams piggyback. The packet payload and additional side channel information can be piped through the IP-core. The generator automatically builds a fifo for the Avalon packet stream to bridge the latency of the IP-core and keep the results of the replay detection synchronous with the packet beats.
The product is bundled with detailed documentation explaining the involved algorithms, the available configuration parameters and their tradeoffs, as well as how to use the generator. For the specific configuration chosen, the generator also performs tests with an internal cycle-exact simulator that runs the driver and logic in a closed loop to verify design correctness. A specific interface documentation for the chosen configuration is also generated that shows and describes the exact functional blocks, associated signals, and waveforms.