Tunnel Configuration (TC) S. Yamamoto Internet-Draft H. Yokota Expires: January 11, 2006 C. Williams KDDI R&D Labs F. Parent Hexago July 10, 2005 Security Considerations for the Tunnel Broker Model draft-yamamoto-v6tc-security-considerations-00.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 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 January 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Tunnel brokers must implement protections against a wide variety of threats. This draft discusses the security considerations for a configured tunneling configuration mechanism such as that described by the Tunnel Broker. The emphasis in this document is on protocol-related security issues. Yamamoto, et al. Expires January 11, 2006 [Page 1] Internet-Draft Security Considerations for the Tunnel Broker Model July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Tunnel Configuration (TC) Security Requirements . . . . . . . 4 4. Security considerations for non-authenticated mode . . . . . . 4 5. Security considerations for authenticated mode . . . . . . . . 5 6. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Signalling . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2 Data path . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1 Normative references . . . . . . . . . . . . . . . . . . . 6 7.2 Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Yamamoto, et al. Expires January 11, 2006 [Page 2] Internet-Draft Security Considerations for the Tunnel Broker Model July 2005 1. Introduction The transition period from IPv4 to IPv6 will span a decade or more and is still in its early stags. A major impediment is the high cost and technical complexity to move complete network cores, servers and applications to dual stack and the perspective of Return on Investment. The Tunnel Broker model is specifically designed to break this logjam, by enabling IPv6 anywhere in an enterprise network without a major upgrade of the infrastructure. TSP (Tunneling Setup Protocol) is an implementation of the Tunnel Broker. TSP is a signalling protocol specifically designed to enhance and add flexibility to the IPv6 transition mechanisms defined by the IETF. The protocol is used by the server and client to perform specific operations. Various security threats are introduced with these set of signalling operations. The operations by TSP are as follows: 1. exchange their capabilities (i.e., security, IPv4, IPv6, etc) 2. authenticate the client 3. request and delegate IPv6 addresses to the client 4. request and delegate IPv6 prefixes to the client and its networks 5. register AAAA, PTR and NS records in the DNS 6. traverse one or many IPv4 NAT in the path between the client and the broker 7. maintain a permanent IPv6 address even when the IPv4 address changes It is the purpose of this document to provide security threat analysis to this tunnel configuration model. This includes operational security issues as a result of deployment. 2. Terminology Tunnel Broker - The TB is the place where the user connects to register and activate tunnels. The TB manages tunnel creation, modification and deletion on behalf of the user. Tunnel Server - A TS is a dual-stack (IPv4 & IPv6) routing entity connected to the global Internet. Upon receipt of a configuration order coming from the TB, it creates, modifies or deletes the server side of each tunnel. It may also maintain usage statistics for every Yamamoto, et al. Expires January 11, 2006 [Page 3] Internet-Draft Security Considerations for the Tunnel Broker Model July 2005 active tunnel. 3. Tunnel Configuration (TC) Security Requirements Tunnel broker is a mechanism that includes a tunnel setup protocol to tunnel IPv6 in IPv4 packets (as an example) from a dual-stack client to a Tunnel server somewhere in the network. Both the control and data packets of the Tunnel Broker model are vulnerable to attack. An example of a tunnel broker implementation is the TSP protocol. We will use the term Tunneling Configuration (TC) as a generic protocol mechanisms that implements the Tunnel Broker model. TSP then would be an instance of the TC protocol. Examples of attacks include: 1. An adversary may try to discover user identities by snooping data packets. 2. An adversary may try to modify packets (both control and data). 3. An adversary may try to hijack the IPv6 in IPv4 tunnel. 4. An adversary can launch denial of service attacks by terminating TSP created tunnels. 5. An adversary may attempt to disrupt the user negotiation with the tunnel broker in order to weaken or remove confidentiality protection. Alternatively, an adversary may wish gain access to user passwords. 6. An adversary may impersonate the Tunnel broker to intercept traffic ("rogue" tunnel broker). To address these threats, the Tunneling Configuration (TC) security protocol MUST be able to provide authentication, integrity and replay protection for control packets. In addition, it SHOULD be able to protect confidentiality for control packets. It MUST be able to provide integrity and replay protection of data packets, and MAY be able to protect confidentiality of data packets. An Tunneling Configuration (TC) security protocol MUST also provide a scalable approach to key management. 4. Security considerations for non-authenticated mode Assisted tunneling can be provided in two different modes, a simple mode, unauthenticated, as well as an authenticated mode aimed at production deployment. The non-authenticated mode relies "out-of-band" authentication; for example, the IP source address. Or in the case where we global unique IPv4 addresses are not used, an NAI of some sort may also be used. This is the deployment case Yamamoto, et al. Expires January 11, 2006 [Page 4] Internet-Draft Security Considerations for the Tunnel Broker Model July 2005 whereby ISPs will likely not use authentication for their own users, but instead rely on IP-address based filtering. There are various well-known attacks as a result. In addition, the non-authenticated mode relies on security of provider network; otherwise, the Tunnel Broker will be open to a variety of DoS attacks. For instance, in TSP anonymous mode, one can filter TSP requests to his own autonomous system. This is really just a management function, not related to the TSP protocol itself but an operation security consideration none the less. Finally, the non-authenticated mode must be intra-provider only deployment. Here again, because of the out-of-band authentication both the client and the tunnel broker are suspectible to DoS and man in the middle attacks. 5. Security considerations for authenticated mode User authentication will most likely be dominant in deployments. User authentication requires the user and the ISP have to set up some kind of authentication to ensure that nobody else can hijack the tunnel. Using the authenticated mode allows you to always keep the same IPv6 address and prefix, even if your IPv4 address changes. Areas of security requirements and/or issues specific to authenticated mode are: - user authentication prior to tunnel establishment In Authentication mode the Tunnel Configuration (TC) scheme assumes that the endpoints are already known and authenticated prior to tunnel establishment. As a result, any user with access to one of the endpoint machines can use the tunnel. If connecting to an untrusted tunnel broker is a concern, mutual authentication is necessary. - user "owns" IPv6 address/prefix (broker database) Here the protocol must be able to support servers willing to offer stable IPv6 prefixes to the authenticated customers. - User authentication must be compatible with methods generally deployed (RADIUS) The authentication mechanism supported should be compatible with standardized methods that are generally deployed. In order to assure interoperability, at least one common authentication method must be supported. Other authentication may be supported and should be negotiated between the client and server. Yamamoto, et al. Expires January 11, 2006 [Page 5] Internet-Draft Security Considerations for the Tunnel Broker Model July 2005 6. Security Threats This section details the different areas of security threats 6.1 Signalling User authentication must be protected. If data in signalling is considered sensitive (ex: IP address?) signaling must be protected (encrypted). Encryption should be used when the plaintext password is needed and sent as part of the session management protocol, such as when using the password to register with the tunnel broker. 6.2 Data path The data path is defined to be the tunnel itself as compared to the signaling. If tunnel data is to be protected, the tunnel broker should allow the use of security on the tunnel. For example, IPsec over IPv6 should be possible. This is a requirement for those roaming users outside of a protected domain (i.e., enterprise users) that will need to tunnel back into the protected domain from an untrusted access network. 7. References 7.1 Normative references [1] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [2] Huitema, C., Austein, R., Satapati, S. and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2 Informative References [4] Parent, F., "Goals for Registered Assisted Tunneling", Internet-Draft draft-ietf-v6ops-assisted-tunneling-requirements-01 , October 2004. [5] Palet, J., "Goals for Tunneling Configuration", Internet-Draft draft-palet-v6tc-goals-tunneling-00, February 2005. [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461 , December 1998. Yamamoto, et al. Expires January 11, 2006 [Page 6] Internet-Draft Security Considerations for the Tunnel Broker Model July 2005 [7] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC3056 , Feb. 2001. Authors' Addresses Shu Yamamoto KDDI R&D Labs Kamifukuoka-Shi Saitama 356-8502 Japan Phone: 81 (49) 278-7894 Email: shu@kddilabs.jp Hidetoshi Yokota KDDI R&D Labs Kamifukuoka-Shi Saitama 356-8502 Japan Phone: 81 (49) 278-7894 Email: yokota@kddlabs.co.jp Carl Williams KDDI R&D Labs Palo Alto, CA 94301 USA Phone: +1.650.279.5903 Email: carlw@mcsr-labs.org Florent Parent Hexago 2875 boul. Laurier, Suite 300 Sainte-Foy, QC GIV 2M2 94301 Canada Email: florent.parent@hexago.com Yamamoto, et al. Expires January 11, 2006 [Page 7] Internet-Draft Security Considerations for the Tunnel Broker Model July 2005 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. Yamamoto, et al. Expires January 11, 2006 [Page 8] Internet-Draft Security Considerations for the Tunnel Broker Model July 2005 Copyright Statement Copyright (C) The Internet Society (2005). 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. Yamamoto, et al. Expires January 11, 2006 [Page 9]