idnits 2.17.1 draft-ietf-v6ops-balanced-ipv6-security-01.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 (December 05, 2013) is 3794 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations M. Gysi 3 Internet-Draft Swisscom 4 Intended status: Informational G. Leclanche 5 Expires: June 8, 2014 Viagenie 6 E. Vyncke, Ed. 7 Cisco Systems 8 R. Anfinsen 9 Altibox 10 December 05, 2013 12 Balanced Security for IPv6 Residential CPE 13 draft-ietf-v6ops-balanced-ipv6-security-01 15 Abstract 17 This document describes how an IPv6 residential Customer Premise 18 Equipment (CPE) can have a balanced security policy that allows for a 19 mostly end-to-end connectivity while keeping the major threats 20 outside of the home. It is documenting an existing IPv6 deployment 21 by Swisscom and allows all packets inbound/outbound EXCEPT for some 22 layer-4 ports where attacks and vulnerabilities (such as weak 23 passwords) are well-known. The policy is a proposed set of rules 24 that can be used as a default setting. The set of blocked inbound 25 and outbound ports is expected to be updated as threats come and go. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 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 June 8, 2014. 44 Copyright Notice 46 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Rules for Balanced Security Policy . . . . . . . . . . . 4 65 3.2. Rules Example for Layer-4 Protection: Swisscom 66 Implementation . . . . . . . . . . . . . . . . . . . . . 5 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 7. Informative References . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Internet access in residential IPv4 deployments generally consists of 76 a single IPv4 address provided by the service provider for each home. 77 The residential CPE then translates the single address into multiple 78 private IPv4 addresses allowing more than one device in the home, but 79 at the cost of losing end-to-end reachability. IPv6 allows all 80 devices to have a globally unique IP address, restoring end-to-end 81 reachability directly between any device. Such reachability is very 82 powerful for ubiquitous global connectivity, and is often heralded as 83 one of the significant advantages to IPv6 over IPv4. Despite this, 84 concern about exposure to inbound packets from the IPv6 Internet 85 (which would otherwise be dropped by the address translation function 86 if they had been sent from the IPv4 Internet) remain. 88 This difference in residential default internet protection between 89 IPv4 and IPv6 is a major concern to a sizable number of ISPs and the 90 security policy described in this document addresses this concern 91 without damaging IPv6 end-to-end connectivity. 93 The security model provided in this document is meant to be used as a 94 pre-registered setting and potentially default one for IPv6 security 95 in CPEs. The model departs from the "simple security" model 96 described in [RFC6092] . It allows most traffic, including incoming 97 unsolicited packets and connections, to traverse the CPE unless the 98 CPE identifies the traffic as potentially harmful based on a set of 99 rules. This policy has been deployed as a default setting in 100 Switzerland by Swisscom for residential CPEs. 102 This document can be applicable to off-the-shelves CPE as well as to 103 managed Service Provider CPE or for mobile Service Providers (where 104 it can be centrally implemented). 106 2. Threats 108 For a typical residential network connected to the Internet over a 109 broadband or mobile connection, the threats can be classified into: 111 o denial of service by packet flooding: overwhelming either the 112 access bandwidth or the bandwidth of a slower link in the 113 residential network (like a slow home automation network) or the 114 CPU power of a slow IPv6 host (like networked thermostat or any 115 other sensor type nodes); 117 o denial of service by Neighbor Discovery cache exhaustion 118 [RFC6583]: the outside attacker floods the inside prefix(es) with 119 packets with a random destination address forcing the CPE to 120 exhaust its memory and its CPU in useless Neighbor Solicitations; 122 o denial of service by service requests: like sending print jobs 123 from the Internet to an ink jet printer until the ink cartridge is 124 empty or like filing some file server with junk data; 126 o unauthorized use of services: like accessing a webcam or a file 127 server which are open to anonymous access within the residential 128 network but should not be accessed from outside of the home 129 network or accessing to remote desktop or SSH with weak password 130 protection; 132 o exploiting a vulnerability in the host in order to get access to 133 data or to execute some arbitrary code in the attacked host; 135 o trojanized host (belonging to a Botnet) can communicate via a 136 covert channel to its master and launch attacks to Internet 137 targets. 139 3. Overview 140 The basic goal is to provide a pre-defined security policy which aims 141 to block known harmful traffic and allow the rest, restoring as much 142 of end-to-end communication as possible. This pre-defined policy 143 should be centrally updated, as threats are changing over time. It 144 could also be a member of a list of pre-defined security policies 145 available to an end-customer, for example together with "simple 146 security" from [RFC6092] and a "strict security" policy denying 147 access to all unexpected input packets. 149 3.1. Rules for Balanced Security Policy 151 These are an example set of generic rules to be applied. Each would 152 normally be configurable, either by the user directly or on behalf of 153 the user by a subscription service. This document does not address 154 the statefulness of the filtering rules as its main objective is to 155 present an approach where some protocols (identified by layer-4 156 ports) are assumed weak or malevolent and therefore are blocked while 157 all other protocols are assumed benevolent and are permitted. 159 If we name all nodes on the residential side of the CPE as 'inside' 160 and all nodes on the Internet as 'outside', and any packet sent from 161 outside to inside as being 'inbound' and 'outbound' in the other 162 direction, then the behavior of the CPE is described by a small set 163 or rules: 165 1. Rule RejectBogon: apply ingress filtering in both directions per 166 [RFC3704] and [RFC2827] for example with unicast reverse path 167 forwarding (uRPF) checks (anti-spoofing) for all inbound and 168 outbound traffic (implicitly blocking link-local and ULA in the 169 same shot), as described in Section 2.1 Basic Sanitation and 170 Section 3.1 Stateless Filters of [RFC6092]; 172 2. Rule AllowManagement: if the CPE is managed by the SP, then allow 173 the management protocols (SSH, SNMP, syslog, TR-069, IPfix, ...) 174 from/to the SP Network Operation Center; 176 3. Rule ProtectWeakServices: drop all inbound and outbound packets 177 whose layer-4 destination is part of a limited set (see 178 Section 3.2), the intent is to protect against the most common 179 unauthorized access and avoid propagation of worms; an advanced 180 residential user should be able to modify this pre-defined list; 182 4. Rule Openess: allow all unsolicited inbound packets with rate 183 limiting the initial packet of a new connection (such as TCP SYN, 184 SCTP INIT or DCCP-request, not applicable to UDP) to provide very 185 basic protection against SYN port and address scanning attacks. 186 All transport protocols and all non-deprecated extension headers 187 are accepted. This is a the major deviation from REC-11, REC-17 188 and REC-33 of [RFC6092]. 190 5. All requirements of [RFC6092] except REC-11, REC-18 and REC-33 191 must be supported. 193 3.2. Rules Example for Layer-4 Protection: Swisscom Implementation 195 As of 2013, Swisscom has implemented the rule ProtectWeakService as 196 described below. This is meant as an example and must not be 197 followed blindly: each implementer has specific needs and 198 requirements. Furthermore, the example below will not be updated as 199 time passes, whereas threats will evolve. 201 +-----------+------+-----------------------------------+ 202 | Transport | Port | Description | 203 +-----------+------+-----------------------------------+ 204 | tcp | 22 | Secure Shell (SSH) | 205 | tcp | 23 | Telnet | 206 | tcp | 80 | HTTP | 207 | tcp | 3389 | Microsoft Remote Desktop Protocol | 208 | tcp | 5900 | VNC remote desktop protocol | 209 +-----------+------+-----------------------------------+ 211 Table 1: Drop Inbound 213 +-----------+------+-----------------------------------+ 214 | Transport | Port | Description | 215 +-----------+------+-----------------------------------+ 216 | tcp-udp | 88 | Kerberos | 217 | tcp | 111 | SUN Remote Procedure Call | 218 | tcp | 135 | MS Remote Procedure Call | 219 | tcp | 139 | NetBIOS Session Service | 220 | tcp | 445 | Microsoft SMB Domain Server | 221 | tcp | 513 | Remote Login | 222 | tcp | 514 | Remote Shell | 223 | tcp | 548 | Apple Filing Protocol over TCP | 224 | tcp | 631 | Internet Printing Protocol | 225 | udp | 1900 | Simple Service Discovery Protocol | 226 | tcp | 2869 | Simple Service Discovery Protocol | 227 | udp | 3702 | Web Services Dynamic Discovery | 228 | udp | 5353 | Multicast DNS | 229 | udp | 5355 | Link-Lcl Mcast Name Resolution | 230 +-----------+------+-----------------------------------+ 232 Table 2: Drop Inbound and Outbound 234 Choosing services to protect is not an easy task, and as of 2013 235 there is no public service proposing a list of ports to use in such a 236 policy. The Swisscom approach was to think in terms of services, by 237 defining a list of services that are LAN-Only (ex: Multicast DNS) 238 whose communication is denied by the policy both inbound and 239 outbound, and a list of services that are known to be weak or 240 vulnerable like management protocols that could be activated 241 unbeknownst to the user. 243 The process used to set-up and later update the filters is out of 244 scope of this document. The update of the specific rules could be 245 done together with a firmware upgrade or by a policy update (for 246 example using Broadband Forum TR-069). 248 Among other sources, [DSHIELD] was used by Swisscom to set-up their 249 filters. Another source of information could be the appendix A of 250 [TR124]. The L4-filter as described does not block GRE tunnels 251 ([RFC2473]) so this is a deviation from [RFC6092]. 253 Note: the authors believe that with a dozen of rules only, a naive 254 and unaware residential subscriber would be reasonably protected. Of 255 course, technically-aware susbcribers should be able to open other 256 applications (identified by their layer-4 ports or IP protocol 257 numbers) through their CPE using some kind of user interface or even 258 to select a completely different security policy such as the open or 259 'closed' policies defined by [RFC6092]. This is the case in the 260 Swisscom deployment. 262 It is worth mentioning that PCP ([RFC6887]), UPnP ([IGD]) and similar 263 protocols can also be used to dynamically override the default rules. 265 4. IANA Considerations 267 There are no extra IANA consideration for this document. 269 5. Security Considerations 271 The security policy protects from the following type of attacks: 273 o Unauthorized access because vulnerable ports are blocked 275 Depending on the extensivity of the filters, certain vulnerabilities 276 could be protected or not. It does not preclude the need for end- 277 devices to have proper host-protection as most of those devices 278 (smartphones, laptops, etc.) would anyway be exposed to completely 279 unfiltered internet at some point of time. The policy addresses the 280 major concerns related to the loss of stateful filtering imposed by 281 IPV4 NAPT when enabling public globally reachable IPv6 in the home. 283 To the authors' knowledge, there has not been any incident related to 284 this deployment in Swisscom network, and no customer complaints have 285 been registered. 287 This set of rules cannot help with the following attacks: 289 o Flooding of the CPE access link; 291 o Malware which is fetched by inside hosts on a hostile web site 292 (which is in 2013 the majority of infection sources). 294 6. Acknowledgements 296 The authors would like to thank several people who initiated the 297 discussion on the ipv6-ops@lists.cluenet.de mailing list and others 298 who provided us valuable feedback and comments, notably: Tore 299 Anderson, Rajiv Asati, Fred Baker, Lorenzo Colitti, Paul Hoffman, 300 Merike Kaeo, Simon Leinen, Eduard Metz, Martin Millnert, Benedikt 301 Stockebrand. Thanks as well to the following SP that discussed with 302 the authors about this technique: Altibox, Swisscom and Telenor. 304 7. Informative References 306 [DSHIELD] DShield, "Port report: DShield", . 309 [IGD] UPnP Forum, "WANIPConnection:2 Service", December 20110, 310 . 313 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 314 IPv6 Specification", RFC 2473, December 1998. 316 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 317 Defeating Denial of Service Attacks which employ IP Source 318 Address Spoofing", BCP 38, RFC 2827, May 2000. 320 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 321 Networks", BCP 84, RFC 3704, March 2004. 323 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 324 Customer Premises Equipment (CPE) for Providing 325 Residential IPv6 Internet Service", RFC 6092, January 326 2011. 328 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 329 Neighbor Discovery Problems", RFC 6583, March 2012. 331 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 332 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 333 2013. 335 [TR124] Broadband Forum, "Functional Requirements for Broadband 336 Residential Gateway Devices", December 2006, . 339 Authors' Addresses 341 Martin Gysi 342 Swisscom 343 Binzring 17 344 Zuerich 8045 345 Switzerland 347 Phone: +41 58 223 57 24 348 Email: Martin.Gysi@swisscom.com 350 Guillaume Leclanche 351 Viagenie 352 246 Aberdeen 353 Quebec, QC G1R 2E1 354 Canada 356 Phone: +1 418 656 9254 357 Email: guillaume.leclanche@viagenie.ca 359 Eric Vyncke (editor) 360 Cisco Systems 361 De Kleetlaan 6a 362 Diegem 1831 363 Belgium 365 Phone: +32 2 778 4677 366 Email: evyncke@cisco.com 367 Ragnar Anfinsen 368 Altibox 369 Breiflaatveien 18 370 Stavanger 4069 371 Norway 373 Phone: +47 93488235 374 Email: Ragnar.Anfinsen@altibox.no