idnits 2.17.1 draft-berger-rsvp-ext-08.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 5 IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC1825], [RFC1826], [RFC1827], [RSVPspec96], [RSVPproc96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 288 has weird spacing: '..." error is ge...' -- 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 (Auguest 20, 1997) is 9982 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) -- Missing reference section? 'RFC1826' on line 416 looks like a reference -- Missing reference section? 'RFC1827' on line 419 looks like a reference -- Missing reference section? 'RSVPspec96' on line 403 looks like a reference -- Missing reference section? 'RSVPproc96' on line 408 looks like a reference -- Missing reference section? 'RFC1825' on line 413 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft L. Berger 3 Expiration: February 20, 1998 FORE Systems 4 File: draft-berger-rsvp-ext-08.txt T. O'Malley 5 BBN 7 RSVP Extensions for IPSEC Data Flows 9 Auguest 20, 1997 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This document presents extensions to Version 1 of RSVP. These 32 extensions permit support of individual data flows using RFC 1826 IP 33 Authentication Header (AH) or RFC 1827 IP Encapsulating Security 34 Payload (ESP). RSVP Version 1 as currently specified can support the 35 IPSEC protocols, but only on a per address, per protocol basis not on 36 a per flow basis. The presented extensions can be used with both 37 IPv4 and IPv6. 39 Table of Contents 41 1 Introduction 3 43 2 Overview of Extensions 4 45 3 Object Definition 6 46 3.1 SESSION Class 6 47 3.2 FILTER_SPEC Class 7 48 3.3 SENDER_TEMPLATE Class 7 50 4 Processing Rules 8 51 4.1 Required Changes 8 52 4.2 Merging Flowspecs 9 53 4.2.1 FF and SE Styles 9 54 4.2.2 WF Styles 9 56 5 IANA Considerations 10 58 6 Security Considerations 10 60 7 References 11 62 8 Acknowledgments and Authors' Information 12 63 8.1 Acknowledgments 12 64 8.2 Authors' Information 12 66 A Options Considered 13 67 A.1 UDP Encapsulation 14 68 A.2 FlowID Header Encapsulation 14 69 A.3 IPSEC Protocol Modification 15 70 A.4 AH Transparency 16 72 1 Introduction 74 Recently published Standards Track RFCs specify protocol mechanisms 75 to provide IP level security. These IP Security, or IPSEC, protocols 76 support packet level authentication, [RFC1826], and integrity and 77 confidentiality [RFC1827]. A number of interoperable implementations 78 already exist and several vendors have announced commercial products 79 that will use these mechanisms. 81 The IPSEC protocols provide service by adding a new header between a 82 packet's IP header and the transport (e.g. UDP) protocol header. The 83 two security headers are the Authentication Header (AH), for 84 authentication, and the Encapsulating Security Payload (ESP), for 85 integrity and confidentiality. 87 RSVP is being developed as a resource reservation (dynamic QoS setup) 88 protocol. RSVP as currently specified [RSVPspec96] is tailored 89 towards IP packets carrying protocols that have TCP or UDP-like 90 ports. Protocols that do not have such UDP/TCP-like ports, such as 91 the IPSEC protocols, can be supported, but only with limitations. 92 Specifically, for flows of IPSEC data packets, flow definition can 93 only be done on per IP address, per protocol basis. 95 This memo proposes extensions to RSVP so that data flows containing 96 IPSEC protocols can be controlled at a granularity similar to what is 97 already specified for UDP and TCP. The proposed extensions can be 98 used with both IPv4 and IPv6. Section 2 of this memo will provide an 99 overview of extensions. Section 3 contains a description of extended 100 protocol mechanisms. Section 4 presents extended protocol processing 101 rules. Section 5 defines the additional RSVP data objects. 103 2 Overview of Extensions 105 The basic notion is to extend RSVP to use the IPSEC Security 106 Parameter Index, or SPI, in place of the UDP/TCP-like ports. This 107 will require a new FILTER_SPEC object, which will contain the IPSEC 108 SPI, and a new SESSION object. 110 While SPIs are allocated based on destination address, they will 111 typically be associated with a particular sender. As a result, two 112 senders to the same unicast destination will usually have different 113 SPIs. In order to support the control of multiple independent flows 114 between source and destination IP addresses, the SPI will be included 115 as part of the FILTER_SPEC. When using WF, however, all flows to the 116 same IP destination address using the same IP protocol ID will share 117 the same reservation. (This limitation exists because the IPSEC 118 transport headers do not contain a destination demultiplexing value 119 like the UDP/TCP destination port.) 121 Although the RESV message format will not change, RESV processing 122 will require modification. Processing of the new IPSEC FILTER_SPEC 123 will depend on the use of the new SESSION object and on the protocol 124 ID contained in the session definition. When the new FILTER_SPEC 125 object is used, the complete four bytes of the SPI will need to be 126 extracted from the FILTER_SPEC for use by the packet classifier. The 127 location of the SPI in the transport header of the IPSEC packets is 128 dependent on the protocol ID field. 130 The extension will also require a change to PATH processing, 131 specifically in the usage of the port field in a session definition. 132 An RSVP session is defined by the triple: (DestAddress, protocol ID, 133 DstPort). [RSVPspec96] includes the definition of one type of 134 SESSION object, it contains UDP/TCP destination ports, specifically 135 "a 16-bit quantity carried at the octet offset +2 in the transport 136 header" or zero for protocols that lack such a field. The IPSEC 137 protocols do not contain such a field, but there remains a 138 requirement for demultiplexing sessions beyond the IP destination 139 address. In order to satisfy this requirement, a virtual destination 140 port, or vDstPort, is introduced. The vDstPort value will be carried 141 in the new SESSION object but not in the IPSEC transport header. The 142 vDstPort allows for the differentiation of multiple IPSEC sessions 143 destined to the same IP address. See Section 5 for a discussion of 144 vDstPort ranges. 146 In PATH messages, the SENDER_TEMPLATE for IPSEC flows will have the 147 same format as the modified FILTER_SPEC. But, a new SESSION object 148 will be used to unambiguously distinguish the use of a virtual 149 destination port. 151 Traffic will be mapped (classified) to reservations based on SPIs in 152 FILTER_SPECs. This, of course, means that when WF is used all flows 153 to the same IP destination address and with the same IP protocol ID 154 will share the same reservation. 156 The advantages to the described approach are that no changes to 157 RFC1826 and 1827 are required and that there is no additional per 158 data packet overhead. Appendix A contains a discussion of the 159 advantages of this approach compared to several other alternatives. 160 This approach does not take advantage of the IPv6 Flow Label field, 161 so greater efficiency may be possible for IPv6 flows. The details of 162 IPv6 Flow Label usage is left for the future. 164 3 Object Definition 166 The FILTER_SPEC and SENDER_TEMPLATE used with IPSEC protocols will 167 contain a four byte field that will be used to carry the SPI. Rather 168 than label the modified field with an IPSEC specific label, SPI, the 169 label "Generalized Port Identifier", or GPI, will be so that these 170 object may be reused for non-IPSEC uses in the future. The name for 171 these objects are the IPv4/GPI FILTER_SPEC, IPv6/GPI FILTER_SPEC, 172 IPv4/GPI SENDER_TEMPLATE, and IPv6/GPI SENDER_TEMPLATE. Similarly, 173 the new SESSION objects will be the IPv4/GPI SESSION and the IPv6/GPI 174 SESSION. When referring to the new objects, IP version will not be 175 included unless a specific distinction between IPv4 and IPv6 is being 176 made. 178 3.1 SESSION Class 180 SESSION Class = 1. 182 o IPv4/GPI SESSION object: Class = 1, C-Type = 3 184 +-------------+-------------+-------------+-------------+ 185 | IPv4 DestAddress (4 bytes) | 186 +-------------+-------------+-------------+-------------+ 187 | Protocol ID | Flags | vDstPort | 188 +-------------+-------------+-------------+-------------+ 190 o IPv6/GPI SESSION object: Class = 1, C-Type = 4 192 +-------------+-------------+-------------+-------------+ 193 | | 194 + + 195 | | 196 + IPv6 DestAddress (16 bytes) + 197 | | 198 + + 199 | | 200 +-------------+-------------+-------------+-------------+ 201 | Protocol ID | Flags | vDstPort | 202 +-------------+-------------+-------------+-------------+ 204 3.2 FILTER_SPEC Class 206 FILTER_SPEC class = 10. 208 o IPv4/GPI FILTER_SPEC object: Class = 10, C-Type = 4 210 +-------------+-------------+-------------+-------------+ 211 | IPv4 SrcAddress (4 bytes) | 212 +-------------+-------------+-------------+-------------+ 213 | Generalized Port Identifier (GPI) | 214 +-------------+-------------+-------------+-------------+ 216 o IPv6/GPI FILTER_SPEC object: Class = 10, C-Type = 5 218 +-------------+-------------+-------------+-------------+ 219 | | 220 + + 221 | | 222 + IPv6 SrcAddress (16 bytes) + 223 | | 224 + + 225 | | 226 +-------------+-------------+-------------+-------------+ 227 | Generalized Port Identifier (GPI) | 228 +-------------+-------------+-------------+-------------+ 230 3.3 SENDER_TEMPLATE Class 232 SENDER_TEMPLATE class = 11. 234 o IPv4/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 4 236 Definition same as IPv4/GPI FILTER_SPEC object. 238 o IPv6/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 5 240 Definition same as IPv6/GPI FILTER_SPEC object. 242 4 Processing Rules 244 This section presents additions to the Processing Rules presented in 245 [RSVPproc96]. These additions are required in order to properly 246 process the GPI SESSION and FILTER_SPEC objects. Values for 247 referenced error codes can be found in [RSVPspec96]. As in with the 248 other RSVP documents, values for internally reported (API) errors are 249 not defined. 251 4.1 Required Changes 253 Both RESV and PATH processing will need to be changed to support the 254 new objects. The changes ensure consistency and extend port 255 processing. 257 The following PATH message processing changes are required: 259 o When a session is defined using the GPI SESSION object, only 260 the GPI SENDER_TEMPLATE may be used. When this condition is 261 violated, end-stations should report a "Conflicting C-Type" API 262 error to the application. 264 o For PATH messages that contain the GPI SESSION object, 265 end-stations must verify that the protocol ID corresponds to a 266 protocol known to use the GPI SESSION object. Values 51 (AH) 267 or 50 (ESP) must be supported by implementations supporting 268 the described IPSEC extensions. If an unknown protocol ID is 269 used, then the API should report an "API Error" to the 270 application. 272 o For such messages, the vDstPort value should be recorded. 273 The vDstPort value forms part of the recorded state and is used 274 to match Resv messages, but it is not passed to traffic control. 275 Non-zero values of vDstPort are required. This requirement 276 ensures that a non-GPI SESSION object will never merge with a 277 GPI SESSION object. Violation of this condition causes an 278 "Invalid Destination Port" API error. 280 The changes to RESV message processing are: 282 o When a RESV message contains a GPI FILTER_SPEC, the session 283 must be defined using the GPI SESSION object. Otherwise, this is a 284 message formatting error. 286 o The GPI contained in the FILTER_SPEC must match the GPI 287 contained in the SENDER_TEMPLATE. Otherwise, a "No sender 288 information for this Resv message" error is generated. 290 o When the GPI FILTER_SPEC is used, each node must create 291 a data classifier for the flow described by the quadruple: 292 (DestAddress, protocol ID, SrcAddress, GPI). The data classifier 293 will need to look for the four byte GPI at transport header 294 offset +4 for AH, and at transport header offset +0 for ESP. 296 4.2 Merging Flowspecs 298 When using this extension for IPSEC data flows, RSVP sessions are 299 defined by the triple: (DestAddress, protocol Id, vDstPort). 300 Similarly, a sender is defined by the tuple: (SrcAddress, GPI), where 301 the GPI field will be a four byte representation of a generalized 302 source port. These extensions have some ramifications depending upon 303 the reservation style. 305 4.2.1 FF and SE Styles 307 In the FF and SE Styles, the FILTER_SPEC object contains the 308 (SrcAddress, GPI) pair. This allows the receiver to uniquely 309 identify senders based on both elements of the pair. When merging 310 explicit sender descriptors, the senders may only be considered 311 identical when both elements are identical. 313 4.2.2 WF Styles 315 These extensions provide very limited service when used with WF style 316 reservations. As described, the SENDER_TEMPLATE and FILTER_SPEC each 317 contain the GPI. In a WF style reservation, the RESV message does 318 NOT contain a FILTER_SPEC (after all, it is a wildcard filter), and 319 the SENDER_TEMPLATE is ignored (again, because any sender is 320 allowed). As a result, classifiers may match all packets which 321 contain both the session's destination IP address and protocol ID to 322 such WF reservations. 324 Although a solution for this limitation is not proposed, this issue 325 is not seen as significant since IPSEC applications are less likely 326 to use WF style reservations. 328 5 IANA Considerations 330 The range of possible vDstPort values is broken down into sections, 331 in a fashion similar to the UDP/TCP port ranges. 333 0 Illegal Value 334 1 - 10 Reserved. Contact authors. 335 11 - 8191 Assigned by IANA 336 8192 - 65535 Dynamic 338 IANA is directed to assign the well-known vDstPorts using the 339 following criteria: Anyone who asks for an assigned vDstPort must 340 provide a) a Point of Contact, b) a brief description of intended 341 use, and c) a short name to be associated with the assignment (e.g. 342 "ftp"). 344 6 Security Considerations 346 The same considerations stated in [RSVPspec96], [RFC1826], and 347 [RFC1827] apply to the extensions described in this note. There are 348 two additional issue related to these extensions. 350 First, the vDstPort mechanism represents another data element about 351 the IP Flow that might be available to an adversary. Such data might 352 be useful to an adversary engaging in traffic analysis by monitoring 353 not only the data packets of the IP Flow but also the RSVP control 354 messages associated with that Flow. Protection against traffic 355 analysis attacks is outside the scope of this mechanism. One 356 possible approach to precluding such attacks would be deployment and 357 use of appropriate link-layer confidentiality mechansisms, such as 358 encryption. 360 Secondly, Changes in SPI values for a given flow will affect RSVP 361 flows and reservations. Changes will happen whenever that flow 362 changes its Security Association. Such changes will occur when a 363 flow is rekeyed (i.e. to use a new key). Rekeying intervals are 364 typically set based on traffic levels, key size, threat environment, 365 and crypto algorithm in use. When an SPI change occurs it will, in 366 most cases, be necessary to update (send) the corresponding 367 SENDER_TEMPLATEs and FILTER_SPECs. IPSEC implementations, RSVP 368 applications, and RSVP end-station implementations will need to take 369 the possibility of changes of SPI into account to ensure proper 370 reservation behavior. This issue is likely to be a tolerable, since 371 rekeying intervals are under the control of local administrators. 373 Many, if not most, RSVP sessions will not need to deal with this 374 rekeying issue. For those applications that do need to deal with 375 changes of SPIs during a session, the impact of sending new PATH and 376 RESV messages will vary based on the reservation style being used. 377 Builders of such applications may want to select reservation style 378 based on interaction with SPI changes. 380 The least impact of an SPI change will be to WF style reservations. 381 For such reservations, a new SENDER_TEMPLATE will need to be sent, 382 but no new RESV is required. For SE style reservations, both a new 383 SENDER_TEMPLATE and a new RESV will need to be sent. This will 384 result in changes to state, but should not affect data packet 385 delivery or actual resource allocation in any way. The FF style will 386 be impacted the most. Like with SE, both PATH and RESV messages will 387 need to be sent. But, since FF style reservations result in sender 388 receiving its own resource allocation, resources will be allocated 389 twice for a period of time. Or, even worse, there won't be enough 390 resources to support the new flow without first freeing the old flow. 392 A way around this FF/SPI-change problem does exist. Applications 393 that want FF style reservations can use multiple SE reservations. 394 Each real sender would have a separate SESSION (vDstPort) definition. 395 When it came time to switch SPIs, a shared reservation could be made 396 for the new SPI while the old SPI was still active. Once the new SPI 397 was in use, the old reservation could be torn down. This is less 398 than optimal, but will provide uninterrupted service for a set of 399 applications. 401 7 References 403 [RSVPspec96] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and 404 S. Jamin, "Resource ReSerVation Protocol (RSVP) -- 405 Version 1 Functional Specification. Internet Draft 406 draft-ietf-rsvp-spec-014.ps, November 1996. 408 [RSVPproc96] Braden, R., Ed., Zhang, "Resource ReSerVation 409 Protocol (RSVP) -- Version 1 Message Processing Rules", 410 Internet Draft draft-ietf-rsvp-procrules-00.txt, 411 November 1996. 413 [RFC1825] Atkinson, R., "Security Architecture for the Internet 414 Protocol", RFC 1825, NRL, August 1995. 416 [RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, 417 August 1995. 419 [RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 420 1827, NRL, August 1995. 422 8 Acknowledgments and Authors' Information 424 8.1 Acknowledgments 426 This note includes ideas originated and reviewed by a number of 427 individuals who did not participate in this note's writing. The 428 authors would like to acknowledge their contribution. We thank Ran 429 Atkinson , Fred Baker , Greg Troxel 430 , John Krawczyk for much 431 appreciated input and feedback. Special appreciation goes to Bob 432 Braden for his detailed editorial and technical 433 comments. We also thank Buz Owen, Claudio Topolcic, Andy Veitch, and 434 Luis Sanchez for their help in coming up with the proposed approach. 435 If any brain-damage exists in this note, it originated solely from 436 the authors. 438 8.2 Authors' Information 440 Lou Berger Tim O'Malley 441 FORE Systems BBN Corporation 442 6905 Rockledge Drive 10 Moulton Street 443 Suite 800 Cambridge, MA 02138 444 Bethesda, MD 20817 446 Phone: 301-571-2534 Phone: 617-873-3076 447 EMail: lberger@fore.com EMail: timo@bbn.com 449 A Options Considered 451 This sections reviews other approaches that were explored in 452 developing the described extensions. They are included here to 453 provide additional context into the general problem. All listed 454 options were rejected by the working group. 456 Four other options were considered: 458 1. UDP Encapsulation 459 Add a UDP header between the IP and the IPSEC AH or ESP 460 headers. 462 2. FlowID Header Encapsulation 463 Add a new type of header between the IP and the IPSEC AH or 464 ESP headers. 466 3. IPSEC modification 467 Modify IPSEC headers so that there are appropriate fields in 468 same location as UDP and TCP ports. 470 4. AH Transparency 471 Skip over the Authentication Header packet classifier 472 processing. 474 A.1 UDP Encapsulation 476 Since current SESSION and FILTER object expect UDP or TCP ports, this 477 proposal says let's just give it to them. The basic concept is to 478 add a UDP port between the IP and AH/ESP headers. The UDP ports 479 would provide the granularity of control that is need to associate 480 specific flows with reservations. 482 Source and destination ports would be used, as normal, in RSVP 483 session definition and control. The port fields would also need to 484 be used to identify the real transport level protocol (e.g. ESP) 485 being used. Also since many UDP ports are assigned as well known 486 ports, use of port numbers would be limited. So, the port fields 487 would need to be used to unambiguously identify 1) the next level 488 protocol, 2) the RSVP session, and 3) the RSVP reservation. 490 The advantages of this option is that no RSVP changes are required. 491 The disadvantages is that, since the headers aren't in the expected 492 location, RFC1826 and 1827 are violated. 494 A.2 FlowID Header Encapsulation 496 [This option was originally proposed by Greg Troxel .] 498 This option is very similar to option 1, but is more generic and 499 could be adopted as a standard solution. The notion is to use UDP 500 like ports for the sole purpose of flow identification. RSVP would 501 treat this new protocol exactly the same as UDP. 503 The difference between this and UDP encapsulation is in destination 504 host processing. The destination host would essentially ignore port 505 information and use a new field, protocol ID, to identify which 506 protocol should process the packet next. Some examples of protocol 507 IDs correspond to TCP, UDP, ESP, or AH. 509 The format of the FlowID Header would be: 511 +---------------+---------------+---------------+---------------+ 512 | Source Port | Dest Port | 513 +---------------+---------------+---------------+---------------+ 514 | Ver | Len | Protocol ID | Checksum | 515 +---------------+---------------+---------------+---------------+ 516 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 518 2 bytes source port 4 bits length-32 (2) 519 2 bytes dest port 8 bits protocol ID 520 4 bits version (1) 16 bits checksum 522 The advantage of this protocol is that flow identification is 523 separated from all other protocol processing. The disadvantage is 524 that the addition of a header violates RFC 1826 and 1827, and also 525 that applications using RSVP will need to add this extra header on 526 all data packets whose transport headers do not have UDP/TCP like 527 ports. 529 A.3 IPSEC Protocol Modification 531 The basic notion of this option is to leave RSVP as currently 532 specified and use the Security Association Identifier (SPI) found in 533 the IPSEC headers for flow identification. There are two issues with 534 using the SPI. The first is that the SPI is located in the wrong 535 location when using Authentication (AH). The second issue is how to 536 make use of the SPI. 538 The first issue is easy to fix, but violates RFC 1826. UDP and TCP 539 have port assignments in the first 4 bytes of their headers, each is 540 two bytes long, source comes first, then destination. The ESP header 541 has the SPI in the same location as UDP/TCP ports, the AH doesn't. 542 The IP Authentication Header has the following syntax: 544 +---------------+---------------+---------------+---------------+ 545 | Next Header | Length | RESERVED | 546 +---------------+---------------+---------------+---------------+ 547 | Security Parameters Index | 548 +---------------+---------------+---------------+---------------+ 549 | | 550 + Authentication Data (variable number of 32-bit words) | 551 | | 552 +---------------+---------------+---------------+---------------+ 553 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 555 Simply reversing the first 4 bytes with the SPI we will have the SPI 556 in the location that RSVP expects. This would be non-standard, or 557 require a major (i.e. not backward compatible) change to RSVP 1826. 559 The second issue is how to make use of the SPI. Per the current RSVP 560 specification, the first two bytes of a flow's SPI will need to be 561 carried in the PATH message and the second two bytes in the RESV 562 message. The biggest problem is that the SPI is normally selected by 563 the receiver and is likely to be different for EACH sender. (There 564 is a special case where the same SPI is used by all senders in a 565 multicast group. But this is a special case.) It is possible to 566 have the SPI selected prior to starting the RSVP session. This will 567 work for unicast and the special multicast case. But using this 568 approach means that setup time will usually be extended by at least 1 569 round trip time. Its not clear how to support SE and WF style 570 reservations. 572 The advantage of this approach is no change to RSVP. The 573 disadvantages are modification to RFC1827 and limited support of RSVP 574 reservation styles. 576 A.4 AH Transparency 578 The source of the RSVP support of IPSEC protocols problem is that the 579 real transport header is not in the expected location. With ESP 580 packets, the real source and destination ports are encrypted and 581 therefore useless to RSVP. This is not the case for authentication. 582 For AH, the real header just follows the Authentication Header. So, 583 it would be possible to use the real transport header for RSVP 584 session definition and reservation. 586 To use the transport header, all that would need to be done is for 587 the flow classifier to skip over AHs before classifying packets. No 588 modification to RSVP formats or setup processing would be required. 589 Applications would make reservations based on transport (i.e., UDP or 590 TCP) ports as usual. 592 The advantages of this approach are no changes to either IPSEC 593 protocols or RSVP formats. The major disadvantage is that routers 594 and hosts must skip all AHs before classifying packets. The working 595 group decided that it was best to have a consistent solution for both 596 AH and ESP.