Summary

  • RFC 1701 gave GRE an optional four-octet Key and suggested that it might authenticate a packet’s source, but defined no way to create, distribute, protect or verify that claim.
  • RFC 2890 later made the boundary explicit: Key identifies one logical traffic flow inside a tunnel, and “despite its name” has no security role. Sequence Number can order that flow, but delivery remains unreliable.
  • An attacker able to inject an arbitrary Sequence value can advance receiver state and make legitimate packets look old. Classification and ordering become trustworthy only when a separate protection layer covers the GRE header and payload.

A field named before its authority was known

The word key arrives with expectations. In ordinary speech it opens something. In cryptography it selects or enables a protected transformation. In access control it may stand for a credential. A packet field bearing the name can therefore acquire authority in an operator’s mind before the protocol has earned it.

GRE’s history records that danger unusually clearly. RFC 1701, published as an Informational document in October 1994, proposed a general way to carry one network-layer protocol over another. A delivery header surrounded a GRE header, which in turn described the payload. The header could contain a checksum, routing information, a four-octet Key and a four-octet Sequence Number.

For the Key, the document said a receiver might use it to authenticate the packet’s source. The techniques for deciding authenticity were outside the specification. No algorithm generated the value. No exchange bound it to an endpoint. No freshness rule stopped reuse. No integrity mechanism kept an intermediary from changing it. No failure procedure distinguished a guessed value from a compromised one.

That sentence was not an authentication protocol waiting to be switched on. It was an unfilled interface. Two implementations could put the same four bytes on the wire while assigning them incompatible evidentiary weight.

Sequence Number had the same unfinished shape. RFC 1701 said the receiver might use the unsigned 32-bit value to establish transmission order, then left both generation and reception semantics outside the document. The field had a location, but not yet an interoperable state machine.

The base specification deliberately became smaller

RFC 2784 took a different approach in March 2000. It described the intersection of GRE behavior already deployed by multiple vendors and placed that small common form on the standards track. Its base header kept the Checksum-present bit, Version and Protocol Type. Protocol Type told the decapsulator what kind of payload followed. The earlier Key, Sequence and Routing positions were not silently reinterpreted.

Instead, bits 1 through 5 were treated as a compatibility boundary. A receiver had to discard a packet with any of them set unless it implemented RFC 1701. A transmitter following only RFC 2784 sent the reserved positions as zero. Separate interoperability sections explained how older transmitters and receivers could meet the new base.

This was restraint, not erasure. The common header included what cross-vendor running code could already share. Optional meaning that lacked the new contract remained visibly outside that compatibility set. A parser did not guess from a vendor name, tunnel address or operator intention.

The design also kept GRE’s authority narrow. The protocol specified encapsulation and decapsulation. It did not decide when a packet ought to enter the tunnel. That admission decision belonged to configuration and surrounding control systems.

RFC 2890 made Key useful by making it less grand

Six months later, RFC 2890 updated the base. It reused the RFC 1701 bit positions: K announced a four-octet Key; S announced a four-octet Sequence Number. The extension was wire-compatible with the earlier layout but no longer left the fields’ central duties to imagination.

The encapsulator inserts the Key. How it obtains the number remains outside the RFC. The decapsulator uses that number to identify an individual traffic flow within the tunnel, particularly when the encapsulated data lacks context needed for routing or treatment. Packets belonging to one flow carry the same value. The field creates a logical relationship between two tunnel endpoints.

That relationship is useful precisely because it is local. One outer tunnel can carry traffic that the receiving endpoint must direct into different contexts. A small number is cheaper than copying an entire control-plane explanation into every payload. The receiver needs only a deterministic mapping from the received value and tunnel context to its own flow state.

It proves no more than that. Anyone capable of inserting or altering a packet can copy a four-byte number. The value is not secret, does not carry a signature and does not say why the sender was entitled to select the flow. RFC 2890 closes the ambiguity in its Security Considerations: the Key field is not involved in any sort of security, despite its name.

The correction did not rename the field. It did something operationally stronger: it fixed the field’s claim. A Key could select context without being allowed to impersonate a credential.

Sequence supplied order, not delivery

