idnits 2.17.1 draft-haddad-netlmm-pmipv6-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 469. 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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 11, 2007) is 6004 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) ** Downref: Normative reference to an Informational RFC: RFC 3792 (ref. 'CGA') ** Obsolete normative reference: RFC 3775 (ref. 'MIP6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-04) exists of draft-haddad-alien-threat-model-00 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-06 == Outdated reference: A later version (-06) exists of draft-haddad-alien-privacy-terminology-03 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network-based Mobility Management W. Haddad 3 (Netlmm) S. Krishnan 4 Internet-Draft Ericsson Research 5 Intended status: Standards Track November 11, 2007 6 Expires: May 11, 2008 8 On Providing Light SeND and Privacy Extensions for Proxy MIPv6 (PMIPv6) 9 draft-haddad-netlmm-pmipv6-privacy-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 11, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a light and CGA free version of the secure 43 neighbor discovery protocol combined with a privacy extension for the 44 Proxy Mobile IPv6 protocol. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions used in this document . . . . . . . . . . . . . . 4 50 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 4. Background and Motivation . . . . . . . . . . . . . . . . . . 6 52 5. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 8 53 5.1. Solution for On-path attacks . . . . . . . . . . . . . . . 8 54 5.2. Solution for On-link attacks . . . . . . . . . . . . . . . 8 55 5.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 56 5.4. Future work . . . . . . . . . . . . . . . . . . . . . . . 10 57 6. New Option Format . . . . . . . . . . . . . . . . . . . . . . 11 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 63 Intellectual Property and Copyright Statements . . . . . . . . . . 15 65 1. Introduction 67 Proxy Mobile IPv6 protocol (described in [PMIPv6]) is an ongoing 68 activity, which aims essentially to provide network based mobility. 69 The main concept is to trick the mobile node (MN) into believing that 70 it is always attached to its home network even when in reality, it 71 has switched to foreign network(s). Consequently, the MN can keep 72 using it IP home address (HoA) while being located away from its home 73 network. 75 This document describes a mechanism which combines a light and CGA 76 free version of the secure neighbor discovery (described in [SeND]) 77 combined with a privacy extension for PMIPv6 protocol. At this 78 stage, the light SeND (LiSeND) protocol enables the MN and its access 79 router, i.e., the mobility access gateway (MAG), to authenticate the 80 exchange of router solicitation (RtSol) and advertisement (RtAdv) 81 messages and removes the need for running duplicate address detection 82 (DAD) on the MN side (for more details on RtAdv/RtSol and DAD, please 83 refer to the Neighbor Discovery Protocol described in [NDP]). 84 Another key feature lies in the fact that LiSeND does not require the 85 crypto generated address technique (described in [CGA]) deployment on 86 both the infrastructure and the MN sides. 88 Building on LiSeND, we then describe a simple privacy extension which 89 enables to mask the MN's HoA in a visited network(s) and thus, 90 prevents an eavesdropper from learning, identifying and tracing the 91 MN. A side effect of the suggested proposal is a mechanism which 92 removes the harmful impact on the MN's ongoing sessions in case of a 93 possible duplicate address detection (DAD) failure. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [TERM]. 101 3. Terminology 103 Since our proposal is mainly designed for network-based mobility, we 104 borrow the terminology used in PMIPv6 and refer to a mobility 105 (un)aware by MN. The main privacy aspects definitions are defined in 106 [PRITERM]. Finally, we reuse the tunneling optimization mechanism 107 and terminology that we have introduced earlier in [TOM]. 109 4. Background and Motivation 111 Being a network-base mobility, PMIPv6 achieves its goal by enabling 112 the MN to retain the same IP address while roaming between different 113 foreign networks and delegates the task of securely discovering and 114 updating the MN's Local Mobility Anchor (LMA) to the MAG. 116 The MAG fulfills its task by sending a proxy binding update (PBU) 117 message to request binding (and potentially assigning) the MN's home 118 network prefix (HNP) to its own egress interface address as being the 119 MN's care-of address (CoA). Following a successful update, the MN's 120 LMA starts tunneling data packets sent from the correspondent node(s) 121 (CN) (i.e., which is kept totally unaware about the MN's mobility) to 122 the MN's CoA, i.e., MAG's egress interface address. The MAG then 123 decapsulates each data packet sent to the MN's CoA and forwards it to 124 the MN. It follows, as mentioned earlier, that the MN will always 125 believe that it is still attached to its home network, especially 126 that the MAG takes great care of nurturing the MN's belief by 127 advertising in unicast mode its home prefix in order to convince it 128 to (re)-configure its HoA. 130 Our motivation is mainly guided by a requirement in EU and some Asian 131 countries and from a general desire in others (!!), to protect the 132 MN's privacy while switching to and moving across foreign networks. 133 Such protection should enable to provide anonymity and unlinkability 134 aspects whenever possible. Consequently, privacy protection in a 135 PMIPv6 environment means first and foremost preventing the MN from 136 disclosing its HoA within any foreign network and removing any 137 "linkability" when switching to a new MAG. It follows that an 138 efficient privacy protection should enable the MN to mask its HoA and 139 to update the mask each time it switches to a new MAG. It is 140 noteworthy that updating the mask becomes more efficient for 141 protecting the MN's privacy if it is applied at higher frequency than 142 just when switching to a new MAG. While the suggested proposal 143 enables such enhancement, we don't detail it in this version. 145 A malicious node (acting independently), has two topological 146 locations from which, it can learn/detect the MN's HoA (or maybe the 147 HNP only) and use it to trace the MN's subsequent movements. The 148 first location is anywhere on-path between the MAG and the MN's LMA. 149 In such location, the eavesdropper is able to check the inner header 150 carried in each data packet sent by the MN's HA to its current MAG. 151 The data packet inner header carries the MN's HoA and the CN's IP 152 address. With such ability, the eavesdropper can rely for example, 153 on som prior knowledge/hint to uncover the targeted MN's current 154 whereabout and even "lock" on it. 156 The second location is the link to which the MN is attached. In such 157 location, the eavesdropper is also able to identify the MN and trace 158 its movements. In addition, other static identifier(s), e.g., the 159 MN's MAC address, become available and may significantly contribute 160 in detecting and tracing the MN. However, we consider out of scope 161 all parameters below the IP layer but we carefully note that our 162 proposal can also be extended to cover the MAC address, i.e., by 163 extending the scope of the mask. Privacy issues related to the MAC 164 layer are detailed in [ANON]. 166 The unlinkability protection can be seriously endangered each time 167 the MN switches to a foreign network and keeps using its CGA public 168 key from which, it has generated its HoA. In fact, the requirement 169 behind PMIPv6 design to enable the MN to retain its HoA means also 170 that the MN won't be able to change its CGA public key as its HoA 171 won't remain the same. Consequently, if an eavesdropper learns the 172 MN's public key (which is far from being a problem!), then it will 173 always be able to trace the MN after switching to a new MAG(s). In 174 addition, as applying the mask will generate a pseudo-IPv6 (pIPv6) 175 address, it is of high importance to make sure that pIPv6 won't be 176 reused when switching to a new MAG. 178 The picture of the two separate threats scenarios described above 179 becomes rapidly more complicated when they are combined. This is the 180 case where at least two malicious nodes with each following one of 181 the two scenarios, are coordinating their "search, identify and 182 trace" activities. In such case, an efficient anonymity and 183 unlinkability protection can be obtained by simply merging the two 184 solutions addressing each of the the two scenarios. In other words, 185 the MN's HoA MUST NOT be disclosed neither on the link between the MN 186 and its MAG nor anywhere between the MAG and the MN's LMA. Also, the 187 MN MUST avoid (re)-using its CGA public key and the pIPv6 MUST be 188 refreshed after the handoff. 190 In the following section, we address the above scenarios separately 191 and describe two mechanisms to reduce the eavesdropper's ability to 192 learn the MN's HoA and/or trace its movements. The combination of 193 the two protections is highlighted in the last section. 195 5. Proposed Solutions 197 5.1. Solution for On-path attacks 199 Our proposed mechanism addresses the first scenario where an 200 eavesdropper is located on-path between the MN's MAG and the LMA by 201 completely eliminating the need for disclosing the MN's HoA in any 202 data packet sent to the MN's PMA. This is achieved by removing it 203 from each data packet exchanged between the MN's LMA and its current 204 MAG, via applying the tunneling optimization (TO) mechanism. As in 205 the Mobile IPv6 case [MIP6], the TO mechanism can be securely applied 206 during the PBU/PBA messages exchange between the MAG and the LMA 207 nodes. In this case, the PMIPv6 signaling exchange should lead both 208 sides to create a PaT, which can be immediately applied on each data 209 packet sent by the MN to the correspondent node (CN) and/or tunneled 210 from the HA to the MN's CoA, i.e., the MAG. This results in a 211 complete removal of the MN's HoA from the path between the MAG and 212 the LMA. Consequently, implementing such optimization significantly 213 complicates the eavesdropper's task of identifying the targeted MN 214 from snooping into data packets flow(s) exchanged between the MN's 215 MAG and its LMA. Note that if the MN is using multiple HoAs as it 216 may be talking to different CNs, then the PMA and HA will have to 217 generate one PaT for each HoA. 219 In addition to removing the MN's HoA from data packets and in order 220 to enhance the unlinkability aspect, it is highly recommended that 221 the MAG refreshes periodically the MN's CoA, i.e., its own IP egress 222 interface address, and updates all associated PaT(s) accordingly. 223 This can be done by re-sending PBU message(s) to the LMA to update 224 its binding cache entries table. 226 5.2. Solution for On-link attacks 228 As mentioned in the second threat scenario, when an eavesdropper is 229 attached to the same link than the MN, it can easily detect the 230 unicast RtAdv message sent by the MAG to the MN following a 231 successful authentication and the receipt of a PBA message (unless 232 the HNP is obtained via another way, e.g., from the AAA). However, 233 as disclosing the MN's home network prefix (HNP) alone may be very 234 sufficient for an eavesdropper to identify the MN, providing privacy 235 protection to the MN requires a complete "blackout" on its HNP on any 236 foreign link. Such requirement may also be raised within the MN's 237 home network as it blocks malicious nodes from learning the MN's HoA 238 even when it is still attached to its home network. Imposing an HNP 239 blackout requires the MAG and/or LMA to send special parameters to 240 the MN in order to enable it to (re)-configure its HoA and at the 241 same time, generate a special PaT to translate its HoA to another 242 pIPv6 address in each IP packet sent by the MN as well as in each IP 243 packet forwarded by the LMA/MAG to the MN. In addition, these 244 parameters MUST be sent encrypted, which makes it tempting at this 245 stage to turn to the CGA technique to achieve this particular goal 246 (i.e., using the MN's CGA public key), then send them in the unicast 247 RtAdv message. However, as mentioned earlier, using the MN's CGA 248 public key provides the eavesdropper just another valuable tool to 249 identify and trace the MN. In order to avoid the CGA impasse, a new 250 secret called "privacy key (Kp)" should be computed and stored in the 251 AAA. Computing Kp should be performed when authenticating the MN for 252 the first time. Note that generating Kp can occur when the MN is 253 attached to a foreign network. The mechanism(s) to be used to 254 compute Kp is out of scope of this document. 256 5.3. Operation 258 After generating and storing Kp, the AAA may decide to share it with 259 the MN's LMA. But, in general, Kp is used by the MN and the AAA to 260 derive the "transient handoff key (THK)", which is then sent to the 261 MN's current MAG. THK can be sent to the MAG directly by the AAA, 262 following a successful authentication or by the LMA in the PBA 263 message. This means that each time the MN has to perform an 264 authentication, a new THK is computed and sent to the current MAG. 265 In addition to refreshing THK, the AAA and the MN SHOULD also 266 generate a pseudo-NAI (pNAI) and bind it to the new TKh to be used. 267 The new pNAI is used by the MN during the next authentication and is 268 carried by the PBU message sent by the MAG to the LMA. It follows 269 that the pNAI MUST be sent to the LMA prior to receiving a PBU 270 message (e.g., after a successful authentication). 272 Upon receiving a THK, the MAG SHOULD use it to derive a PaT and to 273 encrypt the HNP sent by the LMA in order to be advertised to the MN. 274 For this purpose, the MAG has to signal to the MN its capability to 275 offer anonymity and unlinkability services. This is done by setting 276 a new bit called "Privacy (P)" bit in the unicast RtAdv message sent 277 to the MN. The presence of the "P" bit also indicates to the MN that 278 it has to generate the PaT which corresponds to the THK computed by 279 the MN. One way to handle the "P" bit is to set it in the same new 280 option (called "Unicast RtAdv Authentication (URA)") carrying the 281 message authentication. Moreover, the MAG MUST use THK to 282 authenticate all unicast RtAdv messages sent to the MN. Similarly, 283 the MN MUST use THK to authenticate any RtSol message sent to the 284 MAG. 286 Upon receiving a RtAdv message carrying a URA (i.e., following a 287 successful authentication), the MN proceeds first to check the 288 message validity with its own THK. If the message is valid then the 289 MN decrypts the HNP, configures its HoA and generates the 290 corresponding PaT. Otherwise, the MN should silently discard the 291 message. 293 The PaT SHOULD be applied by the MN on each data packet sent to the 294 CN. The MAG SHOULD apply the PaT on each IP packet sent to the MN's 295 HoA and on each data packet sent by the MN. It follows that the MN's 296 HNP is never disclosed on the link. It should be noted that for the 297 purpose of enhancing the unlinkability while being attached to the 298 same link, it is highly recommended to periodically refresh the PaT. 300 In addition to hiding the HNP advertised to the MN, the MAG SHOULD 301 also run the DAD procedure on the MN's new pIPv6 address before 302 advertising the HNP to the MN. In case of a collision, the MAG 303 SHOULD randomly generate a unique pseudo-HNP then share it with the 304 MN. This is achieved by XORing a random 64-bit parameter with the 305 corresponding PaT then with the HNP and testing its uniqueness. The 306 MAG SHOULD then send the 64-bit parameter to the MN in a new option 307 (called "Pseudo Home Network Prefix (PHNP)") carried by the RtAdv 308 message. Note that the PHNP MUST be encrypted with THK. 310 In the unlikely event leading to inserting a PHNP option in the RtAdv 311 message, the MN MUST use the 64-bit pseudo-HNP to update the PaT 312 generated from THK. This is done by XORing the 64-bit pseudo-HNP 313 with the PaT in order to enable generating a new pIPv6 when the data 314 packet header is XORed with the updated PaT. 316 It follows from the above, that in order to avoid breaking the MN's 317 anonymity during an NDP exchange between two MNs, the MAG SHOULD also 318 act as the "reference" node for any NDP queries. Such enhancement 319 will enable LiSeND to provide most of features provided by SeND 320 protocol. 322 In order to address merging privacy threats scenarios described 323 earlier, the two mechanisms have to be combined in order to protect 324 the path between the MAG and the LMA and at the same time, the one 325 between the MN and the MAG against malicious eavesdroppings. Doing 326 so provides anonymity and unlinkability features to the MN on the 327 path between the MN to its LMA. This means that the MN's MAG SHOULD 328 apply a PaT when dealing with the corresponding LMA and another one 329 when dealing with the MN in order to mask the MN's HoA or its HNP 330 from each data packet exchanged between the MN and the CN and/or from 331 signaling messages exchanged between the MAG and the LMA. 333 5.4. Future work 335 Future versions of this work will probe further enhancements for the 336 LiSeND protocol and possible stretching of anonymity and 337 unlinkability extensions down to the MAC layer. 339 6. New Option Format 341 TBD 343 7. Security Considerations 345 This document introduces first LiSeND protocol which is a light and 346 CGA free version of SeND protocol. LiSeND is shown to be adapted to 347 the concept of network based mobility where PMIPv6 protocol is a 348 leading candidate. We describe next how key privacy aspects can be 349 build on top of LiSeND in a seamless way which does not affect the 350 MN's unawareness about its mobility. 352 Our proposal relies on sharing a different "privacy key" between the 353 MN and each MAG visited by the mobility unaware MN. For this 354 purpose, and considering the main clients for deploying PMIPv6, we 355 adopt a realistic approach centered around the existence of a AAA 356 infrastructure which will enable the MN to be authenticated upon 357 attachment to foreign network(s). We also consider that the MN is 358 able to derive the corresponding transient handoff key (THK) after 359 each successful authentication. 361 However, in order to avoid sharing the same THK between three 362 different nodes (i.e., MN, LMA and MAG), and in order to enable 363 LiSeND to protect the MN against compromised MAG, we suggest sending 364 a hash of the current THK (H_THK) to the MN's LMA. It follows that 365 each MAG MUST include H_THK in the PBU message sent to the LMA 366 following a successful authentication of the MN. 368 8. References 370 8.1. Normative References 372 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 373 RFC 3792, March 2005. 375 [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 376 for IPv6", RFC 3775, June 2004. 378 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 379 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 380 September 2007. 382 [SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. 383 Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971, 384 March 2005. 386 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 387 Requirement Levels", RFC 2119, BCP , March 1997. 389 8.2. Informative References 391 [ANON] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Patil, 392 B., and H. Tschofenig, "Anonymous Identifiers (ALIEN): 393 Privacy Threat Model for Mobile and Multi-Homed Nodes", 394 Internet Draft, draft-haddad-alien-threat-model-00.txt, 395 January 2007. 397 [PMIPv6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 398 and B. Patil, "Proxy Mobile IPv6", Internet 399 Draft, draft-ietf-netlmm-proxymip6-06.txt, september 2007. 401 [PRITERM] Haddad, W. and E. Nordmark, "Privacy Terminology", 402 Internet 403 Draft, draft-haddad-alien-privacy-terminology-03.txt, 404 October 2007. 406 [TOM] Haddad, W., Naslund, M., and P. Nikander, "IP Tunneling 407 Optimization in a Mobile Environment", Internet- 408 Draft, draft-haddad-mip6-tunneling-optimization-01.txt, 409 July 2007. 411 Authors' Addresses 413 Wassim Haddad 414 Ericsson Research 415 Torshamnsgatan 23 416 SE-164 80 Stockholm 417 Sweden 419 Phone: +46 8 4044079 420 Email: Wassim.Haddad@ericsson.com 422 Suresh Krishnan 423 Ericsson Research 424 8400 Decarie Blvd. 425 Town of Mount Royal, QC 426 Canada 428 Phone: +1 514 345 7900 429 Email: Suresh.Krishnan@ericsson.com 431 Full Copyright Statement 433 Copyright (C) The IETF Trust (2007). 435 This document is subject to the rights, licenses and restrictions 436 contained in BCP 78, and except as set forth therein, the authors 437 retain all their rights. 439 This document and the information contained herein are provided on an 440 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 441 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 442 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 443 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 444 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 445 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 447 Intellectual Property 449 The IETF takes no position regarding the validity or scope of any 450 Intellectual Property Rights or other rights that might be claimed to 451 pertain to the implementation or use of the technology described in 452 this document or the extent to which any license under such rights 453 might or might not be available; nor does it represent that it has 454 made any independent effort to identify any such rights. Information 455 on the procedures with respect to rights in RFC documents can be 456 found in BCP 78 and BCP 79. 458 Copies of IPR disclosures made to the IETF Secretariat and any 459 assurances of licenses to be made available, or the result of an 460 attempt made to obtain a general license or permission for the use of 461 such proprietary rights by implementers or users of this 462 specification can be obtained from the IETF on-line IPR repository at 463 http://www.ietf.org/ipr. 465 The IETF invites any interested party to bring to its attention any 466 copyrights, patents or patent applications, or other proprietary 467 rights that may cover technology that may be required to implement 468 this standard. Please address the information to the IETF at 469 ietf-ipr@ietf.org. 471 Acknowledgment 473 Funding for the RFC Editor function is provided by the IETF 474 Administrative Support Activity (IASA).