Network Working Group S. Yamamoto Internet-Draft C. Williams Expires: September 7, 2006 KDDI R&D Labs F. Parent H. Yokota KDDI R&D Labs March 6, 2006 Security Considerations for Softwire draft-yamamoto-v6tc-security-considerations-01 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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses the security requirements of softwire. Authentication, integrity and confidentiality of the softwire control and data packets are discussed. Both hub and spokes and mesh solutions are discussed. Yamamoto, et al. Expires September 7, 2006 [Page 1] Internet-Draft Softwire security considerations March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Softwire Security Requirements . . . . . . . . . . . . . . . . 3 3.1. Hub and Spokes . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Authentication requirements . . . . . . . . . . . . . . . . . . 5 5. IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Yamamoto, et al. Expires September 7, 2006 [Page 2] Internet-Draft Softwire security considerations March 2006 1. Introduction The softwire working group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6-only networks and IPv6 networks across IPv4-only networks. Two deployment scenarios were identified: "Hubs and spokes" and "Mesh" [I-D.softwire-problem-statement]. This document defines the security requirements based on the softwire problem statement, and specify the required security mechanism for softwire. Author Note: The softwire solution for both Hubs and Spokes and Mesh are to defined in framework documents which are currently work-in- progress. This document is thus incomplete and will evolve as the framework documents progress. 2. Terminology The terminology is based on the softwire problem statement document [I-D.softwire-problem-statement] Softwire Concentrator (SC) - The node terminating the softwire in the service provider network. Softwire Initiator (SI) - The node initiating the softwire within the customer network. Softwire Transport Header AF (STH AF) - the address family of the outermost IP header of a softwire. Softwire Payload Header AF (SPH AF) - the address family of the IP headers being carried within a softwire. Note that additional "levels" of IP headers may be present if (for example) a tunnel is carried over a softwire - the key attribute of SPH AF is that it is directly encapsulated within the softwire and the softwire endpoint will base forwarding decisions on the SPH AF when a packet is exiting the softwire. 3. Softwire Security Requirements Softwire can be used to connect IPv4 networks across public IPv6 networks and IPv6 networks across public IPv4 networks. The control and data packets used during the softwire session are vulnerable to attack. Yamamoto, et al. Expires September 7, 2006 [Page 3] Internet-Draft Softwire security considerations March 2006 A complete threat analysis of softwire requires examination of the protocols used for the for the softwire setup, the encapsulation method used to transport the payload, and other protocols used for configuration (e.g., router advertisements, DHCP). Threat analysis done for other protocols L2TP using IPsec [RFC3193], PANA [RFC4016], NSIS [RFC4081], [I-D.rpsec-routing-threats] are applicable here as well and should be used as reference. Examples of attacks on softwire include: 1. An adversary may try to discover 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 softwire tunnel. 4. An adversary can launch denial of service attacks by terminating softwire created tunnels. 5. An adversary may attempt to disrupt the softwire negotiation in order to weaken or remove confidentiality protection. 6. An adversary may impersonate the softwire concentrator to intercept traffic ("rogue" softwire concentrator). 7. to be completed... The following sections describe differences between the hub and spokes and the mesh solutions which are important to consider with respect to security considerations. 3.1. Hub and Spokes o Softwire is always initiated from the client side o Initiator can be a host, appliance, sensor, etc. (not necessarily a human being) o Must support roaming. Initiator may connect from a visiting (untrusted) network o Yamamoto, et al. Expires September 7, 2006 [Page 4] Internet-Draft Softwire security considerations March 2006 3.2. Mesh o Mesh scenario consists of routers (AFBRs) advertising routes for relatively large network islands. There is no softwire concentrator, as in the hub and spoke scenario. o Used inside a provider network. No "roaming". o Authentication must be supported, but may be deactivated. This authentication is done between AFBRs. There is no user authentication, as in the hub and spoke scenario. The following softwire requirements are not covered in this document yet (with respect to security): service discovery, scaling, routing and multicast. 4. Authentication requirements The requirements defined in the problem statement state that authentication MUST be supported, but mutual authentication and no authentication SHOULD be possible. 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 whereby ISPs will likely not use authentication for their own users, but instead rely on IP-address based filtering. In addition, the non-authenticated mode relies on security of provider network; otherwise, the softwire concentrator (Hubs and Spokes scenario) will be open to a variety of DoS attacks. The non- authenticated mode must be intra-provider only deployment. 5. IPSec Although the softwire framework documents are not yet completed, IPsec is already mentioned as must support in the problem statement. [I-D.bellovin-useipsec] gives guidelines on what authors should describe with respect to mandating IPsec. The question list that follows is taken literally from that document. Author note: To be completed based on "Hubs and Spokes" and "Mesh" frameworks. Point out differences (e.g., user authentication) Yamamoto, et al. Expires September 7, 2006 [Page 5] Internet-Draft Softwire security considerations March 2006 1. What selectors the initiator of the conversation (the client, in client-server architectures) should use? What addresses, port numbers, etc., are to be used? 2. What IPsec protocol is to be used: AH or ESP? What mode is to be employed: transport mode or tunnel mode? 3. What form of key management is appropriate? 4. What security policy database entry types should be used by the responder (i.e., the server) when deciding whether or not to accept the IPsec connection request? 5. What form of identification should be used? Choices include IP address, DNS name, and X.500 distinguished name. 6. What form of authentication should be used? Choices include pre- shared secrets, certificates, and (for IKEv2) an EAP exchange [RFC2284]. 7. Which of the many variants of IKE must be supported? Main mode? Aggressive mode? 8. Is suitable IPsec support available in likely configurations of the products that would have to employ IPsec? 6. Acknowledgements 7. References 7.1. Normative References [I-D.softwire-problem-statement] Li, X., Durand, A., Ward, D., and S. Dawkins, "Softwire Problem Statement", draft-ietf-softwire-problem-statement-01 (work in progress), February 2006. 7.2. Informative References [I-D.bellovin-useipsec] Bellovin, S., "Guidelines for Mandating the Use of IPsec", draft-bellovin-useipsec-03 (work in progress), March 2004. [I-D.rpsec-routing-threats] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Yamamoto, et al. Expires September 7, 2006 [Page 6] Internet-Draft Softwire security considerations March 2006 Routing Protocols", draft-ietf-rpsec-routing-threats-07 (work in progress), October 2005. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, March 2005. [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005. Yamamoto, et al. Expires September 7, 2006 [Page 7] Internet-Draft Softwire security considerations March 2006 Authors' Addresses Shu Yamamoto KDDI R&D Labs 2-1-15 Fujimino-shi Saitama, 356-8502 Japan Phone: 81 (49) 278-7311 Email: shu@kddilabs.jp Carl Williams KDDI R&D Labs Palo Alto, CA 94301 USA Phone: +1.650.279.5903 Email: carlw@mcsr-labs.org Florent Parent Phone: Email: Florent.Parent@mac.com Hidetoshi Yokota KDDI R&D Labs 2150 Ohara Saitama, 356-8502 Japan Phone: 81 (49) 278-7894 Email: yokota@kddilabs.jp Yamamoto, et al. Expires September 7, 2006 [Page 8] Internet-Draft Softwire security considerations March 2006 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 (2006). 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 September 7, 2006 [Page 9]