< draft-dommety-gre-ext-03.txt   draft-dommety-gre-ext-04.txt >
Internet Engineering Task Force Gopal Dommety Internet Engineering Task Force Gopal Dommety
INTERNET DRAFT cisco Systems INTERNET DRAFT cisco Systems
Category: Standards Track June 2000 Category: Standards Track June 2000
Title: draft-dommety-gre-ext-03.txt Title: draft-dommety-gre-ext-04.txt
Expires January 2001 Expires January 2001
Key and Sequence Number Extensions to GRE Key and Sequence Number Extensions to GRE
draft-dommety-gre-ext-03.txt draft-dommety-gre-ext-04.txt
Status of this Memo Status of this Memo
This document is a submission by the Network Working Group of the This document is a submission by the Network Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the gre@ops.ietf.org mailing list. to the gre@ops.ietf.org mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
skipping to change at page 2, line 11 skipping to change at page 2, line 12
describes extensions by which two fields, Key and Sequence describes extensions by which two fields, Key and Sequence
Number, can be optionally carried in the GRE (Generic Routing Number, can be optionally carried in the GRE (Generic Routing
Encapsulation) Header [1]. Encapsulation) Header [1].
1. Introduction 1. Introduction
The current specification of Generic Routing Encapsulation [1] The current specification of Generic Routing Encapsulation [1]
specifies a protocol for encapsulation of an arbitrary protocol over specifies a protocol for encapsulation of an arbitrary protocol over
another arbitrary network layer protocol. This document describes another arbitrary network layer protocol. This document describes
enhancements by which two fields, Key and Sequence Number, can be enhancements by which two fields, Key and Sequence Number, can be
optionally carried in The GRE Header [1]. Key field is intended to be optionally carried in The GRE Header [1]. The Key field is intended
used for identifying an individual traffic flow within a tunnel. to be used for identifying an individual traffic flow within a
Sequence Number field is used to maintain sequence of packets within tunnel. The Sequence Number field is used to maintain sequence of
The GRE Tunnel. packets within The GRE Tunnel.
1.1. Specification Language 1.1. Specification Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [3]. this document are to be interpreted as described in RFC 2119 [3].
In addition, the following words are used to signify the In addition, the following words are used to signify the
requirements of the specification. requirements of the specification.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
Key Present (bit 2) Key Present (bit 2)
If the Key Present bit is set to 1, then it indicates that the 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 Key field is present in the GRE header. Otherwise, the Key
field is not present in the GRE header. field is not present in the GRE header.
Sequence Number Present (bit 3) Sequence Number Present (bit 3)
If the Sequence Number Present bit is set to 1, then it If the Sequence Number Present bit is set to 1, then it
indicates that the Sequence Number field is present. indicates that the Sequence Number field is present.
Otherwise, the Sequence Number field is not present in Otherwise,
the GRE header. the Sequence Number field is not present in the GRE header.
The Key and Sequence Present bits are chosen to be compatible The Key and the Sequence Present bits are chosen to be
compatible
with RFC 1701 [2]. with RFC 1701 [2].
2.1. Key Field (4 octets) 2.1. Key Field (4 octets)
The Key field contains a four octet number which was inserted The Key field contains a four octet number which was inserted
by the encapsulator. The actual method by which this Key is by the encapsulator. The actual method by which this Key is
obtained is beyond the scope of The document. Key field is intended obtained is beyond the scope of The document. The Key field is
to be used for identifying an individual traffic flow within a intended to be used for identifying an individual traffic flow
tunnel. For example, packets may need to be routed based on context within a tunnel. For example, packets may need to be routed based on
information not present in the encapsulated data. The Key field context information not present in the encapsulated data. The Key
provides this context and defines a logical traffic flow between field provides this context and defines a logical traffic flow
encapsulator and decapsulator. Packets belonging to a traffic flow between encapsulator and decapsulator. Packets belonging to a
are encapsulated using the same Key value and the decapsulating traffic flow are encapsulated using the same Key value and the
tunnel endpoint identifies packets belonging to a traffic flow based decapsulating tunnel endpoint identifies packets belonging to a
on the Key Field value. traffic flow based on the Key Field value.
2.2. Sequence Number (4 octets) 2.2. Sequence Number (4 octets)
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 Sequence Number field is a four byte field and is inserted by
the encapsulator when Sequence Number Present Bit is set. The the encapsulator when Sequence Number Present Bit is set. The
Sequence Number MUST be used by the receiver to establish the order Sequence Number MUST be used by the receiver to establish the order
in which packets have been transmitted from the encapsulator to the in which packets have been transmitted from the encapsulator to the
receiver. The intended use of the Sequence Field is to provide receiver. The intended use of the Sequence Field is to provide
unreliable but in-order delivery. If the Key present bit (bit 2) is unreliable but in-order delivery. If the Key present bit (bit 2) is
set, the sequence number is specific to the traffic flow identified set, the sequence number is specific to the traffic flow identified
by the Key field. Note that packets without the sequence bit set can by the Key field. Note that packets without the sequence bit set can
be interleaved with packets with the sequence bit set. be interleaved with packets with the sequence bit set.
The sequence number value ranges from 1 to 2**32-1. The first The sequence number value ranges from 0 to (2**32)-1. The
datagram is sent with a sequence number of 1. The sequence number is first datagram is sent with a sequence number of 0. The sequence
thus a free running counter represented modulo 2**32, with the number is thus a free running counter represented modulo 2**32.
exception that 1 is used when modulo 2**32 results in 0 (i.e., roll- The receiver maintains the sequence number value of the last
over to 1 instead of 0). 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 When the decapsulator receives an out-of sequence packet it
SHOULD be silently discarded. A packet is considered an out-of- SHOULD be silently discarded. A packet is considered an out-of-
sequence packet if the sequence number of the received packet is sequence packet if the sequence number of the received packet is less
lesser than or equal to the sequence number of last successfully than or equal to the sequence number of last successfully
decapsulated packet. The sequence number of a received message is decapsulated packet. The sequence number of a received message is
considered less than or equal to the last successfully received 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 if its value lies in the range of the last received
sequence number and the preceding 2**31-1 values, inclusive. sequence number and the preceding 2**31-1 values, inclusive.
If the received packet is an in-sequence packet, it is If the received packet is an in-sequence packet, it is successfully
successfully decapsulated. Note that the sequence number is used to decapsulated. An in-sequence packet is one with a sequence number
detect lost packets and/or restore the original sequence of packets exactly 1 greater than (modulo 2**32) the last successfully
(with buffering) that may have been reordered during transport. Use decapsulated packet, or one in which the sequence number field is not
of the sequence number option should be used appropriately; in present (S bit not set).
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 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.
Sequence Number field is used to maintain sequence of packets Under no circumstances should a packet wait more that
within a GRE Tunnel and the intended use of the Sequence Field is to OUTOFORDER_TIMER milliseconds in the buffer. If a packet has been
provide unreliable and in-order delivery. The sequence number MAY be waiting that long, the receiver MUST immediately traverse the buffer
used to restore the original sequence of packets that may have been in sorted order, decapsulating packets (and ignoring any sequence
reordered during transport. 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.
Reordering of out-of sequence packets MAY be performed by the The receiver may place a limit on the number of packets in
decapsulator for improved performance and tolerance to reordering in any per-flow buffer (Packets with the same Key Field value belong
the network. A small amount of reordering buffer may help in to a flow). If a packet arrives that would cause the receiver to
improving performance when the higher layer employs stateful place more than MAX_PERFLOW_BUFFER packets into a given buffer,
compression or encryption. Since the state of the stateful then the packet at the head of the buffer is immediately
compression or encryption is reset by packet loss, it might help the decapsulated regardless of its sequence number and the
performance to tolerate some small amount of packet reordering in the "last successfully decapsulated sequence number" is set to its
network by buffering. When a specific implementation intends to sequence number. The newly arrived packet may then be placed in the
perform reordering, care should be taken to implement buffering buffer.
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 Note that the sequence number is used to detect lost packets and/or
sequence number is considered lost is by implementing a timer-based restore the original sequence of packets (with buffering) that may
mechanism (i.e, implementing an OUTOFORDER_TIMER) along with have been reordered during transport. Use of the sequence number
maintaince of a per-flow buffer of a limited size option should be used appropriately; in particular, it is a good idea
(MAX_PERFLOW_BUFFER). With a timer-based mechanism, when an out-of- a avoid using when tunneling protocols that have higher layer in-
order packet arrives, the tunnel endpoint starts a timer with a value order delivery mechanisms or are tolerant to out-of-order delivery.
of OUTOFORDER_TIMER. For example a packet with a sequence number N+M If only at certain instances the protocol being carried in the GRE
(value of M is greater than 0) while waiting for the packet with the tunnel requires in-sequence delivery, only the corresponding packets
sequence number N the OUTOFORDER_TIMER is started. If the packet encapsulated in a GRE header can be sent with the sequence bit set.
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. Reordering of out-of sequence packets MAY be performed by
Note that this method could lead to buffer overflow depending of the the decapsulator for improved performance and tolerance to
value of the OUTOFORDER_TIMER. In order to avoid buffer overflows, a reordering in the network. A small amount of reordering buffer
per-flow buffer (MAX_PERFLOW_BUFFER) is maintained. When there are (MAX_PERFLOW_BUFFER) may help in improving performance when the
MAX_PERFLOW_BUFFER number of packets to be dequeued (i.e., the buffer higher layer employs stateful compression or encryption. Since
is full), if a new packet arrives prior to the arrival of the packet the state of the stateful compression or encryption is reset by
with a sequence number value of N and prior to the expiry of the packet loss, it might help the performance to tolerate some small
OUTOFORDER_TIMER, the packet with sequence number of N is considered amount of packet reordering in the network by buffering.
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 3. Security Considerations
This document describes extensions by which two fields, Key This document describes extensions by which two fields, Key
and Sequence Number, can be optionally carried in the GRE (Generic and Sequence Number, can be optionally carried in the GRE (Generic
Routing Encapsulation) Header [1]. When using the Sequence number Routing Encapsulation) Header [1]. When using the Sequence number
field, it is possible to inject packets with an arbitrary Sequence field, it is possible to inject packets with an arbitrary Sequence
number and launch a Denial of Service attack. In order to protect number and launch a Denial of Service attack. In order to protect
against such attacks, IP security protocols [4] MUST be used to against such attacks, IP security protocols [4] MUST be used to
protect the GRE header and the tunneled payload. Either ESP protect the GRE header and the tunneled payload. Either ESP
(Encapsulating Security Payload) [5] or AH (Authentication (Encapsulating Security Payload) [5] or AH (Authentication
Header)[6] MUST be used to protect the GRE header. If ESP is used 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 it protects the IP payload which includes the GRE header. If AH
is used, the entire packet other than the mutable fields are is used the entire packet other than the mutable fields are
authenticated. Note that Key field is not involved in any sort or authenticated. Note that Key field is not involved in any sort or
security (despite its name). security (despite its name).
4. IANA Considerations 4. IANA Considerations
This document does not require any allocations by the IANA and This document does not require any allocations by the IANA and
therefore does not have any new IANA considerations. therefore does not have any new IANA considerations.
5. Acknowledgments 5. Acknowledgments
 End of changes. 15 change blocks. 
84 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/