GRE key and sequence: Key and Sequence Number Extensions to GRE
Two optional GRE header fields: one labels the traffic flow inside a tunnel, the other keeps packets in order.
Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.
@misc{rfc2890,
series = {Request for Comments},
number = 2890,
howpublished = {RFC 2890},
publisher = {RFC Editor},
doi = {10.17487/RFC2890},
url = {https://www.rfc-editor.org/info/rfc2890},
author = {G. Dommety},
title = {{Key and Sequence Number Extensions to GRE}},
pagetotal = 7,
year = 2000,
month = sep,
} RFC text
Contents
Network Working Group G. Dommety
Request for Comments: 2890 Cisco Systems
Category: Standards Track September 2000
Key and Sequence Number Extensions to GRE
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
GRE (Generic Routing Encapsulation) specifies a protocol for
encapsulation of an arbitrary protocol over another arbitrary network
layer protocol. This document describes extensions by which two
fields, Key and Sequence Number, can be optionally carried in the GRE
Header [1].
1. Introduction
The current specification of Generic Routing Encapsulation [1]
specifies a protocol for encapsulation of an arbitrary protocol over
another arbitrary network layer protocol. This document describes
enhancements by which two fields, Key and Sequence Number, can be
optionally carried in the GRE Header [1]. The Key field is intended
to be used for identifying an individual traffic flow within a
tunnel. The Sequence Number field is used to maintain sequence of
packets within the GRE Tunnel.
1.1. Specification Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
In addition, the following words are used to signify the requirements
of the specification.
Silently discard
The implementation discards the datagram without further
processing, and without indicating an error to the
sender. The implementation SHOULD provide the
capability of logging the error, including the contents
of the discarded datagram, and SHOULD record the event
in a statistics counter.
2. Extensions to GRE Header
The GRE packet header[1] has the following format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The proposed GRE header will have the following format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Present (bit 2)
If the Key Present bit is set to 1, then it indicates that the
Key field is present in the GRE header. Otherwise, the Key
field is not present in the GRE header.
Sequence Number Present (bit 3)
If the Sequence Number Present bit is set to 1, then it
indicates that the Sequence Number field is present.
Otherwise, the Sequence Number field is not present in the GRE
header.
The Key and the Sequence Present bits are chosen to be
compatible with RFC 1701 [2].
2.1. Key Field (4 octets)
The Key field contains a four octet number which was inserted by the
encapsulator. The actual method by which this Key is obtained is
beyond the scope of the document. The Key field is intended to be
used for identifying an individual traffic flow within a tunnel. For
example, packets may need to be routed based on context information
not present in the encapsulated data. The Key field provides this
context and defines a logical traffic flow between encapsulator and
decapsulator. Packets belonging to a traffic flow are encapsulated
using the same Key value and the decapsulating tunnel endpoint
identifies packets belonging to a traffic flow based on the Key Field
value.
2.2. Sequence Number (4 octets)
The Sequence Number field is a four byte field and is inserted by the
encapsulator when Sequence Number Present Bit is set. 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.
The intended use of the Sequence Field is to provide unreliable but
in-order delivery. If the Key present bit (bit 2) is set, the
sequence number is specific to the traffic flow identified by the Key
field. Note that packets without the sequence bit set can be
interleaved with packets with the sequence bit set.
The sequence number value ranges from 0 to (2**32)-1. The first
datagram is sent with a sequence number of 0. The sequence number is
thus a free running counter represented modulo 2**32. The receiver
maintains the sequence number value of the last successfully
decapsulated packet. Upon establishment of the GRE tunnel, this value
should be set to (2**32)-1.
When the decapsulator receives an out-of sequence packet it SHOULD be
silently discarded. A packet is considered an out-of-sequence packet
if the sequence number of the received packet is less than or equal
to the sequence number of last successfully decapsulated packet. The
sequence number of a received message is considered less than or
equal to the last successfully received sequence number if its value
lies in the range of the last received sequence number and the
preceding 2**31-1 values, inclusive.
If the received packet is an in-sequence packet, it is successfully
decapsulated. An in-sequence packet is one with a sequence number
exactly 1 greater than (modulo 2**32) the last successfully
decapsulated packet, or one in which the sequence number field is not
present (S bit not set).
If the received packet is neither an in-sequence nor an out-of-
sequence packet it indicates a sequence number gap. The receiver may
perform a small amount of buffering in an attempt to recover the
original sequence of transmitted packets. In this case, the packet
may be placed in a buffer sorted by sequence number. If an in-
sequence packet is received and successfully decapsulated, the
receiver should consult the head of this buffer to see if the next
in-sequence packet has already been received. If so, the receiver
should decapsulate it as well as the following in-sequence packets
that may be present in the buffer. The "last successfully
decapsulated sequence number" should then be set to the last packet
that was decapsulated from the buffer.
Under no circumstances should a packet wait more that
OUTOFORDER_TIMER milliseconds in the buffer. If a packet has been
waiting that long, the receiver MUST immediately traverse the buffer
in sorted order, decapsulating packets (and ignoring any sequence
number gaps) until there are no more packets in the buffer that have
been waiting longer than OUTOFORDER_TIMER milliseconds. The "last
successfully decapsulated sequence number" should then be set to the
last packet so decapsulated.
The receiver may place a limit on the number of packets in any per-
flow buffer (Packets with the same Key Field value belong to a flow).
If a packet arrives that would cause the receiver to place more than
MAX_PERFLOW_BUFFER packets into a given buffer, then the packet at
the head of the buffer is immediately decapsulated regardless of its
sequence number and the "last successfully decapsulated sequence
number" is set to its sequence number. The newly arrived packet may
then be placed in the buffer.
Note that the sequence number is used to detect lost packets and/or
restore the original sequence of packets (with buffering) that may
have been reordered during transport. Use of the sequence number
option should be used appropriately; in particular, it is a good idea
a avoid using when tunneling protocols that have higher layer in-
order delivery mechanisms or are tolerant to out-of-order delivery.
If only at certain instances the protocol being carried in the GRE
tunnel requires in-sequence delivery, only the corresponding packets
encapsulated in a GRE header can be sent with the sequence bit set.
Reordering of out-of sequence packets MAY be performed by the
decapsulator for improved performance and tolerance to reordering in
the network. A small amount of reordering buffer
(MAX_PERFLOW_BUFFER) may help in improving performance when the
higher layer employs stateful compression or encryption. Since the
state of the stateful compression or encryption is reset by packet
loss, it might help the performance to tolerate some small amount of
packet reordering in the network by buffering.
3. Security Considerations
This document describes extensions by which two fields, Key and
Sequence Number, can be optionally carried in the GRE (Generic
Routing Encapsulation) Header [1]. When using the Sequence number
field, it is possible to inject packets with an arbitrary Sequence
number and launch a Denial of Service attack. In order to protect
against such attacks, IP security protocols [4] MUST be used to
protect the GRE header and the tunneled payload. Either ESP
(Encapsulating Security Payload) [5] or AH (Authentication Header)[6]
MUST be used to protect the GRE header. If ESP is used it protects
the IP payload which includes the GRE header. If AH is used the
entire packet other than the mutable fields are authenticated. Note
that Key field is not involved in any sort or security (despite its
name).
4. IANA Considerations
This document does not require any allocations by the IANA and
therefore does not have any new IANA considerations.
5. Acknowledgments
This document is derived from the original ideas of the authors of
RFC 1701. Kent Leung, Pete McCann, Mark Townsley, David Meyer,
Yingchun Xu, Ajoy Singh and many others provided useful discussion.
The author would like to thank all the above people.
6. References
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing
Encapsulation", RFC 1701, October 1994.
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[6] Kent, S., and R. Atkinson, " IP Authentication Header", RFC 2402,
November 1998.
Author's Address
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
EMail: gdommety@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1What GRE Does and What This Adds
GRE (Generic Routing Encapsulation) specifies a protocol for encapsulating an arbitrary protocol over another arbitrary network layer protocol. The original GRE header has a small set of fields: a Checksum Present flag, a Reserved0 field, a Version field and a Protocol Type field, followed by an optional Checksum and an optional Reserved1 field.
This RFC describes enhancements by which two fields, Key and Sequence Number, can optionally be carried in that header. The Key field is meant to identify an individual traffic flow within a tunnel, and the Sequence Number field is used to maintain the order of packets within the GRE tunnel.
The RFC also defines one term for the requirements. To silently discard a datagram is to discard it without further processing and without indicating an error to the sender; the implementation should be able to log the error, including the contents of the discarded datagram, and should record the event in a statistics counter.
GRE is a way of carrying one protocol inside another, so that a packet can cross a network that does not know how to handle it. This RFC adds two optional fields to the wrapper: one that names the conversation a packet belongs to, and one that numbers the packets so the far end can restore their order.
§2The Extended GRE Header
The proposed header adds two flag bits and two optional fields to the original one. After the Checksum Present flag come the Key Present bit and the Sequence Number Present bit, then the Reserved0 field, the Version field and the Protocol Type field; the optional Checksum and Reserved1 fields follow, and then the optional Key field and the optional Sequence Number field.
The Key Present bit is bit 2. When it is set to 1, the Key field is present in the GRE header; otherwise it is not. The Sequence Number Present bit is bit 3. When it is set to 1, the Sequence Number field is present; otherwise it is not. The two bits are chosen to be compatible with the earlier GRE specification in RFC 1701.
Because the fields are optional, a receiver can tell from the bits alone whether to expect them, and a sender that does not need them leaves the bits clear and the fields out of the header entirely.
Two extra flag bits say whether the two new fields are there at all, so a receiver knows how to read the rest of the header without any out-of-band agreement.
| Field | Original GRE header | Extended GRE header |
|---|---|---|
| Flags THIS RFC | C, Reserved0, Ver | C, K, S, Reserved0, Ver |
| Protocol Type | Present | Present |
| Checksum and Reserved1 | Optional | Optional |
| Key | Not present | 4 octets, present when bit 2 is set |
| Sequence Number | Not present | 4 octets, present when bit 3 is set |
§2.1The Key Field
The Key field holds a four octet number inserted by the encapsulator. The method by which the Key is obtained is beyond the scope of the document, so the tunnel ends agree on it in whatever way suits them.
The Key is intended to identify an individual traffic flow within a tunnel. Packets may need to be routed on context information that is not present in the encapsulated data, and the Key supplies that context: it defines a logical traffic flow between the encapsulator and the decapsulator. Packets that belong to a flow are encapsulated with the same Key value, and the decapsulating tunnel endpoint identifies the packets of that flow by their Key value.
The Key is a number that both ends of the tunnel agree on for one conversation. When a packet arrives, the far end looks at the number to decide which conversation it belongs to, even when the packet's own contents do not say.
- Four octetsThe Key is a four octet number inserted by the encapsulator.
- Chosen locallyHow the Key is obtained is beyond the scope of the RFC.
- One flow per valuePackets of a flow are encapsulated with the same Key value.
- Identifies the flowThe decapsulating endpoint groups packets by their Key value.
- Not securityThe Key field is not involved in any sort of security, despite its name.
§2.2The Sequence Number and What the Receiver Does
The Sequence Number field is a four byte field inserted by the encapsulator when the Sequence Number Present bit is set. The receiver must use it to establish the order in which packets were transmitted to it. The intended use is to provide unreliable but in-order delivery. When the Key Present bit is set, the sequence number is specific to the flow named by the Key field. Packets without the sequence bit set can be interleaved with packets that have it set.
The sequence number ranges from 0 to (2^32)-1. The first datagram is sent with a sequence number of 0, and the number is a free running counter represented modulo 2^32. The receiver keeps the sequence number of the last successfully decapsulated packet; when the tunnel is established, that value is set to (2^32)-1.
When the decapsulator receives an out-of-sequence packet it should silently discard it. A packet counts as out of sequence when its sequence number is less than or equal to the sequence number of the last successfully decapsulated packet, and a sequence number counts as less than or equal when its value lies in the range of the last received sequence number and the preceding 2**31-1 values, inclusive.
A packet is in sequence when its sequence number is exactly 1 greater than, modulo 2^32, the last successfully decapsulated packet, or when its sequence number field is not present at all. Such a packet is decapsulated successfully.
A packet that is neither in sequence nor out of sequence shows a sequence number gap. The receiver may do a small amount of buffering to recover the original order, placing the packet in a buffer sorted by sequence number. When an in-sequence packet is received and decapsulated, the receiver should look at the head of the buffer to see whether the next in-sequence packet has already arrived, and if it has, decapsulate it along with any further in-sequence packets in the buffer; the last successfully decapsulated sequence number is then set to the last packet decapsulated from the buffer.
No packet should ever wait more than OUTOFORDER_TIMER milliseconds in the buffer. When a packet has waited that long, the receiver must immediately walk the buffer in sorted order, decapsulating packets and ignoring any sequence number gaps, until no packet that has waited longer than OUTOFORDER_TIMER milliseconds is left, and then set the last successfully decapsulated sequence number to the last packet decapsulated. The receiver may also cap the number of packets in any per-flow buffer, where packets with the same Key value belong to a flow. If a packet arrives that would push more than MAX_PERFLOW_BUFFER packets into a buffer, the packet at the head of that buffer is decapsulated immediately whatever its sequence number, the last successfully decapsulated sequence number is set to its sequence number, and the newly arrived packet may then go into the buffer.
The RFC notes that the sequence number is used to detect lost packets and to restore the original order of packets that the network reordered, and that it should be used accordingly. It is a good idea to avoid it when the protocol carried in the tunnel has its own in-order delivery or tolerates reordering. If only some instances of the carried protocol need in-order delivery, only the corresponding packets need to be sent with the sequence bit set. Reordering out-of-sequence packets may be done for better performance and tolerance of reordering, and a small reordering buffer may help when the higher layer uses stateful compression or encryption, since the state of that compression or encryption is reset by packet loss.
The sending side numbers its packets, and the receiving side uses the numbers to sort them back into order. A packet that arrives too late is thrown away, a packet that fits the next expected number is passed on, and a packet that arrives early waits in a small buffer for a while in case the missing ones turn up.
- In sequenceDECAPSULATE — The number is exactly one greater than the last decapsulated packet, or the sequence bit is not set.
- Out of sequenceDISCARD — The number is less than or equal to the last decapsulated packet; discard it silently.
- GapBUFFER — Neither of the above: hold the packet briefly in case the missing ones arrive.
§3Security Considerations
The RFC is brief here, and the reason is specific. When the Sequence Number field is used, it is possible to inject packets with an arbitrary sequence number and so launch a denial of service attack.
To protect against such attacks, the IP security protocols must be used to protect the GRE header and the tunneled payload. Either ESP (Encapsulating Security Payload) or AH (Authentication Header) must be used to protect the GRE header. ESP protects the IP payload, which includes the GRE header; AH authenticates the entire packet apart from the mutable fields. The RFC ends with a note that catches people out: the Key field is not involved in any sort of security, despite its name.
Because the sequence number is easy to forge, a tunnel that uses it has to be protected by IP security, with either ESP or AH covering the GRE header. The Key field carries no protection of any kind, whatever its name suggests.