idnits 2.17.1 draft-gont-opsec-vpn-leakages-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 15, 2012) is 4211 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4191' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 304, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ra-guard-implementation-04 == Outdated reference: A later version (-01) exists of draft-gont-opsec-dhcpv6-shield-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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 October 15, 2012 5 Intended status: Informational 6 Expires: April 18, 2013 8 Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ 9 networks 10 draft-gont-opsec-vpn-leakages-00 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 on the local network. This document 20 discusses some scenarios in which such VPN leakages may occur, either 21 as a side effect of enabling IPv6 on a local network, or as a result 22 of a deliberate attack from a local attacker. Additionally, it 23 discusses possible mitigations for the aforementioned issue. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may not be modified, 29 and derivative works of it may not be created, and it may not be 30 published except as an Internet-Draft. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 18, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . . 4 63 3. Virtual Private Networks in IPv4/IPv6 dual-stack 64 hosts/networks . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. VPN traffic-leakages in legitimate scenarios . . . . . . . . . 6 66 5. VPN traffic-leakage attacks . . . . . . . . . . . . . . . . . 7 67 6. Mitigations to VPN traffic-leakage vulnerabilities . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 10.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 It is a very common practice for employees working at remote 79 locations to establish a VPN connection with their office or home 80 office. This is typically done to gain access to some resources only 81 available within the company's network, but also to secure the host's 82 traffic against attackers that might be connected to the same remote 83 location. In some scenarios, it is even assumed that employing a VPN 84 connection makes the use of insecure protocols (e.g. that transfer 85 sensitive information in the clear) acceptable, as the VPN provides 86 security services (such as confidentiality) for all communications 87 made over the VPN. 89 Many VPN products that are typically employed for the aforementioned 90 VPN connections only support the IPv4 protocol: that is, they perform 91 the necessary actions such that IPv4 traffic is sent over the VPN 92 connection, but they do nothing to secure IPv6 traffic originated 93 from (or being received at) the host employing the VPN client. 94 However, the hosts themselves are typically dual-stacked: they 95 support (and enable by default) both IPv4 and IPv6 (even if such IPv6 96 connectivity is simply "dormant" when they connect to IPv4-only 97 networks). When the IPv6 connectivity of such hosts is enabled, they 98 may end up employing an IPv6-unaware VPN client in a dual-stack 99 network. This may have "unexpected" consequences, as explained 100 below. 102 The subtle way in which the IPv4 and IPv6 protocols interact and co- 103 exist in dual-stacked networks might, either inadvertently or as a 104 result of a deliberate attack, result in VPN traffic leakages -- that 105 is, traffic meant to be transferred over a VPN connection could leak 106 out of the VPN connection and be transmitted in the clear on the 107 local network, without employing the VPN services at all. 109 Section 2 provides some background about IPv6 and IPv4 co-existence, 110 summarizing how IPv4 and IPv4 interact on a typical dual-stacked 111 network. Section 3 describes the underlying problem that leads to 112 the aforementioned VPN traffic leakages. Section 4 describes 113 legitimate scenarios in which such traffic leakages might occur, 114 while Section 5 describes how VPN traffic leakages can be triggered 115 by deliberate attacks. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2. IPv4 and IPv6 co-existence 123 The co-existence of the IPv4 and IPv6 protocols has a number of 124 interesting and subtle aspects that may have "surprising" 125 consequences. While IPv6 is not backwards-compatible with IPv4, the 126 two protocols are "glued" together by the Domain Name System (DNS). 128 For example, consider a site (say, www.example.com) that has both 129 IPv4 and IPv6 support. The corresponding domain name 130 (www.example.com, in our case) will contain both A and AAAA DNS 131 resource records (RRs). Each A record will contain one IPv4 address, 132 while each AAAA record will contain one IPv6 address -- and there 133 might be more than one instance of each of these record types. Thus, 134 when a dual-stacked client application means to communicate with the 135 aforementioned site, it can request both A and AAAA records, and use 136 any of the available addresses. The preferred address family (IPv4 137 or IPv6) and the specific address that will be used (assuming more 138 than one address of each family is available) varies from one 139 protocol implementation to another, with many host implementations 140 preferring IPv6 addresses over IPv4 addresses. 142 [RFC6724] specifies an algorithm for selecting a destination 143 address from a list of IPv6 and IPv4 addresses. [RFC6555] 144 discusses the challenge of selecting the most appropriate 145 destination address, along with a proposed implementation approach 146 that mitigates connection-establishment delays. 148 This "co-existence" between IPv6 and IPv4 means that, when a dual- 149 stacked client means to communicate with some other system, the 150 availability of A and AAAA DNS resource records will typically affect 151 which protocol is employed to communicate with that system. 153 3. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks 155 Many Virtual Private Network (VPN) implementations do not support the 156 IPv6 protocol -- or, what is worse, they completely ignore IPv6. 157 This typically means that, when establishing a VPN connection, the 158 VPN software takes care of the IPv4 connectivity by, e.g. inserting 159 an IPv4 default route that causes all IPv4 traffic to be sent over 160 the VPN connection (as opposed to sending the traffic in the clear, 161 employing the local router). However, if IPv6 is not supported (or 162 completely ignored), any packets destined to an IPv6 address will be 163 sent in the clear using the local IPv6 router. That is, the VPN 164 software will do nothing about the IPv6 traffic. 166 The underlying problem here is that while IPv4 and IPv6 are two 167 different protocols incompatible with each other, the two protocols 168 are glued together by the Domain Name System. Therefore, for dual- 169 stacked systems, it is not possible to secure secure the 170 communication with another system without securing both protocols 171 (IPv6 and IPv4). 173 4. VPN traffic-leakages in legitimate scenarios 175 Consider a dual-stacked host that employs IPv4-only VPN software to 176 establish a VPN connection with a VPN server, and that the host now 177 attaches to a dual-stacked network (that provides both IPv6 and IPv4 178 connectivity). If some application on the client needs to 179 communicate with a dual-stacked destination, the client will 180 typically query both A and AAAA DNS resource records. Since the host 181 will have both IPv4 and IPv6 connectivity, and the intended 182 destination will have both A and AAAA DNS resource records, one of 183 the possible outcomes is that the host will employ IPv6 to 184 communicate with the aforementioned system. Since the VPN software 185 does not support IPv6, the IPv6 traffic will not employ the VPN 186 connection, and will be sent in the clear on the local network. 188 This could inadvertently expose sensitive traffic that was assumed to 189 be secured by the VPN software. In this particular scenario, the 190 resulting VPN traffic leakage is a side-effect of employing IPv6- 191 unaware software in a dual-stacked host/network. 193 5. VPN traffic-leakage attacks 195 A local attacker could deliberately trigger IPv6 connectivity on the 196 victim host by sending forged ICMPv6 Router Advertisement messages. 197 Such packets could be sent by employing standard software such as 198 rtadvd [RTADVD], or by employing packet-crafting tools such as the 199 [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has 200 been enabled, communications with dual-stacked systems could result 201 in VPN traffic leakages, as previously mentioned. 203 While this attack may be useful enough (due to the increasing number 204 of IPv6-enabled sites), it will only lead to traffic leakages when 205 the destination system is dual-stacked. However, it is usually 206 trivial for an attacker to trigger such VPN leakages for any 207 destination systems: an attacker could simply advertise himself as 208 the local recursive DNS server by sending forged Router Advertisement 209 messages that include the corresponding RDNSS option, and then 210 perform a DNS spoofing attack such that he can become a "Man in the 211 Middle" and intercept the corresponding traffic. As with the 212 previous attack scenario, packet-crafting tools such as [SI6-Toolkit] 213 and [THC-IPv6] can readily perform this attack. 215 Some systems are known to prefer IPv6-based recursive DNS servers 216 over IPv4-based ones, and hence the "malicious" recursive DNS 217 servers would be preferred over the legitimate ones advertised by 218 the VPN server. 220 6. Mitigations to VPN traffic-leakage vulnerabilities 222 There are a number of possible mitigations for the VPN traffic- 223 leakage vulnerability discussed in this document. 225 If the VPN client is configured by administrative decision to 226 redirect all traffic for IPv4 to the VPN, it should: 228 1. If IPv6 is not supported, disable IPv6 support in all network 229 interfaces 231 For IPv6-unaware VPN clients, the most simple mitigation 232 (although not necessarily the most desirable one) would be to 233 disable IPv6 support in all network interface cards when a VPN 234 connection is meant to be employed. Thus, applications on the 235 host running the VPN client software will have no other option 236 than to employ IPv4, and hence they will simply not even try 237 to send/process IPv6 traffic. 239 2. If IPv6 is supported, ensure that all IPv6 traffic is also sent 240 via the VPN 242 If the VPN client is configured to only send a subset of IPv4 243 networks to the VPN tunnel (split-tunnel mode), and the VPN client 244 does not support IPv6, it should disable IPv6 as well. If it 245 supports IPv6, it is the administrators responsibility to ensure that 246 the correct corresponding sets of IPv4 and IPv6 networks get routed 247 into the VPN tunnel. 249 Additionally, VPN clients that support IPv6 should mitigate all ND- 250 based attacks that may introduce new entries in the routing table, 251 such attacks based on forged RA messages containing more specific 252 routes, forged ICMPv6 Redirect messages, etc. 254 A network may prevent local attackers from successfully performing 255 the aforementioned attacks against other local hosts by implementing 256 First-Hop Security solutions such as Router Advertisement Guard (RA- 257 Guard) [RFC6105] and DHCPv6-Shield [I-D.gont-opsec-dhcpv6-shield]. 258 However, for obvious reasons, a host cannot and should not rely on 259 this type of mitigations when connecting to an open network 260 (cybercafe, etc.). 262 Besides, popular implementations of RA-Guard are known to be 263 vulnerable to evasion attacks 264 [I-D.ietf-v6ops-ra-guard-implementation]. 266 7. IANA Considerations 268 This document has no actions for IANA. 270 8. Security Considerations 272 This document discusses how traffic meant to be transferred over a 273 VPN connection can leak out of the VPN, and hence appear in the clear 274 on the local network. This is the result of employing IPv6-unaware 275 VPN client software on dual-stacked hosts. 277 Possible ways to mitigate this problem include fixing the VPN client 278 software, or disabling IPv6 connectivity on all network interfaces 279 when the previous option is not feasible. 281 9. Acknowledgements 283 The author would like to thank (in alphabetical order) Gert Doering 284 and Tor Houghton, who providing comments on earlier versions of this 285 document. 287 This documents has benefited from the input of Cameron Byrne, Gert 288 Doering, Seth Hall, Tor Houghton, Alastair Johnson, Henrik Lund 289 Kramshoj, and Jim Small, while discussing this topic on the 290 ipv6hackers mailing-list [IPv6-Hackers]. It has also benefited from 291 discussions with Andrew Yourtchenko on the opsec wg mailing-list 292 [OPSEC-LIST]. 294 10. References 296 10.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 302 More-Specific Routes", RFC 4191, November 2005. 304 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 305 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 306 September 2007. 308 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 309 "Default Address Selection for Internet Protocol Version 6 310 (IPv6)", RFC 6724, September 2012. 312 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 313 Dual-Stack Hosts", RFC 6555, April 2012. 315 10.2. Informative References 317 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 318 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 319 February 2011. 321 [I-D.ietf-v6ops-ra-guard-implementation] 322 Gont, F., "Implementation Advice for IPv6 Router 323 Advertisement Guard (RA-Guard)", 324 draft-ietf-v6ops-ra-guard-implementation-04 (work in 325 progress), May 2012. 327 [I-D.gont-opsec-dhcpv6-shield] 328 Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6 329 Servers", draft-gont-opsec-dhcpv6-shield-00 (work in 330 progress), May 2012. 332 [IPv6-Hackers] 333 "IPv6 Hackers mailing-list", 334 http://lists.si6networks.com/listinfo/ipv6hackers/. 336 [OPSEC-LIST] 337 "OPSEC WG mailing-list", 338 https://www.ietf.org/mailman/listinfo/opsec. 340 [SI6-Toolkit] 341 "SI6 Networks' IPv6 toolkit", 342 . 344 [THC-IPv6] 345 "The Hacker's Choice IPv6 Attack Toolkit", 346 . 348 [RTADVD] "rtadvd(8) manual page", . 351 Author's Address 353 Fernando Gont 354 Huawei Technologies 355 Evaristo Carriego 2644 356 Haedo, Provincia de Buenos Aires 1706 357 Argentina 359 Phone: +54 11 4650 8472 360 Email: fgont@si6networks.com 361 URI: http://www.si6networks.com