GRE Security Mechanisms
GRE provides two types of security mechanisms:
Checksum Verification
Checksum verification is an end-to-end check on encapsulated packets.
If the C bit in the GRE header is set to 1, the checksum is valid. The sender calculates the checksum based on information in the GRE header and the payload and then sends the packet containing the checksum to the receiver. The receiver calculates the checksum based on information in the received packet and compares the calculated value with the checksum in the packet. If they are the same, the receiver forwards the packet. If they are different, the receiver discards the packet.
You can enable or disable checksum verification on both ends of a tunnel in actual applications. If checksum verification is enabled on the local end and disabled on the remote end, the local end does not check the checksum values of received packets, but checks the checksum values of packets to be sent. If checksum verification is disabled on the local end and enabled on the remote end, the local end checks the checksum values of received packets, but does not check the checksum values of packets to be sent.
Key Authentication
Key authentication is used to verify the validity of a tunnel interface. This security mechanism ensures that a device accepts only packets sent from a valid tunnel interface and discards invalid packets.
If the K bit in the GRE header is set to 1, a four-byte Key field is inserted into the GRE header. Both the receiver and the sender need to authenticate the key.
The Key field is used to identify the traffic in a tunnel. Packets transmitted over the same tunnel use the same key. During decapsulation, GRE identifies data packets based on the key. Packets pass key authentication only when the keys on both ends of the tunnel are consistent. Otherwise, packets failing the key authentication are discarded. When both ends of a tunnel have no key or the same key, the key configurations on the two ends are consistent.
Previous
