idnits 2.17.00 (12 Aug 2021) /tmp/idnits50020/draft-ietf-v6ops-addr-select-req-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 364. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 12, 2008) is 5115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-v6ops-addr-select-ps has been published as RFC 5220 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group A. Matsumoto 3 Internet-Draft T. Fujisaki 4 Intended status: Informational NTT 5 Expires: November 13, 2008 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 May 12, 2008 10 Requirements for address selection mechanisms 11 draft-ietf-v6ops-addr-select-req-07.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 13, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 There are some problematic cases when using the default address 45 selection mechanism which RFC 3484 defines. This document describes 46 additional requirements co-working with RFC 3484 to solve the 47 problems. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements of Address Selection . . . . . . . . . . . . . . . 3 53 2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4 56 2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4 57 2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4 58 2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4 59 2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4 60 2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4 61 2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4 62 2.10. Compatibility and Interoperability with RFC 3484 . . . . . 5 63 2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 3.1. List of threats introduced by new address-selection 66 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. List of recommendations in which security mechanism 68 should be applied . . . . . . . . . . . . . . . . . . . . . 6 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 72 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 Intellectual Property and Copyright Statements . . . . . . . . . . 9 77 1. Introduction 79 Today, the RFC 3484 [RFC3484] mechanism is widely implemented in 80 major OSs. However, in many sites, the default address-selection 81 rules are not appropriate, and cause a communication failure. PS 82 [I-D.ietf-v6ops-addr-select-ps] lists problematic cases that resulted 83 from incorrect address selection. 85 Though RFC 3484 made the address-selection behavior of a host 86 configurable, typical users cannot make use of that because of the 87 complexity of the mechanism and lack of knowledge about their network 88 topologies. Therefore, an address-selection autoconfiguration 89 mechanism is necessary, especially for unmanaged hosts of typical 90 users. 92 This document contains requirements for address-selection mechanisms 93 that enable hosts to perform appropriate address selection 94 automatically. 96 2. Requirements of Address Selection 98 Address-selection mechanisms have to fulfill the following eleven 99 requirements. 101 2.1. Effectiveness 103 The mechanism can modify RFC 3484 default address-selection behavior 104 at nodes. As documented in PS [I-D.ietf-v6ops-addr-select-ps], the 105 default rules defined in RFC 3484 do not work properly in some 106 environments. Therefore, the mechanism has to be able to modify the 107 address-selection behavior of a host, and to solve the problematic 108 cases described in the PS document. 110 2.2. Timing 112 Nodes can perform appropriate address selection when they select 113 addresses. 115 If nodes need to have address-selection information to perform 116 appropriate address selection, then the mechanism has to provide a 117 function for nodes to obtain the necessary information beforehand. 119 The mechanism should not degrade usability. The mechanism should not 120 enforce long address-selection processing time upon users. 121 Therefore, forcing every consumer user to manipulate address 122 selection policy table is usually not an acceptable solution. So, in 123 this case, some kind of autoconfiguration mechanism is desirable. 125 2.3. Dynamic Behavior Update 127 The address-selection behavior of nodes can be dynamically updated. 128 When the network structure changes and the address-selection behavior 129 has to be changed accordingly, a network administrator can modify the 130 address-selection behavior of nodes. 132 2.4. Node-Specific Behavior 134 The mechanism can support node-specific address-selection behavior. 135 Even when multiple nodes are on the same subnet, the mechanism should 136 be able to provide a method for the network administrator to make 137 nodes behave differently. For example, each node may have a 138 different set of assigned prefixes. In such a case, the appropriate 139 address-selection behavior may be different. 141 2.5. Application-Specific Behavior 143 The mechanism can support application-specific address-selection 144 behavior or combined use with an application-specific address- 145 selection mechanism such as address-selection APIs. 147 2.6. Multiple Interface 149 The mechanism can support those nodes equipped with multiple 150 interfaces. The mechanism has to assume that nodes have multiple 151 interfaces and makes address selection of those nodes work 152 appropriately. 154 2.7. Central Control 156 The address selection behavior of nodes can be centrally controlled. 157 A site administrator or a service provider could determine or could 158 have effect on the address-selection behavior at their users' hosts. 160 2.8. Next-hop Selection 162 The mechanism can control next-hop-selection behavior at hosts or 163 cooperate with other routing mechanisms, such as routing protocols 164 and RFC 4191 [RFC4191]. If the address-selection mechanism is used 165 with a routing mechanism, the two mechanisms have to be able to work 166 synchronously. 168 2.9. Compatibility with RFC 3493 170 The mechanism can allow an application that uses the basic socket 171 interface defined in RFC 3493 [RFC3493] to work correctly. That is, 172 with the basic socket interface the application can select 173 appropriate source and destination addresses and can communicate with 174 the destination host. This requirement does not necessarily mean 175 that OS protocol stack and socket libraries should not be changed. 177 2.10. Compatibility and Interoperability with RFC 3484 179 The mechanism is compatible with RFC 3484. Now that RFC 3484 is 180 widely implemented, it may be most preferrable that a new address 181 selection mechanism does not conflict with the address selection 182 mechanisms defined in RFC 3484. 184 If the solution mechanism changes or replaces the address selection 185 mechanism defined in RFC 3484, interoperability has to be retained. 186 That is, a host with the new solution mechanism and a host with the 187 mechanism of RFC 3484 have to be interoperable. 189 2.11. Security 191 The mechanism works without any security problems. Possible security 192 threats are described in Security Considerations section of this 193 document. 195 3. Security Considerations 197 3.1. List of threats introduced by new address-selection mechanism 199 There will be some security incidents when combining these 200 requirements described in Section 2 into a protocol. In particular, 201 there are 3 types of threats, "Leakage", "Hijacking", and "Denial of 202 Services". 204 1. Tapping from malicious nodes to collect the network policy 205 information and leak them to unauthorized parties. 206 2. Hijacking of nodes made possible by malicious injection of 207 illegitimate policy information: RFC 3484 defines both of source 208 and destination selection algorithm. An attacker able to inject 209 malicious policy information could redirect packets sent by a 210 victim node to an intentionally chosen server that would scan the 211 victim node activities to find out exploit code. Once exploit 212 code is found the attacker can take control of the victim node. 213 3. Denial of Service Attack on the ability of nodes to communicate 214 in the absence of the address selection policy: An attacker could 215 launch a flooding attack on the controller to prevent it to 216 deliver the address selection policy information to nodes, thus 217 preventing these nodes to appropriately communicate in the 218 absence of that information. 220 3.2. List of recommendations in which security mechanism should be 221 applied 223 The source address selection protocol should be afforded security 224 services listed below. It is preferable that these security services 225 are afforded via use of existing protocols (e.g., IPsec). 227 1. Integrity of the network policy information itself and the 228 messages exchanged in the protocol. This is a countermeasure 229 against "Leakage", "Hijacking", and "Denial of Services". 230 2. Authentication and authorization of parties involved in the 231 protocol. This is a countermeasure against "Leakage" and 232 "Hijacking". 234 4. IANA Considerations 236 This document has no actions for IANA. 238 5. References 240 5.1. Normative References 242 [I-D.ietf-v6ops-addr-select-ps] 243 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 244 "Problem Statement of Default Address Selection in Multi- 245 prefix Environment: Operational Issues of RFC3484 Default 246 Rules", draft-ietf-v6ops-addr-select-ps-05 (work in 247 progress), April 2008. 249 [RFC3484] Draves, R., "Default Address Selection for Internet 250 Protocol version 6 (IPv6)", RFC 3484, February 2003. 252 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 253 Stevens, "Basic Socket Interface Extensions for IPv6", 254 RFC 3493, February 2003. 256 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 257 More-Specific Routes", RFC 4191, November 2005. 259 5.2. Informative References 261 Appendix A. Appendix. Revision History 263 01: 265 Other than policy table distribution approach, the solution 266 section included several solutions discussed at 67th IETF meeting. 267 02: 268 The description and evaluation of solution approaches were 269 separated into a new document called 270 draft-arifumi-v6ops-addr-select-sol-00. 271 03: 272 Security Considerations section was rewritten according to 273 comments from SECDIR. 274 04: 275 A new requirement item "Compatibility with RFC 3493" was added, 276 which reflected a comment from Remi Denis-Courmont at the v6ops 277 mailing list. 278 05: 279 A new requirement item "Security" was added. Security 280 Considerations section was rewritten according to comments from 281 SECDIR. 282 06: 283 A new requirement item "Compatibility and Interoperability with 284 RFC 3484" was added in response to comments from Tim Polk. 285 07: 286 A couple of textual and typographical changes were made in 287 response to comments from Alfred Hoenes. 289 Authors' Addresses 291 Arifumi Matsumoto 292 NTT PF Lab 293 Midori-Cho 3-9-11 294 Musashino-shi, Tokyo 180-8585 295 Japan 297 Phone: +81 422 59 3334 298 Email: arifumi@nttv6.net 300 Tomohiro Fujisaki 301 NTT PF Lab 302 Midori-Cho 3-9-11 303 Musashino-shi, Tokyo 180-8585 304 Japan 306 Phone: +81 422 59 7351 307 Email: fujisaki@nttv6.net 308 Ruri Hiromi 309 Intec Netcore, Inc. 310 Shinsuna 1-3-3 311 Koto-ku, Tokyo 136-0075 312 Japan 314 Phone: +81 3 5665 5069 315 Email: hiromi@inetcore.com 317 Ken-ichi Kanayama 318 Intec Netcore, Inc. 319 Shinsuna 1-3-3 320 Koto-ku, Tokyo 136-0075 321 Japan 323 Phone: +81 3 5665 5069 324 Email: kanayama_kenichi@intec-si.co.jp 326 Full Copyright Statement 328 Copyright (C) The IETF Trust (2008). 330 This document is subject to the rights, licenses and restrictions 331 contained in BCP 78, and except as set forth therein, the authors 332 retain all their rights. 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 337 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 338 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 339 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Intellectual Property 344 The IETF takes no position regarding the validity or scope of any 345 Intellectual Property Rights or other rights that might be claimed to 346 pertain to the implementation or use of the technology described in 347 this document or the extent to which any license under such rights 348 might or might not be available; nor does it represent that it has 349 made any independent effort to identify any such rights. Information 350 on the procedures with respect to rights in RFC documents can be 351 found in BCP 78 and BCP 79. 353 Copies of IPR disclosures made to the IETF Secretariat and any 354 assurances of licenses to be made available, or the result of an 355 attempt made to obtain a general license or permission for the use of 356 such proprietary rights by implementers or users of this 357 specification can be obtained from the IETF on-line IPR repository at 358 http://www.ietf.org/ipr. 360 The IETF invites any interested party to bring to its attention any 361 copyrights, patents or patent applications, or other proprietary 362 rights that may cover technology that may be required to implement 363 this standard. Please address the information to the IETF at 364 ietf-ipr@ietf.org. 366 Acknowledgment 368 Funding for the RFC Editor function is provided by the IETF 369 Administrative Support Activity (IASA).