idnits 2.17.1 draft-ietf-v6ops-addr-select-req-06.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 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 352. 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 (April 28, 2008) is 5839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-addr-select-ps-05 ** 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: October 30, 2008 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 April 28, 2008 10 Requirements for address selection mechanisms 11 draft-ietf-v6ops-addr-select-req-06.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 October 30, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 There are some problematic cases when using default address selection 45 mechanism which RFC 3484 defines. This document describes additional 46 requirements co-working with RFC3484 to solve the problems. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements of Address Selection . . . . . . . . . . . . . . . 3 52 2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 3 55 2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4 56 2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4 57 2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4 58 2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4 59 2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4 60 2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4 61 2.10. Compatibility and Interoperability with RFC 3484 . . . . . 5 62 2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 3.1. List of threats introduced by new address-selection 65 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. List of recommendations in which security mechanism 67 should be applied . . . . . . . . . . . . . . . . . . . . . 5 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 72 Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 74 Intellectual Property and Copyright Statements . . . . . . . . . . 9 76 1. Introduction 78 Today, the RFC 3484 [RFC3484] mechanism is widely implemented in 79 major OSs. However, in many sites, the default address-selection 80 rules are not appropriate, and cause a communication failure. PS 81 [I-D.ietf-v6ops-addr-select-ps] lists problematic cases that resulted 82 from incorrect address selection. 84 Though RFC 3484 made the address-selection behavior of a host 85 configurable, typical users cannot make use of that because of the 86 complexity of the mechanism and lack of knowledge about their network 87 topologies. Therefore, an address-selection autoconfiguration 88 mechanism is necessary, especially for unmanaged hosts of typical 89 users. 91 This document contains requirements for address-selection mechanisms 92 that enable hosts to perform appropriate address selection 93 automatically. 95 2. Requirements of Address Selection 97 Address-selection mechanisms have to fulfill the following seven 98 requirements. 100 2.1. Effectiveness 102 The mechanism can modify RFC 3484 default address-selection behavior 103 at nodes. As documented in PS [I-D.ietf-v6ops-addr-select-ps], the 104 default rules defined in RFC 3484 do not work properly in some 105 environments. Therefore, the mechanism has to be able to modify 106 address-selection behavior of a host. 108 2.2. Timing 110 Nodes can obtain address selection information when necessary. If 111 nodes need to have address-selection information before performing 112 address selection, then the mechanism has to provide a function for 113 nodes to obtain necessary information beforehand. The mechanism 114 should not degrade usability. The mechanism should not enforce long 115 address-selection processing time upon users. 117 2.3. Dynamic Behavior Update 119 Address-selection behavior of nodes can be dynamically updated. When 120 the network structure changes and address-selection behavior has to 121 be changed accordingly, a network administrator can modify the 122 address-selection behavior of nodes. 124 2.4. Node-Specific Behavior 126 The mechanism can support node-specific address-selection behavior. 127 Even when multiple nodes are on the same subnet, the mechanism should 128 be able to provide a method for the network administrator to make 129 nodes behave differently. For example, each node may have a 130 different set of assigned prefixes. In such a case, the appropriate 131 address-selection behavior may be different. 133 2.5. Application-Specific Behavior 135 The mechanism can support application-specific address-selection 136 behavior or combined use with an application-specific address- 137 selection mechanism such as address-selection APIs. 139 2.6. Multiple Interface 141 The mechanism can support those nodes equipped with multiple 142 interfaces. The mechanism has to assume that nodes have multiple 143 interfaces and makes address selection of those nodes work 144 appropriately. 146 2.7. Central Control 148 The address selection behavior of nodes can be centrally controlled. 149 A site administrator or a service provider could determine or could 150 have effect on address-selection behavior at their users' hosts. 152 2.8. Next-hop Selection 154 The mechanism can control next-hop-selection behavior at hosts or 155 cooperate with other routing mechanisms, such as routing protocols 156 and RFC 4191 [RFC4191]. If the address-selection mechanism is used 157 with a routing mechanism, the two mechanisms have to be able to work 158 synchronously. 160 2.9. Compatibility with RFC 3493 162 The mechanism can allow an application that uses the basic socket 163 interface defined in RFC 3493 [RFC3493] to work correctly. That is, 164 with the basic socket interface the application can select an 165 appropriate source and destination addresses and can communicate with 166 the destination host. This requirement does not necessarily mean 167 that OS protocol stack and socket libraries should not be changed. 169 2.10. Compatibility and Interoperability with RFC 3484 171 The mechanism has compatibility with RFC 3484. Now that RFC 3484 is 172 widely implemented, it may be most preferrable that a new address 173 selection mechanism does not conflict with the address selection 174 mechanisms defined in RFC 3484. 176 If the solution mechanism changes or replaces the address selection 177 mechanism defined in RFC 3484, interoperability has to be retained. 178 That is, a host with the new solution mechanism and a host with the 179 mechanism of RFC 3484 have to be interoperable. 181 2.11. Security 183 The mechanism works without any security problems. Possible security 184 threats are described in Security Considerations section. 186 3. Security Considerations 188 3.1. List of threats introduced by new address-selection mechanism 190 There will be some security incidents when combining these 191 requirements described in Section 2 into a protocol. In particular, 192 there are 3 types of threats, "Leakage","Hijacking", and "Denial of 193 Services". 195 1. Tapping from malicious nodes to collect the network policy 196 information and leak them to unauthorized parties. 197 2. Hijacking of nodes made possible by malicious injection of 198 illegitimate policy information: RFC3484 defines both of source 199 and destination selection algorithm. An attacker able to inject 200 malicious policy information could redirect packets sent by a 201 victim node to an intentionally chosen server that would scan the 202 victim node activities to find out exploit code. Once exploit 203 code is found the attacker can take control of the victim node. 204 3. Denial of Service Attack on the ability of nodes to communicate 205 in the absence of the address selection policy: An attacker could 206 launch a flooding attack on the controller to prevent it to 207 deliver the address selection policy information to nodes, thus 208 preventing these nodes to appropriately communicate in the 209 absence of that information. 211 3.2. List of recommendations in which security mechanism should be 212 applied 214 The source address selection protocol should be afforded security 215 services listed below. It is preferable that these security services 216 are afforded via use of existing protocols(e.g. IPsec). 218 1. Integrity of the network policy information itself and the 219 messages exchanging in the protocol. This is countermeasure 220 against "Leakage", "Hijacking", and "Denial of Services". 221 2. Authentication and authorization of parties involved in the 222 protocol. This is countermeasure against "Leakage" and 223 "Hijacking". 225 4. IANA Considerations 227 This document has no actions for IANA. 229 5. References 231 5.1. Normative References 233 [I-D.ietf-v6ops-addr-select-ps] 234 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 235 "Problem Statement of Default Address Selection in Multi- 236 prefix Environment: Operational Issues of RFC3484 Default 237 Rules", draft-ietf-v6ops-addr-select-ps-05 (work in 238 progress), April 2008. 240 [RFC3484] Draves, R., "Default Address Selection for Internet 241 Protocol version 6 (IPv6)", RFC 3484, February 2003. 243 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 244 Stevens, "Basic Socket Interface Extensions for IPv6", 245 RFC 3493, February 2003. 247 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 248 More-Specific Routes", RFC 4191, November 2005. 250 5.2. Informative References 252 Appendix A. Appendix. Revision History 254 01: 255 Other than policy table distribution approach, the solution 256 section included several solutions discussed at 67th IETF meeting. 257 02: 259 The description and evaluation of solution approaches were 260 separated into a new document called 261 draft-arifumi-v6ops-addr-select-sol-00. 262 03: 263 Security Considerations section was rewritten according to 264 comments from SECDIR. 265 04: 266 A new requirement item "Compatibility with RFC 3493" was added, 267 which reflected a comment from Remi Denis-Courmont at the v6ops 268 mailing list. 269 05: 270 A new requirement item "Security" was added. Security 271 Considerations section was rewritten according to comments from 272 SECDIR. 273 06: 274 A new requirement item "Compatibility and Interoperability with 275 RFC 3484" was added in response to comments from Tim Polk. 277 Authors' Addresses 279 Arifumi Matsumoto 280 NTT PF Lab 281 Midori-Cho 3-9-11 282 Musashino-shi, Tokyo 180-8585 283 Japan 285 Phone: +81 422 59 3334 286 Email: arifumi@nttv6.net 288 Tomohiro Fujisaki 289 NTT PF Lab 290 Midori-Cho 3-9-11 291 Musashino-shi, Tokyo 180-8585 292 Japan 294 Phone: +81 422 59 7351 295 Email: fujisaki@nttv6.net 296 Ruri Hiromi 297 Intec Netcore, Inc. 298 Shinsuna 1-3-3 299 Koto-ku, Tokyo 136-0075 300 Japan 302 Phone: +81 3 5665 5069 303 Email: hiromi@inetcore.com 305 Ken-ichi Kanayama 306 Intec Netcore, Inc. 307 Shinsuna 1-3-3 308 Koto-ku, Tokyo 136-0075 309 Japan 311 Phone: +81 3 5665 5069 312 Email: kanayama@inetcore.com 314 Full Copyright Statement 316 Copyright (C) The IETF Trust (2008). 318 This document is subject to the rights, licenses and restrictions 319 contained in BCP 78, and except as set forth therein, the authors 320 retain all their rights. 322 This document and the information contained herein are provided on an 323 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 324 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 325 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 326 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 327 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 330 Intellectual Property 332 The IETF takes no position regarding the validity or scope of any 333 Intellectual Property Rights or other rights that might be claimed to 334 pertain to the implementation or use of the technology described in 335 this document or the extent to which any license under such rights 336 might or might not be available; nor does it represent that it has 337 made any independent effort to identify any such rights. Information 338 on the procedures with respect to rights in RFC documents can be 339 found in BCP 78 and BCP 79. 341 Copies of IPR disclosures made to the IETF Secretariat and any 342 assurances of licenses to be made available, or the result of an 343 attempt made to obtain a general license or permission for the use of 344 such proprietary rights by implementers or users of this 345 specification can be obtained from the IETF on-line IPR repository at 346 http://www.ietf.org/ipr. 348 The IETF invites any interested party to bring to its attention any 349 copyrights, patents or patent applications, or other proprietary 350 rights that may cover technology that may be required to implement 351 this standard. Please address the information to the IETF at 352 ietf-ipr@ietf.org. 354 Acknowledgment 356 Funding for the RFC Editor function is provided by the IETF 357 Administrative Support Activity (IASA).