--- 1/draft-ietf-v6ops-addr-select-req-04.txt 2008-03-11 22:12:32.000000000 +0100 +++ 2/draft-ietf-v6ops-addr-select-req-05.txt 2008-03-11 22:12:32.000000000 +0100 @@ -1,21 +1,21 @@ IPv6 Operations Working Group A. Matsumoto Internet-Draft T. Fujisaki Intended status: Informational NTT -Expires: May 9, 2008 R. Hiromi +Expires: September 7, 2008 R. Hiromi K. Kanayama Intec Netcore - November 6, 2007 + March 6, 2008 Requirements for address selection mechanisms - draft-ietf-v6ops-addr-select-req-04.txt + draft-ietf-v6ops-addr-select-req-05.txt 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 @@ -26,78 +26,66 @@ 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 on May 9, 2008. + This Internet-Draft will expire on September 7, 2008. Copyright Notice - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). Abstract - In a multi-prefix environment, nodes could have multiple addresses on - one network interface. RFC 3484 defines a source and destination - address-selection algorithm, which is commonly deployed in current - popular OSs. However, nodes could encounter some difficulties in - network communication when they use default address selection rules - defined in RFC 3484. Some mechanisms for solving address-selection - problems are proposed including the RFC 3484 policy table - distribution and ICMP error-based mechanisms. This document - describes requirements for these address-selection mechanisms. + There are some problematic cases when using default address selection + mechanism which RFC 3484 defines. This document describes additional + requirements co-working with RFC3484 to solve the problems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements of Address Selection . . . . . . . . . . . . . . . 3 2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4 + 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 3 2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4 2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4 2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4 2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4 2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4 2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4 + 2.10. Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 3.1. List of threats introduced by new address-selection mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. List of recommendations in which security mechanism should be applied . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . . . 8 1. Introduction - One physical network can have multiple logical networks. In that - case, an end-host has multiple IP addresses. (e.g., in the IPv4-IPv6 - dual-stack environment, in a site that uses both ULA [RFC4193] and - global scope addresses or in a site connected to multiple upstream - IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default - address-selection rules for the source and destination addresses. - - Today, the RFC 3484 mechanism is widely implemented in major OSs. - However, we and others have found that in many sites the default - address-selection rules are not appropriate for the network - structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic - cases that resulted from incorrect address selection. + Today, the RFC 3484 [RFC3484] mechanism is widely implemented in + major OSs. However, in many sites, the default address-selection + rules are not appropriate, and cause a communication failure. PS + [I-D.ietf-v6ops-addr-select-ps] lists problematic cases that resulted + from incorrect address selection. Though RFC 3484 made the address-selection behavior of a host configurable, typical users cannot make use of that because of the complexity of the mechanism and lack of knowledge about their network topologies. Therefore, an address-selection autoconfiguration mechanism is necessary, especially for unmanaged hosts of typical users. This document contains requirements for address-selection mechanisms that enable hosts to perform appropriate address selection @@ -170,118 +158,110 @@ 2.9. Compatibility with RFC 3493 The mechanism can allow an application that uses the basic socket interface defined in RFC 3493 [RFC3493] to work correctly. That is, with the basic socket interface the application can select an appropriate source and destination addresses and can communicate with the destination host. This requirement does not necessarily mean that OS protocol stack and socket libraries should not be changed. +2.10. Security + + The mechanism works without any security problems. Possible security + threats are described in Security Considerations section. + 3. Security Considerations 3.1. List of threats introduced by new address-selection mechanism - There are some security incidents when combining these requirements - described in Section 2 into a protocol. In particular, here are six - possible threats. + There will be some security incidents when combining these + requirements described in Section 2 into a protocol. In particular, + there are 3 types of threats, "Leakage","Hijacking", and "Denial of + Services". - 1. Hijacking or tapping from malicious nodes connecting from beyond - unapproved network boundaries. - 2. Malicious changing of policy data by nonapproved nodes. - 3. Denial of Service Attack due to higher traffic volume, and - blocked communication, for example, at both node and network - caused by sending unsafe and tampered data from unbidden - controller. - 4. Attempt to stop service on node/computer resources caused by - unnecessary communication between the controller and nodes. - 5. Intrusion into security boundary caused by malicious use of - multiprefix environment. - 6. Leakage of network policy information from central controller. + 1. Tapping from malicious nodes to collect the network policy + information and leak them to unauthorized parties. + 2. Hijacking of nodes made possible by malicious injection of + illegitimate policy information: RFC3484 defines both of source + and destination selection algorithm. An attacker able to inject + malicious policy information could redirect packets sent by a + victim node to an intentionally chosen server that would scan the + victim node activities to find out exploit code. Once exploit + code is found the attacker can take control of the victim node. + 3. Denial of Service Attack on the ability of nodes to communicate + in the absence of the address selection policy: An attacker could + launch a flooding attack on the controller to prevent it to + deliver the address selection policy information to nodes, thus + preventing these nodes to appropriately communicate in the + absence of that information. 3.2. List of recommendations in which security mechanism should be applied - All the methods listed below should be well-considered for protecting - against security threats. There is no necessity to comply with all - items at same time, if one or more spec(s) could apply to other - security requirements. Secure network operation will also be - considered, and describing network operation for network security - will be better. Referring to and using existing technologies is also - preferable. - - 1. Consideration of the necessity to use digitally signed or - cryptographic messages. - 2. Consideration of the necessity to maintain confidentiality of - source of policy data. - 3. Consideration of the necessity of authentication and validation - of both entity and message integrity. - 4. Consideration of the necessity of having a mechanism for the - avoidance of data conflicts if the policy data comes from - multiple controllers. + The source address selection protocol should be afforded security + services listed below. It is preferable that these security services + are afforded via use of existing protocols(e.g. IPsec). - 5. Consideration of the necessity of an appropriate filtering method - at domain boundaries. - 6. Consideration of the necessity of data independency at every node - or every interface for avoidance of mixing multiple policy data. - 7. Consideration of the necessity of having a mechanism for - controlling policy and all related network information on the - server if the server stores policy and all related neetowrk - information on the outside of its network domain. - 8. Consideration of the necessity to log and collect related system - data. + 1. Integrity of the network policy information itself and the + messages exchanging in the protocol. This is countermeasure + against "Leakage", "Hijacking", and "Denial of Services". + 2. Authentication and authorization of parties involved in the + protocol. This is countermeasure against "Leakage" and + "Hijacking". 4. IANA Considerations This document has no actions for IANA. 5. References 5.1. Normative References [I-D.ietf-v6ops-addr-select-ps] - Matsumoto, A., "Problem Statement of Default Address - Selection in Multi-prefix Environment: Operational Issues - of RFC3484 Default Rules", - draft-ietf-v6ops-addr-select-ps-02 (work in progress), - October 2007. + Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, + "Problem Statement of Default Address Selection in Multi- + prefix Environment: Operational Issues of RFC3484 Default + Rules", draft-ietf-v6ops-addr-select-ps-04 (work in + progress), February 2008. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. -5.2. Informative References - [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. - [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", RFC 4193, October 2005. +5.2. Informative References Appendix A. Appendix. Revision History + 05: + A new requirement item "Security" was added. Security + Considerations section was rewritten according to comments from + SECDIR. 04: - A new requirement item "Compatibility with RFC 3493" was added, which reflected a comment from Remi Denis-Courmont at the v6ops mailing list. 03: - Security Consideration section was rewritten according to comments - from SECDIR. + Security Considerations section was rewritten according to + comments from SECDIR. 02: The description and evaluation of solution approaches were separated into a new document called draft-arifumi-v6ops-addr-select-sol-00. 01: + Other than policy table distribution approach, the solution section included several solutions discussed at 67th IETF meeting. Authors' Addresses Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan @@ -310,21 +291,21 @@ Intec Netcore, Inc. Shinsuna 1-3-3 Koto-ku, Tokyo 136-0075 Japan Phone: +81 3 5665 5069 Email: kanayama@inetcore.com Full Copyright Statement - Copyright (C) The IETF Trust (2007). + 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