idnits 2.17.1 draft-giaretta-mip6-aaa-ha-goals-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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 512. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 516), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 516. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 149 has weird spacing: '...ionship trust...' -- 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 (September 2004) is 7162 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 (-05) exists of draft-ietf-mip6-bootstrap-ps-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. '2') == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-16 ** Downref: Normative reference to an Informational RFC: RFC 3410 (ref. '4') ** Downref: Normative reference to an Historic RFC: RFC 3084 (ref. '5') == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-01) exists of draft-chowdhury-mip6-bootstrap-radius-00 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-02) exists of draft-jang-dhc-haopt-00 -- Possible downref: Normative reference to a draft: ref. '8' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIP6 Working Group G. Giaretta 2 Internet Draft I. Guardini 3 Expires: March 2005 E. Demaria 4 TILab 5 J. Bournelle 6 GET/INT 7 R. Lopez 8 Univ. of Murcia 9 September 2004 11 Goals for AAA-HA interface 12 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, I 18 certify that any applicable patent or other IPR claims of which I am 19 aware have been disclosed, and any of which I become aware will be 20 disclosed, in accordance with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 In commercial deployments Mobile IPv6 can be a service offered by a 41 Mobility Services Provider (MSP). In this case all protocol 42 operations may need to be explicitely authorized and traced. A 43 convenient approach to do that is to define an interface between the 44 Home Agent (HA) and the AAA infrastructure of the MSP, which stores 45 user's credentials and service profiles. The availability of this 46 interface can be useful also to enable dynamic Mobile IPv6 47 bootstrapping on both the mobile node and the designated HA. 48 This document describes various scenarios where an interface between 49 the HA and the AAA infrastructure of the MSP is required. 50 Furthermore, a list of design goals for this interface is provided. 52 Table of Contents 54 1. Introduction................................................3 55 2. Motivation..................................................4 56 3. Basic security model........................................5 57 4. Bootstrapping scenarios.....................................6 58 4.1 Scenario 1...............................................6 59 4.2 Scenario 2...............................................6 60 4.3 Scenario 3...............................................7 61 4.4 Scenario 4...............................................8 62 5. Goals for the AAA-HA interface..............................9 63 5.1 General goals............................................9 64 5.2 Service Authorization....................................9 65 5.3 Accounting..............................................10 66 5.4 Mobile Node Authentication..............................10 67 5.5 Provisioning of configuration parameters................10 68 6. Mapping between goals and scenarios........................11 69 7. Security Considerations....................................12 70 References......................................................13 71 Authors� Addresses..............................................14 72 Intellectual Property Statement.................................15 73 1. Introduction 75 Mobile IPv6 [1] was originally designed as a standalone protocol to 76 handle terminal mobility relying on a centralized and pre-configured 77 Home Agent (HA). Nonetheless, if Mobile IPv6 is a service offered by 78 a Mobility Services Provider (MSP), all protocol operations may need 79 to be explicitely authorized and traced (e.g. for accounting 80 purposes). A convenient approach to achieve this result is to define 81 an interface between the AAA infrastructure of the MSP and the HA. 82 Such an interface may be useful also in some Mobile IPv6 dynamic 83 bootstrapping scenarios [2]. 85 This document describes various scenarios for which an interface 86 between the HA and the AAA infrastructure of the MSP is useful. 87 Furthermore, a list of goals for such an interface is provided. 89 No assumptions are made on the protocol used to implement the 90 interface. An obvious choice may be the employment of a AAA protocol 91 such as RADIUS or Diameter. Nonetheless, for some scenarios, other 92 non AAA protocols such as SNMPv3 [4] or COPS-PR [5] may satisfy all 93 the goals described herewith. 95 2. Motivation 97 Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are 98 provisioned with a set of configuration parameters, namely the Home 99 Address and the Home Agent Address, in order to accomplish a home 100 registration. Moreover MNs and Home Agents (HAs) must share the 101 cryptographic material needed to protect Mobile IPv6 signaling (e.g. 102 shared keys or certificates to setup an IPsec security association). 104 The simplest option is to statically provision all the necessary 105 configuration data on MNs and HAs. This solution raises obvious 106 scalability issues especially in a large network with a lot of users 107 (e.g. a mobile operator network). For this reason the dynamic Mobile 108 IPv6 bootstrapping problem is currently under study [2]. 110 In case Mobile IPv6 is a service offered by a Mobility Service 111 Provider (MSP) all protocol operations (e.g. home registrations) may 112 need to be explicitely authorized and monitored (e.g. for accounting 113 purposes). This can be done relying on the AAA infrastructure of the 114 MSP, that stores users' service profiles and credentials. 116 The deployment of this service model requires the availability of an 117 interface between the AAA infrastructure and the HA, that can be 118 seen as the Network Access Server (NAS) for Mobile IPv6. The core 119 capabilities that should be supported by this interface include 120 Mobile IPv6 service authorization and maintenance (e.g. asynchronous 121 service termination) as well as the exchange of accounting data. 122 This is the basic set of features needed in any Mobile IPv6 123 bootstrapping scenario (i.e. static or dynamic). 125 Moreover, whenever static provisioning is not feasible, the AAA 126 infrastructure of the MSP can be used as the central element to 127 build a dynamic Mobile IPv6 bootstrapping solution. In this case the 128 AAA infrastructure can be exploited also to send to the designated 129 HA the needed configuration parameters (e.g. keying material) as 130 well as to assist the HA with mobile node authentication. 132 There is therefore space for the definition of a general AAA-HA 133 communication interface capable to support the basic features 134 described above (e.g. authorization and accounting) as well as the 135 extended capabilities (e.g. transfer of configuration data) needed 136 to enable various dynamic Mobile IPv6 bootstrapping scenarios. 138 3. Basic security model 140 The basic security model behind this draft assumes that the mobile 141 node shares a pre-configured trust relationship with the AAA server 142 of the MSP (AAAH), as stated in [2]. Furthermore the HA is expected 143 to share a trust relationship with the AAAH server (see Figure 1). 145 MN AAAH HA 146 ^ ^ ^ ^ 147 | | | | 148 +----------------+ +---------------+ 149 trust relationship trust relationship 151 Figure 1 - Basic Model 152 4. Bootstrapping scenarios 154 This section describes some bootstrapping scenarios in which a 155 communication between the AAA infrastructure of the Mobility Service 156 Provider and the Home Agent is needed. These scenarios include both 157 dynamic (Scenario 1 and Scenario 2) and static (Scenario 3 and 158 Scenario 4) bootstrapping. 160 4.1 Scenario 1 162 In this scenario, depicted in Figure 2, the MN discovers the Home 163 Agent address (e.g. by means of a new DNS SRV record or DHCP) and 164 performs an IKEv2 [3] exchange with the HA to setup the IPsec SA 165 needed to protect mobility signaling. Eventually, during this 166 handshake, the MN can also obtain a valid Home Address from the HA. 168 The MN is not expected to share a pre-configured trust relationship 169 with the HA, nor to share a secret with it. For this reason, peer 170 authentication in IKEv2 can be performed through an EAP exchange. 171 The HA, behaving as an EAP authenticator operating in pass-through 172 mode, forwards this EAP exchange to the AAAH server, that can 173 authenticate the MN and authorize the Mobile IPv6 service. 174 Therefore, in this case an interface between the HA and the AAAH 175 server is needed at least for authentication and authorization 176 purposes. 178 MN AAAH HA 180 <---------- IKEv2(EAP) --------> 182 <---------> 183 AAA-HA protocol 185 Figure 2 - Dynamic MIPv6 bootstrapping through IKEv2 and EAP 187 4.2 Scenario 2 189 In this scenario Mobile IPv6 bootstrapping is performed during 190 network access authentication (it is assumed that the access 191 provider and the MSP are the same entity, i.e. Integrated ASP [2]) 192 and the AAA server of the MSP (AAAH) controls the whole 193 bootstrapping procedure interacting with both the mobile node and 194 the designated HA. 196 The AAAH server and the MN can exploit AAA routing to exchange 197 configuration data. Possible approaches to implement this 198 communication are the following: 200 - if network access authentication is carried out using EAP, it is 201 possible to piggyback Mobile IPv6 configuration parameters (e.g. 203 Home Agent address, Home Address) within the EAP exchange [6]. See 204 Figure 3; 206 - alternatively, Mobile IPv6 parameters can be transferred to the 207 Network Access Server (NAS) by means of RADIUS or Diameter AVPs 208 [7] and then forwarded to the MN through other means (e.g. L2- 209 specific extensions, DHCP [8]). See Figure 4 for an example. 211 In both cases, the AAAH server must communicate with the designated 212 HA to select a suitable Home Address for the MN and to deliver to 213 the HA the necessary configuration parameters (e.g. pre-shared key 214 for IKE bootstrapping). Therefore also in this scenario an interface 215 between the AAAH server and the HA must be defined for parameter 216 exchange as well as authentication and Mobile IPv6 service 217 authorization. 219 MN AAAH HA 220 <------------------------> <--------> 221 Piggybacking of MIPv6 AAA-HA protocol 222 data within EAP 224 Figure 3 - MIPv6 bootstrapping with piggybacking within EAP 226 MN NAS AAAH HA 227 <----------> <---------> <--------> 228 L2-specific MIPv6 AAA-HA protocol 229 extensions RADIUS AVPs 231 Figure 4 - MIPv6 bootstrapping with RADIUS AVPs 233 4.3 Scenario 3 235 In this scenario the MN is statically provisioned with the data 236 needed to bootstrap Mobile IPv6 service (i.e. Home Agent Address, 237 Home Address and a shared secret with the HA). For example, the MN 238 can be configured with a pre-shared key to dynamically establish an 239 IPsec Security Association with the HA using IKE. 241 However, in general the static configuration of these parameters and 242 the authentication performed through the pre-shared key may not be 243 sufficient to conclude that the MN is authorized for MIPv6 service. 244 For example, the MSP might want to prevent the usage of MIPv6 if the 245 the credit of the MN is going to exhaust. Moreover, there might be 246 the need for the MSP to enforce more complex dynamic authorization 247 policies based on time of day and/or visited location. 249 This implies that during the IKE exchange the HA must communicate 250 with the AAAH server in order to explicitly authorize MIPv6 service 251 for that particular MN. See Figure 5. 253 MN AAAH HA 255 <-------------- IKE ------------> 257 <-----------> 258 AAA-HA protocol 260 Figure 5 - Mobile IPv6 authorization with static boostrapping 262 4.4 Scenario 4 264 In this scenario, the IPsec SA between MN and HA is statically and 265 manually configured, thus the MN does not need to perform an IKE 266 exchange with the HA. The MN activates MIPv6 service, sending a 267 Binding Update message to the HA in order to update its location. 269 The presence of the IPsec SA between MN and HA is enough in order to 270 authenticate the binding management messages. However, it is not 271 enough to authorize MIPv6 service; thus, as soon as it receives a 272 Binding Update, the HA must explicitly authorize MIPv6 service 273 interacting with the AAAH server (Figure 6). For this purpose, an 274 interface between the HA and the AAAH is needed at least for 275 authorization purposes. 277 If deemed necessary, the explicit authorization of Binding Updates 278 based on the handshake depicted in Figure 5 can be used also in the 279 bootstrapping scenarios described in the previous sections. It may 280 be useful to enforce dynamic authorization policies, such as those 281 based on the MN's location. 283 MN AAAH HA 285 ------------ BU ------------> 287 <-----------> 288 AAA-HA protocol 290 <----------- BA ------------- 292 Figure 6 - Binding Update Authorization 293 5. Goals for the AAA-HA interface 295 The motivations and scenarios illustrated in previous sections raise 296 the need to define an interface between the AAAH server and the HA. 297 The following sections list a set of goals for this interface. 299 5.1 General goals 301 G1.1 The AAAH server and the HA must be able to authenticate each 302 other (mutual authentication) in order to prevent the 303 installation of unauthorized state on the HA. 305 G1.2 The AAA-HA interface must provide integrity protection in 306 order to prevent any alteration of exchanged data (e.g. Mobile 307 IPv6 configuration parameters). 309 G1.3 The AAA-HA interface must provide replay protection. 311 G1.4 The AAA-HA interface should provide confidentiality since it 312 may be used to transfer security parameters (e.g. IKE pre- 313 shared key). 315 G1.5 The AAA-HA interface should support inactive peer detection. 316 This functionality can be used by the AAAH server to maintain 317 a list of active HAs (e.g. useful for HA selection). 319 5.2 Service Authorization 321 G2.1 The AAA-HA interface should allow the use of Network Access 322 Identifier (NAI) to identify the mobile node. 324 G2.2 The HA should be able to query the AAAH server to verify 325 Mobile IPv6 service authorization for the mobile node. 327 G2.3 The AAAH server should be able to enforce explicit operational 328 limitations and authorization restrictions on the HA (e.g. 329 packet filters, QoS parameters). 331 G2.4 The AAAH server should be able to send an authorization 332 lifetime to the HA to limit Mobile IPv6 session duration for 333 the MN. 335 G2.5 The HA should be able to request to the AAAH server an 336 extension of the authorization lifetime granted to the MN. 338 G2.6 The AAAH server should be able to force the HA to terminate an 339 active Mobile IPv6 session for authorization policy reasons 340 (e.g. credit exhaustion). 342 G2.7 The AAAH server should be able to retreive the Mobile IPv6 343 state associated to a specific MN from the correspondent HA. 344 This may be useful to periodically verify the Mobile IPv6 345 service status. 347 5.3 Accounting 349 G3.1 The AAA-HA interface must support the transfer of accounting 350 records needed for service control and charging. These include 351 (but may not be limited to): time of binding cache entry 352 creation and deletion, octets sent and received by the mobile 353 node in Bi-directional Tunneling, etc. 355 5.4 Mobile Node Authentication 357 G4.1 The AAA-HA interface should support MN authentication (and re- 358 authentication) with the HA working as a NAS and the AAAH 359 server working a back-end authentication server. 361 G4.2 The AAA-HA interface should support at least pass-through EAP 362 authentication with the HA working as a EAP authenticator 363 operating in pass-through mode and the AAAH server working as 364 back-end authentication server. 366 5.5 Provisioning of configuration parameters 368 G5.1 The AAAH server should be able to poll the designated HA for 369 the allocation of a Home Address to the MN. Optionally, the 370 AAAH server can provide a set of hints for the construction of 371 the Home Address (e.g. a preferred Home Address or a preferred 372 Interface Identifier). 374 G5.2 The HA should be able to communicate to the AAAH server the 375 Home Address allocated to the MN. 377 G5.3 The AAAH server should be able to send to the HA the security 378 data needed to setup the IPsec SA between the MN and the HA. 379 Possible security data are the authentication method and the 380 cryptographic material to be used for IKE bootstrapping. 382 6. Mapping between goals and scenarios 384 The table below shows which goals, among those listed in section 5, 385 are strictly (X) or optionally (O) required for each of the 386 scenarios discussed in section 4. 388 Section +---------------------------------------+ 389 Defined Goals | Scen. 1 | Scen. 2 | Scen. 3 | Scen. 4 | 390 -------------------+---------|---------|---------|---------| 391 G1.1 | X | X | X | X | 392 G1.2 | X | X | X | X | 393 5.1 G1.3 | X | X | X | X | 394 G1.4 | O | X | O | O | 395 G1.5 | X | X | X | X | 396 -------------------|---------|---------|---------|---------| 397 G2.1 | X | X | O | O | 398 G2.2 | X | X | X | X | 399 G2.3 | X | X | X | X | 400 5.2 G2.4 | X | X | X | X | 401 G2.5 | X | X | X | X | 402 G2.6 | X | X | X | X | 403 G2.7 | X | X | X | X | 404 -------------------|---------|---------|---------|---------| 405 5.3 G3.1 | X | X | X | X | 406 -------------------|---------|---------|---------|---------| 407 5.4 G4.1 | X | | | | 408 G4.2 | X | | | | 409 -------------------|---------|---------|---------|---------| 410 G5.1 | | X | | | 411 5.5 G5.2 | | X | | | 412 G5.3 | | X | | | 413 -------------------+---------+---------+---------+---------+ 414 7. Security Considerations 416 As stated in section 5.1 the AAA-HA interface must provide mutual 417 authentication, integrity and replay protection. Furthermore, if 418 security paramters (e.g. IKE pre-shared key) are transferred through 419 this interface, confidentiality support is also required. 421 References 423 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", 424 draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. 426 [2] Patel, A. et al. "Problem Statement for bootstrapping Mobile IPv6", 427 draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. 429 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 430 draft-ietf-ipsec-ikev2-16 (work in progress), September 2004. 432 [4] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and 433 Applicability Statements for Internet-Standard Management 434 Framework", RFC 3410, December 2002. 436 [5] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. 437 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for 438 Policy Provisioning,", RFC 3084, March 2001. 440 [6] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Laurent- 441 Maknavicius, M., "MIPv6 Authorization and Configuration based on 442 EAP", draft-giaretta-mip6-authorization-eap-02 (work in progress), 443 September 2004. 445 [7] Chowdhury, K. and Lior, A., "RADIUS Attributes for Mobile IPv6 446 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-00 (work in 447 progress), July 2004. 449 [8] Jang, H. J. and Yegin, A., "DHCP Option for Home Agent Discovery in 450 MIPv6", draft-jang-dhc-haopt-00 (work in progress), May 2004. 452 Authors' Addresses 454 Gerardo Giaretta 455 Telecom Italia Lab 456 via G. Reiss Romoli, 274 457 10148 TORINO 458 Italy 459 Phone: +39 011 2286904 460 Email: gerardo.giaretta@tilab.com 462 Ivano Guardini 463 Telecom Italia Lab 464 via G. Reiss Romoli, 274 465 10148 TORINO 466 Italy 467 Phone: +39 011 2285424 468 Email: ivano.guardini@tilab.com 470 Elena Demaria 471 Telecom Italia Lab 472 via G. Reiss Romoli, 274 473 10148 TORINO 474 Italy 475 Phone: +39 011 2285403 476 Email: elena.demaria@tilab.com 478 Julien Bournelle 479 GET/INT 480 9 rue Charles Fourier 481 Evry 91011 482 France 483 Email: julien.bournelle@int-evry.fr 485 Rafa Marin Lopez 486 University of Murcia 487 30071 Murcia 488 Spain 489 EMail: rafa@dif.um.es 490 Intellectual Property Statement 492 The IETF takes no position regarding the validity or scope of any 493 Intellectual Property Rights or other rights that might be claimed 494 to pertain to the implementation or use of the technology described 495 in this document or the extent to which any license under such 496 rights might or might not be available; nor does it represent that 497 it has made any independent effort to identify any such rights. 498 Information on the procedures with respect to rights in RFC 499 documents can be found in BCP 78 and BCP 79. 501 Copies of IPR disclosures made to the IETF Secretariat and any 502 assurances of licenses to be made available, or the result of an 503 attempt made to obtain a general license or permission for the use 504 of such proprietary rights by implementers or users of this 505 specification can be obtained from the IETF on-line IPR repository 506 at http://www.ietf.org/ipr. 508 The IETF invites any interested party to bring to its attention any 509 copyrights, patents or patent applications, or other proprietary 510 rights that may cover technology that may be required to implement 511 this standard. Please address the information to the IETF at 512 ietf-ipr@ietf.org. 514 Full Copyright Statement 516 Copyright (C) The Internet Society (2004). All Rights Reserved. 518 This document is subject to the rights, licenses and restrictions 519 contained in BCP 78, and except as set forth therein, the authors 520 retain all their rights. 522 Disclaimer of Validity 524 This document and the information contained herein are provided on 525 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 526 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 527 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 528 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 529 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 530 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 532 Acknowledgment 534 Funding for the RFC Editor function is currently provided by the 535 Internet Society.