idnits 2.17.1 draft-liu-opsec-ds-lite-security-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 1, 2014) is 3765 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3115' is mentioned on line 120, but not defined == Unused Reference: 'RFC3315' is defined on line 222, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Liu 3 Internet-Draft Huawei Technologies 4 Intended status: Informational F. Gont 5 Expires: July 5, 2014 SI6 Networks / UTN-FRH 6 T. Tsou 7 Huawei Technologies (USA) 8 January 1, 2014 10 DS-lite security 11 draft-liu-opsec-ds-lite-security-00 13 Abstract 15 More and more operators have deployed or are about to deploy IPv6 16 transition technologies such as DS-lite, MAP, LAFT6, etc. The 17 fundamental elements of these technologies are Network Address 18 Translation (NAT) and Tunneling. The elements of these transition 19 technologies may be subject to a number of attacks, unless 20 appropriate mitigations are in place. This memo discusses the 21 security implications of the aforementioned points, and additionally, 22 provides a number of operational mitigations that could be deployed 23 against these attacks. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 5, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. DHCPv6-based attacks . . . . . . . . . . . . . . . . . . . . . 4 62 4. IPv6 fragmentation . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Attacks against the AFTR/CPE //neet to reorganize the arch . . 4 64 6. Attacks based on encapsulation/decapsulation . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Due to the world-wide IPv4 address exhaustion, more and more 73 operators have deployed or are about to deploy IPv6 transition 74 technologies such as DS-lite, MAP, LAFT6, etc. The fundamental 75 elements of these technologies are Network Address Translation (NAT) 76 and Tunneling. The traffic traversing a NAT or Tunneling function 77 may be under attack due to the lack of protection on the node where 78 the NAT or/and Tunneling is placed. In addition, the node conducting 79 the function of NAT or/and Tunneling may also be the victim of DDOS 80 attack. This memo discusses the security implications of the 81 aforementioned points, and additionally, provides a number of 82 operational mitigations that could be deployed against these attacks. 84 Dual-Stack Lite (DS-Lite) technology, which enables a broadband 85 service provider to share IPv4 addresses among customers by combining 86 two well-known technologies: IP in IP (IPv4- in-IPv6) and Network 87 Address Translation (NAT), was proposed aiming at better aligning the 88 costs and benefits of deploying IPv6 in service provider networks. 89 [RFC6333] A typical DS-Lite deployment is shown in the figure below. 90 the Dual-Stack Lite model is built on to cross the network to reach a 91 carrier-grade IPv4-IPv4 NAT (the AFTR), where customers will share 92 IPv4 addresses. A IPv4-in-IPv6 tunnel(DS-Lite Tunnel) is built from 93 Bridging BroadBand (B4) element crossing the network to reach a DS- 94 Lite Address Family Transition Router (AFTR) element, where a 95 carrier-grade IPv4-IPv4 NAT is implemented. In such an end to end 96 DS-Lite deployment, there are several points that are vulnerable and 97 will be discussed in the rest of this document. 99 ------ ------ 100 // \\ +--------+ // \\ 101 +---+ +--+ | IPv6 | | BRAS | | IPv4 | +------+ 102 |Cli|-->|B4|-->+ network +-->+ with +-->+ network +-->|Server| 103 +---+ +--+ | | | AFTR | | | +------+ 104 \\ // +--------+ \\ // 105 ------ ------ 107 DS-Lite Tunnel 108 +--------------------------+ 110 Figure 1: DS-Lite deployment 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. DHCPv6-based attacks 120 In DS-Lite, DHCPv6 [RFC3115] is used to assign address for CPE, so 121 DHCPv6 can be exploited as an attack vector. The following aspects 122 should be considered: 124 1. Authentication between client and server. 126 a) Rogue/malicious DHCP server: A rogue server may allocate fake 127 IP address to the client requesting address and causes the client 128 unable to communicate. This has been well discussed in 129 draft-ietf-opsec-dhcpv6-shield. 131 b) Rogue/malicious client: A rogue client may make DoS attacks by 132 following two ways: 134 i)Using up all the resources of DHCP server. A client may 135 unremittingly send forged DHCP requests to DHCP server to use 136 up the resources of DHCP server. 138 ii)Dos attack other client by forging its IP address. A 139 malicious client may unremittingly send forged DHCP requests to 140 cause it unable to communicate. 142 We note that these attacks are not different than in the typical home 143 network case where a DHCPv6 server is employed. 145 4. IPv6 fragmentation 147 Since the encapsulation of IPv4 traffic in IPv6 may rely on the use 148 of IPv6 fragmentation, DS-lite may be subject to fragmentation-based 149 attacks. 151 Operational mitigation: Limit resources used by per client and/or 152 globally. 154 5. Attacks against the AFTR/CPE //neet to reorganize the arch 156 1. Forge tunnel source addresses of CPE(B4). An attacker may forge 157 many IPv6 addresses as DS-lite tunnel source addresses and create 158 many tunnels, and/or entries in the NAT state table with AFTR, 159 causing a DoS attack to the CGN(AFTR). 161 +---------+ +----------+ +----------+ 162 + Host +----+ CPE1(B4) +----+ CGN(AFTR)+---------- Internet 163 +---------+ +----------+ +-----+----+ 164 | 165 +---------+ +----------+ | 166 +Attacker +----+ CPE2(B4) +----------+ 167 +---------+ +----------+ 169 Figure 2: Forge tunnel source addresses of CPE(B4) 171 As shown in Figure 2, the attacker can cause a DoS attack to the 172 CGN(AFTR) by creating tunnels on CPE2(B4), and/or entries in the NAT 173 state table with the CGN(AFTR). 175 2. Forge CPE's address. One or many hackers may forge IPv6 176 addresses of CPEs of other users and send lots of packets to 177 CGN(AFTR). After receiving too many such packets, the CNG(AFTR) may 178 deny the further request from those victim CPEs whose addresses are 179 forged. 181 Take Figure 2 as an example, Attacker may make CPE2(B4) to forge the 182 address of CPE1 and start an attack. With too many packets from with 183 the v6 address of CPE1 received, the CGN might deny the service of 184 CPE1. 186 3. Session attack. An attacker may create many sessions at the same 187 time within one tunnel. This may cause a DoS attack that other user 188 can hardly create sessions due to resource excessive occupancy. 190 4. Big header attack. An attacker forges DS-lite packet with 191 multiple Next Headers in IP header to cause an excessive occupancy of 192 the CPU resource. 194 Operational mitigation: Limit on the number of sessions per client 195 and globally. Limit on the rate of building sessions to avoid the 196 memory being used up. Limit on the number of next headers of packet 197 to avoid the CPU resource being used up. 199 6. Attacks based on encapsulation/decapsulation 201 Not sure about this one. Could you please write more about this? 202 Thanks. 204 e.g. Can clients leverage DS-LITE to spoof the sure address? [fgont] 205 Yes Can clients diretly acess themselves with DS-list (to avoid being 206 monitored)? [fgont] This would be another possible one. [fgont] You 207 might find this reference useful: RFC 6169 209 7. Security Considerations 211 N/A. 213 8. Acknowledgements 215 N/A. 217 9. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 223 and M. Carney, "Dynamic Host Configuration Protocol for 224 IPv6 (DHCPv6)", RFC 3315, July 2003. 226 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 227 Stack Lite Broadband Deployments Following IPv4 228 Exhaustion", RFC 6333, August 2011. 230 Authors' Addresses 232 Will(Shucheng) Liu 233 Huawei Technologies 234 Bantian, Longgang District 235 Shenzhen 518129 236 P.R. China 238 Email: liushucheng@huawei.com 240 Fernando Gont 241 SI6 Networks / UTN-FRH 242 Evaristo Carriego 2644 243 Haedo, Provincia de Buenos Aires 1706 244 Argentina 246 Phone: +54 11 4650 8472 247 Email: fgont@si6networks.com 248 URI: http://www.si6networks.com 249 Tina Tsou 250 Huawei Technologies (USA) 251 2330 Central Expressway 252 Santa Clara, CA 95050 253 USA 255 Phone: +1 408 330 4424 256 Email: tina.tsou.zouting@huawei.com