Internet Engineering Task Force A. Vives Internet-Draft J. Palet Expires: April 24, 2005 Consulintel P. Savola CSC/FUNET October 24, 2004 IPv6 Security Problem Statement draft-vives-v6ops-ipv6-security-ps-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Today, each network is often secured by a unique device (i.e. security gateway or firewall) that becomes a bottleneck for the end-to-end security model with IPv6. The deployment of IPv6 enabled devices and networks bring some issues, which must be addressed by security administrators in order to guarantee at least the same level Vives, et al. Expires April 24, 2005 [Page 1] Internet-Draft IPv6 Security Problem Statement October 2004 of security that is obtained nowadays with IPv4 and network-based (including perimeter-based) security schemes, allowing at the same time all the IPv6 advantages. The most important issues are the rediscovery of end-to-end communications, the availability of IPsec in all IPv6 stacks, the increase in the number and type of IP devices and also the increase in the number of "nomadic" devices, connecting to different networks that could have different security policies. The security policies and architectures currently applied in Internet with IPv4 do no longer apply for end-to-end security models which IPv6 will need. This document outlines the advantages and drawbacks of both security schemes: network/perimeter-based and distributed. This document aims to identify IPv6 issues that justify the need of a distributed security model for IPv6, that is, simply to show that a security problem will arise with the deployment of IPv6 networks if nothing is done. Vives, et al. Expires April 24, 2005 [Page 2] Internet-Draft IPv6 Security Problem Statement October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Network-based versus Host-based Security . . . . . . . . . . . 5 2.1 Network-based Security . . . . . . . . . . . . . . . . . . 5 2.2 Host-based Security . . . . . . . . . . . . . . . . . . . 7 3. IPv6 Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 End-to-End . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 IPsec-encrypted ESP-traffic in transport mode . . . . . . 11 3.3 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.1 Link-local addresses . . . . . . . . . . . . . . . . . 12 3.4.2 New Multicast addresses . . . . . . . . . . . . . . . 12 3.5 Neighbor Discovery Weakness . . . . . . . . . . . . . . . 13 3.6 Routing Header . . . . . . . . . . . . . . . . . . . . . . 13 3.7 Home Address Option . . . . . . . . . . . . . . . . . . . 13 3.8 Embedded Devices . . . . . . . . . . . . . . . . . . . . . 14 4. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 7.2 Informative References . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 17 Vives, et al. Expires April 24, 2005 [Page 3] Internet-Draft IPv6 Security Problem Statement October 2004 1. Introduction This document will cope only with IPv6 issues related to security, i.e., it will try to answer the following question: How would the deployment of IPv6 affect the security of a network? This network could be a dual-stack network with IPv6 traffic from IPv6 capable nodes, or an IPv6 only network. The deployment of IPv6 enabled devices and networks forces the security administrator to consider several issues: o The rediscovery of end-to-end communications. o The availability of IPsec in all IPv6 stacks. o The increase in the number and type of IP devices. o The increase in the number of "nomadic" devices, connecting and moving between different networks. The security policies and architectures currently applied in Internet with IPv4 no longer apply for end-to-end security models which IPv6 will enable. This document outlines the advantages and drawbacks of both the security schemes: network/perimeter-based and distributed. Also IPv6 issues will be identified that justify the need of distributed security for IPv6, that is, simply to show that a security problem will arise with the deployment of IPv6 networks if traditional schemes are used. The following issues are out of scope of this document and will be addressed elsewhere: o State the security requirements for the described IPv6 scenarios. o Propose a solution or architecture to address the problem stated in this document. o To address security problems derived from the use of transition mechanisms. Last but not least, this document contains a brief definition of what we understand by "security". We use security in the "big scope" of the word, trying to include as much as possible. In other words, a host, a network or some information, will be secure when no attacks could succeed against them. A success will mean compromise of availability, integrity, confidentiality or authenticity. The realistic objective is to be as much secure as possible in a precise Vives, et al. Expires April 24, 2005 [Page 4] Internet-Draft IPv6 Security Problem Statement October 2004 moment. It will be part of the requirements to establish which kind of security is given using a number of mechanisms. For clarity, in the rest of this document, network-based security includes also the perimeter-based model. 2.. Network-based versus Host-based Security In this section two different approaches are analyzed to be used later in the rationale about the security problems that IPv6 could introduce 2.1 Network-based Security This is the most used scheme, where the security of a host depends on the point of the network it is connected to. The perimeter scheme is the simplest one (see Fig. 1) and is based in the topology of the network. The security policy is enforced in a central host or firewall (FW), which provides secure network connectivity to one or more network segments. The FW will be what an "outside" host sees when tries to attack the network. Attacks coming from the same LAN segment are not protected by the FW. Different nodes (even different addresses in the same node) may have different policies. In a more advanced form of perimeter security, the different networks could be protected from each other, or a number of internal firewalls could be used as well. This way some networks could be protected from hosts in other internal network Vives, et al. Expires April 24, 2005 [Page 5] Internet-Draft IPv6 Security Problem Statement October 2004 /-------\ / \ | Internet | \ / \---+---/ | | Policy Enforcement Point +---+---+ LAN-1 | | DMZ-1 ----+---------+ FW +-------+---- | | | | +-+--+ +---+---+ +--+-+ | H1 | | | S1 | +----+ |LAN-2 +----+ | +----+ | | H2 +--+ +----+ | Figure 1: Perimeter Security This model is based on the following assumptions: o The threats come from "outside" the FW, basically the Internet. o Everybody from the same LAN segment is trusted. o The protected nodes won't go "outside" where FW won't be able to protect them. o There are no backdoors on the network (modem, WLAN, other connections). o The hosts will not need to be accessed directly from outside (at least in a general manner, i.e., potentially all ports on all hosts). The main advantage of this scheme is its simplicity and easiness as the elements and points of configuration are reduced to the minimum, requiring few/no protocols and mechanisms to implement the security. In case of a more complex configuration, where multiple FW are deployed within an organization network, the complexity will increase. The drawbacks of this model are: o This is a centralized model: Single point of failure for both Vives, et al. Expires April 24, 2005 [Page 6] Internet-Draft IPv6 Security Problem Statement October 2004 performance and availability. If the FW fails, then all the networks connected to it loose network connectivity unless specific fail-over techniques are applied. o A big percentage of the threats come from inside the FW, and are not addressed by this security model, especially when internal firewalls are not deployed. o The most dangerous threats, in the sense that one may not be able to protect from them, come from inside the FW. o The FW usually acts as NAT and/or proxy box, interfering or even disallowing end-to-end communications. In complex configurations, even more than one level of NAT/proxy could appear. o Transport mode secured communications (using IPsec ESP for example) need special solutions ([1]). o The same security policy may be enforced for all the nodes of each network connected to the FW, but it is also possible to have separate policies for all hosts. In any case, an error in the FW will equally expose all hosts in a network. o Virtual organizations, for example those using GRID models, don't work with traditional centralized security models. o The lack of secure end-to-end prevents innovation. 2.2 Host-based Security Host based security model, already introduced by [2], is based on the idea of enforcing the security policy in each network host from a central control point. The three main elements identified in the distributed security model are: o Policy Specification Language. o Policy Exchange Protocol. o Authentication of Entities. The basic idea is simple: the Security Policy is centrally defined using the Policy Specification Language and distributed to each host by means of the Policy Exchange Protocol. The Network Entities need to be authenticated in order to be trusted, for example to allow an Vives, et al. Expires April 24, 2005 [Page 7] Internet-Draft IPv6 Security Problem Statement October 2004 incoming connection or to trust the received Security Policy. The biggest challenge, however, is trusting that the hosts comply to the rules they've received, for example that the user can't just disable the firewall if (s)he dislike the policy; of course, this only can happen in the case (s)he has administrative rights for that (often not the case in non-personal systems, those not owned by the end user). It seems that one ore more network entities would have to keep watch over the hosts in order to detect if they are not following the received policy. At first look the more appropriated entity seems to be one that knows the security policy, for example the one that distributes it. From a security point of view this model somehow eases the work to the "enemies", putting the Policy Enforcement Point in their hands. So not only mechanisms to prevent direct attacks to the security solution must be developed but mechanisms to minimize the consequences. /-------\ / \ | Internet | +------+ \ / |Sec. | \---+---/ |Policy| | +--+---+ | | /-+-\ | | \ / | LAN-3 -+---+------+ x +-------+-- LAN-1 | (*) | / \ | | (*)Policy Enforcement Point +--+-+ \-+-/ +-+--+ | H1 | | LAN-2 | H3 | +----+ | +----+ | (*) +--+-+ | H2 | +----+ Figure 2: Host-based Security This model is based on the following assumptions: o Each host can be uniquely and securely identified. o The security policy could be applied in one or more of the following levels: network, transport and application. Vives, et al. Expires April 24, 2005 [Page 8] Internet-Draft IPv6 Security Problem Statement October 2004 o The threat comes from anywhere in the network. o The intruder has no physical access to the protected network hosts (what about malicious users? See other topics section). o "Outside" hosts may be able to access all hosts "Inside", depending on the policies. The advantages of this model are: o The security policy can be host-specific. o A host can take better decisions as it knows what it is doing or trying to do, that means it can better detect strange packets. For example, it could allow mail traffic to only one application on the system. o Enables the usage of end-to-end applications level security (e.g., web services security standards). o Enables better protection from attacks by the "internal" users, and possibly even to a degree from those in the local segment. For example address spoofing can be detected and avoided coming from the same LAN segment, without router participation. o Can protect a host independent of the topology, i.e., wherever the host is connected. o Does not need specific devices to secure a host (consider the case of a single host with a CPE, if the CPE had no (user-controllable) firewall functions). o Can control the outgoing attempts from each host, avoiding local network misbehavior or malicious practices. o The collection of audit information could be more complete in a distributed model, despite the processing of that information is done in a distributed or centralized fashion. o It maintains the centralized control of the security policies, from where they are distributed to each host (central decisions, local enforcement). The drawbacks of this model are: o It is more complex than the perimeter one. o The uniqueness and secured identification of hosts is not trivial, Vives, et al. Expires April 24, 2005 [Page 9] Internet-Draft IPv6 Security Problem Statement October 2004 for example using certificates [2]. o The hosts must be trusted (or designed appropriately) so that they will operate according to the policy. For example, it must be impossible to disable the firewall functions or if the policy is not followed network communication is not allowed. o A host that becomes compromised or infected with a worm or virus in any case can't be trusted to operate according to the policies, as the worms/viruses probably first create holes or disable the protections if they can. o It may be challenging to design the system so that policy updates are made available to the nodes which may not be network-reachable all the time. o It may be difficult to distinguish a misbehaving application from a legitimate application (for example, many email worms may be channeled through the MUA which must be authorized to send the mails to operate correctly). 3. IPv6 Issues When IPv6 is deployed, either in an existing IPv4 network or in a new IPv6-only network, the security administrator must take into account that IPv6 traffic will be different from the IPv4. IPv6 enabled nodes will likely have global addresses, which means they may be reachable from any other IPv6 node in the Internet. A security administrator can prevent this by using local addressing and/or firewalls, but the benefits of IPv6 may not be fully realized if so. The differences between IPv4 and IPv6 change the type of attacks which IPv6 networks are likely to see. 3.1 End-to-End As stated in [3], section 6, there is a problem with end-to-end communications, which means that every host should be reachable from any other host, included the ones from "outside". This is a problem in the network-based security model. This kind of communications provides the required framework for further innovation, where technologies like P2P and GRID (among others) can be widely spread with no problems. Vives, et al. Expires April 24, 2005 [Page 10] Internet-Draft IPv6 Security Problem Statement October 2004 In [3] some possible solutions are outlined, one of them being a host firewall. 3.2 IPsec-encrypted ESP-traffic in transport mode As stated in [3], section 5, there is a problem with the IPv6 encrypted traffic (IPsec ESP mechanism in transport mode, for example) and the network-based security model. The idea is that a host inside the network can establish an encrypted communication channel with other host outside of the network, for example. A middlebox (for example the perimeter firewall) won't be able to inspect the content of such a communication.. In [3] some possible solutions are outlined, one of them being a host firewall. 3.3 Mobility In parallel to the increase in the number of devices, IPv6 facilitates that those devices are "mobile", that is, can easily move from one network to another using Mobile IPv6 or just disconnecting from one and connecting to another. Because of the amount of addresses available and the facilities given by Autoconfiguration mechanisms together with the mentioned rise of the number of IP devices, this kind of behavior should be taken into account by the security administrator, as these devices will be connected to networks where they have no control and consequently, no responsibility. A possible solution for these devices is the use of host based security, enabled in every network it is connected. The policies and mechanisms should be described elsewhere. 3.4 Addresses Regarding the addresses in IPv6 must be taken into account that: o The amount of addresses is much bigger for a given network. o Each host will have more than one address which are probably globally routable. o An IPv6 node can use randomly generated addresses [4]. That means: Vives, et al. Expires April 24, 2005 [Page 11] Internet-Draft IPv6 Security Problem Statement October 2004 o To scan a given network whole range of addresses and ports will take a really big effort [5]. It would be easier to do that by sniffing a LAN segment looking for existent addresses. o The common way of identifying a host by means of its IP address will be more difficult to use. o If a host uses randomly generated addresses [4], it could be problematic to identify a host using its IP address for security policy matching purposes. Regarding the scan of addresses, [5] demonstrates that the "brute force" scanning would make no sense for an IPv6 address range, typically a minimum of /64. A host based security scheme would protect the other hosts from the compromised one. The idea behind all this is that the new IPv6 address scheme and mechanisms will somehow protect from existent attack techniques but we can be sure that they will adapt themselves to the new scheme and we have to act consequently being prepared. 3.4.1 Link-local addresses In IPv6 we have got the link-local addresses that allows a host that connects to a network to have IP connectivity without any external help. Even if this is quite useful, also represents a security problem because allows a host to attack the network it is connected to. This must be taken into account by the security administrator. As a guideline, we should not simply rely on trusting by default those sessions which are from link local addresses. It is better to restrict to use link local address to some fundamental services, until the host is trusted. 3.4.2 New Multicast addresses In IPv6 new multicast addresses are defined than identifies resources in a well known manner. This can enable an enemy to locate and attack those key resources with no need of a time consuming address search. This kind of addresses have an scope field. This means that many of such services would have either link-local scope. Note that these addresses are used for the protocol itself, for example in the Vives, et al. Expires April 24, 2005 [Page 12] Internet-Draft IPv6 Security Problem Statement October 2004 autoconfiguration process. This kind of addresses must be taken into account by a security solution that addresses inside attacks. There are also global-scope addresses that must be published to the outside. This kind of services must be protected and monitored by a security solution that addresses outside attacks. For an updated IPv6 multicast addresses list see [6]. 3.5 Neighbor Discovery Weakness As said above, one of the assumptions of the host-based security model is that all hosts in the network are non trusted, the possible threats coming from the same LAN segment must be taken into account, in this case the ones coming from Neighbor Discovery (ND) [7][8]. Note that this is not possible within the perimeter security model, although some detection mechanism could be implemented, nothing can be done to protect the hosts. There are some ways to interfere in the normal behavior of the autoconfiguration process, causing redirection of traffic and/or DoS (Denial of Service). Special attention must be put on Router Advertisement (RA), Router Solicitation (RS), Neighbor Solicitation (NS), Neighbor Advertisement (NA) and Redirect messages. See [9] for a detailed explanation of possible threats. Using host firewalls and/or IDS (Intrusion Detection Systems) for protecting hosts against these threats is very likely a wrong approach, as that would basically imply reinventing SEND; it is better to use SEND instead [10][11]. There is no easy protection against these threats as the ND features (e.g., using link-local or the unspecified addresses) are needed before a host can authorize itself to the other network components. 3.6 Routing Header TBD. 3.7 Home Address Option TBD. Vives, et al. Expires April 24, 2005 [Page 13] Internet-Draft IPv6 Security Problem Statement October 2004 3.8 Embedded Devices With the deployment of IPv6 we can expect the avenue of a big amount of new IPv6-enabled devices with few resources, low computing capacity, even low battery capacity. In some cases, this kind of devices will not be able even to perform the minimum set of functions required by the Host-based Security Model. This should be taken into account when the security requirements are outlined and by the proposed solutions. 4. Other Issues Further elaboration is required (TBD) on: o Malicious users: We can't protect the network from malicious users that have physical access to network hosts in the protected network. The objective is to minimize the danger they can cause. o In the host-based security, the host that stores and distributes the security policies seems to be the best option to be the one that acts as IDS. 5. Security Considerations This document is concerned entirely with security. 6. Acknowledgements The authors would like to acknowledge the inputs of Brian Carpenter, Satoshi Kondo and the European Commission support in the co-funding of the Euro6IX project, where this work is being developed. 7. References 7.1 Normative References 7.2 Informative References [1] "IETF midcom WG", . [2] Bellovin, S., "Distributed Firewalls", November 1999, . [3] Savola, P., "Firewalling Considerations for IPv6", draft-savola-v6ops-firewalling-02 (work in progress), October Vives, et al. Expires April 24, 2005 [Page 14] Internet-Draft IPv6 Security Problem Statement October 2004 2003. [4] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [5] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", draft-chown-v6ops-port-scanning-implications-01 (work in progress), July 2004. [6] "IANA's IPv6 Multicast Addresses List", . [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [8] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [9] Nikander, P., "IPv6 Neighbor Discovery trust models and threats", draft-ietf-send-psreq-04 (work in progress), October 2003. [10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 (work in progress), July 2004. [11] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-06 (work in progress), April 2004. Authors' Addresses Alvaro Vives Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: alvaro.vives@consulintel.es Vives, et al. Expires April 24, 2005 [Page 15] Internet-Draft IPv6 Security Problem Statement October 2004 Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: jordi.palet@consulintel.es Pekka Savola CSC/FUNET Espoo Finland EMail: psavola@funet.fi Vives, et al. Expires April 24, 2005 [Page 16] Internet-Draft IPv6 Security Problem Statement October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vives, et al. Expires April 24, 2005 [Page 17]