 In the previous video, we explained what replay attacks are. In this video, we show how IPsec detects and deals with such attacks. The main idea to detect such attacks is to include in every packet a unique sequential number. If a certain number is received twice, the associated packet has already been received and will therefore be dropped. The sequence number of the first transmitted packet is 1 and gets incremented for each subsequent packet. Initially, the RFCs specified that the sequence number should have lengths of 32 bits. However, with the increase of link capacity, the standards also allowed the use of 64-bit extended sequence numbers. Since packets may arrive out of order, the receiver maintains a window of acceptable sequence numbers. The window is generally chosen to be 32 or 64 packets, although the receiver may decide to use a larger window. For simplicity, we will use in this video a received window of 4 packets and sequence numbers between 1 and 12. We will see that the highest received sequence number is 4 and that the other packets with sequence numbers in black, thus 3, 2 and 1, have also already been received. Assume the sender sends the next packet, which has sequence number 5. The receiver checks the sequence number of this packet and sees that sequence number 5 has not yet been received. It will therefore advance the pointer to the highest received sequence number to 5. Before doing that, it checks the integrity of the received packet first to ensure it is authentic and correct. Number 5 is now shown in black and the window is moved one position further. The next packet transmitted by the sender carries sequence number 6. But assume this packet gets delayed somewhere in the network. The next packet, with sequence number 7, may now overtake the previous packet and arrive earlier at the destination. The receiver will now advance the pointer to 7 and move the window two positions further. Numbers 4, 5 and 7 are shown in black, indicating that packets with these sequence numbers have already been received. Note that the color of number 6 remains gray to indicate that the packet with number 6 has not yet been received. Once the packet with sequence number 6 is received, the color of number 6 in the window changes into black to indicate that the packet with sequence number 6 has also been received and checked for integrity. Let's now assume that the man in the middle has captured the packet with sequence number 5 and replaced that packet. The packet will arrive with the receiver, but the receiver knows from the fact that number 5 has been marked black that a packet with that number has already been received. The receiver therefore knows that the packet has been replayed and will drop the packet. If a packet arrives with the sequence number below the lowest number in the window, the packet is also regarded as replay attack and will also be dropped. Be aware that IPsec windows and sequence numbers have no relationship with TCP windows and sequence numbers. With IPsec, sequence numbers are maintained to detect replay attacks. The IPsec window is needed to deal with out-of-sequence packets. The size of the window is determined by the receiver. The sender is not informed which sequence numbers have been received thus far and how many packets will fit into the window. The window site is not negotiated during the establishment of the Security Association. With TCP, sequence numbers are used to reorder out-of-sequence packets. The TCP window facilitates the retransmission of lost packets and the receiver sends acknowledgments to the sender of the sequence number that have been received thus far. The window is also used by the sender to perform flow control. In this video, we illustrated how IPsec uses sequence numbers and the window to detect replay attacks. The disadvantage of this approach is that both sender and receiver needs to maintain state information regarding which sequence numbers have already been used. Remembering state information is somehow against the principle of IP that says that IP packets should be treated as independent entities unrelated to other internet packets. An alternative approach to detect replay attacks is to include a time field in every packet. Although such approach would not require the maintenance of state information, a drawback of using time fields is that clocks at the sender and receiver site must be synchronized, for example by using NTP. Instead of absolute time, replay attacks can also be detected using time relative to the last reboot of the receiver. Version 3 of the Simple Network Management Protocol uses such mechanisms to detect replays.