Network Working Group Y. Cui Internet-Draft J. Dong Intended status: Standards Track Tsinghua University Expires: April 18, 2011 Dayong. Guo Huawei Technologies Co., Ltd October 15, 2010 pcp subscriber identification draft-cui-pcp-subscriber-identification-00 Abstract This document analyzes on PCP security problems related with subscriber identification, such as denial-of-service(DoS), unwanted deleting of mappings, man-in-the-middle(MITM), and stale mapping problem. Then several solutions are proposed. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 18, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Cui, et al. Expires April 18, 2011 [Page 1] Internet-Draft pcp subscriber identification October 2010 described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security problem analysis of PCP separated scenario . . . . . 4 2.1. DoS attacking with address spoofing . . . . . . . . . . . 4 2.2. Unwanted Deleting of Mappings . . . . . . . . . . . . . . 4 2.3. MITM attack . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Stale Mappings . . . . . . . . . . . . . . . . . . . . . . 4 3. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Authentication model for PCP . . . . . . . . . . . . . . . 5 3.2. Random number . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Safe tunnel negotiation . . . . . . . . . . . . . . . . . 6 3.4. Digit signature . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Cui, et al. Expires April 18, 2011 [Page 2] Internet-Draft pcp subscriber identification October 2010 1. Introduction PCP is primarily designed to be implemented in the context of large scale NAT deployments. It offers the ability to configure a port forwarding capability in Service Provider NATs. In a Service Provider case, subscriber identification and security are two of the important features. It's the basic of providing port service and accounting. In Section 8.3 Subscriber Identification of current PCP protocol[I-D.draft-wing-softwire-port-control-protocol], PCP server uses IP address or prefix to identify PCP subscribers. However, PCP is a lightweight protocol and no connection is required to be maintained between the Client and the Server. It's very easy to create a fake IP address in many cases, so PCP server could not differentiate between legitimate requests and fake requests. Due to these reasons, ISPs need more reliable technology to enhance the security. Generally in ISP networks, Broadband Network Gateway(BNG), aka Broadband Remote Access Server, provides the access authentication for subscribers. The BNG can identify by means of subscribers information besides IP address, for example MAC address, Circuit ID of access device which subscribers are attached to [RFC3046], etc. If PCP server is embedded into BNG, it can identify a PCP client with the information provided by BNG. In this case, PCP operations have high security. However, PCP server is usually coupled with Service Provider NAT rather than BNG. When PCP server is separated from BNG, it can only identify PCP client by IP address, which may cause significant security problems. This document mainly focuses on the security problems in the separated scenario and methods on how to solve these problems. Cui, et al. Expires April 18, 2011 [Page 3] Internet-Draft pcp subscriber identification October 2010 2. Security problem analysis of PCP separated scenario PCP is a simple protocol based on UDP. It achieves its purpose by one simply request/response procedure. In separated scenario, these steps are vulnerable to denial-of-service (DoS), unwanted deleting of mappings, man-in-the-middle(MITM), and have stale mapping problem. 2.1. DoS attacking with address spoofing Section 11.4 of PCP recommends IPv6 source address validation to protect against creating unwanted mappings. However, an adversary can flood the PCP requests with bogus source address, which satisfies the validation rules, to cause DoS attacks exhausting mapping resources. PCP server will allocate mappings for these illegal requests. The limited mapping resources will soon be exhausted, causing legitimate subscribers not having available resources. 2.2. Unwanted Deleting of Mappings In PCP, requests with internal IP address and lifetime set to zero are used to delete all mappings of a subscriber. An adversary can flood the PCP requests with bogus source address deleting legitimate mappings. By trying a large number of source addresses, an adversary may successfully delete some legitimate mappings. This kind of attack will disrupt the normal PCP uses. 2.3. MITM attack An adversary may try to eavesdrop and collect PCP requests. The normal request message contains some internal port numbers the PCP client wants to request. Adversary may increase a large number of fake internal ports and replay these requests. Then PCP server has to allocate some additional mappings that are unnecessary. If a large number of PCP requests are modified, the mapping resources would be exhausted. On the other way, by setting the lifetime and internal address to zero, an adversary may successfully delete some mappings to disrupt normal PCP uses. 2.4. Stale Mappings Section 11.6 of [I-D.wing-softwire-port-control-protocol] has described this problem. Cui, et al. Expires April 18, 2011 [Page 4] Internet-Draft pcp subscriber identification October 2010 3. Possible solutions This section will introduce several possible solutions to authenticate legitimate clients. According to different operating environment, ISPs could choose different method. 3.1. Authentication model for PCP User name and password of a subscriber can be used to enhance PCP security. As shown in figure 1, PCP client sends request message with an extended Informational Element(IE) including user name and password to the PCP server. Then PCP server, as an AAA client, authenticates with AAA server via Diameter[RFC3588]/Radius protocol[RFC2865]. Only when the authentication succeeds can the PCP server start to allocate mappings to PCP client. +---------+ | | | AAA | | server | +---------+ | | | | +---------+ +---------+ +----------+ | PCP | | PCP | | | | client |----------| server |-------------| Internet | | | | | | | +---------+ +---------+ +----------+ Figure 1: Authentication model With the adoption of the user name and password identification procedure, the DoS attack, unwanted mapping deleting and stale mapping problem can be well defended against. This procedure doesn't change the original PCP procedure for there are no new steps. However, it adds AAA procedure. 3.2. Random number With this method, when PCP server receives a PCP request from a subscriber for the first time, it will reply an Error Response with a random number without allocating mappings to the PCP client. The random number can be contained in an IE. When a PCP client receives this response with random number, it will resend another PCP request with the same random number IE. The IE should be stored for later PCP communication. Cui, et al. Expires April 18, 2011 [Page 5] Internet-Draft pcp subscriber identification October 2010 With the random number method, when DoS attack with faked source address arrives, PCP server will not allocate mappings immediately. On the contrary, it replies a packet to the faked source address to ask the PCP client for another request with the random number, which the attackers will never receive. Furthermore, random number is valuable against unwanted deleting of mappings. However, it cannot defend MITM attacks. This method increases steps of PCP communication procedure at the first time. 3.3. Safe tunnel negotiation This method suggests a safe tunnel like TLS or IPsec to be established between PCP client and server before the starting of PCP communication. Based on the established safe tunnel, the PCP communication would be safe. All the problems stated in section 2 could be solved. Note that the negotiation procedure could be separated from PCP communication. As we known that PCP is designed as a lightweight protocol. However, safe tunnel negotiation would makes the whole PCP procedure complicate. Especially, PCP server needs to process a large number of encrypted/decrypted information to establish safe tunnel. The costs for safe tunnel establishing may be more than that of PCP procedure itself. 3.4. Digit signature The digit signature method suggests that PCP request and response messages should have an extended IE including digitally signed random number. The random number is firstly generated by PCP server. Every time when PCP server needs to send a response, it should generate a new random number and signs this random number. Figure 2 is a simple procedure of the digit signature method. +---------+ +---------+ | PCP | | PCP | | client | | server | | | | | +---------+ +---------+ | PCP request with digitally signed random number | | -------------------------------------------------------> | | | | | | PCP response with digitally signed random number | | <------------------------------------------------------- | Figure 2: Digit signature method Cui, et al. Expires April 18, 2011 [Page 6] Internet-Draft pcp subscriber identification October 2010 This method is considered to be more secure than random number method and not as complicated as safe tunnel negotiation method. Cui, et al. Expires April 18, 2011 [Page 7] Internet-Draft pcp subscriber identification October 2010 4. Security Considerations To be defined. Cui, et al. Expires April 18, 2011 [Page 8] Internet-Draft pcp subscriber identification October 2010 5. IANA Considerations No IANA requirement. Cui, et al. Expires April 18, 2011 [Page 9] Internet-Draft pcp subscriber identification October 2010 6. Acknowledgments Cui, et al. Expires April 18, 2011 [Page 10] Internet-Draft pcp subscriber identification October 2010 7. References 7.1. Normative References [I-D.wing-softwire-port-control-protocol] Wing, D., Penno, R., and M. Boucadair, "Pinhole Control Protocol (PCP)", draft-wing-softwire-port-control-protocol-02 (work in progress), July 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Cui, et al. Expires April 18, 2011 [Page 11] Internet-Draft pcp subscriber identification October 2010 Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: yong@csnet1.cs.tsinghua.edu.cn Jiang Dong Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: dongjiang@csnet1.cs.tsinghua.edu.cn Dayong Guo Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing 100085 P.R.China Email: guoseu@huawei.com Cui, et al. Expires April 18, 2011 [Page 12]