Network Working Group Y. Xu Internet-Draft Tsinghua Univ. Intended status: Standards Track P. Yang Expires:January 8,April 10, 2009 Y. Ma Hitachi (China) R&D Corporation H. Deng China Mobile K. Xu Tsinghua UniversityJulyOctober 7, 2008IKEIKEv2 SA Synchronizationdraft-xu-ike-sa-sync-00for session resumption draft-xu-ike-sa-sync-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onJanuary 8,April 10, 2009. Abstract It will take a long time and mass computation to dosecurity association syncronizationsession resumption among IKE/IPsec gateways possibly maintaining huge numbers ofIKEv2/ IPsec SAs.IKEv2/IPsec SAs, when the serving gateway fails or over-loaded. The major reason is that the prcocedure of IKEv2 SAre- establishmentre-establishment will incur a time-consuming computation especially in theDiffie-HellmanDiffie- Hellman exchange. In this draft, a new IKE security associations synchronization solution is proposed toreduce the computationdo fast IKE SA session resumption by directly transferring the indexed IKE SA (named stub) from old gateway to new gateway, wherein the most expensiveDiffie-HellmanDiffie- Hellman calculation can be avoided. Without some time-consuming IKEv2 exchanges, the huge amount of IKE/IPsec SAsynchronizationsession resumption procedures can be finished in a short time. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Application scenarios. . . . . . . . . . . . . .of IKEv2 Session Resumption . . . . . . 4 2.1. Scenario offailover . . . . .IKEv2 Gateway fail . . . . . . . . . . . . . . 4 2.2. Scenario of load-balance . . . . . . . . . . . . . . . . . 5 3. Details on Proposed solution . . . . . . . . . . . . . . . . . 6 3.1. Overview of the Proposed solution . . . . . . . . . . . . 6 3.2.Keydata structure of stub . . . . . . . . . . . . . . . . . . 7 3.3. Consideration on building IKE SA in session resumption . .6 3.3.7 3.4. Consideration on Stub handling . . . . . . . . . . . . . . 73.4.3.5. Consideration on location of Stub . . . . . . . . . . . .8 3.5.9 3.6. When should Gateways download/update Stub . . . . . . . .9 3.6.10 3.7. Related new messages . . . . . . . . . . . . . . . . . . .911 4. Modification on the base IKEv2 protocol . . . . . . . . . . .1112 5. Security Considerations . . . . . . . . . . . . . . . . . . .1213 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .1314 7. Normative References . . . . . . . . . . . . . . . . . . . . .1415 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .1516 Intellectual Property and Copyright Statements . . . . . . . . . .1718 1. Background IKEv2 protocol which has been defined byrfc4306[1][RFC4306] provides us a method to negotiate ipsec's key automatically between ipsec clients and gateway. Before negotiating ipsec's key, they should negotiate IKE's SA first. Usually, ipsec client sends IKE_INIT message to gateway with SAi1, KEi, Ni, then gateway chooses some proposal of SAi1 which come to the algorithm for encryption and decryption, also proposal for Diffie-Hellman, and then calculates the Diffie-Hellman, sends IKE_INIT respond message back to ipsec client. At this time, the most important keyring can be generated. After other IKE_AUTH exchange,each otherThe identity hasverified the identity.verified. IKE SA has completely been established. The timing overhead of IKEv2 protocol, including some computation and signaling round-trips, is rather big especially when the Extensible Authentication Protocol (EAP) is used for third-party authentication. The picture below is the typical procedure for IKEv2 SA establishment. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> < -- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],AUTH, SAi2, TSi, TSr} --> < -- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Figure 1: IKE_INIT and IKE_AUTH exchangesBut it seems too time consuming to establishThe establishment of an IKE SA inthesethe first twoexchanges, especiallyexchanges of IKEv2 procedure in [RFC4306] (especially Diffie-Hellmancomputation, as we know itcomputation), istoo slow to compute, so it is a challenge torather time-consuming. Normally, thenew gateway when thousands of, even more, ipsec clients are transfered from oldIKEv2/IPsec gateway embodyment (like IPsec VPN gateway, Mobile IPv6 Home Agent, etc) keeps a large number of IKE/IPsec sessions. So in some scenarios (see Section 2), it will take a very time tonewre-establish all thegateway.IKE SA for session resumption of IKEv2/IPsec clients. 2. Application scenarios of IKEv2 Session Resumption 2.1. Scenario offailoverIKEv2 Gateway fail IPsec old new/old client Gateway gateway | | | | IKE/IPsec SAs | | |< ========================== >| | | | | | | | | O Fail of old GW | | | | O detect the fail | | | of old GW | | | | | | new IKE init procedure | |< =================================================== >| | | | | set up other child IPsec SAs | |< =================================================== >| | | | Figure 2:failoverscenarios of IKEv2 Gateway fail In this scenario,ipsecIPsec clients has establishedIKEIKE/IPsec connections with oldgateway, then forgateway with tunnel mode or transporation mode. Because of some reason, the old gatewayfails, after a short time, ipsecmay fail. In this case, IPsec clientknowscan know old gateway has failed(how to know gateway fail is out of ourscope),scope in this draft), andreconnect tore-establish the IKEv2/IPsec sessions with the old gateway or another new gateway.It must beWhile arush hour, so many ipseclarge number of IPsec clientsconnecttry to make thegateway inIKEv2/IPsec connections at the sametime, as we know, re-establish IKE security associations(SAs) is too slowmoment, it will take a rather long time due tocompute because of Diffie- Huffman(DH).the reason mentioned in Section 1. And, the target gateway may have problem to response some clients in this case as well. The problem statement and goals for a failover solution are described in[2].[Narayanan06]. 2.2. Scenario of load-balance IPsec old new client Gateway gateway | | | | IKE/IPsec SAs | | |< ========================== >| | | | | | | | | O overload of old GW | | | | O detect the overload | | | of old GW | | | | | | new IKE init procedure | |< =================================================== >| | | | | set up other child IPsec SAs | |< =================================================== >| | | | Figure 3: load-balance scenarios In this scenario, after establishing IKE connections betweenipsecIPsec clients and old gateway, the old gateway maynot fail, owing to traffic engineer or old gateway is over-loading, ipsecbe over-loading. then, some of the IPsec clientsknows theyshould stop the connection with old gateway and establish the connection with new gateway(how to know new gateway is also out of our scope).IfAgain, while manyipsec clientsIKE/IPsec sessions aretransferdtransferred from old gateway to new gateway,as same as failover,it is a challenge to new gateway toestablishre-establish bunch of IKESA inSAs at the same time. 3. Details on Proposed solution 3.1. Overview of the Proposed solution In this section,we definea new data structurestubis named as "stub", which has the most important information of IKESA, andSA. And gateway can use this data structure tofast rebuildaccelerate the rebuilding of IKE SA.We expand theIKE_INITexchange, and addmessage is extended with a new payload called IKE_SA_SYN.because oldSince the gateway's IP address and SPI can uniquely index theuniquestub of IKE SA,so we make themthese two information are mandatory inSYNthe IKE_SA_SYN payload in order toindex stub.retrieve the stub of IKE SA by the target gateway. The detailed data structure of Stub is introduced in Section 3.2. The IKE SA session resumption procedure in this draft is depicted below: Initiator Responder ----------- --------------HDR, SAi1,HDRGBP[not]SAr1, KEi, Ni, [SYN] ---> < -- HDR, Nr Figure 4: IKE SA synchronization exchangeOnce ipseco While the IPsec client notices that it has to be transfer from old gateway tonew gateway,target gateway and want to pursue the fast session resumption, itcan sendsends IKE_INITwhich is extended a SYN payload as optional,message with theIKESYNpayload has some index informatin such aspayload. The stub indexing information like old gatewayipIP address and old gateway'sSPI, if old/new gateway finds IKE_SA_SYN payloadSPI shall be enclosed in the IKE SYN payload. o Upon receiving the IKE_INITmessage, it can fast re-establishmessage with the IKE_SA_SYN payload, the target gateway uses the information inside to retrieve the the stub of previous IKE SAwithout DH computation and IKE_AUTH exchange,in the stub bank. if the retrieved stub is qualified for IKE SA re-building, the target gateway will choose the new SPI, derive the new set of keyring and re-establish the IKE session for the related client. Lastly, it sends IKE_INITrespondresponse witholny Nr to ipsec client to tell itnew SPI in the IKEv2 header and Nr. The new IKE_SA has been re-established.established successfully. Ifnewthe taget gateway does not support IKE_SA_SYN or not find the proper stub, it can establish IKE SA by normal IKE_INIT and IKE_AUTHexchanges,exchanges as specified in [RFC4306], or just drop thepacket.packet based on the local policy configured by network operator. The stub can be stored in an independent stub bank, co-located with target gateway or even co-located with the corresponding IPsec client. This is discussed in Section 3.5. However, the case of stub co-located with IPsec client is only optional in this draft. 3.2.Keydata structure of stub the stub data structure should conclude all these informations.(We have referenced "ticket" proposal[3].)o IDi, IDr. o SPIi, SPIr. o SAr (the accepted proposal). oSK_d.SK_d_old. o shared secret. o old gateway's ip address.We propose using c++ STL mapo lifetime In the data structureto store this stub message, useof stub, the old gateway's ip address and SPI are used askey, andtheother properties as value. You also can use other data structure to hash old gateway's ip address and SPI to other properties.index for retrieval of stub. SAr have the encrypt and decrypt algorithm, and shared secrect is the DH exchange's result, we can calculate the IKE SA's keyring as rekey process. It will be very quick. 3.3. Consideration on building IKE SA in session resumption After the stub index has been presented by IKE client in the gateway, it will retrieve the stub from the stub bank. The way to get the stub from the stub bank can be found in Section 3.4. As shown in Section 3.2, IDi, SA value can be obtained directly from the retrieved stub. The target gateway shall choose the new SPIr (called SPIr_new in this draft) for the key derivation of session resumption. The nounce values, Ni and Nr, are from the current IKE SYNC exchange. So, the new value of SKEYSEED is calculated as below (SK_d_old value is from the stub): SKEYSEED = prf (SK_d_old, Ni | Nr) And the keyring set are derived by the way of generic IKEv2 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr_new ) The prf (pseudo-random function) of the cryptographic algorithms is specified in the SA value of stub. 3.4. Consideration on Stub handling 1) generationWhenAfter IKE SA has been established(after first two exchanges), the IKE/IPsec gateway extracts the stub from IKESA and store it.SA. 2) propagation Afterextrctedextracted from IKE SA, stubs should be updated to infrastructure such as stubbank(we will define next section)bank. The stub bank can be independent entity in the network orother gateway.co-located with the gateways (see Section 3.5). 3)look-up AsRetrieve The gateway can use the the old gateway's ip address and spi can index the unique stub.Such as map data structure, hash operation is very light-weighted, you can find it very fast.4)usage In some senarios,Expire The stub may be invalid when theipsec clients wantlifetime expires. The value of lifetime is recommended tosynchrinazationbe same as the one in the IKESA with a gateway. ThenSA. The gateway may set different lifetime in stub. 5) Delete When the IKEv2/IPsec session is deleted, theipsec clients send IKE_INIT message with SYN payload to old/new gateway,gatewaywill get old gateway's IP address and SPI from IKE_SA SYN payload, and findshall delete thestubrelated stubs inlocal machine database (maybe downloadthe stubfrom other gateway or stub bank before), then rebuild the IKE SA. If IKE SA has been established, gateway sends IKE_INIT respond(only conclude HDR and Nr) to ipsec client. then create-child-sa exchanges, and so on.bank. The following signaling shall be supported by IKE/IPsec gateways to communicate withStub.Stub bank. oUpdateInitiate Stub: Gatewayupdates itsinitiates the stubto infrastructurein the stub bank once new stub has beenestablished, andestablished. The index shall at least include theinfrastructure store them bygateway's IP address andSPI in a hash data structure.SPI. o Update Stub: Gateway updates its stub to infrastructure once the related IKE SA has been changed o GET Stub: Gateway uses this message to receives stub by the information in IKE_SA SYNpayload, then it send GET Stub to ask for some stubs, the infrastructure index the stubs.payload from IKE client. o Download Stub:After infrastructure finds the stubs, it pushsThe stub bank can use this message to push the stubs to gateway.3.4.o Delete Stub: The Gateway can delete the stubs while the related IKE SAs are no longer available. 3.5. Consideration on location of Stub 1. Centralized infrastructureipsec old/newIPsec old Target stub clientgatewayGW GW bank|| ||| | | | | IKE/IPsec | | | |< ================= >| | Update Stub|| || HDR,SAi1,KEi,Ni,SYN||------------------->|| ||------------------->||| | | ------------------------>| | o Fail | | | | | | | HDR,SAr1,KEi,Ni,SYN | | |----------------------------->| GET Stub|| ||< ------------------||------------------->|| || HDR,Nr ||| | | |---------------->| | | | Download Stub|| || ||< ------------------|| || || ||| | | |< ---------------| | HDR,Nr | | | |< --------------------------- | | | | | | Figure 5: centralized structure This proposal has a centralized Stub Bank server, gateway doesn't need local stub database. a) After IKE connection has been established, old gatewayupdateset up the stub to stub bank. b) Oncetransferring ipsec from old gateway to old/new gateway, ipsecthe fast session resumption is started, IPsec clientsendsends IKE_INIT with SYN payload. c) Whenold/newthe target gateway receives IKE_INIT with SYN payload, itaskasks Stub Bank for stub via GET Stub signaling. d) stub bank push proper stub toold/newtarget gateway.old/newe) Target gatewayfindgets theproperstub and rebuild IKE SA, then send HDR, Nr totell ipsecNotify IPsec client thatit has acceptedthestub.new IKE SA has been set up by IKE SYNC session resumption. 2. Distributed infrastructureipsec old/newIPsec Target Old GW client gateway Stub|| || || || HDR,SAi1,KEi,Ni,SYN||| | | | HDR,SAr1,KEi,Ni,SYN| Update Stub|| ||------------------->||< ------------------|| ||< ------------------|| || ||| | ------------------->| < ------------------| | < ------------------| | | HDR,Nr|| ||| | Figure 6: distributed structure This structure doesn't have centralized Stub Bank, and all gateway must have local stubdatabase,database. if there is stub in local database, it will find the stub in local database, otherwise, it will GET the stub from othergateway.gateways. a) After IKE connection has been established, old gatewayupdateinitiates the stub tostub bank.the potential target gateway. b) Oncetransferring ipsec from old gateway to old/new gateway, ipsecsession resumption is initiated, IPsec client send IKE_INIT with SYN payload. c)old/newTarget gatewayfindfinds the proper stub and rebuild IKE SA, then send HDR, Nr totell ipsec client that it has accepted the stub.IPsec client. Gateway has to store stubs in distributed structure, but it seems more simple than centralized structure. Also, these two proposals can mix together, other gateway also can be Stub Bank.3.5.3. Full distributed in IKEv2/IPsec Client There is also the possibility that the Gateway or Stub bank push the stub to the corresponding client. During the session resumption process, the target gateway can have another option to retrieve the stub from the corresponding client by the way specified in Section 3.4. But, this way of stub co-located with IPsec client is ONLY OPTIONAL. if the operator wants to use this case, the stub MUST be protected perfectly by strong encryption and integrity protection. So, in this draft, it is only optional to co-locate the stub in the client. 3.6. When should Gateways download/update Stub Because of the stub is not sensitive with time,we canthe gateways assemble the stub messages to reduce the message number inupdateinitiate event. The single gateway can get many stubs at a time in download event. The gateway may also update the stubs in bundles whenever it was thought to be necessary3.6.3.7. Related new messages 1)IKE_SA_SYN Payload format 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GateWay's SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GateWay's IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C bit is the direction of this message. 2) Stub related signaling Header Format 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload| type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type number Init 0x01 update010x02 get100x03 download110x04 delete 0x05 reserved000x00 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PAYLOAD CONTENT | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Modification on the base IKEv2 protocol Asour principle, Thethe core principle of this draft, the base IKEv2 protocol should be changed as little as possible. In the proposal, three aspects require slight modification on IKEv2 protocol in [RFC4306] 1) new IKE payload in the IKE_INIT message: IKE_SA_SYN 2)modificationModification on the state machineAs ipsec client, itIPsec client can send generic IKE_INIT message with SYNpayload as usual, andpayload, if itreceivesdecides to use the session resumption. Upon receiving IKE_INITrespondresponse onlyhave Nr,with the Nr and SPIr_new, it will calculate the newike sa likeIKE SA as IKE SA rekey. And set state toike saIKE SA has been established.Asif the session resumption can not be accepted by the target gateway, the client will receive the usual IKE_INIT response as in [RFC4306] and continue the usual IKE_AUTH procedure afterwards The target gateway, once receives IKE_SA_SYN payload, will firstly find the properstub,stub. iffindthestub,stub can be found successfully, it willfastfollow the session resumption proecedure as specified in this draft: re-establish IKE SA, send IKE_INIT respond with Nr only to ipsec client, and set state toike saIKE SA has been established. if the session resumption can not be accepted by target gateway, it just follows the usual IKEv2 initiation procedure as in [RFC4306] 3) The gateway should support the Stub related functionslike extract_stub, update_stub and get_stubas specified in Section 3.4 5. Security Considerations the security framework of IKEv2 protocol will not be compromised in this solution. 1) The stub index (Old gateway's IP address and SPI) in IKE_SA_SYN is a light-weightedoperation,information, which can be transported without encryption. And it relies on IKE_INIT message to handle the replay protection andno stub, no response.DoS attack. 2) The Gateway can use SAr1, KEi to verify the identity, such as ID property.But it depends on the configuration of operators.3) Even if the index isright, ipsecright and IPsec client cannot rebuildIKE_SA,IKE_SA because of some reason, thecommunication can't last,newly re-built IKE SA in gateway will be deleted aftera little time,somewhile. 4) In theIKE_SAcase of stub co-located with IPsec Client, the stub MUST be perfected protected to prevent the malicious attackers from cracking the stub, if they can obtain the stub on the network. Actually, even if the stub is strongly encrypted, there still has the risk. With the development of harware ingatewayaccord with the Moore's Law, the capability of computing equipment will bedeleted.increased step by step. Sometime, somehow, the brutal force decryption of the stub encryption method may be possible. And, there is also posibility that the currently safe encryption algorithm may be proved to be mathematically solvable. So, all in all, it is only optional to tranport the stub on the untrusted network, even if it can be protected strongly. 6. Conclusion In this draft, a new solution is proposed to do IKE SA synchrinization forfast re-establishmentquick session resumption of IKE SA.It willWith the extension of IKE_SA_SYNC payload in IKE_INIT message, it can remove the most time-consuming IKEv2exchanges,exchanges to re-build the IKE SA, which makes it much faster to transfer millions ofipsec clientsIKE sessions from old gateway toold/newtarget gateway. And the proposal in this draft willonlyjust slightly modify the base IKEv2 protocol with a new logical IKE SA Stub bank in the network. 7. Normative References [Narayanan06] Narayanan, V., "IPsec Gateway Failover and Redundancy Problem Statement and Goals", draft-vidya-ipsec-failover-ps-00.txt (work in progress), December 2006. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [Sheffer07] Xie, Y., "Stateless Session Resumption for the IKE Protocol", draft-sheffer-ike-session-resumption-00.txt (work in progress), January 2007. Authors' Addresses Yan Xu Tsinghua Univ. Department of Computer Science Tsinghua University Haidian District Beijing, 100088 P.R. China Email: xydkl@163.com Peng Yang Hitachi (China) R&D Corporation 301, North Wing, Tower C Raycom Infotech Park 2 kexueyuan Nanlu Haidian District Beijing, 100080 P.R. China Phone: +861082862918(ext.)328 Email:pyang@hitachi.cnpeng.yang.chn@gmail.com Yuanchen Ma Hitachi (China) R&D Corporation 301, North Wing, Tower C Raycom Infotech Park 2 kexueyuan Nanlu Haidian District Beijing, 100080 P.R. China Phone: +861082862918(ext.)327 Email: ycma@hitachi.cn Hui Deng China MobileXu53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui@chinamobile.com Ke Xu Tsinghua University Department of Computer Science Tsinghua University Haidian District Beijing, 100088 P.R. China Email: xuke@mail.tsinghua.edu.cn Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.