idnits 2.17.1 draft-ietf-opsec-vpn-leakages-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 23, 2013) is 3870 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-08) exists of draft-ietf-opsec-dhcpv6-shield-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for F. Gont 3 IP Network Infrastructure (opsec) Huawei Technologies 4 Internet-Draft August 23, 2013 5 Intended status: Informational 6 Expires: February 24, 2014 8 Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ 9 networks 10 draft-ietf-opsec-vpn-leakages-02 12 Abstract 14 The subtle way in which the IPv6 and IPv4 protocols co-exist in 15 typical networks, together with the lack of proper IPv6 support in 16 popular Virtual Private Network (VPN) products, may inadvertently 17 result in VPN traffic leaks. That is, traffic meant to be 18 transferred over a VPN connection may leak out of such connection and 19 be transferred in the clear from the local network to the final 20 destination. This document discusses some scenarios in which such 21 VPN leakages may occur, either as a side effect of enabling IPv6 on a 22 local network, or as a result of a deliberate attack from a local 23 attacker. Additionally, it discusses possible mitigations for the 24 aforementioned issue. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 24, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . . 4 62 3. Virtual Private Networks in IPv4/IPv6 dual-stack 63 hosts/networks . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Inadvertent VPN traffic-leakages in legitimate scenarios . . . 6 65 5. VPN traffic-leakage attacks . . . . . . . . . . . . . . . . . 7 66 6. Mitigations to VPN traffic-leakage vulnerabilities . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 72 10.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 It is a very common practice for employees working at remote 78 locations to establish a VPN connection with their office or home 79 office. This is typically done to gain access to some resources only 80 available within the company's network, but also to secure the host's 81 traffic against attackers that might be connected to the same remote 82 location. The same is true for mobile nodes that establish VPN 83 connections to secure their traffic while they roam from one network 84 to another. In some scenarios, it is even assumed that employing a 85 VPN connection makes the use of insecure protocols (e.g. that 86 transfer sensitive information in the clear) acceptable, as the VPN 87 provides security services (such as data integrity and/or 88 confidentiality) for all communications made over the VPN. 90 Many VPN products that are typically employed for the aforementioned 91 VPN connections only support the IPv4 protocol: that is, they perform 92 the necessary actions such that IPv4 traffic is sent over the VPN 93 connection, but they do nothing to secure IPv6 traffic originated 94 from (or being received at) the host employing the VPN client. 95 However, the hosts themselves are typically dual-stacked: they 96 support (and enable by default) both IPv4 and IPv6 (even if such IPv6 97 connectivity is simply "dormant" when they connect to IPv4-only 98 networks). When the IPv6 connectivity of such hosts is enabled, they 99 may end up employing an IPv6-unaware VPN client in a dual-stack 100 network. This may have "unexpected" consequences, as explained 101 below. 103 The subtle way in which the IPv4 and IPv6 protocols interact and co- 104 exist in dual-stacked networks might, either inadvertently or as a 105 result of a deliberate attack, result in VPN traffic leakages -- that 106 is, traffic meant to be transferred over a VPN connection could leak 107 out of the VPN connection and be transmitted in the clear from the 108 local network to the final destination, without employing the VPN 109 services at all. 111 Section 2 provides some background about IPv6 and IPv4 co-existence, 112 summarizing how IPv6 and IPv4 interact on a typical dual-stacked 113 network. Section 3 describes the underlying problem that leads to 114 the aforementioned VPN traffic leakages. Section 4 describes 115 legitimate scenarios in which such traffic leakages might occur, 116 while Section 5 describes how VPN traffic leakages can be triggered 117 by deliberate attacks. 119 2. IPv4 and IPv6 co-existence 121 The co-existence of the IPv4 and IPv6 protocols has a number of 122 interesting and subtle aspects that may have "surprising" 123 consequences. While IPv6 is not backwards-compatible with IPv4, the 124 two protocols are "tied" together by the Domain Name System (DNS). 126 For example, consider a site (say, www.example.com) that has both 127 IPv4 and IPv6 support. The corresponding domain name 128 (www.example.com, in our case) will contain both A and AAAA DNS 129 resource records (RRs). Each A record will contain one IPv4 address, 130 while each AAAA record will contain one IPv6 address -- and there 131 might be more than one instance of each of these record types. Thus, 132 when a dual-stacked client application means to communicate with 133 www.example.com, it can request both A and AAAA records, and use any 134 of the available addresses. The preferred address family (IPv4 or 135 IPv6) and the specific address that will be used (assuming more than 136 one address of each family is available) varies from one protocol 137 implementation to another, with many host implementations preferring 138 IPv6 addresses over IPv4 addresses. 140 [RFC6724] specifies an algorithm for selecting a destination 141 address from a list of IPv6 and IPv4 addresses. [RFC6555] 142 discusses the challenge of selecting the most appropriate 143 destination address, along with a proposed implementation approach 144 that mitigates connection-establishment delays. 146 As a result of this "co-existence" between IPv6 and IPv4, when a 147 dual-stacked client means to communicate with some other system, the 148 availability of A and AAAA DNS resource records will typically affect 149 which protocol is employed to communicate with that system. 151 3. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks 153 Many Virtual Private Network (VPN) implementations do not support the 154 IPv6 protocol -- or, what is worse, they completely ignore IPv6. 155 This typically means that, when establishing a VPN connection, the 156 VPN software takes care of the IPv4 connectivity by, e.g. inserting 157 an IPv4 default route that causes all IPv4 traffic to be sent over 158 the VPN connection (as opposed to sending the traffic in the clear, 159 employing the local router). However, if IPv6 is not supported (or 160 completely ignored), any packets destined to an IPv6 address will be 161 sent in the clear using the local IPv6 router. That is, the VPN 162 software will do nothing about the IPv6 traffic. 164 The underlying problem here is that while IPv4 and IPv6 are two 165 different protocols incompatible with each other, the two protocols 166 are glued together by the Domain Name System. Therefore, for dual- 167 stacked systems, it is not possible to secure the communication with 168 another system without securing both protocols (IPv6 and IPv4). 170 4. Inadvertent VPN traffic-leakages in legitimate scenarios 172 Consider a dual-stacked host that employs IPv4-only VPN software to 173 establish a VPN connection with a VPN server, and that such host now 174 connects to a dual-stacked network (that provides both IPv6 and IPv4 175 connectivity). If some application on the client means to 176 communicate with a dual-stacked destination, the client will 177 typically query both A and AAAA DNS resource records. Since the host 178 will have both IPv4 and IPv6 connectivity, and the intended 179 destination will have both A and AAAA DNS resource records, one of 180 the possible outcomes is that the host will employ IPv6 to 181 communicate with the intended destination. Since the VPN software 182 does not support IPv6, the IPv6 traffic will not employ the VPN 183 connection, and hence will have neither integrity nor confidentiality 184 protection from the source host to the final destination. 186 This could inadvertently expose sensitive traffic that was assumed to 187 be secured by the VPN software. In this particular scenario, the 188 resulting VPN traffic leakage is a side-effect of employing IPv6- 189 unaware VPN software in a dual-stacked host/network. 191 5. VPN traffic-leakage attacks 193 A local attacker could deliberately trigger IPv6 connectivity on the 194 victim host by sending forged ICMPv6 Router Advertisement messages 195 [RFC4861]. Such packets could be sent by employing standard software 196 such as rtadvd [RTADVD], or by employing packet-crafting tools such 197 as [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has 198 been enabled, communications with dual-stacked systems could result 199 in VPN traffic leakages, as previously described. 201 While this attack may be useful enough (due to the increasing number 202 of IPv6-enabled sites), it will only lead to traffic leakages when 203 the destination system is dual-stacked. However, it is usually 204 trivial for an attacker to trigger such VPN leakages for any 205 destination systems: an attacker could simply advertise himself as 206 the local recursive DNS server by sending forged Router Advertisement 207 messages [RFC4861] that include the corresponding RDNSS option 208 [RFC6106], and then perform a DNS spoofing attack such that he can 209 become a "Man in the Middle" and intercept the corresponding traffic. 210 As with the previous attack scenario, packet-crafting tools such as 211 [SI6-Toolkit] and [THC-IPv6] can readily perform this attack. 213 Some systems are known to prefer IPv6-based recursive DNS servers 214 over IPv4-based ones, and hence the "malicious" recursive DNS 215 servers would be preferred over the legitimate ones advertised by 216 the VPN server. 218 6. Mitigations to VPN traffic-leakage vulnerabilities 220 There are a number of possible mitigations for the VPN traffic- 221 leakage vulnerability discussed in this document. 223 If the VPN client is configured by administrative decision to 224 redirect all IPv4 traffic to the VPN, it should: 226 1. If IPv6 is not supported in the VPN software, disable IPv6 227 support in all network interfaces. 229 For IPv6-unaware VPN clients, the most simple mitigation 230 (although not necessarily the most desirable one) would be to 231 disable IPv6 support in all network interface cards when a VPN 232 connection is meant to be employed. Thus, applications on the 233 host running the VPN client software will have no other option 234 than to employ IPv4, and hence they will simply not even try 235 to send/process IPv6 traffic. 237 2. If IPv6 is supported in the VPN software, ensure that all IPv6 238 traffic is also sent via the VPN. 240 If the VPN client is configured to only send a subset of IPv4 traffic 241 to the VPN tunnel (split-tunnel mode), then: 243 1. If the VPN client does not support IPv6, it should disable IPv6 244 support in all network interfaces. 246 2. If the VPN client supports IPv6, it is the administrators 247 responsibility to ensure that the correct corresponding sets of 248 IPv4 and IPv6 networks get routed into the VPN tunnel. 250 Additionally, VPN clients that support IPv6 should mitigate all 251 Neighbor Discovery (ND) attacks that may introduce new entries in the 252 routing table, such as attacks based on forged Router Advertisement 253 messages containing more specific routes [RFC4191], forged ICMPv6 254 Redirect messages, etc. 256 A network may prevent local attackers from successfully performing 257 the aforementioned attacks against other local hosts by implementing 258 First-Hop Security solutions such as Router Advertisement Guard (RA- 259 Guard) [RFC6105] and DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. 260 However, for obvious reasons, a host cannot and should not rely on 261 this type of mitigations when connecting to an open network 262 (cybercafe, etc.). 264 Besides, popular implementations of RA-Guard are known to be 265 vulnerable to evasion attacks 266 [I-D.ietf-v6ops-ra-guard-implementation]. 268 Finally, we note that if (eventually) IPv6-only VPN implementations 269 become available, they should consider similar issues that would 270 arise if they do nothing about the IPv4 traffic. 272 7. IANA Considerations 274 This document has no actions for IANA. 276 8. Security Considerations 278 This document discusses how traffic meant to be transferred over a 279 VPN connection can leak out of the VPN, and hence appear in the clear 280 on the local network. This is the result of employing IPv6-unaware 281 VPN client software on dual-stacked hosts. 283 Possible ways to mitigate this problem include fixing the VPN client 284 software, or disabling IPv6 connectivity on all network interfaces 285 when the previous option is not feasible. 287 9. Acknowledgements 289 The author would like to thank (in alphabetical order) Gert Doering 290 and Tor Houghton, who providing comments on earlier versions of this 291 document. 293 This documents has benefited from the input of Cameron Byrne, Gert 294 Doering, Seth Hall, Tor Houghton, Alastair Johnson, Merike Kaeo, 295 Panos Kampanakis, Henrik Lund Kramshoj, Thomas Osterried, and Jim 296 Small, while discussing this topic on the ipv6hackers mailing-list 297 [IPv6-Hackers]. It has also benefited from discussions with Andrew 298 Yourtchenko on the opsec wg mailing-list [OPSEC-LIST]. 300 10. References 302 10.1. Normative References 304 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 305 More-Specific Routes", RFC 4191, November 2005. 307 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 308 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 309 September 2007. 311 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 312 "IPv6 Router Advertisement Options for DNS Configuration", 313 RFC 6106, November 2010. 315 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 316 "Default Address Selection for Internet Protocol Version 6 317 (IPv6)", RFC 6724, September 2012. 319 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 320 Dual-Stack Hosts", RFC 6555, April 2012. 322 10.2. Informative References 324 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 325 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 326 February 2011. 328 [I-D.ietf-v6ops-ra-guard-implementation] 329 Gont, F., "Implementation Advice for IPv6 Router 330 Advertisement Guard (RA-Guard)", 331 draft-ietf-v6ops-ra-guard-implementation-07 (work in 332 progress), November 2012. 334 [I-D.ietf-opsec-dhcpv6-shield] 335 Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield: 336 Protecting Against Rogue DHCPv6 Servers", 337 draft-ietf-opsec-dhcpv6-shield-00 (work in progress), 338 December 2012. 340 [IPv6-Hackers] 341 "IPv6 Hackers mailing-list", 342 http://lists.si6networks.com/listinfo/ipv6hackers/. 344 [OPSEC-LIST] 345 "OPSEC WG mailing-list", 346 https://www.ietf.org/mailman/listinfo/opsec. 348 [SI6-Toolkit] 349 "SI6 Networks' IPv6 toolkit", 350 . 352 [THC-IPv6] 353 "The Hacker's Choice IPv6 Attack Toolkit", 354 . 356 [RTADVD] "rtadvd(8) manual page", . 359 Author's Address 361 Fernando Gont 362 Huawei Technologies 363 Evaristo Carriego 2644 364 Haedo, Provincia de Buenos Aires 1706 365 Argentina 367 Phone: +54 11 4650 8472 368 Email: fgont@si6networks.com 369 URI: http://www.si6networks.com