idnits 2.17.1 draft-ietf-sip-fork-loop-fix-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 555. 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 (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 (March 7, 2007) is 6257 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) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-08 -- Obsolete informational reference (is this intentional?): RFC 3309 (Obsoleted by RFC 4960) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks, Ed. 3 Internet-Draft Estacado Systems 4 Updates: 3261 (if approved) S. Lawrence 5 Intended status: Standards Track Pingtel Corp. 6 Expires: September 8, 2007 A. Hawrylyshen 7 Ditech Networks Inc. 8 March 7, 2007 10 Addressing an Amplification Vulnerability in Session Initiation Protocol 11 (SIP) Forking Proxies 12 draft-ietf-sip-fork-loop-fix-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 8, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document normatively updates RFC 3261, the Session Initiation 46 Protocol (SIP), to address a security vulnerability identified in SIP 47 proxy behavior. This vulnerability enables an attack against SIP 48 networks where a small number of legitimate, even authorized, SIP 49 requests can stimulate massive amounts of proxy-to-proxy traffic. 51 This document strengthens loop-detection requirements on SIP proxies 52 when they fork requests (that is, forward a request to more than one 53 destination). It also corrects and clarifies the description of the 54 loop-detection algorithm such proxies are required to implement. 56 Table of Contents 58 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 3 61 4. Normative changes to RFC 3261 . . . . . . . . . . . . . . . . 5 62 4.1. Strengthening the requirement to perform loop-detection . 5 63 4.2. Correcting and clarifying the RFC 3261 loop-detection 64 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 6 66 4.2.2. Update to section 16.3 . . . . . . . . . . . . . . . . 7 67 4.2.3. Note to Implementers . . . . . . . . . . . . . . . . . 7 68 5. Impact on overall network performance . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. -03 to -04 (addressing WGLC comments) . . . . . . . . . . 10 74 9.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 Intellectual Property and Copyright Statements . . . . . . . . . . 13 82 1. Conventions and Definitions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC-2119 [RFC2119]. 88 2. Introduction 90 Interoperability testing uncovered a vulnerability in the behavior of 91 forking SIP proxies as defined in [RFC3261]. This vulnerability can 92 be leveraged to cause a small number of valid SIP requests to 93 generate an extremely large number of proxy-to-proxy messages. A 94 version of this attack demonstrates fewer than ten messages 95 stimulating potentially 2^70 messages. 97 This document specifies normative changes to the SIP protocol to 98 address this vulnerability. According to this update, when a SIP 99 proxy forks a request to more than one destination, it is required to 100 ensure it is not participating in a request loop. 102 3. Vulnerability: Leveraging Forking to Flood a Network 104 This section describes setting up an attack with a simplifying 105 assumption, that two accounts on each of two different RFC 3261 106 compliant proxy/registrar servers that do not perform loop-detection 107 are available to an attacker. This assumption is not necessary for 108 the attack, but makes representing the scenario simpler. The same 109 attack can be realized with a single account on a single server. 111 Consider two proxy/registrar services, P1 and P2, and four Addresses 112 of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER 113 requests, establish bindings to these AoRs as follows (non-essential 114 details elided): 116 REGISTER sip:P1 SIP/2.0 117 To: 118 Contact: , 120 REGISTER sip:P1 SIP/2.0 121 To: 122 Contact: , 124 REGISTER sip:P2 SIP/2.0 125 To: 126 Contact: , 128 REGISTER sip:P2 SIP/2.0 129 To: 130 Contact: , 132 With these bindings in place, introduce an INVITE to any of the four 133 AoRs, say a@P1. This request will fork to two requests handled by 134 P2, which will fork to four requests handled by P1, which will fork 135 to eight messages handled by P2, and so on. This message flow is 136 represented in Figure 2. 138 | 139 a@P1 140 / \ 141 / \ 142 / \ 143 / \ 144 a@P2 b@P2 145 / \ / \ 146 / \ / \ 147 / \ / \ 148 a@P1 b@P1 a@P1 b@P1 149 / \ / \ / \ / \ 150 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 151 /\ /\ /\ /\ /\ /\ /\ /\ 152 . 153 . 154 . 156 Figure 2: Attack request propagation 158 Requests will continue to propagate down this tree until Max-Forwards 159 reaches zero. If the endpoint and two proxies involved follow RFC 160 3261 recommendations, the tree will be 70 rows deep, representing 161 2^70 requests. The actual number of messages may be much larger if 162 the time to process the entire tree worth of requests is longer than 163 Timer C at either proxy. In this case, a storm of 408s, and/or a 164 storm of CANCELs will also be propagating through the tree along with 165 the INVITEs. Remember that there are only two proxies involved in 166 this scenario - each having to hold the state for all the 167 transactions it sees (at least 2^69 simultaneously active 168 transactions near the end of the scenario). 170 The attack can be simplified to one account at one server if the 171 service can be convinced that contacts with varying attributes 172 (parameters, schemes, embedded headers) are sufficiently distinct, 173 and these parameters are not used as part of AOR comparisons when 174 forwarding a new request. Since RFC 3261 mandates that all URI 175 parameters must be removed from a URI before looking it up in a 176 location service and that the URIs from the Contact header are 177 compared using URI equality, the following registration should be 178 sufficient to set this attack up using a single REGISTER request to a 179 single account: 181 REGISTER sip:P1 SIP/2.0 182 To: 183 Contact: , 185 This attack was realized in practice during one of the SIP 186 Interoperability Test (SIPit) sessions. The scenario was extended to 187 include more than two proxies, and the participating proxies all 188 limited Max-Forwards to be no larger than 20. After a handful of 189 messages to construct the attack, the participating proxies began 190 bombarding each other. Extrapolating from the several hours the 191 experiment was allowed to run, the scenario would have completed in 192 just under 10 days. Had the proxies used the RFC 3261 recommended 193 Max-Forwards value of 70, and assuming they performed linearly as the 194 state they held increases, it would have taken 3 trillion years to 195 complete the processing of the single INVITE that initiated the 196 attack. It is interesting to note that a few proxies rebooted during 197 the scenario, and rejoined in the attack when they restarted (as long 198 as they maintained registration state across reboots). This points 199 out that if this attack were launched on the Internet at large, it 200 might require coordination among all the affected elements to stop 201 it. 203 4. Normative changes to RFC 3261 205 4.1. Strengthening the requirement to perform loop-detection 207 The following requirements mitigate the risk of a proxy falling 208 victim to the attack described in this document. 210 When a SIP proxy forks a particular request to more than one 211 destination, it MUST ensure that request is not looping through this 212 proxy. It is RECOMMENDED that proxies meet this requirement by 213 performing the Loop-Detection steps defined in this document. 215 The requirement to use this document's refinement of the loop- 216 detection algorithm in RFC 3261 is set at should-strength to allow 217 for future standards track mechanisms that will allow a proxy to 218 determine it is not looping. For example, a proxy forking to 219 destinations established using the sip-outbound mechanism 220 [I-D.ietf-sip-outbound] would know those branches will not loop. 222 A SIP proxy forwarding a request to only one location MAY perform 223 loop detection but is not required to. When forwarding to only one 224 location, the amplification risk being exploited is not present, and 225 the Max-Forwards mechanism is sufficient to protect the network. A 226 proxy is not required to perform loop detection when forwarding a 227 request to a single location even if it happened to have previously 228 forked that request (and performed loop detection) in its progression 229 through the network. 231 4.2. Correcting and clarifying the RFC 3261 loop-detection algorithm 233 4.2.1. Update to section 16.6 235 This section replaces all of item 8 in section 16.6 of RFC 3261 (item 236 8 begins on page 105 and ends on page 106 of RFC 3261). 238 8. Add a Via header field value 240 The proxy MUST insert a Via header field value into the copy before 241 the existing Via header field values. The construction of this value 242 follows the same guidelines of Section 8.1.1.7. This implies that 243 the proxy will compute its own branch parameter, which will be 244 globally unique for that branch, and will contain the requisite magic 245 cookie. Note that following only the guidelines in Section 8.1.1.7 246 will result in a branch parameter that will be different for 247 different instances of a spiraled or looped request through a proxy. 249 Proxies required to perform loop-detection by RFC XXXX (RFC-Editor: 250 replace XXXX with the RFC number of this document) have an additional 251 constraint on the value they place in the Via header field. Such 252 proxies SHOULD create a branch value separable into two parts in any 253 implementation dependent way. The first part MUST satisfy the 254 constraints of Section 8.1.1.7. The second part is used to perform 255 loop detection and distinguish loops from spirals. 257 This second part MUST vary with any field used by the location 258 service logic in determining where to retarget or forward this 259 request. This is necessary to distinguish looped requests from 260 spirals by allowing the proxy to recognize if none of the values 261 affecting the processing of the request have changed. Hence, The 262 second part MUST depend at least on the received Request-URI and any 263 Route header field values used when processing the received request. 264 Implementers need to take care to include all fields used by the 265 location service logic in that particular implementation. 267 This second part MUST NOT vary with the request method. CANCEL and 268 non-200 ACK requests MUST have the same branch parameter value as the 269 corresponding request they cancel or acknowledge. This branch 270 parameter value is used in correlating those requests at the server 271 handling them (see Sections 17.2.3 and 9.2). 273 4.2.2. Update to section 16.3 275 This section replaces all of item 4 in section 16.3 of RFC 3261 (item 276 4 appears on page 95 RFC 3261). 278 4. Loop Detection Check 280 Proxies required to perform loop-detection by RFC-XXXX (RFC-Editor: 281 replace XXXX with the RFC number of this document) MUST perform the 282 following loop-detection test before forwarding a request. Each Via 283 header field value in the request whose sent-by value matches a value 284 placed into previous requests by this proxy MUST be inspected for the 285 "second part" defined in Section 4.2.1 of RFC-XXXX. This second part 286 will not be present if the message was not forked when that Via 287 header field value was added. If the second field is present, the 288 proxy MUST perform the second part calculation described in 289 Section 4.2.1 of RFC-XXXX on this request and compare the result to 290 the value from the Via header field. If these values are equal, the 291 request has looped and the proxy MUST reject the request with a 482 292 (Loop Detected) response. If the values differ, the request is 293 spiraling and processing continues to the next step. 295 4.2.3. Note to Implementers 297 A common way to create the second part of the branch parameter value 298 when forking a request is to compute a hash over the concatenation of 299 the Request-URI, any Route header field values used during processing 300 the request and any other values used by the location service logic 301 while processing this request. The hash should be chosen so that 302 there is a low probability that two distinct sets of these parameters 303 will collide. Because the maximum number of inputs which need to be 304 compared is 70 the chance of a collision is low even with a 305 relatively small hash value, such as 32 bits. CRC-32c as specified 306 in [RFC3309] is a specific acceptable function, as is MD5 [RFC1321]. 307 Note that MD5 is being chosen purely for non-cryptographic 308 properties. An attacker who can control the inputs in order to 309 produce a hash collision can attack the connection in a variety of 310 other ways. When forming the second part using a hash, 311 implementations SHOULD include at least one field in the input to the 312 hash that varies between different transactions attempting to reach 313 the same destination to avoid repeated failure should the hash 314 collide. The Call-ID and CSeq fields would be good inputs for this 315 purpose. 317 A common point of failure to interoperate at SIPit events has been 318 due to parsers objecting to the contents of other's Via header field 319 values when inspecting the Via stack for loops. Implementers need to 320 take care to avoid making assumptions about the format of another 321 element's Via header field value beyond the basic constraints placed 322 on that format by RFC 3261. In particular, parsing a header field 323 value with unknown parameter names, parameters with no values, 324 parameters values with and without quoted strings must not cause an 325 implementation to fail. 327 5. Impact on overall network performance 329 These requirements and the recommendation to use the loop-detection 330 mechanisms in this document make the favorable trade of exponential 331 message growth for work that is at worst case order n^2 as a message 332 crosses n proxies. Specifically, this work is order m*n where m is 333 the number of proxies in the path that fork the request to more than 334 one location. In practice, m is expected to be small. 336 The loop detection algorithm expressed in this document requires a 337 proxy to inspect each Via element in a received request. In the 338 worst case where a message crosses N proxies, each of which loop 339 detect, proxy k does k inspections, and the overall number of 340 inspections spread across the proxies handling this request is the 341 sum of k from k=1 to k=N which is N(N+1)/2. 343 6. IANA Considerations 345 None. 347 7. Security Considerations 349 This document is entirely about documenting and addressing a 350 vulnerability in SIP proxies as defined by RFC 3261 that can lead to 351 an exponentially growing message exchange attack. 353 Alternative solutions that were discussed included 355 Doing nothing - rely on suing the offender: While systems that have 356 accounts have logs that can be mined to locate abusers, it isn't 357 clear that this provides a credible deterrent or defense against 358 the attack described in this document. Systems that don't 359 recognize the situation and take corrective/preventative action 360 are likely to experience failure of a magnitude that precludes 361 retrieval of the records documenting the setup of the attack. (In 362 one scenario, the registrations can occur in a radically different 363 time period than the invite. The invite itself may have come from 364 an innocent). It's even possible that the scenario may be set up 365 unintentionally. Furthermore, for some existing deployments, the 366 cost and audit ability of an account is simply an email address. 367 Finding someone to punish may be impossible. Finally, there are 368 individuals who will not respond to any threat of legal action, 369 and the effect of even a single successful instance of this kind 370 of attack would be devastating to a service-provider. 372 Putting a smaller cap on Max-Forwards: The effect of the attack is 373 exponential with respect to the initial Max-Forwards value. 374 Turning this value down limits the effect of the attack. This 375 comes at the expense of severely limiting the reach of requests in 376 the network, possibly to the point that existing architectures 377 will begin to fail. 379 Controlling the number of concurrent requests: Bounding the total 380 number branches to which the original request can be forwarded 381 simultaneously limits the impact of the attack at any given point 382 in time. Proposals for limiting mechanisms where considered, but 383 no consensus to adopt them currently exists. 385 Disallowing registration bindings to arbitrary contacts: The way 386 registration binding is currently defined is a key part of the 387 success of the kind of attack documented here. The alternative of 388 limiting registration bindings to allow only binding to the 389 network element performing the registration, perhaps to the 390 extreme of ignoring bits provided in the Contact in favor of 391 transport artifacts observed in the registration request has been 392 discussed (particularly in the context of the mechanisms being 393 defined in [I-D.ietf-sip-outbound]. Mechanisms like this may be 394 considered again in the future, but are currently insufficiently 395 developed to address the present threat. 397 Deprecate forking: This attack does not exist in a system that 398 relies entirely on redirection and initiation of new requests by 399 the original endpoint. Removing such a large architectural 400 component from the system at this time was deemed a too extreme 401 solution. 403 8. Acknowledgments 405 Thanks go to the implementors that subjected their code to this 406 scenario and helped analyze the results at SIPit 17. Eric Rescorla 407 provided guidance and text for the hash recommendation note. 409 9. Change Log 411 RFC Editor - Remove this section before publication 413 9.1. -03 to -04 (addressing WGLC comments) 415 Changed the hash recommendation per list consensus 417 Reintroduced Call-ID and CSeq (list discussion rediscovered one 418 use for them in avoiding repeated hash collisions) 420 9.2. -02 to -03 422 Closed Open Issue 1 "Why are we including all of the Route headers 423 values?". The text has been modified to include only those values 424 used in processing the request. 426 Closed Open Issues 2 and 3 "Why did 3261 include Call-ID To-tag, 427 and From-tag and CSeq?" and "Why did 3261 include Proxy-Require 428 and Proxy-Authorization?". The group has not been able to 429 identify why these fields would be included in the hash generally, 430 and successful interoperability tests have not included them. 431 Since they were not included in the text for -02, the text for 432 this version was not affected. 434 Removed the word "cryptographic" from the hash description in the 435 non-normative note to implementers (per list discussion) and added 436 characterization of the properties the hash chosen should have. 438 9.3. -01 to -02 440 Integrated several editorial fixes suggested by Jonathan Rosenberg 441 Noted that the reduction of the attack to a single registration 442 against a single URI as documented in previous versions, is, in 443 fact, going to be effective against implementations conforming to 444 the standards before this repair. 446 Re-incorporated motivation from the original maxforwards-problem 447 draft into the security considerations section based on feedback 448 from Cullen Jennings 450 Introduced replacement text for the loop detection algorithm 451 description in RFC 3261, fixing the bug 648 (the topmost Via value 452 must not be included in the second part) and clarifying the 453 algorithm. Removed several other fields suggested by 3261 and 454 placed open issues around their presence. 456 Added a Notes to Implementors section capturing the "common way" 457 text and pointing to the interoperability issues that have been 458 observed with loop detection at previous SIPits 460 10. References 462 10.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 468 A., Peterson, J., Sparks, R., Handley, M., and E. 469 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 470 June 2002. 472 10.2. Informative References 474 [I-D.ietf-sip-outbound] 475 Jennings, C. and R. Mahy, "Managing Client Initiated 476 Connections in the Session Initiation Protocol (SIP)", 477 draft-ietf-sip-outbound-08 (work in progress), March 2007. 479 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 480 April 1992. 482 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 483 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 484 September 2002. 486 Authors' Addresses 488 Robert Sparks (editor) 489 Estacado Systems 490 17210 Campbell Road 491 Suite 250 492 Dallas, Texas 75254-4203 493 USA 495 Email: RjS@nostrum.com 497 Scott Lawrence 498 Pingtel Corp. 499 400 West Cummings Park 500 Suite 2200 501 Woburn, MA 01801 502 USA 504 Phone: +1 781 938 5306 505 Email: slawrence@pingtel.com 507 Alan Hawrylyshen 508 Ditech Networks Inc. 509 1167 Kensington Rd NW 510 Suite 200 511 Calgary, Alberta T2N 1X7 512 Canada 514 Phone: +1 403 806 3366 515 Email: ahawrylyshen@ditechnetworks.com 517 Full Copyright Statement 519 Copyright (C) The IETF Trust (2007). 521 This document is subject to the rights, licenses and restrictions 522 contained in BCP 78, and except as set forth therein, the authors 523 retain all their rights. 525 This document and the information contained herein are provided on an 526 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 527 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 528 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 529 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 530 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 531 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 533 Intellectual Property 535 The IETF takes no position regarding the validity or scope of any 536 Intellectual Property Rights or other rights that might be claimed to 537 pertain to the implementation or use of the technology described in 538 this document or the extent to which any license under such rights 539 might or might not be available; nor does it represent that it has 540 made any independent effort to identify any such rights. Information 541 on the procedures with respect to rights in RFC documents can be 542 found in BCP 78 and BCP 79. 544 Copies of IPR disclosures made to the IETF Secretariat and any 545 assurances of licenses to be made available, or the result of an 546 attempt made to obtain a general license or permission for the use of 547 such proprietary rights by implementers or users of this 548 specification can be obtained from the IETF on-line IPR repository at 549 http://www.ietf.org/ipr. 551 The IETF invites any interested party to bring to its attention any 552 copyrights, patents or patent applications, or other proprietary 553 rights that may cover technology that may be required to implement 554 this standard. Please address the information to the IETF at 555 ietf-ipr@ietf.org. 557 Acknowledgment 559 Funding for the RFC Editor function is provided by the IETF 560 Administrative Support Activity (IASA).