Internet Engineering Task Force Gopal Dommety
INTERNET DRAFT cisco Systems
Category: Standards Track June 2000
Title: draft-dommety-gre-ext-03.txt
Expires January 2001
Key and Sequence Number Extensions to GRE
draft-dommety-gre-ext-03.txt
Status of this Memo
This document is a submission by the Network Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the gre@ops.ietf.org mailing list.
Distribution of this memo is unlimited.
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
GRE 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 (Generic Routing
Encapsulation) Header [1].
Dommety [Page 1]
Internet Draft Key and Sequence Number Extensions to GRE June, 2000
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]. Key field is intended to be
used for identifying an individual traffic flow within a tunnel.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dommety [Page 2]
Internet Draft Key and Sequence Number Extensions to GRE June, 2000
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 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. 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)
Dommety [Page 3]
Internet Draft Key and Sequence Number Extensions to GRE June, 2000
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 1 to 2**32-1. The first
datagram is sent with a sequence number of 1. The sequence number is
thus a free running counter represented modulo 2**32, with the
exception that 1 is used when modulo 2**32 results in 0 (i.e., roll-
over to 1 instead of 0).
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
lesser 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. 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. Mechanisms to determine which packets
need to be sent in-sequence and the signaling mechanisms are outside
the scope of this document.
2.2.1 Re-ordering of Out-of-Sequence packets
Sequence Number field is used to maintain sequence of packets
within a GRE Tunnel and the intended use of the Sequence Field is to
provide unreliable and in-order delivery. The sequence number MAY be
used to restore the original sequence of packets that may have been
reordered during transport.
Dommety [Page 4]
Internet Draft Key and Sequence Number Extensions to GRE June, 2000
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 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. When a specific implementation intends to
perform reordering, care should be taken to implement buffering
schemes with caution, as some implementations could lead to
degradation in performance of the tunnel endpoint and also to buffer
over flows. Exact buffering schemes and methods to determine when a
packet with a certain sequence number is considered lost are outside
the scope of this document.
A possible method to determine when a packet with a certain
sequence number is considered lost is by implementing a timer-based
mechanism (i.e, implementing an OUTOFORDER_TIMER) along with
maintaince of a per-flow buffer of a limited size
(MAX_PERFLOW_BUFFER). With a timer-based mechanism, when an out-of-
order packet arrives, the tunnel endpoint starts a timer with a value
of OUTOFORDER_TIMER. For example a packet with a sequence number N+M
(value of M is greater than 0) while waiting for the packet with the
sequence number N the OUTOFORDER_TIMER is started. If the packet
with the sequence number N does not arrive prior to the expiry of
this timer, the packet with the sequence number N is considered lost.
Note that this method could lead to buffer overflow depending of the
value of the OUTOFORDER_TIMER. In order to avoid buffer overflows, a
per-flow buffer (MAX_PERFLOW_BUFFER) is maintained. When there are
MAX_PERFLOW_BUFFER number of packets to be dequeued (i.e., the buffer
is full), if a new packet arrives prior to the arrival of the packet
with a sequence number value of N and prior to the expiry of the
OUTOFORDER_TIMER, the packet with sequence number of N is considered
lost and the next packet with the smallest valid sequence number
(sequence number of N+K, where K is the smallest possible among the
packets waiting to be decapsulated) is decapsulated.
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
Dommety [Page 5]
Internet Draft Key and Sequence Number Extensions to GRE June, 2000
(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 Traina, P.,
"Generic Routing Encapsulation (GRE)," RFC 2784, March 2000.
[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing
Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, October
1994.
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[4] Kent S, and Atkinson R, "Security Architecture for the Internet
Protocol ", RFC 2401, November 1998.
[5] Kent S, and Atkinson R, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[6] Kent S, and Atkinson R, " IP Authentication Header", RFC 2402,
November 1998.
Dommety [Page 6]
Internet Draft Key and Sequence Number Extensions to GRE June, 2000
Authors's Address
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: gdommety@cisco.com
This internet draft expires in January 2001