idnits 2.17.1 draft-ietf-opsec-vpn-leakages-06.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 (April 24, 2014) is 3654 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-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft Huawei Technologies 4 Intended status: Informational April 24, 2014 5 Expires: October 26, 2014 7 Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- 8 stack hosts/networks 9 draft-ietf-opsec-vpn-leakages-06 11 Abstract 13 The subtle way in which the IPv6 and IPv4 protocols co-exist in 14 typical networks, together with the lack of proper IPv6 support in 15 popular Virtual Private Network (VPN) tunnel products, may 16 inadvertently result in VPN tunnel traffic leaks. That is, traffic 17 meant to be transferred over an encrypted and integrity protected VPN 18 tunnel may leak out of such tunnel and be sent in the clear on the 19 local network towards the final destination. This document discusses 20 some scenarios in which such VPN tunnel traffic leakages may occur as 21 a result of employing IPv6-unaware VPN software. Additionally, this 22 document offers possible mitigations for this issue. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 26, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . 5 61 4. Virtual Private Networks in IPv4/IPv6 dual-stack 62 hosts/networks . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Inadvertent VPN tunnel traffic leakages in legitimate 64 scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. VPN tunnel traffic leakage attacks . . . . . . . . . . . . . 6 66 7. Mitigations to VPN tunnel traffic leakage vulnerabilities . . 7 67 7.1. Fixing VPN client software . . . . . . . . . . . . . . . 7 68 7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 11.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 It is a very common practice for users to employ VPN software when 80 employing a public (and possibly-rogue) local network. This is 81 typically done not only to gain access to remote resources that may 82 not otherwise be accessible from the public Internet, but also to 83 secure the host's traffic against attackers that might be connected 84 to the same local network as the victim host. The latter case 85 constitutes the problem space of this document. Indeed, it is 86 sometimes assumed that employing a VPN tunnel makes the use of 87 insecure protocols (e.g., that transfer sensitive information in the 88 clear) acceptable, as a VPN tunnel provides security services (such 89 as data integrity and/or confidentiality) for all communications made 90 over it. However, this document illustrates that under certain 91 circumstances, some traffic might not be mapped onto the VPN tunnel 92 and thus be sent in the clear on the local network. 94 Many VPN products that are typically employed for the aforementioned 95 VPN tunnels only support the IPv4 protocol: that is, they perform the 96 necessary actions such that IPv4 traffic is sent over the VPN tunnel, 97 but they do nothing to secure IPv6 traffic originated from (or being 98 received at) the host employing the VPN client. However, the hosts 99 themselves are typically dual-stacked: they support (and enable by 100 default) both IPv4 and IPv6 (even if such IPv6 connectivity is simply 101 "dormant" when they connect to IPv4-only networks). When the IPv6 102 connectivity of such hosts is enabled, they may end up employing an 103 IPv6-unaware VPN client in a dual-stack network. This may have 104 "unexpected" consequences, as explained below. 106 The subtle way in which the IPv4 and IPv6 protocols interact and co- 107 exist in dual-stacked networks might, either inadvertently or as a 108 result of a deliberate attack, result in VPN tunnel traffic leakages 109 -- that is, traffic meant to be transferred over a VPN tunnel could 110 leak out of the VPN tunnel and be transmitted in the clear from the 111 local network to the final destination, without employing the VPN 112 services at all. 114 Since this issue is specific to VPN solutions that route layer-3 115 traffic, it is applicable to the following types of VPN technologies: 117 o IPsec-based VPN tunnel 119 o SSL/TLS VPN tunnel 121 NOTE: see Section 2 for a definition and description of these 122 terms. 124 Section 2 clarifies the terminology employed throughout this 125 document. Section 3 provides some background about IPv6 and IPv4 co- 126 existence, summarizing how IPv6 and IPv4 interact on a typical dual- 127 stacked network. Section 4 describes the underlying problem that 128 leads to the aforementioned VPN traffic leakages. Section 5 129 describes legitimate scenarios in which such traffic leakages might 130 occur, while Section 6 describes how VPN traffic leakages can be 131 triggered by deliberate attacks. Finally, Section 7 discusses 132 possible mitigation for the aforementioned issue. 134 2. Terminology 136 When employing the term "Virtual Private Network tunnel" (or "VPN 137 tunnel"), this document refers to IPsec-based or SSL/TLS-based 138 tunnels, where layer-3 packets are encapsulated and sent from a 139 client to a middle-box, to access multiple network services (possibly 140 employing different transport and/or application protocols). 142 IPsec-based VPN tunnels simply employ IPsec in tunnel mode to 143 encapsulate ans transfer layer-3 packets over the VPN tunnel. On the 144 other hand, the term "SSL/TLS-based VPN tunnels" warrants a 145 clarification, since two different technologies are usually referred 146 to as "SSL/TLS VPN": 148 SSL VPN tunnel: 149 A technology that encapsulates traffic from a client to a 150 middlebox. In essence, an SSL/TLS VPN tunnel acts just like an 151 IPsec-based tunnel, but instead employs SSL/TLS for encryption, 152 and some proprietary/unspecified mechanism for encapsulation and 153 routing. 155 SSL VPN portal: 156 A front-end provided by the middlebox to add security to a 157 normally-unsecured site. A TLS/SSL VPN portal is typically 158 application specific, wrapping the specific protocol, such as 159 HTTP, to provide access to specific services on a network. In 160 such case, the SSL/TLS VPN portal would be accessed just like any 161 HTTPS URL. TLS/SSL VPN portals are used when one wants to 162 restrict access and only provide remote users to very specific 163 services on the network. SSL/TLS VPN portals do not require an 164 agent and the policy is typically more liberal from organizations 165 allowing access from anywhere via this access method. All other 166 traffic on the system may be routed directly to the destination, 167 whether it is IPv4, IPv6, or even other service level (HTTP) 168 destination addresses. 170 Our document focuses on layer-3 VPNs that employ IPsec-based or SSL/ 171 TLS-based tunnels, and excludes the so-called SSL/TLS VPN portals. 172 Both IPsec-basec and TLS/SSL-based VPN tunnels are designed to route 173 layer-3 traffic via de VPN tunnel through to VPN tunnel server. 174 Typically, these solutions are agent-based, meaning that software is 175 required on the client end-point to establish the VPN tunnel and 176 manage access control or routing rules. This provides an opportunity 177 for controls to be managed through that application as well as on the 178 client endpoint. 180 NOTE: Further discussion of SSL-based VPNs can be found in 181 [SSL-VPNs]. 183 We note that, in addition to the general case of "send all traffic 184 through the VPN", this document considers the so-called "split- 185 tunnel" case, where some subset of the traffic is sent through the 186 VPN, while other traffic is sent to its intended destination with a 187 direct routing path (i.e., without employing the VPN tunnel). We 188 note that many organizations will prevent split-tunneling in their 189 VPN configurations if they would like to make sure the users data 190 goes through a gateway with protections (malware detection, URL 191 filtering, etc.), but others are more interested in performance of 192 the user's access or the ability for researchers to have options to 193 access sites they may not be able to through the gateway. 195 3. IPv4 and IPv6 co-existence 197 The co-existence of the IPv4 and IPv6 protocols has a number of 198 interesting and subtle aspects that may have "surprising" 199 consequences. While IPv6 is not backwards-compatible with IPv4, the 200 two protocols are "glued" together by the Domain Name System (DNS). 202 For example, consider a site (say, www.example.com) that has both 203 IPv4 and IPv6 support. The corresponding domain name 204 (www.example.com, in our case) will contain both A and AAAA DNS 205 resource records (RRs). Each A record will contain one IPv4 address, 206 while each AAAA record will contain one IPv6 address -- and there 207 might be more than one instance of each of these record types. Thus, 208 when a dual-stacked client application means to communicate with 209 www.example.com, it can request both A and AAAA records, and use any 210 of the available addresses. The preferred address family (IPv4 or 211 IPv6) and the specific address that will be used (assuming more than 212 one address of each family is available) varies from one protocol 213 implementation to another, with many host implementations preferring 214 IPv6 addresses over IPv4 addresses. 216 NOTE: [RFC6724] specifies an algorithm for selecting a destination 217 address from a list of IPv6 and IPv4 addresses. [RFC6555] 218 discusses the challenge of selecting the most appropriate 219 destination address, along with a proposed implementation approach 220 that mitigates connection-establishment delays. 222 As a result of this "co-existence" between IPv6 and IPv4, when a 223 dual-stacked client means to communicate with some other system, the 224 availability of A and AAAA DNS resource records will typically affect 225 which protocol is employed to communicate with that system. 227 4. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks 229 Many VPN tunnel implementations do not support the IPv6 protocol -- 230 or, what is worse, they completely ignore IPv6. This typically means 231 that, once a VPN tunnel has been established, the VPN software takes 232 care of the IPv4 connectivity by, e.g. inserting an IPv4 default 233 route that causes all IPv4 traffic to be sent over the VPN connection 234 (as opposed to sending the traffic in the clear, employing the local 235 router). However, if IPv6 is not supported (or completely ignored), 236 any packets destined to an IPv6 address will be sent in the clear 237 using the local IPv6 router. That is, the VPN software will do 238 nothing about the IPv6 traffic. 240 The underlying reason for which these VPN leakages may occur is that, 241 for dual-stacked systems, it is not possible to secure the 242 communication with another system without securing both protocols 243 (IPv6 and IPv4). Therefore, as long as the traffic for one of these 244 protocols is not secured, there is the potential for VPN traffic 245 leakages. 247 5. Inadvertent VPN tunnel traffic leakages in legitimate scenarios 249 Consider a dual-stacked host that employs IPv4-only VPN software to 250 establish a VPN tunnel with a VPN server, and that such host now 251 connects to a dual-stacked network (that provides both IPv6 and IPv4 252 connectivity). If some application on the client means to 253 communicate with a dual-stacked destination, the client will 254 typically query both A and AAAA DNS resource records. Since the host 255 will have both IPv4 and IPv6 connectivity, and the intended 256 destination will have both A and AAAA DNS resource records, one of 257 the possible outcomes is that the host will employ IPv6 to 258 communicate with the intended destination. Since the VPN software 259 does not support IPv6, the IPv6 traffic will not employ the VPN 260 connection, and hence will have neither integrity nor confidentiality 261 protection from the source host to the final destination. 263 This could inadvertently expose sensitive traffic that was assumed to 264 be secured by the VPN software. In this particular scenario, the 265 resulting VPN tunnel traffic leakage is a side-effect of employing 266 IPv6-unaware VPN software in a dual-stacked host/network. 268 6. VPN tunnel traffic leakage attacks 270 A local attacker could deliberately trigger IPv6 connectivity on the 271 victim host by sending forged ICMPv6 Router Advertisement messages 272 [RFC4861]. Such packets could be sent by employing standard software 273 such as rtadvd [RTADVD], or by employing packet-crafting tools such 274 as [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has 275 been enabled, communications with dual-stacked systems could result 276 in VPN tunnel traffic leakages, as previously described. 278 While this attack may be useful enough (due to the increasing number 279 of IPv6-enabled sites), it will only lead to traffic leakages when 280 the destination system is dual-stacked. However, it is usually 281 trivial for an attacker to trigger such VPN tunnel traffic leakages 282 for any destination systems: an attacker could simply advertise 283 himself as the local recursive DNS server by sending forged Router 284 Advertisement messages [RFC4861] that include the corresponding RDNSS 285 option [RFC6106], and then perform a DNS spoofing attack such that he 286 can become a "Man in the Middle" and intercept the corresponding 287 traffic. As with the previous attack scenario, packet-crafting tools 288 such as [SI6-Toolkit] and [THC-IPv6] can readily perform this attack. 290 NOTE: Some systems are known to prefer IPv6-based recursive DNS 291 servers over IPv4-based ones, and hence the "malicious" recursive 292 DNS servers would be preferred over the legitimate ones advertised 293 by the VPN server. 295 7. Mitigations to VPN tunnel traffic leakage vulnerabilities 297 At the time of this writing, a large number of VPN implementations 298 have not yet addressed the issue of VPN tunnel traffic leakages. 299 Most of these implementations simply ignore IPv6, and hence IPv6 300 traffic leaks out of the VPN tunnel. Some VPN-tunnel implementations 301 handle IPv6, but not properly. For example, they may be able to 302 prevent inadvertent VPN tunnel traffic leakages arising in legitimate 303 dual-stack networks, but fail to properly handle the myriad of 304 vectors available to an attacker for injecting "more specific 305 routes", such as ICMPv6 Router Advertisement messages with Prefix 306 Information Options and/or Route Information Options, and ICMPv6 307 Redirect messages. 309 Clearly, the issue of VPN tunnel traffic leakages warrants proper 310 IPv6 support in VPN tunnel implementations. 312 7.1. Fixing VPN client software 314 There are a number of possible mitigations for the VPN tunnel traffic 315 leakage vulnerability discussed in this document. 317 If the VPN client is configured by administrative decision to 318 redirect all IPv4 traffic to the VPN, it should: 320 1. If IPv6 is not supported in the VPN software, disable IPv6 321 support in all network interfaces. 323 NOTE: For IPv6-unaware VPN clients, the most simple mitigation 324 would be to disable IPv6 support in all network interface 325 cards when a VPN connection is meant to be employed. Thus, 326 applications on the host running the VPN client software will 327 have no other option than to employ IPv4, and hence they will 328 simply not even try to send/process IPv6 traffic. We note 329 that this should only be regarded as a temporary workaround, 330 since the proper mitigation would be to correctly handle IPv6 331 traffic. 333 2. If IPv6 is supported in the VPN software, ensure that all IPv6 334 traffic is also sent via the VPN. 336 NOTE: This would imply, among other things, properly handling 337 any vectors that might be employed by an attacker to install 338 IPv6 routes at the victim system (such as ICMPv6 Router 339 Advertisement messages with Prefix Information Options or 340 Route information Options [RFC4191], ICMPv6 Redirect messages, 341 etc.). We note that properly handling all the aforementioned 342 vectors may prove to be non-trivial. 344 If the VPN client is configured to only send a subset of IPv4 traffic 345 to the VPN tunnel (split-tunnel mode), then: 347 1. If the VPN client does not support IPv6, it should disable IPv6 348 support in all network interfaces. 350 NOTE: As noted above, this should only be regarded as a 351 temporary workaround, since the proper mitigation would be to 352 correctly handle IPv6 traffic. 354 2. If the VPN client supports IPv6, it is the administrators 355 responsibility to ensure that the correct corresponding sets of 356 IPv4 and IPv6 networks get routed into the VPN tunnel. 358 NOTE: As noted above, this would imply, among other things, 359 properly handling any vectors that might be employed by an 360 attacker to install IPv6 routes at the victim system, and that 361 this may prove to be a non-trivial task. 363 A network may prevent local attackers from successfully performing 364 the aforementioned attacks against other local hosts by implementing 365 First-Hop Security solutions such as Router Advertisement Guard (RA- 366 Guard) [RFC6105] and DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. 367 However, for obvious reasons, a host cannot and should not rely on 368 this type of mitigations when connecting to an open network 369 (cybercafe, etc.). 371 NOTE: Besides, popular implementations of RA-Guard are known to be 372 vulnerable to evasion attacks [RFC7113]. 374 Finally, we note that if (eventually) IPv6-only VPN implementations 375 become available, similar issues to the ones discussed in this 376 document could arise if these IPv6-only VPN implementations do 377 nothing about the IPv4 traffic. 379 7.2. Operational Mitigations 381 While the desired mitigation for the issues discussed in this 382 document is for VPN clients to be IPv6-aware, we note that in 383 scenarios where this would be unfeasible, and administrator may want 384 to disable IPv6 connectivity on all network interfaces of the node 385 employing the IPv6-unaware VPN client. 387 8. IANA Considerations 389 This document has no actions for IANA. 391 9. Security Considerations 393 This document discusses how traffic meant to be transferred over a 394 VPN tunnel can leak out of such tunnel, and hence appear in the clear 395 on the local network. This is the result of employing IPv6-unaware 396 VPN client software on dual-stacked hosts. 398 The proper mitigation of this issue is to correctly handle IPv6 399 traffic in the VPN client software. However, in scenarios in which 400 such mitigation is unfeasible, an administrator may choose to disable 401 IPv6 connectivity on all network interfaces of the host employing the 402 VPN client. 404 10. Acknowledgements 406 The author would like to thank Kathleen Moriarty and Paul Hoffman who 407 contributed text that was readily incorporated into Section 2 of this 408 document. 410 The author of this document would like to thank (in alphabetical 411 order) Cameron Byrne, Spencer Dawkins, Gert Doering, Stephen Farrell, 412 Seth Hall, Paul Hoffman, Tor Houghton, Russ Housley, Joel Jaeggli, 413 Alastair Johnson, Merike Kaeo, Panos Kampanakis, Stephen Kent, Warren 414 Kumari, Henrik Lund Kramshoj, Barry Leiba, Kathleen Moriarty, Thomas 415 Osterried, Jim Small, Martin Vigoureux, and Andrew Yourtchenko for 416 providing valuable comments on earlier versions of this document. 418 11. References 420 11.1. Normative References 422 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 423 More-Specific Routes", RFC 4191, November 2005. 425 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 426 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 427 September 2007. 429 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 430 "IPv6 Router Advertisement Options for DNS Configuration", 431 RFC 6106, November 2010. 433 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 434 "Default Address Selection for Internet Protocol Version 6 435 (IPv6)", RFC 6724, September 2012. 437 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 438 Dual-Stack Hosts", RFC 6555, April 2012. 440 11.2. Informative References 442 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 443 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 444 February 2011. 446 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 447 Advertisement Guard (RA-Guard)", RFC 7113, February 2014. 449 [I-D.ietf-opsec-dhcpv6-shield] 450 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 451 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 452 opsec-dhcpv6-shield-02 (work in progress), February 2014. 454 [SI6-Toolkit] 455 "SI6 Networks' IPv6 toolkit", 456 . 458 [THC-IPv6] 459 "The Hacker's Choice IPv6 Attack Toolkit", 460 . 462 [RTADVD] "rtadvd(8) manual page", . 465 [SSL-VPNs] 466 Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72, 467 SAAG Meeting., 2008, 468 . 470 Author's Address 472 Fernando Gont 473 Huawei Technologies 474 Evaristo Carriego 2644 475 Haedo, Provincia de Buenos Aires 1706 476 Argentina 478 Phone: +54 11 4650 8472 479 Email: fgont@si6networks.com 480 URI: http://www.si6networks.com