idnits 2.17.1 draft-cui-pcp-subscriber-identification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2010) is 4935 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-wing-softwire-port-control-protocol' is mentioned on line 94, but not defined == Unused Reference: 'RFC2119' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 294, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft J. Dong 4 Intended status: Standards Track Tsinghua University 5 Expires: April 18, 2011 Dayong. Guo 6 Huawei Technologies Co., Ltd 7 October 15, 2010 9 pcp subscriber identification 10 draft-cui-pcp-subscriber-identification-00 12 Abstract 14 This document analyzes on PCP security problems related with 15 subscriber identification, such as denial-of-service(DoS), unwanted 16 deleting of mappings, man-in-the-middle(MITM), and stale mapping 17 problem. Then several solutions are proposed. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 18, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Security problem analysis of PCP separated scenario . . . . . 4 67 2.1. DoS attacking with address spoofing . . . . . . . . . . . 4 68 2.2. Unwanted Deleting of Mappings . . . . . . . . . . . . . . 4 69 2.3. MITM attack . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.4. Stale Mappings . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Authentication model for PCP . . . . . . . . . . . . . . . 5 73 3.2. Random number . . . . . . . . . . . . . . . . . . . . . . 5 74 3.3. Safe tunnel negotiation . . . . . . . . . . . . . . . . . 6 75 3.4. Digit signature . . . . . . . . . . . . . . . . . . . . . 6 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 PCP is primarily designed to be implemented in the context of large 87 scale NAT deployments. It offers the ability to configure a port 88 forwarding capability in Service Provider NATs. In a Service 89 Provider case, subscriber identification and security are two of the 90 important features. It's the basic of providing port service and 91 accounting. 93 In Section 8.3 Subscriber Identification of current PCP 94 protocol[I-D.draft-wing-softwire-port-control-protocol], PCP server 95 uses IP address or prefix to identify PCP subscribers. However, PCP 96 is a lightweight protocol and no connection is required to be 97 maintained between the Client and the Server. It's very easy to 98 create a fake IP address in many cases, so PCP server could not 99 differentiate between legitimate requests and fake requests. Due to 100 these reasons, ISPs need more reliable technology to enhance the 101 security. 103 Generally in ISP networks, Broadband Network Gateway(BNG), aka 104 Broadband Remote Access Server, provides the access authentication 105 for subscribers. The BNG can identify by means of subscribers 106 information besides IP address, for example MAC address, Circuit ID 107 of access device which subscribers are attached to [RFC3046], etc. 108 If PCP server is embedded into BNG, it can identify a PCP client with 109 the information provided by BNG. In this case, PCP operations have 110 high security. 112 However, PCP server is usually coupled with Service Provider NAT 113 rather than BNG. When PCP server is separated from BNG, it can only 114 identify PCP client by IP address, which may cause significant 115 security problems. 117 This document mainly focuses on the security problems in the 118 separated scenario and methods on how to solve these problems. 120 2. Security problem analysis of PCP separated scenario 122 PCP is a simple protocol based on UDP. It achieves its purpose by 123 one simply request/response procedure. In separated scenario, these 124 steps are vulnerable to denial-of-service (DoS), unwanted deleting of 125 mappings, man-in-the-middle(MITM), and have stale mapping problem. 127 2.1. DoS attacking with address spoofing 129 Section 11.4 of PCP recommends IPv6 source address validation to 130 protect against creating unwanted mappings. However, an adversary 131 can flood the PCP requests with bogus source address, which satisfies 132 the validation rules, to cause DoS attacks exhausting mapping 133 resources. PCP server will allocate mappings for these illegal 134 requests. The limited mapping resources will soon be exhausted, 135 causing legitimate subscribers not having available resources. 137 2.2. Unwanted Deleting of Mappings 139 In PCP, requests with internal IP address and lifetime set to zero 140 are used to delete all mappings of a subscriber. An adversary can 141 flood the PCP requests with bogus source address deleting legitimate 142 mappings. By trying a large number of source addresses, an adversary 143 may successfully delete some legitimate mappings. This kind of 144 attack will disrupt the normal PCP uses. 146 2.3. MITM attack 148 An adversary may try to eavesdrop and collect PCP requests. The 149 normal request message contains some internal port numbers the PCP 150 client wants to request. Adversary may increase a large number of 151 fake internal ports and replay these requests. Then PCP server has 152 to allocate some additional mappings that are unnecessary. If a 153 large number of PCP requests are modified, the mapping resources 154 would be exhausted. On the other way, by setting the lifetime and 155 internal address to zero, an adversary may successfully delete some 156 mappings to disrupt normal PCP uses. 158 2.4. Stale Mappings 160 Section 11.6 of [I-D.wing-softwire-port-control-protocol] has 161 described this problem. 163 3. Possible solutions 165 This section will introduce several possible solutions to 166 authenticate legitimate clients. According to different operating 167 environment, ISPs could choose different method. 169 3.1. Authentication model for PCP 171 User name and password of a subscriber can be used to enhance PCP 172 security. As shown in figure 1, PCP client sends request message 173 with an extended Informational Element(IE) including user name and 174 password to the PCP server. Then PCP server, as an AAA client, 175 authenticates with AAA server via Diameter[RFC3588]/Radius 176 protocol[RFC2865]. Only when the authentication succeeds can the PCP 177 server start to allocate mappings to PCP client. 179 +---------+ 180 | | 181 | AAA | 182 | server | 183 +---------+ 184 | 185 | 186 | 187 | 188 +---------+ +---------+ +----------+ 189 | PCP | | PCP | | | 190 | client |----------| server |-------------| Internet | 191 | | | | | | 192 +---------+ +---------+ +----------+ 194 Figure 1: Authentication model 196 With the adoption of the user name and password identification 197 procedure, the DoS attack, unwanted mapping deleting and stale 198 mapping problem can be well defended against. This procedure doesn't 199 change the original PCP procedure for there are no new steps. 200 However, it adds AAA procedure. 202 3.2. Random number 204 With this method, when PCP server receives a PCP request from a 205 subscriber for the first time, it will reply an Error Response with a 206 random number without allocating mappings to the PCP client. The 207 random number can be contained in an IE. When a PCP client receives 208 this response with random number, it will resend another PCP request 209 with the same random number IE. The IE should be stored for later 210 PCP communication. 212 With the random number method, when DoS attack with faked source 213 address arrives, PCP server will not allocate mappings immediately. 214 On the contrary, it replies a packet to the faked source address to 215 ask the PCP client for another request with the random number, which 216 the attackers will never receive. Furthermore, random number is 217 valuable against unwanted deleting of mappings. 219 However, it cannot defend MITM attacks. This method increases steps 220 of PCP communication procedure at the first time. 222 3.3. Safe tunnel negotiation 224 This method suggests a safe tunnel like TLS or IPsec to be 225 established between PCP client and server before the starting of PCP 226 communication. Based on the established safe tunnel, the PCP 227 communication would be safe. All the problems stated in section 2 228 could be solved. Note that the negotiation procedure could be 229 separated from PCP communication. 231 As we known that PCP is designed as a lightweight protocol. However, 232 safe tunnel negotiation would makes the whole PCP procedure 233 complicate. Especially, PCP server needs to process a large number 234 of encrypted/decrypted information to establish safe tunnel. The 235 costs for safe tunnel establishing may be more than that of PCP 236 procedure itself. 238 3.4. Digit signature 240 The digit signature method suggests that PCP request and response 241 messages should have an extended IE including digitally signed random 242 number. The random number is firstly generated by PCP server. Every 243 time when PCP server needs to send a response, it should generate a 244 new random number and signs this random number. Figure 2 is a simple 245 procedure of the digit signature method. 247 +---------+ +---------+ 248 | PCP | | PCP | 249 | client | | server | 250 | | | | 251 +---------+ +---------+ 252 | PCP request with digitally signed random number | 253 | -------------------------------------------------------> | 254 | | 255 | | 256 | PCP response with digitally signed random number | 257 | <------------------------------------------------------- | 259 Figure 2: Digit signature method 260 This method is considered to be more secure than random number method 261 and not as complicated as safe tunnel negotiation method. 263 4. Security Considerations 265 To be defined. 267 5. IANA Considerations 269 No IANA requirement. 271 6. Acknowledgments 272 7. References 274 7.1. Normative References 276 [I-D.wing-softwire-port-control-protocol] 277 Wing, D., Penno, R., and M. Boucadair, "Pinhole Control 278 Protocol (PCP)", 279 draft-wing-softwire-port-control-protocol-02 (work in 280 progress), July 2010. 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, March 1997. 285 7.2. Informative References 287 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 288 "Remote Authentication Dial In User Service (RADIUS)", 289 RFC 2865, June 2000. 291 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 292 RFC 3046, January 2001. 294 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 295 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 297 Authors' Addresses 299 Yong Cui 300 Tsinghua University 301 Department of Computer Science, Tsinghua University 302 Beijing 100084 303 P.R.China 305 Phone: +86-10-6260-3059 306 Email: yong@csnet1.cs.tsinghua.edu.cn 308 Jiang Dong 309 Tsinghua University 310 Department of Computer Science, Tsinghua University 311 Beijing 100084 312 P.R.China 314 Phone: +86-10-6278-5822 315 Email: dongjiang@csnet1.cs.tsinghua.edu.cn 317 Dayong Guo 318 Huawei Technologies Co., Ltd 319 Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 320 Beijing 100085 321 P.R.China 323 Email: guoseu@huawei.com