idnits 2.17.1 draft-ietf-tsvwg-ecn-tunnel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1547. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (Oct 16, 2008) is 5642 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: 'Encapsulate' is mentioned on line 1331, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-07 == Outdated reference: A later version (-05) exists of draft-ietf-pcn-marking-behaviour-00 == Outdated reference: A later version (-02) exists of draft-ietf-pwe3-congestion-frmwk-01 == Outdated reference: A later version (-01) exists of draft-moncaster-pcn-3-state-encoding-00 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group B. Briscoe 3 Internet-Draft BT 4 Intended status: Standards Track Oct 16, 2008 5 Expires: April 19, 2009 7 Layered Encapsulation of Congestion Notification 8 draft-ietf-tsvwg-ecn-tunnel-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 19, 2009. 35 Abstract 37 This document redefines how the explicit congestion notification 38 (ECN) field of the outer IP header of a tunnel should be constructed. 39 It brings all IP in IP tunnels (v4 or v6) into line with the way 40 IPsec tunnels now construct the ECN field. It includes a thorough 41 analysis of the reasoning for this change and the implications. It 42 also gives guidelines on the encapsulation of IP congestion 43 notification by any outer header, whether encapsulated in an IP 44 tunnel or in a lower layer header. Following these guidelines should 45 help interworking, if the IETF or other standards bodies specify any 46 new encapsulation of congestion notification. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. The Need for Rationalisation . . . . . . . . . . . . . . . 5 52 1.2. Document Roadmap . . . . . . . . . . . . . . . . . . . . . 6 53 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 8 55 3. Design Constraints . . . . . . . . . . . . . . . . . . . . . . 8 56 3.1. Security Constraints . . . . . . . . . . . . . . . . . . . 8 57 3.2. Control Constraints . . . . . . . . . . . . . . . . . . . 10 58 3.3. Management Constraints . . . . . . . . . . . . . . . . . . 12 59 4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 12 60 4.1. Design Guidelines for New Encapsulations of Congestion 61 Notification . . . . . . . . . . . . . . . . . . . . . . . 14 62 5. Default ECN Tunnelling Rules . . . . . . . . . . . . . . . . . 15 63 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 64 7. Changes from Earlier RFCs . . . . . . . . . . . . . . . . . . 18 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 67 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 69 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 23 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 71 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 72 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 73 Appendix A. Why resetting CE on encapsulation harms PCN . . . . . 25 74 Appendix B. Contribution to Congestion across a Tunnel . . . . . 26 75 Appendix C. Ideal Decapsulation Rules . . . . . . . . . . . . . . 27 76 Appendix D. Non-Dependence of Tunnelling on In-path Load 77 Regulation . . . . . . . . . . . . . . . . . . . . . 29 78 D.1. Dependence of In-Path Load Regulation on Tunnelling . . . 30 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 80 Intellectual Property and Copyright Statements . . . . . . . . . . 34 82 Changes from previous drafts (to be removed by the RFC Editor) 84 From briscoe-01 to ietf-00 (current): 86 * Re-wrote Appendix B giving much simpler technique to measure 87 contribution to congestion across a tunnel. 89 * Added discussion of backward compatibility of the ideal 90 decapsulation scheme in Appendix C 92 * Updated references. Minor corrections & clarifications 93 throughout. 95 From -00 to -01: 97 * Related everything conceptually to the uniform and pipe models 98 of RFC2983 on Diffserv Tunnels, and completely removed the 99 dependence of tunnelling behaviour on the presence of any in- 100 path load regulation by using the [1 - Before] [2 - Outer] 101 function placement concepts from RFC2983; 103 * Added specific cases where the existing standards limit new 104 proposals, particularly Appendix A; 106 * Added sub-structure to Introduction (Need for Rationalisation, 107 Roadmap), added new Introductory subsection on "Scope" and 108 improved clarity; 110 * Added Design Guidelines for New Encapsulations of Congestion 111 Notification (Section 4.1); 113 * Considerably clarified the Backward Compatibility section 114 (Section 6); 116 * Considerably extended the Security Considerations section 117 (Section 9); 119 * Summarised the primary rationale much better in the 120 conclusions; 122 * Added numerous extra acknowledgements; 124 * Added Appendix A. "Why resetting CE on encapsulation harms 125 PCN", Appendix B. "Contribution to Congestion across a Tunnel" 126 and Appendix C. "Ideal Decapsulation Rules"; 128 * Re-wrote Appendix D, explaining how tunnel encapsulation no 129 longer depends on in-path load-regulation (changed title from 130 "In-path Load Regulation" to "Non-Dependence of Tunnelling on 131 In-path Load Regulation"), but explained how an in-path load 132 regulation function must be carefully placed with respect to 133 tunnel encapsulation (in a new sub-section entitled "Dependence 134 of In-Path Load Regulation on Tunnelling"). 136 1. Introduction 138 This document redefines how the explicit congestion notification 139 (ECN) field [RFC3168] of the outer IP header of a tunnel should be 140 constructed. It brings all IP in IP tunnels (v4 or v6) into line 141 with the way IPsec tunnels [RFC4301] now construct the ECN field, 142 ensuring that the outer header reveals any congestion experienced so 143 far on the whole path, not just since the last tunnel ingress. 145 ECN allows a congested resource to notify the onset of congestion 146 without having to drop packets, by explicitly marking a proportion of 147 packets with the congestion experienced (CE) codepoint. Because 148 congestion is exhaustion of a physical resource, if the transport 149 layer is to deal with congestion, congestion notification must 150 propagate upwards; from the physical layer to the transport layer. 151 The transport layer can directly detect loss of a packet (or frame) 152 by a lower layer. But if a lower layer marks rather than drops a 153 forward-travelling data packet (or frame) in order to notify 154 incipient congestion, this marking has to be explicitly copied up the 155 layers at every header decapsulation. So, at each decapsulation of 156 an outer (lower layer) header a congestion marking has to be arranged 157 to propagate into the forwarded (upper layer) header. It must 158 continue upwards until it reaches the destination transport. Then 159 typically the destination feeds this congestion notification back to 160 the source transport. Given encapsulation by lower layer headers is 161 functionally similar to tunnelling, it is necessary to arrange 162 similar propagation of congestion notification up the layers. For 163 instance, ECN and its propagation up the layers has recently been 164 specified for MPLS [RFC5129]. 166 As packets pass up the layers, current specifications of 167 decapsulation behaviours are largely all consistent and correct. 168 However, as packets pass down the layers, specifications of 169 encapsulation behaviours are not consistent. This document is 170 primarily aimed at rationalising encapsulation. (Nevertheless, 171 Appendix C explains why the consistency of decapsulation solutions 172 will not last for long and proposes a fix to decapsulation rules as 173 well. The IETF can then discuss whether to rationalise decapsulation 174 at the same time as encapsulation.) 176 1.1. The Need for Rationalisation 178 IPsec tunnel mode is a specific form of tunnelling that can hide the 179 inner headers. Because the ECN field has to be mutable, it cannot be 180 covered by IPsec encryption or authentication calculations. 181 Therefore concern has been raised in the past that the ECN field 182 could be used as a low bandwidth covert channel to communicate with 183 someone on the unprotected public Internet even if an end-host is 184 restricted to only communicate with the public Internet through an 185 IPsec gateway. However, the updated version of IPsec [RFC4301] chose 186 not to block this covert channel, deciding that the threat could be 187 managed given the channel bandwidth is so limited (ECN is a 2-bit 188 field). 190 An unfortunate sequence of standards actions leading up to this 191 latest change in IPsec has left us with nearly the worst of all 192 possible combinations of outcomes, despite the best endeavours of 193 everyone concerned. The controversy has been over whether to reveal 194 information about congestion experienced on the path upstream of the 195 tunnel ingress. Even though this has various uses if it is revealed 196 in the outer header of a tunnel, when ECN was standardised [RFC3168] 197 it was decided that all IP in IP tunnels should hide this upstream 198 congestion simply to avoid the extra complexity of two different 199 mechanisms for IPsec and non-IPsec tunnels. However, now that 200 [RFC4301] IPsec tunnels deliberately no longer hide this information, 201 we are left in the perverse position where non-IPsec tunnels still 202 hide congestion information unnecessarily. This document is designed 203 to correct that anomaly. 205 Specifically, RFC3168 says that, if a tunnel fully supports ECN 206 (termed a 'full-functionality' ECN tunnel in [RFC3168]), the tunnel 207 ingress must not copy a CE marking from the inner header into the 208 outer header that it creates. Instead the tunnel ingress has to set 209 the ECN field of the outer header to ECT(0) (i.e. codepoint 10). We 210 term this 'resetting' a CE codepoint. However, RFC4301 reverses 211 this, stating that the tunnel ingress must simply copy the ECN field 212 from the inner to the outer header. The main purpose of this 213 document is to carry the new behaviour of IPsec over to all IP in IP 214 tunnels, so all tunnel ingress nodes consistently copy the ECN field. 216 Why does it matter if we have different ECN encapsulation behaviours 217 for IPsec and non-IPsec tunnels? The general argument is that 218 gratuitous inconsistency constrains the available design space and 219 makes it harder to design networks and new protocols that work 220 predictably. 222 Already complicated constraints have had to be added to a standards 223 track congestion marking proposal. The section of the pre-congestion 224 notification (PCN) architecture [I-D.ietf-pcn-architecture] on 225 tunnelling says PCN works correctly in the presence of RFC4301 IPsec 226 encapsulation (and RFC5129 MPLS encapsulation). However it doesn't 227 work with RFC3168 IP in IP encapsulation (Appendix A explains why). 229 To ensure we do not cause any unintended side-effects, Section 3 230 assesses whether copying or resetting CE would harm any security, 231 control or management functions. It finds that resetting CE makes 232 life difficult in a number of directions, while copying CE harms 233 nothing (other than opening a low bit-rate covert channel 234 vulnerability which the IETF Security Area deems is manageable). 236 1.2. Document Roadmap 238 Most of the document gives a thorough analysis of the knock-on 239 effects of the apparently minor change to tunnel encapsulation. The 240 reader may jump to Section 5 if only interested in standards actions 241 impacting implementation. The whole document is organised as 242 follows: 244 o S.5 of RFC3168 permits the Diffserv codepoint (DSCP)[RFC2474] to 245 'switch in' different behaviours for marking the ECN field, just 246 as it switches in different per-hop behaviours (PHBs) for 247 scheduling. Therefore we cannot only discuss the ECN protocol 248 that RFC3168 gives as a default. Instead, Section 3 lays out the 249 design constraints when tunnelling congestion notification without 250 assuming a particular congestion marking scheme. 252 o Then in Section 4 we resolve the tensions between these 253 constraints to give general design principles and guidelines on 254 how a tunnel should process congestion notification; principles 255 that could apply to any marking behaviour for any PHB, not just 256 the default in RFC3168. In particular, we examine the underlying 257 principles behind whether CE should be reset or copied into the 258 outer header at the ingress to a tunnel--or indeed at the ingress 259 of any layered encapsulation of headers with congestion 260 notification fields. We end this section with a bulleted list of 261 design guidelines for new encapsulations of congestion 262 notification. 264 o Section 5 then uses precise standards terminology to confirm the 265 rules for the default ECN tunnelling behaviour based on the above 266 design principles. 268 o Extending the new IPsec tunnel ingress behaviour to all IP in IP 269 tunnels requires consideration of backwards compatibility, which 270 is covered in Section 6 and changes from earlier RFCs are brought 271 together in Section 7. 273 o Finally, a number of security considerations are discussed and 274 conclusions are drawn. 276 1.3. Scope 278 This document only concerns wire protocol processing at tunnel 279 endpoints and makes no changes or recommendations concerning 280 algorithms for congestion marking or congestion response. 282 This document specifies a common, default congestion encapsulation 283 for any IP in IP tunnelling, based on that now specified for IPsec. 284 It applies irrespective of whether IPv4 or IPv6 is used for either of 285 the inner and outer headers. It applies to all PHBs, unless stated 286 otherwise in the specification of a PHB. It is intended to be a good 287 trade off between somewhat conflicting security, control and 288 management requirements. 290 Nonetheless, if necessary, an alternate congestion encapsulation 291 behaviour can be introduced as part of the definition of an alternate 292 congestion marking scheme used by a specific Diffserv PHB (see S.5 of 293 [RFC3168] and [RFC4774]). When designing such new encapsulation 294 schemes, the principles in Section 4 should be followed as closely as 295 possible. There is no requirement for a PHB to state anything about 296 ECN tunnelling behaviour if the default behaviour is sufficient. 298 Often lower layer resources (e.g. a point-to-point Ethernet link) are 299 arranged to be protected by higher layer buffers, so instead of 300 congestion occurring at the lower layer, it merely causes the queue 301 from the higher layer to overflow. Such non-blocking link and 302 physical layer technologies do not have to implement congestion 303 notification, which can be introduced solely in the active queue 304 management (AQM) from the IP layer. However, not all link layer 305 technologies are always protected from congestion by buffers at 306 higher layers (e.g. a subnetwork of Ethernet links and switches can 307 congest internally). In these cases, when adding congestion 308 notification to lower layers, we have to arrange for it to be 309 explicitly copied up the layers, just as when IP is tunnelled in IP. 311 As well as guiding alternate IP in IP tunnelling schemes, the design 312 guidelines of Section 4 are intended to be followed when IP packets 313 are encapsulated by any connectionless datagram/packet/frame where 314 the outer header is designed to support a congestion notification 315 capability. [RFC5129] already deals with handling ECN for IP in MPLS 316 and MPLS in MPLS, and S.9.3 of [RFC3168] lists IP encapsulated in 317 L2TP [RFC2661], GRE [RFC1701] or PPTP [RFC2637] as possible examples 318 where ECN may be added in future. 320 Of course, the IETF does not have standards authority over every link 321 or tunnel protocol, so this document merely aims to guide the 322 interface between IP ECN and lower layer congestion notification. 323 Then the IETF or the relevant standards body can be free to define 324 the specifics of each lower layer scheme, but a common interface 325 should ensure interworking across all technologies. 327 Note that just because there is forward congestion notification in a 328 lower layer protocol, if the lower layer has its own feedback and 329 load regulation, there is no need to propagate it up the layers. For 330 instance, FECN (forward ECN) has been present in Frame Relay and EFCI 331 (explicit forward congestion indication) in ATM [ITU-T.I.371] for a 332 long time. But so far they have been used for internal management 333 rather than being propagated to endpoint transports for them to 334 control end-to-end congestion. 336 [RFC2983] is a comprehensive primer on differentiated services and 337 tunnels. Given ECN raises similar issues to differentiated services 338 when interacting with tunnels, useful concepts introduced in RFC2983 339 are used throughout, with brief recaps of the explanations where 340 necessary. 342 2. Requirements Language 344 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 345 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 346 document are to be interpreted as described in RFC 2119 [RFC2119]. 348 3. Design Constraints 350 Tunnel processing of a congestion notification field has to meet 351 congestion control needs without creating new information security 352 vulnerabilities (if information security is required). 354 3.1. Security Constraints 356 Information security can be assured by using various end to end 357 security solutions (including IPsec in transport mode [RFC4301]), but 358 a commonly used scenario involves the need to communicate between two 359 physically protected domains across the public Internet. In this 360 case there are certain management advantages to using IPsec in tunnel 361 mode solely across the publicly accessible part of the path. The 362 path followed by a packet then crosses security 'domains'; the ones 363 protected by physical or other means before and after the tunnel and 364 the one protected by an IPsec tunnel across the otherwise unprotected 365 domain. We will use the scenario in Figure 1 where endpoints 'A' and 366 'B' communicate through a tunnel. The tunnel ingress 'I' and egress 367 'E' are within physically protected edge domains, while the tunnel 368 spans an unprotected internetwork where there may be 'men in the 369 middle', M. 371 physically unprotected physically 372 <-protected domain-><--domain--><-protected domain-> 373 +------------------+ +------------------+ 374 | | M | | 375 | A-------->I=========>==========>E-------->B | 376 | | | | 377 +------------------+ +------------------+ 378 <----IPsec secured----> 379 tunnel 381 Figure 1: IPsec Tunnel Scenario 383 IPsec encryption is typically used to prevent 'M' seeing messages 384 from 'A' to 'B'. IPsec authentication is used to prevent 'M' 385 masquerading as the sender of messages from 'A' to 'B' or altering 386 their contents. But 'I' can also use IPsec tunnel mode to allow 'A' 387 to communicate with 'B', but impose encryption to prevent 'A' leaking 388 information to 'M'. Or 'E' can insist that 'I' uses tunnel mode 389 authentication to prevent 'M' communicating information to 'B'. 390 Mutable IP header fields such as the ECN field (as well as the TTL/ 391 Hop Limit and DS fields) cannot be included in the cryptographic 392 calculations of IPsec. Therefore, if 'I' copies these mutable fields 393 into the outer header that is exposed across the tunnel it will have 394 allowed a covert channel from 'A' to M that bypasses its encryption 395 of the inner header. And if 'E' copies these fields from the outer 396 header to the inner, even if it validates authentication from 'I', it 397 will have allowed a covert channel from 'M' to 'B'. 399 ECN at the IP layer is designed to carry information about congestion 400 from a congested resource towards downstream nodes. Typically a 401 downstream transport might feed the information back somehow to the 402 point upstream of the congestion that can regulate the load on the 403 congested resource, but other actions are possible (see [RFC3168] 404 S.6). In terms of the above unicast scenario, ECN is typically 405 intended to create an information channel from 'M' to 'B' (for 'B' to 406 feed back to 'A'). Therefore the goals of IPsec and ECN are mutually 407 incompatible. 409 With respect to the DS or ECN fields, S.5.1.2 of RFC4301 says, 410 "controls are provided to manage the bandwidth of this [covert] 411 channel". Using the ECN processing rules of RFC4301, the channel 412 bandwidth is two bits per datagram from 'A' to 'M' and one bit per 413 datagram from 'M' to 'A' (because 'E' limits the combinations of the 414 2-bit ECN field that it will copy). In both cases the covert channel 415 bandwidth is further reduced by noise from any real congestion 416 marking. RFC4301 therefore implies that these covert channels are 417 sufficiently limited to be considered a manageable threat. However, 418 with respect to the larger (6b) DS field, the same section of RFC4301 419 says not copying is the default, but a configuration option can allow 420 copying "to allow a local administrator to decide whether the covert 421 channel provided by copying these bits outweighs the benefits of 422 copying". Of course, an administrator considering copying of the DS 423 field has to take into account that it could be concatenated with the 424 ECN field giving an 8b per datagram covert channel. 426 Thus, for tunnelling the 6b Diffserv field two conceptual models have 427 had to be defined so that administrators can trade off security 428 against the needs of traffic conditioning [RFC2983]: 430 The uniform model: where the DIffserv field is preserved end-to-end 431 by copying into the outer header on encapsulation and copying from 432 the outer header on decapsulation. 434 The pipe model: where the outer header is independent of that in the 435 inner header so it hides the Diffserv field of the inner header 436 from any interaction with nodes along the tunnel. 438 However, for ECN, the new IPsec security architecture in RFC4301 only 439 standardised one tunnelling model equivalent to the uniform model. 440 It deemed that simplicity was more important than allowing 441 administrators the option of a tiny increment in security, especially 442 given not copying congestion indications could seriously harm 443 everyone's network service. 445 3.2. Control Constraints 447 Congestion control requires that any congestion notification marked 448 into packets by a resource will be able to traverse a feedback loop 449 back to a function capable of controlling the load on that resource. 450 To be precise, rather than calling this function the data source, we 451 will call it the Load Regulator. This will allow us to deal with 452 exceptional cases where load is not regulated by the data source, but 453 usually the two terms will be synonymous. Note the term "a function 454 _capable of_ controlling the load" deliberately includes a source 455 application that doesn't actually control the load but ought to (e.g. 456 an application without congestion control that uses UDP). 458 A--->R--->I=========>M=========>E-------->B 460 Figure 2: Simple Tunnel Scenario 462 We now consider a similar tunnelling scenario to the IPsec one just 463 described, but without the different security domains so we can just 464 focus on ensuring the control loop and management monitoring can work 465 (Figure 2). If we want resources in the tunnel to be able to 466 explicitly notify congestion and the feedback path is from 'B' to 467 'A', it will certainly be necessary for 'E' to copy any CE marking 468 from the outer header to the inner header for onward transmission to 469 'B', otherwise congestion notification from resources like 'M' cannot 470 be fed back to the Load Regulator ('A'). But it doesn't seem 471 necessary for 'I' to copy CE markings from the inner to the outer 472 header. For instance, if resource 'R' is congested, it can send 473 congestion information to 'B' using the congestion field in the inner 474 header without 'I' copying the congestion field into the outer header 475 and 'E' copying it back to the inner header. 'E' can still write any 476 additional congestion marking introduced across the tunnel into the 477 congestion field of the inner header. 479 It might be useful for the tunnel egress to be able to tell whether 480 congestion occurred across a tunnel or upstream of it. If outer 481 header congestion marking was reset by the tunnel ingress ('I'), at 482 the end of a tunnel ('E') the outer headers would indicate congestion 483 experienced across the tunnel ('I' to 'E'), while the inner header 484 would indicate congestion upstream of 'I'. But similar information 485 can be gleaned even if the tunnel ingress copies the inner to the 486 outer headers. At the end of the tunnel ('E'), any packet with an 487 _extra_ mark in the outer header relative to the inner header 488 indicates congestion across the tunnel ('I' to 'E'), while the inner 489 header would still indicate congestion upstream of ('I'). Appendix B 490 gives a simple and precise method for a tunnel egress to infer the 491 congestion level introduced across a tunnel. 493 All this shows that 'E' can preserve the control loop irrespective of 494 whether 'I' copies congestion notification into the outer header or 495 resets it. 497 That is the situation for existing control arrangements but, because 498 copying reveals more information, it would open up possibilities for 499 better control system designs. For instance, Appendix A describes 500 how resetting CE marking at a tunnel ingress confuses a proposed 501 congestion marking scheme on the standards track. It ends up 502 removing excessive amounts of traffic unnecessarily. Whereas copying 503 CE markings at ingress leads to the correct control behaviour. 505 3.3. Management Constraints 507 As well as control, there are also management constraints. 508 Specifically, a management system may monitor congestion markings in 509 passing packets, perhaps at the border between networks as part of a 510 service level agreement. For instance, monitors at the borders of 511 autonomous systems may need to measure how much congestion has 512 accumulated since the original source, perhaps to determine between 513 them how much of the congestion is contributed by each domain. 515 Therefore, when monitoring the middle of a path, it should be 516 possible to establish how far back in the path congestion markings 517 have accumulated from. In this document we term this the baseline of 518 congestion marking (or the Congestion Baseline), i.e. the source of 519 the layer that last reset (or created) the congestion notification 520 field. Given some tunnels cross domain borders (e.g. consider M in 521 Figure 2 is monitoring a border), it would therefore be desirable for 522 'I' to copy congestion accumulated so far into the outer headers 523 exposed across the tunnel. 525 Appendix D discusses various scenarios where the Load Regulator lies 526 in-path, not at the source host as we would typically expect. It 527 concludes that a Congestion Baseline is determined by where the Load 528 Regulator function is, which should be identified in the transport 529 layer, not by addresses in network layer headers. This applies 530 whether the Load Regulator is at the source host or within the path. 531 The appendix also discusses where a Load Regulator function should be 532 located relative to a local tunnel encapsulation function. 534 4. Design Principles 536 The constraints from the three perspectives of security, control and 537 management in Section 3 are somewhat in tension as to whether a 538 tunnel ingress should copy congestion markings into the outer header 539 it creates or reset them. From the control perspective either 540 copying or resetting works for existing arrangements, but copying has 541 more potential for simplifying control. From the management 542 perspective copying is preferable. From the security perspective 543 resetting is preferable but copying is now considered acceptable 544 given the bandwidth of a 2-bit covert channel can be managed. 546 Therefore an outer encapsulating header capable of carrying 547 congestion markings SHOULD reflect accumulated congestion since the 548 last interface designed to regulate load (the Load Regulator). This 549 implies congestion notification SHOULD be copied into the outer 550 header of each new encapsulating header that supports it. 552 We have said that a tunnel ingress SHOULD (as opposed to MUST) copy 553 incoming congestion notification into an outer encapsulating header 554 that supports it. In the case of 2-bit ECN, the IETF security area 555 has deemed the benefit always outweighs the risk. Therefore for 556 2-bit ECN we can and we will say 'MUST' (Section 5). But in this 557 section where we are setting down general design principles, we leave 558 it as a 'SHOULD'. This allows for future multi-bit congestion 559 notification fields where the risk from the covert channel created by 560 copying congestion notification might outweigh the congestion control 561 benefit of copying. 563 The Load Regulator is the node to which congestion feedback should be 564 returned by the next downstream node with a transport layer feedback 565 function (typically but not always the data receiver). The Load 566 Regulator is not always (or even typically) the same thing as the 567 node identified by the source address of the outermost exposed 568 header. In general the addressing of the outermost encapsulation 569 header says nothing about the identifiers of either the upstream or 570 the downstream transport layer functions. As long as the transport 571 functions know each other's addresses, they don't have to be 572 identified in the network layer or in any link layer. It was only a 573 convenience that a TCP receiver assumed that the address of the 574 source transport is the same as the network layer source address of 575 an IP packet it receives. 577 More generally, the return transport address for feedback could be 578 identified solely in the transport layer protocol. For instance, a 579 signalling protocol like RSVP [RFC2205] breaks up a path into 580 transport layer hops and informs each hop of the address of its 581 transport layer neighbour without any need to identify these hops in 582 the network layer. RSVP can be arranged so that these transport 583 layer hops are bigger than the underlying network layer hops. The 584 host identity protocol (HIP) architecture [RFC4423] also supports the 585 same principled separation (for mobility amongst other things), where 586 the transport layer sender identifies its transport address for 587 feedback to be sent to, using an identifier provided by a shim below 588 the transport layer. 590 Keeping to this layering principle deliberately doesn't require a 591 network layer packet header to reveal the origin address from where 592 congestion notification accumulates (its Congestion Baseline). It is 593 not necessary for the network and lower layers to know the address of 594 the Load Regulator. Only the destination transport needs to know 595 that. With forward congestion notification, the network and link 596 layers only notify congestion forwards; they aren't involved in 597 feeding it backwards. If they are (e.g. backward congestion 598 notification (BCN) in Ethernet [IEEE802.1au] or EFCI in ATM 599 [ITU-T.I.371]), that should be considered as a transport function 600 added to the lower layer, which must sort out its own addressing. 601 Indeed, this is one reason why ICMP source quench is now deprecated 602 [RFC1254]; when congestion occurs within a tunnel it is complex 603 (particularly in the case of IPsec tunnels) to return the ICMP 604 messages beyond the tunnel ingress back to the Load Regulator. 606 Similarly, if a management system is monitoring congestion and needs 607 to know the Congestion Baseline, the management system has to find 608 this out from the transport; in general it cannot tell solely by 609 looking at the network or link layer headers. 611 4.1. Design Guidelines for New Encapsulations of Congestion 612 Notification 614 The following guidelines are for specifications of new schemes for 615 encapsulating congestion notification (e.g. for specialised Diffserv 616 PHBs in IP, or for lower layer technologies): 618 1. Congestion notification in outer headers SHOULD be relative to a 619 Congestion Baseline at the node expected to regulate the load on 620 the link in question (the Load Regulator). This implies incoming 621 congestion notifications from the higher layer SHOULD be copied 622 into encapsulating headers. This guideline is particularly 623 important where outer headers might cross trust boundaries, but 624 less important otherwise. 626 2. Congestion notification MUST NOT simply be copied from outer 627 headers to the forwarded header on decapsulation. The forwarded 628 congestion notification field SHOULD be calculated from the inner 629 and outer headers, taking account of the following, in the order 630 given: 632 1. If the inner header does not support congestion notification, 633 or indicates that the transport does not support congestion 634 notification, any explicit congestion notifications in the 635 outer header will not be understood if propagated further, so 636 if the only way to indicate congestion to onward nodes is to 637 drop the packet, it MUST be dropped. 639 2. If the outer header does not support explicit congestion 640 notification, but the inner header does, the inner header 641 SHOULD be forwarded unchanged. 643 3. Congestion indications may be ranked by strength. For 644 instance no congestion would be the weakest indication, with 645 possibly increasing levels of congestion given increasingly 646 stronger indications. 648 4. Where the inner and outer headers carry indications of 649 congestion of different strengths, the stronger indication 650 SHOULD be forwarded in preference to the weaker. Obviously, 651 if the strengths in both inner and outer are the same, the 652 same strength should be forwarded. 654 5. If the outer header carries a weaker indication of congestion 655 than the inner, it MAY be appropriate to raise a warning, as 656 this would be in illegal combination if Guideline Paragraph 1 657 had been followed. 659 3. Where framing boundaries are different between the two layers, 660 congestion indications SHOULD be propagated on the basis that a 661 congestion indication in a packet or frame applies to all the 662 octets in the frame/packet. On average, a tunnel endpoint SHOULD 663 approximately preserve the number of marked octets arriving and 664 leaving. An algorithm for spreading congestion indications over 665 multiple smaller `fragments' SHOULD propagate congestion 666 indications as soon as they arrive, and SHOULD NOT hold them back 667 for later frames. 669 4. Assumptions on incremental deployment MUST be stated. 671 Regarding incremental deployment, the Per-Domain ECT Checking 672 of[RFC5129] is a good example to follow. In this example, header 673 space in the lower layer protocol (MPLS) was extremely limited, so no 674 ECN-capable transport codepoint was added to the MPLS header. 675 Interior nodes in a domain were allowed to set explicit congestion 676 indications without checking whether the frame was destined for a 677 transport that would understand them. This was made safe by 678 emphasising repeatedly that all the decapsulating edges of a whole 679 domain had to be upgraded at once, so there would always be a check 680 that the higher layer transport was ECN-capable on decapsulation. If 681 the decapsulator discovered that the higher layer showed the 682 transport would not understand ECN, it dropped the packet on behalf 683 of the earlier congestion node (see Guideline Paragraph 2.1). 685 Note that such a deployment strategy that assumes a savvy operator 686 was only appropriate because MPLS is targeted solely at professional 687 operators. This strategy would not be appropriate for other link 688 technologies (e.g. Ethernet) targeted at deployment by the general 689 public. 691 5. Default ECN Tunnelling Rules 693 The following ECN tunnel processing rules are the default for a 694 packet with any DSCP. If required, different ECN encapsulation rules 695 MAY be defined as part of the definition of an appropriate Diffserv 696 PHB using the guidelines in Section 4. However, the burden of 697 handling exceptional PHBs in implementations of all affected tunnels 698 and lower layer link protocols should not be underestimated. 700 A tunnel ingress compliant with this specification MUST copy the 701 2-bit ECN field of the arriving IP header into the outer 702 encapsulating IP header, for all types of IP in IP tunnel. This 703 encapsulation behaviour MUST only be used if the tunnel ingress is in 704 `normal state'. A `compatibility state' with a different 705 encapsulation behaviour is also specified in Section 6 for backward 706 compatibility with legacy tunnel egresses that do not understand ECN. 708 To decapsulate the inner header at the tunnel egress, a compliant 709 tunnel egress MUST set the outgoing ECN field to the codepoint at the 710 intersection of the appropriate incoming inner header (row) and outer 711 header (column) in Figure 3. 713 +---------------------------------------------+ 714 | Incoming Outer Header | 715 +---------------------+---------+-----------+-----------+-----------+ 716 | Incoming Inner | Not-ECT | ECT(0) | ECT(1) | CE | 717 | Header | | | | | 718 +---------------------+---------+-----------+-----------+-----------+ 719 | Not-ECT | Not-ECT | drop(!!!) | drop(!!!) | drop(!!!) | 720 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | 721 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE | 722 | CE | CE | CE | CE (!!!) | CE | 723 +---------------------+---------+-----------+-----------+-----------+ 724 | Outgoing Header | 725 +---------------------------------------------+ 727 Figure 3: IP in IP Decapsulation 729 The exclamation marks '(!!!)' in Figure 3 indicate that this 730 combination of inner and outer headers should not be possible if only 731 legal transitions have taken place. So, the decapsulator should drop 732 or mark the ECN field as the table specifies, but it MAY also raise 733 an appropriate alarm. It MUST NOT raise an alarm so often that the 734 illegal combinations would amplify into a flood of alarm messages. 736 6. Backward Compatibility 738 Note: in RFC3168, a tunnel was in one of two modes: limited 739 functionality or full functionality. Rather than working with modes 740 of the tunnel as a whole, this specification uses the term `state' to 741 refer separately to the state of each tunnel end point, which is how 742 implementations have to work. 744 If one end of an IPsec tunnel is compliant with [RFC4301], the other 745 end can be guaranteed to also be [RFC4301] compliant (there could be 746 corner cases where manual keying is used, but they will be ignored 747 here). So there is no backward compatibility problem with IKEv2 748 RFC4301 IPsec tunnels. But once we extend our scope to any IP in IP 749 tunnel, we have to cater for the possibility that a legacy tunnel 750 egress may not know how to process an ECN field, so if ECN capable 751 outer headers were sent towards a legacy (e.g. [RFC2003]) egress, it 752 would most likely simply disregard the outer headers, dangerously 753 discarding information about congestion experienced within the 754 tunnel. ECN-capable traffic sources would not see any congestion 755 feedback and instead continually ratchet up their share of the 756 bandwidth without realising that cross-flows from other ECN sources 757 were continually having to ratchet down. 759 To be compliant with this specification a tunnel ingress that does 760 not always know the ECN capability of its tunnel egress MUST 761 implement a 'normal' state and a 'compatibility' state, and it MUST 762 initiate each negotiated tunnel in the compatibility state. 764 However, a tunnel ingress can be compliant even if it only implements 765 the 'normal state' of encapsulation behaviour, but only as long as it 766 is designed or configured so that all possible tunnel egress nodes it 767 will ever talk to will have full ECN functionality (RFC3168 full 768 functionality mode, RFC4301 and this present specification). The 769 `normal state' is that defined in Section 5 (i.e. header copying). 770 Note that a [RFC4301] tunnel ingress that has used IKEv2 key 771 management [RFC4306] can guarantee that its tunnel egress is also 772 RFC4301-compliant and therefore need not further negotiate ECN 773 capabilities. 775 Before switching to normal state, a compliant tunnel ingress that 776 does not know the egress ECN capability MUST negotiate with the 777 tunnel egress. If the egress says it is in full functionality state 778 (or mode), the ingress puts itself into normal state. In normal 779 state the ingress follows the encapsulation rule in Section 5 (i.e. 780 header copying). If the egress says it is not in full-functionality 781 state/mode or doesn't understand the question, the tunnel ingress 782 MUST remain in compatibility state. 784 A tunnel ingress in compatibility state MUST set all outer headers to 785 Not-ECT. This is the same per packet behaviour as the ingress end of 786 RFC3168's limited functionality mode. 788 A tunnel ingress that only implements compatibility state is at least 789 safe with the ECN behaviour of any egress it may encounter (any of 790 RFC2003, RFC2401, either mode of RFC2481 and RFC3168's limited 791 functionality mode). But an ingress cannot claim compliance with 792 this specification simply by disabling ECN processing across the 793 tunnel. A compliant tunnel ingress MUST at least implement `normal 794 state' and, if it might be used with arbitrary tunnel egress nodes, 795 it MUST also implement `compatibility state'. 797 A compliant tunnel egress on the other hand merely needs to implement 798 the one behaviour in Section 5, which we term 'full-functionality' 799 state, as it is the same as the egress end of the full-functionality 800 mode of [RFC3168]. It is also the same as the [RFC4301] egress 801 behaviour. 803 The decapsulation rules for the egress of the tunnel in Section 5 804 have been defined in such a way that congestion control will still 805 work safely if any of the earlier versions of ECN processing are used 806 unilaterally at the encapsulating ingress of the tunnel (any of 807 RFC2003, RFC2401, either mode of RFC2481, either mode of RFC3168, 808 RFC4301 and this present specification). If a tunnel ingress tries 809 to negotiate to use limited functionality mode or full functionality 810 mode [RFC3168], a decapsulating tunnel egress compliant with this 811 specification MUST agree to either request, as its behaviour will be 812 the same in both cases. 814 For 'forward compatibility', a compliant tunnel egress SHOULD raise a 815 warning about any requests to enter states or modes it doesn't 816 recognise, but it can continue operating. If no ECN-related state or 817 mode is requested, a compliant tunnel egress need not raise an error 818 or warning as its egress behaviour is compatible with all the legacy 819 ingress behaviours that don't negotiate capabilities. 821 Implementation note: if a compliant node is the ingress for multiple 822 tunnels, a state setting will need to be stored for each tunnel 823 ingress. However, if a node is the egress for multiple tunnels, none 824 of the tunnels will need to store a state setting, because a 825 compliant egress can only be in one state. 827 7. Changes from Earlier RFCs 829 The rule that a normal state tunnel ingress MUST copy any ECN field 830 into the outer header is a change to the ingress behaviour of 831 RFC3168, but it is the same as the rules for IPsec tunnels in 832 RFC4301. 834 The rules for calculating the outgoing ECN field on decapsulation at 835 a tunnel egress are in line with the full functionality mode of ECN 836 in RFC3168 and with RFC4301, except that neither identified that an 837 outer header of ECT(1) combined with an inner header of CE was an 838 illegal combination. 840 The rules for how a tunnel establishes whether the egress has full 841 functionality ECN capabilities are an update to RFC3168. For all the 842 typical cases, RFC4301 is not updated by the ECN capability check in 843 this specification, because a typical RFC4301 tunnel ingress will 844 have already established that it is talking to an RFC4301 tunnel 845 egress (e.g. if it uses IKEv2). However, there may be some corner 846 cases (e.g. manual keying) where an RFC4301 tunnel ingress talks with 847 an egress with limited functionality ECN handling. Strictly, for 848 such corner cases, the requirement to use compatibility mode in this 849 specification updates RFC4301. 851 The optional ECN Tunnel field in the IPsec security association 852 database (SAD) and the optional ECN Tunnel Security Association 853 Attribute defined in RFC3168 are no longer needed. The security 854 association (SA) has no policy on ECN usage, because all RFC4301 855 tunnels now support ECN without any policy choice. 857 RFC3168 defines a (required) limited functionality mode and an 858 (optional) full functionality mode for a tunnel, but RFC4301 doesn't 859 need modes. In this specification only the ingress might need two 860 states: a normal state (required) and a compatibility state (required 861 in some scenarios, optional in others). The egress needs only full- 862 functionality state which handles ECN the same as either mode of 863 RFC3168 or RFC4301. 865 Additional changes to the RFC Index (to be removed by the RFC Editor): 867 In the RFC index, RFC3168 should be identified as an update to 868 RFC2003 and RFC4301 should be identified as an update to RFC3168. 870 This specification updates RFC3168. It also suggests a minor 871 optional warning and a corner-case change to RFC4301, but these don't 872 really count as an update. 874 8. IANA Considerations 876 This memo includes no request to IANA. 878 9. Security Considerations 880 Section 3.1 discusses the security constraints imposed on ECN tunnel 881 processing. The Design Principles of Section 4 trade-off between 882 security (covert channels) and congestion monitoring & control. In 883 fact, ensuring congestion markings are not lost is itself another 884 aspect of security, because if we allowed congestion notification to 885 be lost, any attempt to enforce a response to congestion would be 886 much harder. 888 If alternate congestion notification semantics are defined for a 889 certain PHB (e.g. the pre-congestion notification architecture 890 [I-D.ietf-pcn-architecture]), the scope of the alternate semantics 891 might typically be bounded by the limits of a Diffserv region or 892 regions, as envisaged in [RFC4774]. The inner headers in tunnels 893 crossing the boundary of such a Diffserv region but ending within the 894 region can potentially leak the external congestion notification 895 semantics into the region, or leak the internal semantics out of the 896 region. [RFC2983] discusses the need for Diffserv traffic 897 conditioning to be applied at these tunnel endpoints as if they are 898 at the edge of the Diffserv region. Similar concerns apply to any 899 processing or propagation of the ECN field at the edges of a Diffserv 900 region with alternate ECN semantics. Such edge processing must also 901 be applied at the endpoints of tunnels with ends both inside and 902 outside the domain. [I-D.ietf-pcn-architecture] gives specific 903 advice on this for the PCN case, but other definitions of alternate 904 semantics will need to discuss the specific security implications in 905 their case. 907 With the rules as they stand in RFC3168 and RFC4301, a small part of 908 the protection of the ECN nonce [RFC3540] is compromised. One reason 909 two ECT codepoints were defined was to enable the data source to 910 detect if a CE marking had been applied then subsequently removed. 911 The source could detect this by weaving a pseudo-random sequence of 912 ECT(0) and ECT(1) values into a stream of packets, which is termed an 913 ECN nonce. By the decapsulation rules in RFC3168 and RFC4301, if the 914 inner and outer headers carry contradictory ECT values only the inner 915 header is preserved for onward forwarding. So if a CE marking added 916 to the outer ECN field has been illegally (or accidentally) 917 suppressed by a subsequent node in the tunnel, the decapsulator will 918 revert the ECN field to its value before tampering, hiding all 919 evidence of the crime from the onward feedback loop. To close this 920 loophole, we could have specified that an outer header value of ECT 921 should overwrite a contradictory ECT value in the inner header (for 922 how, see the ideal decapsulation rules proposed in Appendix C). But 923 currently we choose to keep the 'broken' behaviour defined in RFC3168 924 & RFC4301 for all the following reasons: 926 1. We wanted to avoid any changes to IPsec tunnelling behaviour; 928 2. Allowing ECT values in the outer header to override the inner 929 header would have increased the bandwidth of the covert channel 930 through the egress gateway from 1 to 1.5 bit per datagram, 931 potentially threatening to upset the consensus established in the 932 security area that says that the bandwidth of this covert channel 933 can now be safely managed; 935 3. This loophole is only applicable in the corner case where the 936 attacker is a network node downstream of a congested node in the 937 same tunnel; 939 4. In tunnelling scenarios, the ECN nonce is already vulnerable to 940 suppression by nodes downstream of a congested node in the same 941 tunnel, if they can copy the ECT value in the inner header to the 942 outer header (any node in the tunnel can do this if the inner 943 header is not encrypted, and an IPsec tunnel egress can do it 944 whether or not the tunnel is encrypted); 946 5. Although the 'broken' decapsulation behaviour removes evidence of 947 congestion suppression from the onward feedback loop, the 948 decapsulator itself can at least detect that congestion within 949 the tunnel has been suppressed; 951 6. The ECN nonce [RFC3540] currently has experimental status and 952 there has been no evidence that anyone has implemented it beyond 953 the author's prototype. 955 If a legacy security policy configures a legacy tunnel ingress to 956 negotiate to turn off ECN processing, a compliant tunnel egress will 957 agree to a request to turn off ECN processing but it will actually 958 still copy CE markings from the outer to the forwarded header. 959 Although the tunnel ingress 'I' in Figure 1 will set all ECN fields 960 in outer headers to Not-ECT, 'M' could still toggle CE on and off to 961 communicate covertly with 'B', because we have specified that 'E' 962 only has one mode regardless of what mode it says it has negotiated. 963 We could have specified that 'E' should have a limited functionality 964 mode and check for such behaviour. But we decided not to add the 965 extra complexity of two modes on a compliant tunnel egress merely to 966 cater for a legacy security concern that is now considered 967 manageable. 969 10. Conclusions 971 This document updates the ingress tunnelling encapsulation of RFC3168 972 ECN for all IP in IP tunnels to bring it into line with the new 973 behaviour in the IPsec architecture of RFC4301. 975 At a tunnel egress, header decapsulation for the default ECN marking 976 behaviour is broadly unchanged except that one exceptional case has 977 been catered for. At the ingress, for all forms of IP in IP tunnel, 978 encapsulation has been brought into line with the new IPsec rules in 979 RFC4301 which copy rather than reset CE markings when creating outer 980 headers. 982 This change to encapsulation has been motivated by analysis from the 983 three perspectives of security, control and management. They are 984 somewhat in tension as to whether a tunnel ingress should copy 985 congestion markings into the outer header it creates or reset them. 986 From the control perspective either copying or resetting works for 987 existing arrangements, but copying has more potential for simplifying 988 control and resetting breaks at least one proposal already on the 989 standards track. From the management and monitoring perspective 990 copying is preferable. From the network security perspective (theft 991 of service etc) copying is preferable. From the information security 992 perspective resetting is preferable, but the IETF Security Area now 993 considers copying acceptable given the bandwidth of a 2-bit covert 994 channel can be managed. Therefore there are no points against 995 copying and a number against resetting CE on ingress. 997 The change ensures ECN processing in all IP in IP tunnels reflects 998 this slightly more permissive attitude to revealing congestion 999 information in the new IPsec architecture. Once all tunnelling of 1000 ECN works the same, ECN markings will have a defined meaning when 1001 measured at any point in a network. This new certainty will enable 1002 new uses of the ECN field that would otherwise be confounded by 1003 ambiguity. 1005 Also, this document defines more generic principles to guide the 1006 design of alternate forms of tunnel processing of congestion 1007 notification, if required for specific Diffserv PHBs or for other 1008 lower layer encapsulating protocols that might support congestion 1009 notification in the future. 1011 11. Acknowledgements 1013 Thanks to David Black for explaining a better way to think about 1014 function placement and to Louise Burness for a better way to think 1015 about multilayer transports and networks, having read 1016 [Patterns_Arch]. Also thanks to Arnaud Jacquet for the idea for 1017 Appendix B. Thanks to Bruce Davie, Toby Moncaster, Gorry Fairhurst, 1018 Sally Floyd, Alfred Hoenes and Gabriele Corliano for their thoughts 1019 and careful review comments. 1021 Bob Briscoe is partly funded by Trilogy, a research project (ICT- 1022 216372) supported by the European Community under its Seventh 1023 Framework Programme. The views expressed here are those of the 1024 author only. 1026 12. Comments Solicited 1028 Comments and questions are encouraged and very welcome. They can be 1029 addressed to the IETF Transport Area working group mailing list 1030 , and/or to the authors. 1032 13. References 1034 13.1. Normative References 1036 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1037 October 1996. 1039 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1040 Requirement Levels", BCP 14, RFC 2119, March 1997. 1042 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1043 "Definition of the Differentiated Services Field (DS 1044 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1045 December 1998. 1047 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1048 of Explicit Congestion Notification (ECN) to IP", 1049 RFC 3168, September 2001. 1051 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1052 Internet Protocol", RFC 4301, December 2005. 1054 13.2. Informative References 1056 [I-D.ietf-pcn-architecture] 1057 Eardley, P., "Pre-Congestion Notification (PCN) 1058 Architecture", draft-ietf-pcn-architecture-07 (work in 1059 progress), September 2008. 1061 [I-D.ietf-pcn-marking-behaviour] 1062 Eardley, P., "Marking behaviour of PCN-nodes", 1063 draft-ietf-pcn-marking-behaviour-00 (work in progress), 1064 October 2008. 1066 [I-D.ietf-pwe3-congestion-frmwk] 1067 Bryant, S., Davie, B., Martini, L., and E. Rosen, 1068 "Pseudowire Congestion Control Framework", 1069 draft-ietf-pwe3-congestion-frmwk-01 (work in progress), 1070 May 2008. 1072 [I-D.moncaster-pcn-3-state-encoding] 1073 Moncaster, T., Briscoe, B., and M. Menth, "A three state 1074 extended PCN encoding scheme", 1075 draft-moncaster-pcn-3-state-encoding-00 (work in 1076 progress), June 2008. 1078 [IEEE802.1au] 1079 IEEE, "IEEE Standard for Local and Metropolitan Area 1080 Networks--Virtual Bridged Local Area Networks - Amendment 1081 10: Congestion Notification", 2008, 1082 . 1084 (Work in Progress; Access Controlled link within page) 1086 [ITU-T.I.371] 1087 ITU-T, "Traffic Control and Congestion Control in 1088 {B-ISDN}", ITU-T Rec. I.371 (03/04), March 2004. 1090 [PCNcharter] 1091 IETF, "Congestion and Pre-Congestion Notification (pcn)", 1092 IETF w-g charter , Feb 2007, 1093 . 1095 [Patterns_Arch] 1096 Day, J., "Patterns in Network Architecture: A Return to 1097 Fundamentals", Pub: Prentice Hall ISBN-13: 9780132252423, 1098 Jan 2008. 1100 [RFC1254] Mankin, A. and K. Ramakrishnan, "Gateway Congestion 1101 Control Survey", RFC 1254, August 1991. 1103 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1104 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1106 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1107 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1108 Functional Specification", RFC 2205, September 1997. 1110 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 1111 W., and G. Zorn, "Point-to-Point Tunneling Protocol", 1112 RFC 2637, July 1999. 1114 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1115 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1116 RFC 2661, August 1999. 1118 [RFC2983] Black, D., "Differentiated Services and Tunnels", 1119 RFC 2983, October 2000. 1121 [RFC3426] Floyd, S., "General Architectural and Policy 1122 Considerations", RFC 3426, November 2002. 1124 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 1125 Congestion Notification (ECN) Signaling with Nonces", 1126 RFC 3540, June 2003. 1128 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1129 RFC 4306, December 2005. 1131 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1132 (HIP) Architecture", RFC 4423, May 2006. 1134 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 1135 Explicit Congestion Notification (ECN) Field", BCP 124, 1136 RFC 4774, November 2006. 1138 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1139 Marking in MPLS", RFC 5129, January 2008. 1141 [Shayman] "Using ECN to Signal Congestion Within an MPLS Domain", 1142 2000, . 1145 (Expired) 1147 Appendix A. Why resetting CE on encapsulation harms PCN 1149 Regarding encapsulation, the section of the PCN architecture 1150 [I-D.ietf-pcn-architecture] on tunnelling says that header copying 1151 (RFC4301) allows PCN to work correctly. However, resetting CE 1152 markings confuses PCN marking. 1154 The specific issue here concerns PCN excess rate marking 1155 [I-D.ietf-pcn-marking-behaviour], i.e. the bulk marking of traffic 1156 that exceeds a configured threshold rate. One of the goals of excess 1157 rate marking is to enable the speedy removal of excess admission 1158 controlled traffic following re-routes caused by link failures or 1159 other disasters. This maintains a share of the capacity for 1160 competing admission controlled traffic and for traffic in lower 1161 priority classes. After failures, traffic re-routed onto remaining 1162 links can often stress multiple links along a path. Therefore, 1163 traffic can arrive at a link under stress with some proportion 1164 already marked for removal by a previous link. By design, marked 1165 traffic will be removed by the overall system in subsequent round 1166 trips. So when the excess rate marking algorithm decides how much 1167 traffic to mark for removal, it doesn't include traffic already 1168 marked for removal by another node upstream (the `Excess traffic 1169 meter function' of [I-D.ietf-pcn-marking-behaviour]). 1171 However, if an RFC3168 tunnel ingress intervenes, it resets the ECN 1172 field in all the outer headers, hiding all the evidence of problems 1173 upstream. Thus, although excess rate marking works fine with RFC4301 1174 IPsec tunnels, with RFC3168 tunnels it typically removes large 1175 volumes of traffic that it didn't need to remove at all. 1177 Appendix B. Contribution to Congestion across a Tunnel 1179 This specification mandates that a tunnel ingress determines the ECN 1180 field of each new outer tunnel header by copying the arriving header. 1181 Concern has been expressed that this will make it difficult for the 1182 tunnel egress to monitor congestion introduced along a tunnel, which 1183 is easy if the outer ECN field is reset at a tunnel ingress (RFC3168 1184 full functionality mode). However, in fact copying CE marks at 1185 ingress will still make it easy for the egress to measure congestion 1186 introduced across a tunnel, as illustrated below. 1188 Consider 100 packets measured at the egress. It measures that 30 are 1189 CE marked in the inner and outer headers and 12 have additional CE 1190 marks in the outer but not the inner. This means packets arriving at 1191 the ingress had already experienced 30% congestion. However, it does 1192 not mean there was 12% congestion across the tunnel. The correct 1193 calculation of congestion across the tunnel is p_t = 12/(100-30) = 1194 12/70 = 17%. This is easy for the egress to to measure. It is the 1195 packets with additional CE marking in the outer header (12) as a 1196 proportion of packets not marked in the inner header (70). 1198 Figure 4 illustrates this in a combinatorial probability diagram. 1199 The square represents 100 packets. The 30% division along the bottom 1200 represents marking before the ingress, and the p_t division up the 1201 side represents marking along the tunnel. 1203 +-----+---------+100% 1204 | | | 1205 | 30 | | 1206 | | | The large square 1207 | +---------+p_t represents 100 packets 1208 | | 12 | 1209 +-----+---------+0 1210 0 30% 100% 1211 inner header marking 1213 Figure 4: Tunnel Marking of Packets Already Marked at Ingress 1215 Appendix C. Ideal Decapsulation Rules 1217 This appendix is not normative. Compliance with this appendix is NOT 1218 REQUIRED for compliance with the present specification. 1220 If the default ECN encapsulation behaviour does not offer suitable 1221 trade offs, procedures exist for associating a new behaviour with a 1222 new Diffserv PHB. However, it is unrealistic to expect vendors of 1223 all IPSec and all IP in IP tunnel endpoints to cater for the 1224 exceptional behaviour of PHB XXX. If all tunnels did require XXX- 1225 specific behaviour, the resulting patchy and error-prone deployment 1226 would probably cause XXX to suffer byzantine feature interactions 1227 with poorly implemented tunnels. The default rules for tunnel 1228 endpoints to handle both the Diffserv field and the ECN field should 1229 'just work' when handling packets with an XXX Diffserv codepoint. 1231 Given this specification requests a standards action to update the 1232 RFC3168 encapsulation behaviour, this appendix explores a further 1233 change to decapsulation that we ought to specify at the same time. 1234 If instead this further change is added later, it will add another 1235 set of backward compatibility combinations to the already complicated 1236 change history of ECN tunnelling. 1238 Multi-level congestion notification is currently on the IETF's 1239 standards track agenda in the Congestion and Pre-Congestion 1240 Notification (PCN) working group. The PCN working group requires 1241 three congestion states (not marked and two levels of congestion 1242 marking) [I-D.ietf-pcn-architecture]. The aim is for the first level 1243 of marking to stop admitting new traffic and the second level to 1244 terminate sufficient existing flows to bring a network back to its 1245 operating point after a serious failure. 1247 Although the ECN field gives sufficient codepoints for these three 1248 states, the PCN working group cannot use them in case any tunnel 1249 decapsulations occur within a PCN region. If a node in a tunnel sets 1250 the ECN field to ECT(0) or ECT(1), this change will be discarded by a 1251 tunnel egress compliant with RFC4301 and RFC3168. This can be seen 1252 in Figure 3, where the ECT values in the outer header are ignored 1253 unless the inner header is the same. Effectively the ECT(0) and 1254 ECT(1) codepoints have to be treated as just one codepoint when they 1255 could otherwise have been used for their intended purpose of 1256 congestion notification. Instead, the PCN w-g has had to propose 1257 using extra Diffserv codepoint(s) to encode the extra states 1258 [I-D.moncaster-pcn-3-state-encoding], using up the rapidly exhausting 1259 DSCP space while leaving ECN codepoints unused. 1261 Although this is currently most pressing for the PCN working group, 1262 the issue is more general. Under Security Considerations (Section 9) 1263 it has already been explained that a data sender cannot use the 1264 experimental ECN nonce [RFC3540] to detect suppression of congestion 1265 notification along a tunnel. 1267 More generally, the currently standardised tunnel decapsulation 1268 behaviour unnecessarily wastes a quarter of two bits (i.e. half a 1269 bit) in the IP (v4 & v6) header. As explained in Section 3.1, the 1270 original reason for not copying down outer ECT codepoints for onward 1271 forwarding was to limit the covert channel across a decapsulator to 1 1272 bit per packet. However, now that the IETF Security Area has deemed 1273 that a 2-bit covert channel through an encapsulator is a manageable 1274 risk, the same should be true for a decapsulator. 1276 Figure 5 proposes a more ideal layered decapsulation behaviour. 1277 Note: this table is only to support discussion. It is not currently 1278 proposed for standards action. The only difference from Figure 3 1279 (that is proposed for standards action), is the swapping of the cells 1280 highlighted as *ECT(X)*. 1282 +---------------------------------------------+ 1283 | Incoming Outer Header | 1284 +---------------------+---------+-----------+-----------+-----------+ 1285 | Incoming Inner | Not-ECT | ECT(0) | ECT(1) | CE | 1286 | Header | | | | | 1287 +---------------------+---------+-----------+-----------+-----------+ 1288 | Not-ECT | Not-ECT | drop(!!!) | drop(!!!) | drop(!!!) | 1289 | ECT(0) | ECT(0) | ECT(0) | *ECT(1)* | CE | 1290 | ECT(1) | ECT(1) | *ECT(0)* | ECT(1) | CE | 1291 | CE | CE | CE | CE (!!!) | CE | 1292 +---------------------+---------+-----------+-----------+-----------+ 1293 | Outgoing Header | 1294 +---------------------------------------------+ 1296 Figure 5: Ideal IP in IP Decapsulation (currently informative, not 1297 normative) 1299 Note that, if this ideal proposal were taken up, a tunnel egress 1300 complying with it would be backwards compatible with all previous 1301 specifications for encapsulation of ECN at the ingress (RFC4301, both 1302 modes of RFC3168, both modes of RFC2481 and RFC2003). In comparison 1303 with an RFC3168 or RFC4301 tunnel egress, it would require no 1304 additional configuration at the ingress nor any additional 1305 negotiation with the ingress. The only new issue would be the burden 1306 of an extra standard to be compliant with, adding to the already 1307 complex history of ECN tunnelling RFCs. 1309 Appendix D. Non-Dependence of Tunnelling on In-path Load Regulation 1311 We have said that at any point in a network, the Congestion Baseline 1312 (where congestion notification starts from zero) should be the 1313 previous upstream Load Regulator. We have also said that the ingress 1314 of an IP in IP tunnel must copy congestion indications to the 1315 encapsulating outer headers it creates. If the Load Regulator is in- 1316 path rather than at the source, and also a tunnel ingress, these two 1317 requirements seem to be contradictory. A tunnel ingress must not 1318 reset incoming congestion, but a Load Regulator must be the 1319 Congestion Baseline, implying it needs to reset incoming congestion. 1321 In fact, the two requirements are not contradictory, because a Load 1322 Regulator and a tunnel ingress are functions within a node that 1323 typically occur in sequence on a stream of packets, not at the same 1324 point. Figure 6 is borrowed from [RFC2983] (which was making a 1325 similar point about the location of Diffserv traffic conditioning 1326 relative to the encapsulation function of a tunnel). An in-path Load 1327 Regulator can act on packets either at [1 - Before] encapsulation or 1328 at [2 - Outer] after encapsulation. Load Regulation does not ever 1329 need to be integrated with the [Encapsulate] function (but it can be 1330 for efficiency). Therefore we can still mandate that the 1331 [Encapsulate] function always copies CE into the outer header. 1333 >>-----[1 - Before]--------[Encapsulate]----[3 - Inner]---------->> 1334 \ 1335 \ 1336 +--------[2 - Outer]------->> 1338 Figure 6: Placement of In-Path Load Regulator Relative to Tunnel 1339 Ingress 1341 Then separately, if there is a Load Regulator at location [2 - 1342 Outer], it might reset CE to ECT(0), say. Then the Congestion 1343 Baseline for the lower layer (outer) will be [2 - Outer], while the 1344 Congestion Baseline of the inner layer will be unchanged. But how 1345 encapsulation works has nothing to do with whether a Load Regulator 1346 is present or where it is. 1348 If on the other hand a Load Regulator resets CE at [1 - Before], the 1349 Congestion Baseline of both the inner and outer headers will be [1 - 1350 Before]. But again, encapsulation is independent of load regulation. 1352 D.1. Dependence of In-Path Load Regulation on Tunnelling 1354 Although encapsulation doesn't need to depend on in-path load 1355 regulation, the reverse is not true. The placement of an in-path 1356 Load Regulator must be carefully considered relative to 1357 encapsulation. Some examples are given in the following for 1358 guidance. 1360 In the traditional Internet architecture one tends to think of the 1361 source host as the Load Regulator for a path. It is generally not 1362 desirable or practical for a node part way along the path to regulate 1363 the load. However, various reasonable proposals for in-path load 1364 regulation have been made from time to time (e.g. fair queuing, 1365 traffic engineering, flow admission control). The IETF has recently 1366 chartered a working group to standardise admission control across a 1367 part of a path using pre-congestion notification (PCN) [PCNcharter]. 1368 This is of particular relevance here because it involves congestion 1369 notification with an in-path Load Regulator, it can involve 1370 tunnelling and it certainly involves encapsulation more generally. 1372 We will use the more complex scenario in Figure 7 to tease out all 1373 the issues that arise when combining congestion notification and 1374 tunnelling with various possible in-path load regulation schemes. In 1375 this case 'I1' and 'E2' break up the path into three separate 1376 congestion control loops. The feedback for these loops is shown 1377 going right to left across the top of the figure. The 'V's are arrow 1378 heads representing the direction of feedback, not letters. But there 1379 are also two tunnels within the middle control loop: 'I1' to 'E1' and 1380 'I2' to 'E2'. The two tunnels might be VPNs, perhaps over two MPLS 1381 core networks. M is a congestion monitoring point, perhaps between 1382 two border routers where the same tunnel continues unbroken across 1383 the border. 1384 ______ _______________________________________ _____ 1385 / \ / \ / \ 1386 V \ V M \ V \ 1387 A--->R--->I1===========>E1----->I2=========>==========>E2------->B 1389 Figure 7: complex Tunnel Scenario 1391 The question is, should the congestion markings in the outer exposed 1392 headers of a tunnel represent congestion only since the tunnel 1393 ingress or over the whole upstream path from the source of the inner 1394 header (whatever that may mean)? Or put another way, should 'I1' and 1395 'I2' copy or reset CE markings? 1397 Based on the design principles in Section 4, the answer is that the 1398 Congestion Baseline should be the nearest upstream interface designed 1399 to regulate traffic load--the Load Regulator. In Figure 7 'A', 'I1' 1400 or 'E2' are all Load Regulators. We have shown the feedback loops 1401 returning to each of these nodes so that they can regulate the load 1402 causing the congestion notification. So the Congestion Baseline 1403 exposed to M should be 'I1' (the Load Regulator), not 'I2'. 1404 Therefore I1 should reset any arriving CE markings. In this case, 1405 'I1' knows the tunnel to 'E1' is unrelated to its load regulation 1406 function. So the load regulation function within 'I1' should be 1407 placed at [1 - Before] tunnel encapsulation within 'I1' (using the 1408 terminology of Figure 6). Then the Congestion Baseline all across 1409 the networks from 'I1' to 'E2' in both inner and outer headers will 1410 be 'I1'. 1412 The following further examples illustrate how this answer might be 1413 applied: 1415 o We argued in Appendix A that resetting CE on encapsulation could 1416 harm PCN excess rate marking, which marks excess traffic for 1417 removal in subsequent round trips. This marking relies on not 1418 marking packets if another node upstream has already marked them 1419 for removal. If there were a tunnel ingress between the two which 1420 reset CE markings, it would confuse the downstream node into 1421 marking far too much traffic for removal. So why do we say that 1422 'I1' should reset CE, while a tunnel ingress shouldn't? The 1423 answer is that it is the Load Regulator function at 'I1' that is 1424 resetting CE, not the tunnel encapsulator. The Load Regulator 1425 needs to set itself as the Congestion Baseline, so the feedback it 1426 gets will only be about congestion on links it can relieve itself 1427 (by regulating the load into them). When it resets CE markings, 1428 it knows that something else upstream will have dealt with the 1429 congestion notifications it removes, given it is part of an end- 1430 to-end admission control signalling loop. It therefore knows that 1431 previous hops will be covered by other Load Regulators. 1432 Meanwhile, the tunnel ingresses at both 'I1' and 'I2' should 1433 follow the new rule for any tunnel ingress and copy congestion 1434 marking into the outer tunnel header. The ingress at 'I1' will 1435 happen to copy headers that have already been reset just 1436 beforehand. But it doesn't need to know that. 1438 o [Shayman] suggested feedback of ECN accumulated across an MPLS 1439 domain could cause the ingress to trigger re-routing to mitigate 1440 congestion. This case is more like the simple scenario of 1441 Figure 2, with a feedback loop across the MPLS domain ('E' back to 1442 'I'). I is a Load Regulator because re-routing around congestion 1443 is a load regulation function. But in this case 'I' should only 1444 reset itself as the Congestion Baseline in outer headers, as it is 1445 not handling congestion outside its domain, so it must preserve 1446 the end-to-end congestion feedback loop for something else to 1447 handle (probably the data source). Therefore the Load Regulator 1448 within 'I' should be placed at [2 - Outer] to reset CE markings 1449 just after the tunnel ingress has copied them from arriving 1450 headers. Again, the tunnel encapsulation function at 'I' simply 1451 copies incoming headers, unaware that the load regulator will 1452 subsequently reset its outer headers. 1454 o The PWE3 working group of the IETF is considering the problem of 1455 how and whether an aggregate edge-to-edge pseudo-wire emulation 1456 should respond to congestion [I-D.ietf-pwe3-congestion-frmwk]. 1457 Although the study is still at the requirements stage, some 1458 (controversial) solution proposals include in-path load regulation 1459 at the ingress to the tunnel that could lead to tunnel 1460 arrangements with similar complexity to that of Figure 7. 1462 These are not contrived scenarios--they could be a lot worse. For 1463 instance, a host may create a tunnel for IPsec which is placed inside 1464 a tunnel for Mobile IP over a remote part of its path. And around 1465 this all we may have MPLS labels being pushed and popped as packets 1466 pass across different core networks. Similarly, it is possible that 1467 subnets could be built from link technology (e.g. future Ethernet 1468 switches) so that link headers being added and removed could involve 1469 congestion notification in future Ethernet link headers with all the 1470 same issues as with IP in IP tunnels. 1472 One reason we introduced the concept of a Load Regulator was to allow 1473 for in-path load regulation. In the traditional Internet 1474 architecture one tends to think of a host and a Load Regulator as 1475 synonymous, but when considering tunnelling, even the definition of a 1476 host is too fuzzy, whereas a Load Regulator is a clearly defined 1477 function. Similarly, the concept of innermost header is too fuzzy to 1478 be able to (wrongly) say that the source address of the innermost 1479 header should be the Congestion Baseline. Which is the innermost 1480 header when multiple encapsulations may be in use? Where do we stop? 1481 If we say the original source in the above IPsec-Mobile IP case is 1482 the host, how do we know it isn't tunnelling an encrypted packet 1483 stream on behalf of another host in a p2p network? 1485 We have become used to thinking that only hosts regulate load. The 1486 end to end design principle advises that this is a good idea 1487 [RFC3426], but it also advises that it is solely a guiding principle 1488 intended to make the designer think very carefully before breaking 1489 it. We do have proposals where load regulation functions sit within 1490 a network path for good, if sometimes controversial, reasons, e.g. 1491 PCN edge admission control gateways [I-D.ietf-pcn-architecture] or 1492 traffic engineering functions at domain borders to re-route around 1493 congestion [Shayman]. Whether or not we want in-path load 1494 regulation, we have to work round the fact that it will not go away. 1496 Author's Address 1498 Bob Briscoe 1499 BT 1500 B54/77, Adastral Park 1501 Martlesham Heath 1502 Ipswich IP5 3RE 1503 UK 1505 Phone: +44 1473 645196 1506 Email: bob.briscoe@bt.com 1507 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ 1509 Full Copyright Statement 1511 Copyright (C) The IETF Trust (2008). 1513 This document is subject to the rights, licenses and restrictions 1514 contained in BCP 78, and except as set forth therein, the authors 1515 retain all their rights. 1517 This document and the information contained herein are provided on an 1518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1520 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1521 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1522 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1525 Intellectual Property 1527 The IETF takes no position regarding the validity or scope of any 1528 Intellectual Property Rights or other rights that might be claimed to 1529 pertain to the implementation or use of the technology described in 1530 this document or the extent to which any license under such rights 1531 might or might not be available; nor does it represent that it has 1532 made any independent effort to identify any such rights. Information 1533 on the procedures with respect to rights in RFC documents can be 1534 found in BCP 78 and BCP 79. 1536 Copies of IPR disclosures made to the IETF Secretariat and any 1537 assurances of licenses to be made available, or the result of an 1538 attempt made to obtain a general license or permission for the use of 1539 such proprietary rights by implementers or users of this 1540 specification can be obtained from the IETF on-line IPR repository at 1541 http://www.ietf.org/ipr. 1543 The IETF invites any interested party to bring to its attention any 1544 copyrights, patents or patent applications, or other proprietary 1545 rights that may cover technology that may be required to implement 1546 this standard. Please address the information to the IETF at 1547 ietf-ipr@ietf.org. 1549 Acknowledgment 1551 This document was produced using xml2rfc v1.33 (of 1552 http://xml.resource.org/) from a source in RFC-2629 XML format.