Skip to main content

Key and Sequence Number Extensions to GRE
draft-dommety-gre-ext-04

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 2890.
Author Gopal Dommety
Last updated 2013-03-02 (Latest revision 2000-06-23)
RFC stream Legacy stream
Intended RFC status Proposed Standard
Formats
Stream Legacy state (None)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 2890 (Proposed Standard)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dommety-gre-ext-04
Internet Engineering Task Force                        Gopal Dommety
INTERNET DRAFT                                         cisco Systems
Category: Standards Track                              June 2000
Title:  draft-dommety-gre-ext-04.txt

Expires January 2001

                 Key and Sequence Number Extensions to GRE
                    draft-dommety-gre-ext-04.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

Dommety                                                         [Page 1]

Internet Draft Key and Sequence Number Extensions to GRE      June, 2000

   Encapsulation) 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)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 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)

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  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.

Dommety                                                         [Page 4]

Internet Draft Key and Sequence Number Extensions to GRE      June, 2000

   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

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.

Authors's Address

Dommety                                                         [Page 6]

Internet Draft Key and Sequence Number Extensions to GRE      June, 2000

      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