-
Notifications
You must be signed in to change notification settings - Fork 140
ZFormationPSrouter
A Secure In-packet Bloom Filters based forwarding node is implemented.
This work was supported by TEKES as part of the Future Internet program of TIVIT (Finnish Strategic Centre for Science, Technology and Innovation in the field of ICT).
- Status :
- Version :
- Authors :
- NetFPGA source :
This work is continuation to the work done by Jari Keinänen at Ericsson's Research by the name zFilter . Among the many future networking projects, an EU FP7 project PSIRP and the Finnish national project ICT SHOK FI are evaluating new approaches to inter-networking. One of the most promising new ideas is to apply the publish/subscribe paradigm in the internetworking layer, instead of the currently dominant send/receive paradigm, which is used in most networking protocols today.
In-packet Bloom filters allow one to forward source-routed packets with minimal forwarding tables, the Bloom filter encoding the identities of the links the packet needs to be forwarded over. If the link identities are made content dependent, e.g. by computing the next-hop candidate link identifiers (Link IDs) by applying a cryptographic function over some information carried in the packet header, the Bloom filters differ pseudo-randomly from packet-to-packet, making the forwarding fabric resistant towards unauthorised traffic.
In this project, we have our early implementation and testing of an in-packet Bloom filters based forwarding node that implements cryptographically computed link identifiers. We have tested two different cryptographic techniques for the link-identity computation and thereby for making the forwarding decision. The algorithms have been implemented and tested on the Stanford NetFPGA.
The goal of zFormation project is to create a forwarding node prototype for a publish/subscribe networks that is secure and dynamically computes the link IDs using cryptographic techniques. The two techniques used are self-synchronizing stream cipher, Mostique and block cipher, Advanced Encryption Standard (AES). Implementation is based on reference switch design but it is modified so that forwarding decisions will be made based on secure and dynamically computed Bloom filters using the encryption schemes. In more detail, Bloom filters are included in the packet header, we call this zFormation, and all links are named with LinkID. Packets are then forwarded to links if the specific LinkID is contained in the Bloom filter. Further details about architecture and design can be found at zFormation.
- Secure In-packet Bloom-filters-based forwarding (see the zFormation)
- In-packet information computation using Moustique and AES separately and two separate implementations for each of them.
- Simple TTL for loop mitigation
- Packets are not sent back to port where they came from
- Defining ethernet protocol field
The source packet contains only sources for the project, reference lib files must be already installed. Those can be downloaded from Obtaining Gateware/Software Package. Download release 2.0.
Guide to use the reference designs can be found from NetFPGA guide. Kernel drivers and CPCI configuration are required and should be installed as described in that guide.
Sources for the project can be downloaded from zFormation project files. It contains two tar balls. One is zFormation implementation with Moustique and the other one is with AES.
We have implemented the central ideas of the Esteve at paper. Our solution dynamically computes the link identifiers on the basis of packet contents, the path the packet takes, and the node keys. In the following, we will use the term zFormation to designate our design, i.e. basically the dynamic computation of the link identifiers on per-packet packet-basis. The idea is that there is a function Z, essentially evaluated for each packet and for each potential outgoing interface, that gives out the indices of the k bits set to one in the m-bits long link identifier (Bloom mask). The function Z can be defined as
O = Z(K, M, I)
where the input parameters of Z are defined as follows:
- _K_ is a secret key that is changed periodically, e.g. once every few minutes, hours, or days.
- _M_ is a medium dynamic term that includes the incoming and outgoing interface indices.
- _I_ denotes some in-packet information that varies per packet, e.g. a counter that increases per packet basis.
Ki = KDF (K, Li )
where the term Li is a literal identifying the particular key.
The Key Derivation Function (KDF) is used to compute the three keys. These keys are used in the construction of zFormation in the following manner: O1 = F1 (K1 , S) where S denotes any (semi-)static inputs to the function.
O2 = F2 (K2 , O1 ||M ) where || denotes concatenation. Furthermore, if there are multiple potential actively valid values for M , it may be necessary to precompute and cache a set of corresponding O2 values. We call such a set of O2 values as O2 value set. O = O3 = F3 (K3 , O2 ⊗ I) where ⊗ denotes exclusive OR.
The functions F1 and F2 can be computed off-line, before packet processing, using a strong algorithm, e.g. HMAC-SHA-256. The function F3 needs to be performed on a per-packet bases, and thereby represents a compromise between security and performance. We use per-packet information, as an input value to the hash function, to make it infeasible to send other packets using an eavesdropped Bloom filter. That is, an active attacker may capture some packet and replay them a number of times, until one of the node keys is changed, but the attacker cannot send modified packets. When combined with per-packet caching or fingerprints, this prevents replay-based DoS attacks. In this paper, we consider two constructions, using a self synchronising stream cipher and a block cipher function.
The in-packet information I can be formed, for example, by using a packet a counter that is incremented once per packet, and then taking a cryptographic hash overc counter, using HMAC-SHA-256.
We have taken the previous implementation of in-packet Bloom Filter (iBF) based forwarding node zFilter on a NetFPGA and optimized it to our needs, as explained below. The basic forwarding method remains unmodified.
The difference here is instead of having fixed Link IDs (or Link ID Tags - LITs) we have dynamically computed identifiers of the links, on a per-packet basis. The dynamic Link IDs are computed using zFormation. We have two implementations for the computation. One is using the Moustique stream cipher and the other one is using AES block cipher. In each case, the Link IDs are computed using i) In-packet information (I), ii) a periodically changingkey (K3 ) and iii) the outgoing interface index (O2 ). The forwarding decision is simple binary AND and comparison operations, for the in-packet Bloom filter and the computed Link ID.
The adopted implementation utilizes only a limited set of modules from the Stanford reference switch, without modifying the rest. The main functionality is implemented in module called output_port_selector, where the forwarding decision takes place and the packet is placed on the correct output queue. For computing the dynamic Link IDs, a separate module moustique is implemented for the stream cipher, and aes_cipher_top for the block cipher. For each link, these modules are instantiated, in parallel with the output_port_selector module.
Prior to sending packets, the computed key K3 and the O2 value set are written into the NetFPGA registers from the user space. In our current implementation, the key K3 and the O2 values in the value set are both 256 bits each, as a result of HMAC-SHA-256 computed at the software side. In our current design, O2 consists of four values, each representing one port of NetFPGA. One 32-bit port is used for writing these values into the registers. Packets arrive in 64-bit pieces at each clock cycle. From the input_arbiter module, packets are sent into the SRAM and to the output_port_selector module, for computing the dynamic link IDs and then taking the forwarding decision. Along-with the forwarding decision that takes place in the do_zfiltering logic block, the three parallelized operations take place for the packet goodness verification, i.e. bit_counter, ethertype, and TTL checks.
For computing the dynamic Link IDs using F3 , two separate implementations were made, one for the Moustique stream cipher and the other for AES block cipher. Dynamic Link ID for each port is calculated separately using Moustique and AES. Both of them are explained as follows:
As the 96 bits of K3 register gets value from the user space, a control signal start_initialization is set to 1 and the initialization vector bits are applied at the cipher input for 105 clock cycles. The implementation then goes to a hold state, until a packet arrives. In the packet header, there comes the in-packet information (I). I is XORed with each value in the O2 value set (currently one for each port) and then applied to the cipher input of the Moustique module, with a control signal start_mostique set to 1. Moustique is instantiated four times, oncefor each outgoing port, for the NetFPGA in a parallel manner.
Our current Moustique implementation performs the ciphering in a single-bit fashion. Hence, the number of clock cycles to perform whole ciphering depends upon k. In our case, when k = 5 and m = 256, we need to perform only 40-bits of decryption, and hence it will take 40 clock cycles with the current implementation. With unrolling, we expect to get this down to maybe 5 cycles, depending on the details of the propagation delays. As soon as the decrypted data is ready, decrypted_data_ready is set to 1 by mostique for one clock cycle, so that decrypted data can be read by output_port_selector.
AES block cipher, with the key and block sizes of 128, is used for the computation of F3 . We used the Open-Cores AES implementation . As the in-packet information I arrives, it is XORed with the values in the O2 value set (one for each port). The data and the key K3 are loaded into the input of the cipher function, and start_AES is set to 1. AES is also instantiated four times for each outgoing port of the NetFPGA in aparallel manner.
The AES block cipher performs complete encryption sequence in 12 clock cycles, where the initial key expansion takes 1 clock cycle, 10 rounds take 10 clock cycles, and the output stage takes 1 clock cycle. As the encryption is finished, decrypted_data_ready is set to 1 and the output_port_selector reads the encrypted data.
The Bloom mask is then computed for each outgoing link. As in our case m = 256, each 8-bits of the decrypted data, from Moustique or AES, gives an index in Bloom mask where a 1 should be written.
In do-zfiltering, the actual matching is done for each outgoing link. For each interface, we have a single bit forming a bit-vector. These bits are set to 1 initially. Matching is done for each Bloom mask and in-packet Bloom filter (iBF) using AND and comparison operations. If there is a mismatch for a particular link, the corresponding bit gets zero.At the end, when the matching is finished for each Bloom mask, the bit vector shows the interfaces to forward the packet. Wherever we have one in the bit vector, the packet is forwarded on that interface. But still we have some other checks from the three verification functions.
The bit_counter module counts number of ones in the iBF. This is done to avoid attacks of setting all bits to one in iBF. The maximum allowed number of ones in a iBF is a constant value. If the iBF contains more number of ones than the constant value, the packet gets dropped. This module is implemented using only wires and logic elements. It takes 64 bits input and returns number of ones. It means for 256 bits iBF it takes 4 clock cycles to count the number of ones.
Currently, our iBF-based packets are identified using 0xacdc as the ethertype. This is checked upon the arrival of the packet. TTL is also checked to avoid loops in the network. If any of the three verification checks or the iBF matching itself fails, the packet is dropped.
The regression tests verify the functionality of the hardware component of the zFormation. As there are two implementations. First, do the regression tests for Moustique and later, repeat the same steps for AES. In order to run the tests we need to connect the cables as described in each of the regression test below. All the procedure should be done while being root. The path and procedure for regression test is also defined below. .bashrc should be updated with right paths for the project directory.
First download the bitfile into the NetFPGA
$ cd bitfiles $ nf2_download zformation_moustique.bit
OR bit file can be taken from the synth folder and then follow the instructions as stated below. ./program writes the K3 and O2 values into the NetFPGA's registers.
$ cd projects/zformation_moustique/synth/ $ nf2_download nf2_top_par.bit $ cd projects/zformation_moustique/regress/test_zformation/ $ make $ ./program
First download the bitfile into the NetFPGA
$ cd bitfiles $ nf2_download zformation_aes.bit
OR bit file can be taken from the synth folder as specified below and then follow the instructions as stated. ./program writes the K3 and O2 values into the NetFPGA's registers.
$ cd projects/zformation_aes/synth $ nf2_download nf2_top_par.bit $ cd projects/zformation_aes/regress/test_zformation/ $ make $ ./program
Five regression tests can be found at regress folder. In each of the regression tests some verifications are done by sending some pre-computed packets. These packets are sent using different ports and and as per computation, expected to receive on particular ports. All these are defined in each of the regression test below. Each test checks for arrival of packets on port defined, ethertype check, TTL check and maximum number of 1s defined in the link IDs.
For this test, connect eth1 and eth2 to any of the ports from nf2c0 to nf2c3. This test will send 10 packets from eth1. The pre-computed packet information iBF for this test matches with all the ports on NetFPGA except the one from which it receives the packets. The packets are then received using eth1.
$ ./regress1.sh
The expected output will be like
-- Test where iBF matches all the ports -- eth1 is connected to any of the ports -- eth2 is connected to any of the ports Test sending of 10 packets from eth1 to eth2 * Received 10 packets * PASSED Test sending of 10 packets from eth2 to eth1 * Received 10 packets * PASSED Test sending of 10 packets from eth1 to eth2, wrong ethertype * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, TTL = 0 * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, No. of 1s exceeding the limit * Received 0 packets * PASSED Failed tests: 0
For this test, connect eth2 to nf2c1 and eth1 to any other port. This test will send 10 packets from eth1. The pre-computed packet information iBF for this test matches with only nf2c1 and eth2 receives the packets. This test will fail if eth2 is connected to some other port.
-- Test where only nf2c1 matches -- eth2 is connected to nf2c1 -- eth1 is connected to any of the remaining ports Test sending of 10 packets from eth1 to eth2 * Received 10 packets * PASSED Test sending of 10 packets from eth1 to eth2, wrong ethertype * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, TTL = 0 * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, No. of 1s exceeding the limit * Received 0 packets * PASSED Failed tests: 0
For this test, connect eth2 to nf2c2 and eth1 to any other port. This test will send 10 packets from eth1. The pre-computed packet information iBF for this test matches with only nf2c2 and eth2 receives the packets. This test will fail if eth2 is connected to any other port.
-- Test where only nf2c2 matches -- eth2 is connected to nf2c2 -- eth1 is connected to any of the remaining ports Test sending of 10 packets from eth1 to eth2 * Received 10 packets * PASSED Test sending of 10 packets from eth1 to eth2, wrong ethertype * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, TTL = 0 * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, No. of 1s exceeding the limit * Received 0 packets * PASSED Failed tests: 0
For this test, connect eth2 to nf2c3 and eth1 to any other port. This test will send 10 packets from eth1. The pre-computed packet information iBF for this test matches with only nf2c3 and eth2 receives the packets. This test will fail if eth2 is connected to any other port.
-- Test where only nf2c3 matches -- eth2 is connected to nf2c3 -- eth1 is connected to any of the remaining ports Test sending of 10 packets from eth1 to eth2 * Received 10 packets * PASSED Test sending of 10 packets from eth1 to eth2, wrong ethertype * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, TTL = 0 * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, No. of 1s exceeding the limit * Received 0 packets * PASSED Failed tests: 0
For this test, connect eth2 to nf2c0 and eth1 to any other port. This test will send 10 packets from eth1. The pre-computed packet information iBF for this test matches with only nf2c0 and eth2 receives the packets. This test will fail if eth2 is connected to any other port.
-- Test where only nf2c0 matches -- eth2 is connected to nf2c0 -- eth1 is connected to any of the remaining ports Test sending of 10 packets from eth1 to eth2 * Received 10 packets * PASSED Test sending of 10 packets from eth1 to eth2, wrong ethertype * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, TTL = 0 * Received 0 packets * PASSED Test sending of 10 packets from eth1 to eth2, No. of 1s exceeding the limit * Received 0 packets * PASSED Failed tests: 0
There are 9 different tests for simulation verification. These tests need ModelSim installed. These are written using Perl script and can be found at path defined below. Each script has the capability to generate packets with computing the in-packet information separately for each packet using the cryptographic technique it uses. It calculates the in-packet information dependent upon keys K1, K2 and K3 with O1, O2 and O3. It writes the required information that is K3 and O2 values into the registers in NetFPGA. Caculates the PID and FID, packs them into the packet's header and sends using different ports.
//For Moustique $ projects/zformation_moustique/verif/ //For AES $ projects/zformation_aes/verif/
Test 1 can be run using
$ nf2_run_test.pl --major cryp --minor 1
Rest of the tests can be run by replacing the number after --minor from 1 to 9.
Ten packets are sent using port 1 that is nf2c0. They are expected to arrive on all the other ports except the port from which they are sent as their paths are included when calculating the in-packet bloom filter (iBF).
$ nf2_run_test.pl --major cryp --minor 1
The expected output at the end should be like this
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [0 packets]
Comparing simulation output for port 2 ...
Port 2 matches [10 packets]
Comparing simulation output for port 3 ...
Port 3 matches [10 packets]
Comparing simulation output for port 4 ...
Port 4 matches [10 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_1)
Test test_cryp_1 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_1
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
Ten packets are sent using port 2 that is nf2c1. They are expected to arrive on all the other ports except the port from which they are sent as their paths are included when calculating the in-packet bloom filter.
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [10 packets]
Comparing simulation output for port 2 ...
Port 2 matches [0 packets]
Comparing simulation output for port 3 ...
Port 3 matches [10 packets]
Comparing simulation output for port 4 ...
Port 4 matches [10 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_2)
Test test_cryp_2 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_2
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
Ten packets are sent using port 3 that is nf2c2. They are expected to arrive on all the other ports except the port from which they are sent as their paths are included when calculating the in-packet bloom filter.
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [10 packets]
Comparing simulation output for port 2 ...
Port 2 matches [10 packets]
Comparing simulation output for port 3 ...
Port 3 matches [0 packets]
Comparing simulation output for port 4 ...
Port 4 matches [10 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_3)
Test test_cryp_3 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_3
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
Ten packets are sent using port 4 that is nf2c3. They are expected to arrive on all the other ports except the port from which they are sent as their paths are included when calculating the in-packet bloom filter.
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [10 packets]
Comparing simulation output for port 2 ...
Port 2 matches [10 packets]
Comparing simulation output for port 3 ...
Port 3 matches [10 packets]
Comparing simulation output for port 4 ...
Port 4 matches [0 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_4)
Test test_cryp_4 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_4
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
Ten packets are sent using port 1 that is nf2c0. They are expected to arrive on all the other ports except the port 1 and port 2 because port1 is used to send the packets while port 2 is not included in the path while calculating iBF. Hence, there will be a mismatch at port 2. So no packets will arrive on port 1 and port 2.
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [0 packets]
Comparing simulation output for port 2 ...
Port 2 matches [0 packets]
Comparing simulation output for port 3 ...
Port 3 matches [10 packets]
Comparing simulation output for port 4 ...
Port 4 matches [10 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_5)
Test test_cryp_5 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_5
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
Ten packets are sent using port 1 that is nf2c0. They are expected to arrive on all the other ports except the port 1 and port 3 because port1 is used to send the packets while port 3 is not included in the path while calculating iBF. Hence, there will be a mismatch at port 3. So no packets will arrive on port 1 and port 3.
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [0 packets]
Comparing simulation output for port 2 ...
Port 2 matches [10 packets]
Comparing simulation output for port 3 ...
Port 3 matches [0 packets]
Comparing simulation output for port 4 ...
Port 4 matches [10 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_6)
Test test_cryp_6 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_6
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
Ten packets are sent using port 1 that is nf2c0. They are expected to arrive on all the other ports except the port 1 and port 4 because port1 is used to send the packets while port 4 is not included in the path while calculating iBF. Hence, there will be a mismatch at port 4. So no packets will arrive on port 1 and port 4.
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [0 packets]
Comparing simulation output for port 2 ...
Port 2 matches [10 packets]
Comparing simulation output for port 3 ...
Port 3 matches [10 packets]
Comparing simulation output for port 4 ...
Port 4 matches [0 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_7)
Test test_cryp_7 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_7
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
Ten packets are sent using port 1 that is nf2c0. Ethertype is set different from 0xacdc. Hence, no packets should arrive on any of the ports.
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [0 packets]
Comparing simulation output for port 2 ...
Port 2 matches [0 packets]
Comparing simulation output for port 3 ...
Port 3 matches [0 packets]
Comparing simulation output for port 4 ...
Port 4 matches [0 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_8)
Test test_cryp_8 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_8
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
Ten packets are sent using port 1 that is nf2c0. TTL is set to 0. Hence, no packets should arrive on any of the ports.
--- Simulation is complete. Validating the output.
Comparing simulation output for port 1 ...
Port 1 matches [0 packets]
Comparing simulation output for port 2 ...
Port 2 matches [0 packets]
Comparing simulation output for port 3 ...
Port 3 matches [0 packets]
Comparing simulation output for port 4 ...
Port 4 matches [0 packets]
Comparing simulation output for DMA queue 1 ...
DMA queue 1 matches [0 packets]
Comparing simulation output for DMA queue 2 ...
DMA queue 2 matches [0 packets]
Comparing simulation output for DMA queue 3 ...
DMA queue 3 matches [0 packets]
Comparing simulation output for DMA queue 4 ...
DMA queue 4 matches [0 packets]
--- Test PASSED (test_cryp_9)
Test test_cryp_9 passed!
------------SUMMARY---------------
PASSING TESTS:
test_cryp_9
FAILING TESTS:
TOTAL: 1 PASS: 1 FAIL: 0
-- Main.AdnanHassanGhani - 25 Jan 2011