Internet Engineering Task Force                        Gopal Dommety
INTERNET DRAFT                                         cisco Systems
Category: Standards Track                              May 2000
Title:  draft-dommety-gre-ext-02.txt

Expires December 2000


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



      This document describes extensions by which two fields, Key and
   Sequence Number, can be optionally carried in the GRE (Generic
   Routing Encapsulation) Header [1]. GRE specifies a protocol for
   encapsulation of an arbitrary protocol over another arbitrary network
   layer protocol.


Dommety                                                         [Page 1]





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




1. Introduction



      Current specification of Generic Routing Encapsulation [1]
   specifies a protocol for encapsulation of an arbitrary network layer
   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 a 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:



Dommety                                                         [Page 2]





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


       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 this document. Key field is intended to be used
   for identifying an individual traffic flow within a tunnel.  For
   example, packets belonging to a PPP session or packets originated by
   a particular source or packets destined to a particular destination
   could belong to a traffic flow. 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



Dommety                                                         [Page 3]





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


   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 and 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 sent in between 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.,
   rollover 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.

       Reordering of out-of sequence packets MAY be performed by the
   decapsulator for improved performance and tolerance to reordering in



Dommety                                                         [Page 4]





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


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






Dommety                                                         [Page 5]





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

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


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 December 2000














Dommety                                                         [Page 6]