The S extension added an executable receiver history. The encapsulator sends a free-running counter from zero through 2^32−1 and wraps modulo 2^32. The receiver remembers the number of the last packet it successfully decapsulated. When K is present, that state is specific to the logical flow identified by the Key.

A packet exactly one step ahead is in sequence. A sufficiently old or duplicate value is out of sequence and should be discarded silently. A value ahead but leaving a gap exposes missing or reordered traffic. The receiver may hold a small number of such packets in a per-flow buffer, wait briefly for the gap and then release what it has in order. When the wait or buffer limit ends, it can skip the missing numbers and advance.

The document names the result carefully: unreliable but in-order delivery. Sequence does not retransmit a missing payload. It cannot promise that the network will deliver every datagram. Bounded buffering only decides how long the decapsulator delays a newer packet in case an older one is still on the way.

Nor does S impose one total order on the whole tunnel. Packets without a Sequence Number may be interleaved with packets that carry one. With K present, separate Keys maintain separate sequence histories. “Newer” therefore means newer within the selected receiver context, not universally newer than every GRE packet observed on the link.

This distinction matters to evidence. A gap proves that the receiver did not successfully decapsulate every preceding number in that flow state. It does not by itself tell whether a packet was lost, reordered beyond the buffer, filtered, forged, reset with the tunnel or never transmitted.

A forged future can erase a legitimate present

The security failure follows directly from the otherwise useful state machine. Suppose the receiver last accepted Sequence 40. A malicious packet carrying the right tunnel addresses, a copied Key and a much later Sequence value reaches the decapsulator first. If no external mechanism authenticates the header, the receiver can advance its memory to the injected future. Legitimate packets that follow now appear old and are discarded.

RFC 2890 identifies arbitrary Sequence injection as a denial-of-service path. Its remedy is not a more impressive Key value or a larger counter. It requires IP security protection for the GRE header and tunneled payload. The decisive property is coverage: provenance and integrity must include the very fields that drive receiver state.

That is why Sequence Number is not anti-replay protection. An anti-replay window is meaningful only after a packet has been authenticated as belonging to the protected association. Without that prior test, the attacker can write the evidence against which later packets will be judged.

Encryption is also a separate question. A protected tunnel may authenticate without concealing a payload, or may provide both properties, depending on the surrounding mechanism and policy. GRE’s K and S bits choose neither. A successful flow lookup says nothing about confidentiality.

Later obligations did not inflate the Key

The base GRE specification did not stop evolving. RFC 9601, published in 2024, is recorded as another update to RFC 2784. It places GRE used between IP headers inside the modern rules for propagating Explicit Congestion Notification and adds safe ingress configuration requirements when the outer delivery protocol is IPv4 or IPv6.

That update is orthogonal to RFC 2890. ECN asks how congestion evidence crosses inner and outer IP headers. Key asks which logical flow context the endpoints select. Sequence asks how a receiver orders packets within the applicable flow. Protection asks whether the header and payload came from an accepted security association without alteration. One tunnel can exercise all four responsibilities, but no field inherits the authority of the others.

RFC 9601 also notes that GRE itself has no dynamic tunnel setup and configuration mechanism. Other control-plane protocols or static configuration may create the relationship. A packet capture can show K and S on the wire; it cannot, by itself, recover the agreement that assigned the Key or authorized the peer.

The honest operational question

An operator should never ask only, “Does the GRE key match?” The useful questions are layered. Which outer endpoint and configured tunnel supplied the namespace? Which local flow does the number select? Was K expected on this packet? Is S required for this flow? What was the previous accepted value, what gap or wrap occurred, and was the header inside an authenticated integrity boundary?

Counters need the same discipline. A rise in out-of-sequence discards may reflect reordering, duplication, buffer pressure, a state reset, inconsistent endpoint configuration or hostile injection. The counter records a receiver decision. It does not contain its own cause.

The historical achievement of RFC 2890 was therefore not that GRE acquired stronger-sounding fields. It was that running endpoints acquired smaller, testable claims. A Key could name context. A Sequence Number could order what that context received. Security remained a separate obligation whose evidence had to surround both.

Sources