idnits 2.17.1 draft-dommety-gre-ext-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 38 has weird spacing: '...rotocol for e...' == Line 40 has weird spacing: '...ensions by wh...' == Line 41 has weird spacing: '...er, can be op...' == Line 115 has weird spacing: '...or. The actua...' == Line 117 has weird spacing: '...ying an indiv...' == (44 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2001) is 8495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '2') ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '5') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Gopal Dommety 2 INTERNET DRAFT cisco Systems 3 Category: Standards Track June 2000 4 Title: draft-dommety-gre-ext-04.txt 6 Expires January 2001 8 Key and Sequence Number Extensions to GRE 9 draft-dommety-gre-ext-04.txt 11 Status of this Memo 13 This document is a submission by the Network Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the gre@ops.ietf.org mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and working groups. Note that other groups may also distribute 23 working documents as Internet Drafts. 25 Internet Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 GRE specifies a protocol for encapsulation of an arbitrary 39 protocol over another arbitrary network layer protocol. This document 40 describes extensions by which two fields, Key and Sequence 41 Number, can be optionally carried in the GRE (Generic Routing 42 Encapsulation) Header [1]. 44 1. Introduction 46 The current specification of Generic Routing Encapsulation [1] 47 specifies a protocol for encapsulation of an arbitrary protocol over 48 another arbitrary network layer protocol. This document describes 49 enhancements by which two fields, Key and Sequence Number, can be 50 optionally carried in The GRE Header [1]. The Key field is intended 51 to be used for identifying an individual traffic flow within a 52 tunnel. The Sequence Number field is used to maintain sequence of 53 packets within The GRE Tunnel. 55 1.1. Specification Language 57 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in RFC 2119 [3]. 61 In addition, the following words are used to signify the 62 requirements of the specification. 64 Silently discard 65 The implementation discards the datagram without 66 further processing, and without indicating an error 67 to the sender. The implementation SHOULD provide the 68 capability of logging the error, including the contents 69 of the discarded datagram, and SHOULD record the event 70 in a statistics counter. 72 2. Extensions to GRE Header 74 The GRE packet header[1] has the following format: 76 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 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 |C| Reserved0 | Ver | Protocol Type | 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 | Checksum (optional) | Reserved1 (Optional) | 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 The proposed GRE header will have the following format: 84 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 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 |C| |K|S| Reserved0 | Ver | Protocol Type | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Checksum (optional) | Reserved1 (Optional) | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Key (optional) | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | Sequence Number (Optional) | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 Key Present (bit 2) 97 If the Key Present bit is set to 1, then it indicates that the 98 Key field is present in the GRE header. Otherwise, the Key 99 field is not present in the GRE header. 101 Sequence Number Present (bit 3) 103 If the Sequence Number Present bit is set to 1, then it 104 indicates that the Sequence Number field is present. 105 Otherwise, 106 the Sequence Number field is not present in the GRE header. 108 The Key and the Sequence Present bits are chosen to be 109 compatible 110 with RFC 1701 [2]. 112 2.1. Key Field (4 octets) 114 The Key field contains a four octet number which was inserted 115 by the encapsulator. The actual method by which this Key is 116 obtained is beyond the scope of The document. The Key field is 117 intended to be used for identifying an individual traffic flow 118 within a tunnel. For example, packets may need to be routed based on 119 context information not present in the encapsulated data. The Key 120 field provides this context and defines a logical traffic flow 121 between encapsulator and decapsulator. Packets belonging to a 122 traffic flow are encapsulated using the same Key value and the 123 decapsulating tunnel endpoint identifies packets belonging to a 124 traffic flow based on the Key Field value. 126 2.2. Sequence Number (4 octets) 127 The Sequence Number field is a four byte field and is inserted by 128 the encapsulator when Sequence Number Present Bit is set. The 129 Sequence Number MUST be used by the receiver to establish the order 130 in which packets have been transmitted from the encapsulator to the 131 receiver. The intended use of the Sequence Field is to provide 132 unreliable but in-order delivery. If the Key present bit (bit 2) is 133 set, the sequence number is specific to the traffic flow identified 134 by the Key field. Note that packets without the sequence bit set can 135 be interleaved with packets with the sequence bit set. 137 The sequence number value ranges from 0 to (2**32)-1. The 138 first datagram is sent with a sequence number of 0. The sequence 139 number is thus a free running counter represented modulo 2**32. 140 The receiver maintains the sequence number value of the last 141 successfully decapsulated packet. Upon establishment of the GRE 142 tunnel, this value should be set to (2**32)-1. 144 When the decapsulator receives an out-of sequence packet it 145 SHOULD be silently discarded. A packet is considered an out-of- 146 sequence packet if the sequence number of the received packet is less 147 than or equal to the sequence number of last successfully 148 decapsulated packet. The sequence number of a received message is 149 considered less than or equal to the last successfully received 150 sequence number if its value lies in the range of the last received 151 sequence number and the preceding 2**31-1 values, inclusive. 153 If the received packet is an in-sequence packet, it is successfully 154 decapsulated. An in-sequence packet is one with a sequence number 155 exactly 1 greater than (modulo 2**32) the last successfully 156 decapsulated packet, or one in which the sequence number field is not 157 present (S bit not set). 159 If the received packet is neither an in-sequence nor 160 an out-of-sequence packet it indicates a sequence number gap. 161 The receiver may perform a small amount of buffering in an 162 attempt to recover the original sequence of transmitted packets. 163 In this case, the packet may be placed in a buffer sorted by sequence 164 number. If an in-sequence packet is received and successfully 165 decapsulated, the receiver should consult the head of this buffer 166 to see if the next in-sequence packet has already been received. 167 If so, the receiver should decapsulate it as well as the 168 following in-sequence packets that may be present in the 169 buffer. The "last successfully decapsulated sequence number" 170 should then be set to the last packet that was decapsulated from 171 the buffer. 173 Under no circumstances should a packet wait more that 174 OUTOFORDER_TIMER milliseconds in the buffer. If a packet has been 175 waiting that long, the receiver MUST immediately traverse the buffer 176 in sorted order, decapsulating packets (and ignoring any sequence 177 number gaps) until there are no more packets in the buffer that have 178 been waiting longer than OUTOFORDER_TIMER milliseconds. The "last 179 successfully decapsulated sequence number" should then be set to the 180 last packet so decapsulated. 182 The receiver may place a limit on the number of packets in 183 any per-flow buffer (Packets with the same Key Field value belong 184 to a flow). If a packet arrives that would cause the receiver to 185 place more than MAX_PERFLOW_BUFFER packets into a given buffer, 186 then the packet at the head of the buffer is immediately 187 decapsulated regardless of its sequence number and the 188 "last successfully decapsulated sequence number" is set to its 189 sequence number. The newly arrived packet may then be placed in the 190 buffer. 192 Note that the sequence number is used to detect lost packets and/or 193 restore the original sequence of packets (with buffering) that may 194 have been reordered during transport. Use of the sequence number 195 option should be used appropriately; in particular, it is a good idea 196 a avoid using when tunneling protocols that have higher layer in- 197 order delivery mechanisms or are tolerant to out-of-order delivery. 198 If only at certain instances the protocol being carried in the GRE 199 tunnel requires in-sequence delivery, only the corresponding packets 200 encapsulated in a GRE header can be sent with the sequence bit set. 202 Reordering of out-of sequence packets MAY be performed by 203 the decapsulator for improved performance and tolerance to 204 reordering in the network. A small amount of reordering buffer 205 (MAX_PERFLOW_BUFFER) may help in improving performance when the 206 higher layer employs stateful compression or encryption. Since 207 the state of the stateful compression or encryption is reset by 208 packet loss, it might help the performance to tolerate some small 209 amount of packet reordering in the network by buffering. 211 3. Security Considerations 213 This document describes extensions by which two fields, Key 214 and Sequence Number, can be optionally carried in the GRE (Generic 215 Routing Encapsulation) Header [1]. When using the Sequence number 216 field, it is possible to inject packets with an arbitrary Sequence 217 number and launch a Denial of Service attack. In order to protect 218 against such attacks, IP security protocols [4] MUST be used to 219 protect the GRE header and the tunneled payload. Either ESP 220 (Encapsulating Security Payload) [5] or AH (Authentication 221 Header)[6] MUST be used to protect the GRE header. If ESP is used 222 it protects the IP payload which includes the GRE header. If AH 223 is used the entire packet other than the mutable fields are 224 authenticated. Note that Key field is not involved in any sort or 225 security (despite its name). 227 4. IANA Considerations 229 This document does not require any allocations by the IANA and 230 therefore does not have any new IANA considerations. 232 5. Acknowledgments 234 This document is derived from the original ideas of the authors 235 of RFC 1701. Kent Leung, Pete McCann, Mark Townsley, David 236 Meyer, Yingchun Xu, Ajoy Singh and many others provided useful 237 discussion. The author would like to thank all the above people. 239 6. References 241 [1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and Traina, P., 242 "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000. 244 [2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing 245 Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, October 246 1994. 248 [3] Bradner S., "Key words for use in RFCs to Indicate Requirement 249 Levels", RFC 2119, March 1997. 251 [4] Kent S, and Atkinson R, "Security Architecture for the Internet 252 Protocol ", RFC 2401, November 1998. 254 [5] Kent S, and Atkinson R, "IP Encapsulating Security Payload 255 (ESP)", RFC 2406, November 1998. 257 [6] Kent S, and Atkinson R, " IP Authentication Header", RFC 2402, 258 November 1998. 260 Authors's Address 261 Gopal Dommety 262 Cisco Systems, Inc. 263 170 West Tasman Drive 264 San Jose, CA 95134 265 e-mail: gdommety@cisco.com 267 This internet draft expires in January 2001