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