Key and Sequence Number Extensions to GRE
updates
- rfc-2784 — Generic Routing Encapsulation (GRE)
Extracted elements (15)
The Key Present (bit 2) and Sequence Number Present (bit 3) bit positions were chosen to maintain compatibility with the original GRE specification RFC 1701, allowing interoperability with RFC 1701 implementations.
The sequence number is intended to provide unreliable but in-order delivery, not reliable delivery. Its use is recommended only when the tunneled protocol requires in-sequence delivery; it should be avoided when the carried protocol already has higher-layer in-order delivery or is tolerant to out-of-order arrival.
Packets without the Sequence Number bit set can be interleaved with packets that have the bit set. An in-sequence packet is defined as one with a sequence number exactly 1 greater (modulo 2^32) than the last successfully decapsulated packet, or one where the S bit is not set.
Reordering of out-of-sequence packets MAY be performed by the decapsulator for improved performance and tolerance to network reordering. A small per-flow reorder buffer (MAX_PERFLOW_BUFFER) may improve performance when higher-layer stateful compression or encryption is in use.
The Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver.
Under no circumstances should a packet wait more than OUTOFORDER_TIMER milliseconds in the reorder buffer. If a packet has waited that long, the receiver MUST immediately traverse the buffer in sorted order, decapsulating packets and ignoring sequence number gaps, until no packets have been waiting longer than OUTOFORDER_TIMER milliseconds.
When a decapsulator receives an out-of-sequence packet (sequence number less than or equal to that of the last successfully decapsulated packet), it SHOULD silently discard the packet.
If a newly arrived packet would cause the per-flow buffer to exceed MAX_PERFLOW_BUFFER packets, the packet at the head of the buffer is immediately decapsulated regardless of its sequence number, the last-decapsulated sequence number is set accordingly, and the new packet may then be placed in the buffer.
The Key field is a 4-octet value inserted by the encapsulator to identify an individual traffic flow within a tunnel. Packets belonging to a flow are encapsulated with the same Key value; the decapsulator uses the Key to distinguish flows. The method of obtaining the Key value is outside the scope of this document.
The Key Present bit (bit 2) in the GRE header flags presence of the 4-octet Key field. When set to 1, the Key field is present; otherwise it is absent. The Key field identifies an individual traffic flow within a tunnel.
The Sequence Number field is a 4-octet free-running counter (modulo 2^32) inserted by the encapsulator when the Sequence Number Present bit is set. The first datagram is sent with sequence number 0. If the Key bit is also set, the sequence number is specific to the traffic flow identified by the Key field.
The Sequence Number Present bit (bit 3) in the GRE header flags presence of the 4-octet Sequence Number field. When set to 1, the Sequence Number field is present; otherwise it is absent.
When using the Sequence Number field, an attacker can inject packets with arbitrary sequence numbers to launch a Denial of Service attack. To protect against such attacks, IP security protocols (IPsec) MUST be used to protect the GRE header and tunneled payload; either ESP or AH MUST be used. The Key field provides no security despite its name.
Upon establishment of the GRE tunnel, the receiver initializes the last successfully decapsulated sequence number to (2^32)-1. Subsequent in-sequence packets (sequence number exactly 1 greater modulo 2^32) are decapsulated and the counter updated; out-of-sequence packets (sequence number <= last received, within the preceding 2^31-1 range) are silently discarded.
The extended GRE header adds two optional fields: a 4-octet Key field (present when bit 2 is set) and a 4-octet Sequence Number field (present when bit 3 is set), appended after the optional Checksum/Reserved1 fields. Bit positions are chosen to be compatible with RFC 1701.