idnits 2.17.1 draft-tschofenig-nsis-qos-authz-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 2003) is 7593 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: 'Tsc03' is mentioned on line 329, but not defined == Unused Reference: 'Tsch03' is defined on line 519, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Her95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tho02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Her96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tsch03' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSP' ** Downref: Normative reference to an Informational RFC: RFC 3521 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS 3 Internet Draft H. Tschofenig 4 Siemens 5 M. Buechli 6 S. Van den Bosch 7 Alcatel 8 H. Schulzrinne 9 Columbia U. 10 T. Chen 11 TU Berlin 12 Document: 13 draft-tschofenig-nsis-qos-authz-issues-00.txt 14 Expires: December 2003 June 2003 16 QoS NSLP Authorization Issues 17 19 Status of this Memo 21 This document is an Internet-Draft and is subject to all provisions 22 of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 Various proposals for NSIS QoS NSLPs have been published recently. 43 The design of a QoS NSLPs has to consider more than only exchanging 44 QoS objects. Authorization has to be handled properly to make this 45 protocol both useful and performant. Authorization in mobile 46 environments, unfortunately, raises additional questions. This 47 document provides an introduction to the topic. 49 Table of Contents 51 1. Introduction..................................................2 52 2. Terminology...................................................3 53 3. Which entities are involved in computing the authorization 54 decision?........................................................3 55 4. How long is the authorization decision valid?.................6 56 5. What information is needed to compute the authorization decision? 57 .................................................................6 58 6. Authorization example based on RSVP...........................7 59 7. Security Considerations......................................10 60 8. Acknowledgments..............................................10 61 9. References...................................................10 62 Author's Addresses..............................................11 64 1. Introduction 66 Authorization is a necessary function in order to prevent theft-of- 67 service and to enable charging. With regard to authorization a few 68 issues still need to be resolved to specify the protocol interaction 69 for a QoS NSLP with regard to authorization of resource requests. 71 [Her95] and [Her96] give some hints about policy handling and 72 authorization in RSVP [RFC2205]. A number of papers have been 73 published in the meanwhile proposing numerous different procedures 74 for handling pricing, charging and even for including micro-payment 75 protocols. None of these proposals, however, plays a role today. To 76 avoid proposing many new alternative ways to handle authorization we 77 would like to draw the attention of the working group to this topic 78 in their effort to create a QoS NSLP. 80 With [TB+03] we tried to address the issues of authorization 81 although due to terminology most NSIS working group members have 82 probably not read the draft. Some others even think that these 83 issues are independently of the NSIS NSLP protocol itself. 85 We think that the following questions should be addressed during the 86 work on a QoS NSLP: 88 a) Which entities are involved in computing the authorization 89 decision? 91 b) How long is the authorization decision valid? 93 c) What information is needed to compute the authorization decision? 95 We will provide more details to these questions in the subsequent 96 sections. 98 It should be noted that the result of the authorization process 99 might be a "yes" or "no" decision or even a complex policy. In some 100 cases the latter might allow to answer further authorization 101 requests locally. 103 2. Terminology 105 This draft uses terminology described in [TB+03]. 107 3. Which entities are involved in computing the authorization decision? 109 At an abstract level we have two different cases with regard to NSIS 110 signaling: 112 +-------------+ QoS request +--------------+ 113 | Entity |----------------->| Entity | 114 | requesting | | authorizing | 115 | resource |granted / rejected| resource | 116 | |<-----------------| request | 117 +-------------+ +--------------+ 118 ^ ^ 119 +...........................+ 120 financial establishment 122 Figure 1: Two party approach 124 Figure 1 describes the simple and basic approach where 125 (a) the authorization decision is purely executed between the two 126 entities only or 127 (b) where previous (out-of-band) mechanisms separated the signaling 128 protocol from executing other entities during NSIS protocol 129 execution. 131 The entity authorizing the resource request and the entity actually 132 performing the QoS reservation are in the same administrative 133 domain. Hence they are treated as a single logical entity. 135 Examples for this type of model can be found between two neighboring 136 networks (inter-domain signaling) where a long-term contract (or 137 other out-of-band mechanisms) exists and allows both networks to 138 know 140 - how much a resource reservation costs 142 - how to charge the other entity (i.e. how the authorizing entity 143 finally gets paid for the consumed resources) and 145 - how to authorize the resource requesting entity (i.e. associating 146 the identifier of the protected signaling message to the identity 147 used in the authentication and key exchange protocol run and 148 finally this identity to the user identity of the contract for the 149 purpose of charging). 151 The consequence for an NSIS QoS NSLP protocol in this case is: 152 - No additional message signaling for authorization is required 154 - It might be necessary to include only some new objects. 156 - Triggering other protocols (such as credit control) might be 157 necessary but has no impact on the NSIS signaling machinery 159 It might also be possible to count micro-payment protocol approaches 160 to the two party case since it is a pure two party protocol. Fully 161 integrating a payment protocol into NSIS, however, requires 162 modifications to the NSIS protocol machinery itself since the 163 message flows of NSIS and the message flows of the payment protocol 164 might not be compatible. 166 Next a three party approach is presented which has two facets 167 whereby the first variant is shown in Figure 2 and the alternative 168 approach in Figure 3: 170 +--------------+ 171 | Entity | 172 | authorizing | <...+ 173 | resource | . 174 | request | . 175 +-----------+--+ . 176 ^ | . 177 | | . 178 QoS | | QoS . 179 authz| |authz . 180 req.| | res. . 181 | | . 182 QoS | v . 183 +-------------+ request +--+-----------+ . 184 | Entity |----------------->| Entity | . 185 | requesting | | performing | . 186 | resource |granted / rejected| QoS | <..+ 187 | |<-----------------| reservation | financial 188 +-------------+ +--------------+ settlement 190 Figure 2: Three party approach 192 The three party approach is considerably more complex since an NSIS 193 protocol has to enable the corresponding mechanisms to contact a 194 third party which executes the authorization request and (if 195 successful) establishes a financial settlement to the entity 196 providing the QoS reservation. The requesting entity is involved in 197 this three party approach since it has to authenticate itself to the 198 entity authorizing the request. 200 This type of configuration is common in mobility environments with 201 per-session authorization. Section 6 gives an example of per-session 202 authorization (per-session or even more often). Thereby a resource 203 request by the end host is send to an RSVP node in the local network 204 and then forwarded to the local PDP (via COPS). Since the local 205 domain is unable to verify the request it has to be forwarded to the 206 user's home network where authorization is provided. The response is 207 then returned and resources are granted (in case of a successful 208 authorization decision). The interaction between the visited network 209 and the home network establishes the necessary financial 210 infrastructure to latter charge the user for the consumed resources. 212 Authorization 213 Token Request +--------------+ 214 +-------------->| Entity | financial settlement 215 | | authorizing | <..................+ 216 | | resource | . 217 | +------+ request | . 218 | | +--------------+ . 219 | | . 220 | |Authorization . 221 | |Token . 222 | | . 223 | | . 224 | | . 225 | | QoS request . 226 +-------------+ + Authz. Token +--------------+ . 227 | Entity |----------------->| Entity | . 228 | requesting | | performing | . 229 | resource |granted / rejected| QoS | <..+ 230 | |<-----------------| reservation | 231 +-------------+ +--------------+ 233 Figure 3: Token based Three party approach 235 The token based three party approach is applicable in environments 236 where a previous protocol interaction is used to request 237 authorization tokens (or something similar) to assist the 238 authorization process at the entity performing the QoS reservation. 239 This approach can be found in solutions where OSP Tokens [OSP] are 240 or Authorization Tokens as used as described in [RFC3520] and in 241 [RFC3521]. 243 Additionally to consider are the following questions: 245 - A resource request might be necessary between neighboring entities 246 only or between non-neighboring entities. 248 - Additionally of interest is whether authorization should be 249 provided to more than one entity along the path. 251 Both issues refer to the difference between the New Jersey Turnpike 252 and the New Jersey Parkway Model. See [TB+03] for a description of 253 the different trust models. Furthermore Section 6 of [TB+03] is of 254 interest when it comes to the question whether the sender or the 255 receiver should authorize a QoS request. 257 4. How long is the authorization decision valid? 259 For the NSIS QoS NSLP protocol machinery it is important to consider 260 at what frequency authorization decisions are made. Some possible 261 options are: 263 - Per request 264 (e.g. a request for more QoS resources than previously requested) 266 - Per session 267 (e.g. only during the initial setup of a QoS resource) 269 - Periodically 270 (authorization decision is repeated after a certain time interval) 272 - Event triggered 273 (as soon as something changes e.g. price changes due to mobility 274 which requires reauthorization) 276 The concept of a per-channel authorization (and financial 277 establishment) is introduced in [TB+03] and tries to move a three 278 party to a two party scenario by establishing the necessary 279 infrastructure outside NSIS and to thereby make it simpler. Thereby 280 it is possible to authorize QoS resource requests locally. The 281 feasibly of this approach heavily depends on assumptions. 283 If authorization is, however, provided based on the three party 284 approach then for example a periodically triggered re-authorization 285 request requires that the third party is contacted with every 286 authorization request. This might place a considerable burden onto 287 the QoS signaling protocol in a mobile environment. 289 5. What information is needed to compute the authorization decision? 291 Whenever an authorization decision has to be made then there is the 292 question which information serves as an input to the authorizing 293 entity. The following information items have been mentioned in the 294 past for computing the authorization decision (in addition to the 295 authenticated identity): 297 - Price 299 - QoS objects 301 - Policy rules 303 Policy rules include attributes like time of day, subscription to 304 certain services, membership, etc. into consideration when computing 305 an authorization decision. 307 Some of these information items are only available at certain 308 places. By, for example, relying on policy rules it is likely that 309 an authorization decision has to be made in the user's home network 310 since the network administrator might not be willing to disclose the 311 policies to other networks in order to offload the authorization 312 decision. 314 In case of QoS objects it might be fairly difficult for an 315 authorizing entity to grant a QoS authorization request since the 316 objects by themselves might not always allow inferring to the price 317 of the reservation. Hence in most cases it might be desirable to 318 provide additionally some price information (if not agreed between 319 the networks in advance). 321 6. Authorization example based on RSVP 323 This section illustrates a simple message flow based on the features 324 offered by RSVP. We assume a mobile environment where an end host is 325 attached to a network which is not his own home network. We do not 326 distinguish the case where the user has no home network and where 327 alternative means of access are used to authorize network access and 328 other resources. A short description of the two principal network 329 access authentication scenarios can be found in [Tsc03]. They are 330 also applicable for this discussion. 332 The description in [RFC3182], in [Her95] and in [Her96] gave us the 333 impression that RSVP aims to target authorization on the basis of an 334 individual RSVP message. Furthermore it seems that the New Jersey 335 Turnpike Model is the favorite model (although not directly 336 mentioned). 338 Figure 4 shows a typically message flow whereby the end host starts 339 with network access authentication before address configuration 340 occurs. Subsequently QoS signaling with RSVP starts with a PATH 341 message. The RSVP PATH message contains a Policy Object with a 342 digital signature (and the corresponding certificate) as proposed in 343 [RFC3182]. 345 Visited Domain Home Domain 346 MN AR PDP/AAA PDP/AAA 347 | | | | 348 | Network Access Authentication | 349 |<======================================================>| 350 | | | | 351 | Address Config. | | | 352 |<================>| | | 353 | | | | 354 | RSVP Signaling | | | 355 | (PATH msg) | | | 356 |=================>| | | 357 | | COPS REQ | | 358 | |==================>| | 359 | | | | 360 | | | COPS REQ | 361 | | |================>| 362 | | | | 363 | | | COPS DEC | 364 | | |================>| 365 | | COPS DEC | | 366 | |<==================| | 367 | | | | 368 ~ RSVP signaling ~ | | 369 | continues to | | | 370 | destination host | | | 372 Figure 4: RSVP Signaling Message Exchange with PDP Interaction 374 In [Tho02] it is suggested to delegate the authorization decision to 375 the local PDP and subsequently to the user's home PDP. This seems to 376 be necessary if an authorization decision has to be provided for 377 each individual session or even for each individual RSVP signaling 378 message. Verification of the digital signature might not help with 379 authorization in most environments. 381 The digital signature allows authentication of the client to the PDP 382 at the home network. Mutual authentication is not offered and replay 383 protection is most likely based on timestamps (although not 384 mentioned in [RFC3182]). In addition to the Policy Object it is also 385 necessary to forward information about the requested resources 386 otherwise an authorization decision by the user's home PDP is 387 worthless. Even then it is difficult for the PDP in the user's home 388 network to perform an authorization decision since the costs of the 389 reservation are most likely not known at this time. Since the 390 duration of the QoS reservation during reservation setup, the 391 authorization request/response scheme would have to be repeated 392 periodically. In this sender-authorizing scheme it is difficult to 393 determine how much resources will be actually reserved due to the 394 nature of the RSVP PATH message with its ADSPEC object and the 395 ability of the receiver to change the QoS reservation. 397 Public key based authentication between the user and his home 398 network would typically be used because 400 (a) user identity confidentiality is desired or 402 (b) if the user authenticates itself to the local network (and not 403 to the home network) 405 Since the public key based authentication proposed in [RFC3182] does 406 not provide (a) and scenarios for (b) do not require client based 407 public key based authentication it seems to be difficult to find a 408 motivation for using a performance intensive mechanism without an 409 additional benefit. 411 Clients today use a number of different authentication protocols 412 such as SRP, UTMS-AKA, etc. which offer different cryptographic 413 properties. In a mobile environment RSVP, together with COPS, 414 simulates functionality known from Radius and Diameter. It seems to 415 be unlikely that network operations add COPS for inter-domain 416 signaling only although Radius and Diameter already offers the same 417 functionality. 419 [RFC3182] also offers authentication based on a shared secret. For 420 entity authentication between the end host and the user's home 421 network this seems to be the most efficient approach although the 422 sequence number handling might not be the best replay protection 423 approach. 425 As with pk-based authentication and authentication based on 426 symmetric keys, Kerberos authentication to the PDP in the user's 427 home network does not provide session key distribution to the first 428 RSVP node in the visited network. To protect signaling messages a 429 session key for the RSVP Integrity object should be available. From 430 a performance point of view it is highly recommended to execute this 431 cross-realm authentication procedure only as frequently as 432 absolutely necessary due the high overhead. If Kerberos should be 433 additionally used to authenticate the user to the first RSVP node 434 then additional problems occur. Kerberos cross-realm authentication 435 does not match to AAA inter-domain handling. Several roundtrips 436 might be required to obtain the Ticket Granting Ticket of the 437 visited domain and finally the service ticket for either the PDP or 438 the first policy aware RSVP router. 440 In case of the New Jersey Turnpike Model authorization is only 441 provided between neighboring entities. For signaling messages which 442 are exchanged between neighboring domains it is not necessary to 443 perform per-session authorization by including a Policy Object. 444 Since the neighboring domains have long-term contracts and security 445 associations can easily be established data origin authentication is 446 provided by the RSVP Integrity Object. The identifier used to select 447 the key for the Integrity object can be associated with the identity 448 which allows authorizing the QoS request. Hence we argue that the 449 Policy Object should not be used for entity authentication between 450 neighboring networks due to the performance restrictions and the 451 presence of the RSVP Integrity object. 453 It should be noted that the policy control and the admission control 454 procedure perform different functions although they use similar 455 information. Both procedures might require information about the 456 requested resources (i.e. QoS objects). The admission control 457 procedure does not need to use user identity information or other 458 complex policy rules for deciding whether to grant a request or not. 459 The two entities executing the policy control and the admission 460 control procedure do not need to be co-located or even in the same 461 network. In the mobile scenario case it seems that admission control 462 is executed at the local network whereas policy control is provided 463 at the user's home network as part of the authorization procedure. 464 Most important for determining an authorization decision at the 465 user's home network is most likely a monetary amount - and not a QoS 466 object. In some cases it might be, however, possible for the PDP in 467 the user's home network to associate the cost of a QoS reservation 468 with the provided IntServ parameter. 470 7. Security Considerations 472 This document address authorization for QoS NSLPs and tries to raise 473 some questions about the expected functionality of this specific 474 application signaling protocol. 476 A definition of authorization in the QoS environment should be 477 created as part of a working group discussion to allow an NSLP 478 protocol to address the corresponding security requirements. 480 8. Acknowledgments 482 We would like to thank Allison Mankin for their comments to the NSIS 483 AAA draft. Her comments gave us the impression that we should work 484 on a shorter draft which raises the most important open issues. 486 9. References 488 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. 489 Jamin, "Resource ReSerVation protocol (RSVP) -- version 1 functional 490 specification," RFC 2205, Internet Engineering Task Force, Sept. 491 1997. 493 [TB+03] H. Tschofenig, M. Buechli, S. Van den Bosch and H. 494 Schulzrinne: "NSIS Authentication, Authorization and Accounting 495 Issues", Internet Draft Internet Engineering Task Force, (work in 496 progress), March 2003. 498 [Her95] Herzog, S.: "Accounting and Access Control in RSVP", 499 Internet Draft Internet Engineering Task Force, (expired), November, 500 1995. 502 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, 503 T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 504 3182, October, 2001. 506 [Tho02] M. Thomas: "Analysis of Mobile IP and RSVP Interactions", 507 Internet Draft Internet Engineering Task Force, (work in progress), 508 October 2002. 510 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, 511 T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 512 3182, October, 2001. 514 [Her96] S. Herzog: "Accounting and Access Control for Multicast 515 Distributions: Models and Mechanisms", PhD Dissertation, University 516 of Southern California, June 1996, available at: 517 http://www.policyconsulting.com/herzog/cv.html. 519 [Tsch03] H. Tschofenig: "PANA Framework Issues", Internet Draft 520 Internet Engineering Task Force, January 2003. 522 [OSP] E. T. S. Institute, "Telecommunications and internet 523 protocol harmonization over networks (tiphon); open settlement 524 protocol (osp) for inter- domain pricing, authorization, and usage 525 exchange, technical specification 101 321. version 2.1.0." 527 [RFC3521] L. Hamer, B. Gage, and H. Shieh, "Framework for session 528 set-up with media authorization," RFC 3521, Internet Engineering 529 Task Force, April 2003. 531 [RFC3520] L. Hamer, B. Gage, B. Kosinski, and H. Shieh, "Session 532 Authorization Policy Element", RFC 3520, Internet Engineering Task 533 Force, April 2003. 535 Author's Addresses 536 Hannes Tschofenig 537 Siemens AG 538 Otto-Hahn-Ring 6 539 81739 Munich 540 Germany 541 EMail: Hannes.Tschofenig@siemens.com 543 Henning Schulzrinne 544 Dept. of Computer Science 545 Columbia University 546 1214 Amsterdam Avenue 547 New York, NY 10027 548 USA 549 EMail: schulzrinne@cs.columbia.edu 551 Sven Van den Bosch 552 Alcatel 553 Francis Wellesplein 1 554 B-2018 555 Antwerpen 556 Phone: 32-3-240-8103 557 EMail: sven.van_den_bosch@alcatel.be 559 Maarten B�chli 560 Alcatel 561 Francis Wellesplein 1 562 B-2018 563 Antwerpen 564 EMail: maarten.buchli@alcatel.be 566 Tianwei Chen 567 Technical University of Berlin 568 Sekr. FT 5-2, Einsteinufer 25 569 Berlin 10587 570 Germany 571 EMail: chen@ee.tu-berlin.de 573 Intellectual Property Statement 575 The IETF takes no position regarding the validity or scope of any 576 intellectual property or other rights that might be claimed to 577 pertain to the implementation or use of the technology described in 578 this document or the extent to which any license under such rights 579 might or might not be available; neither does it represent that it 580 has made any effort to identify any such rights. Information on the 581 IETF's procedures with respect to rights in standards-track and 582 standards-related documentation can be found in BCP-11. Copies of 583 claims of rights made available for publication and any assurances 584 of licenses to be made available, or the result of an attempt made 585 to obtain a general license or permission for the use of such 586 proprietary rights by implementors or users of this specification 587 can be obtained from the IETF Secretariat. 589 The IETF invites any interested party to bring to its attention any 590 copyrights, patents or patent applications, or other proprietary 591 rights which may cover technology that may be required to practice 592 this standard. Please address the information to the IETF Executive 593 Director. 595 Full Copyright Statement 597 Copyright (C) The Internet Society (2003). All Rights Reserved. 599 This document and translations of it may be copied and furnished to 600 others, and derivative works that comment on or otherwise explain it 601 or assist in its implementation may be prepared, copied, published 602 and distributed, in whole or in part, without restriction of any 603 kind, provided that the above copyright notice and this paragraph 604 are included on all such copies and derivative works. However, this 605 document itself may not be modified in any way, such as by removing 606 the copyright notice or references to the Internet Society or other 607 Internet organizations, except as needed for the purpose of 608 developing Internet standards in which case the procedures for 609 copyrights defined in the Internet Standards process must be 610 followed, or as required to translate it into languages other than 611 English. 613 The limited permissions granted above are perpetual and will not be 614 revoked by the Internet Society or its successors or assignees. 616 This document and the information contained herein is provided on an 617 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 618 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 619 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 620 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 621 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 623 Acknowledgement 625 Funding for the RFC Editor function is currently provided by the 626 Internet Society.