idnits 2.17.1 draft-v6ops-vyncke-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 (July 15, 2013) is 3939 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 G. Leclanche 4 Intended status: Informational Swisscom 5 Expires: January 16, 2014 E. Vyncke, Ed. 6 Cisco Systems 7 R. Anfinsen 8 Altibox 9 July 15, 2013 11 Balanced Security for IPv6 CPE 12 draft-v6ops-vyncke-balanced-ipv6-security-01.txt 14 Abstract 16 This document describes how an IPv6 residential Customer Premise 17 Equipment (CPE) can have a balanced security policy that allows for a 18 mostly end-to-end connectivity while keeping the major threats 19 outside of the home. It is based on an actual IPv6 deployment by 20 Swisscom and proposes to allow all packets inbound/outbound EXCEPT 21 for some layer-4 ports where attacks and vulnerabilities (such as 22 weak passwords) are well-known. 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 January 16, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Rules for Balanced Security Policy . . . . . . . . . . . 3 62 3.2. Rules example for Layer-4 Protection as Used by Swisscom 4 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Informative References . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 Internet access in residential IPv4 deployments generally consist of 72 a single IPv4 address provided by the service provider for each home. 73 Residential CPE then translates the single address into multiple 74 private IPv4 addresses allowing more than one device in the home, but 75 at the cost of losing end-to-end reachability. IPv6 allows all 76 devices to have a unique, global, IP address, restoring end-to-end 77 reachability directly between any device. Such reachability is very 78 powerful for ubiquitous global connectivity, and is often heralded as 79 one of the significant advantages to IPv6 over IPv4. Despite this, 80 concern about exposure to inbound packets from the IPv6 Internet 81 (which would otherwise be dropped by the address translation function 82 if they had been sent from the IPv4 Internet) remain. This document 83 describes firewall functionality for an IPv6 CPE which departs from 84 the "simple security" model described in [RFC6092] . The intention is 85 to provide an example of a security model which allows most traffic, 86 including incoming unsolicited packets and connections, to traverse 87 the CPE unless the CPE identifies the traffic as potentially harmful 88 based on a set of rules. This model has been deployed successfully 89 in Switzerland by Swisscom without any known security incident. 91 This document is applicable to off-the-shelves CPE as well to managed 92 Service Provider CPE or for mobile Service Providers (where it can be 93 centrally implemented). 95 2. Threats 96 For a typical residential network connected to the Internet over a 97 broadband connection, the threats can be classified into: 99 o denial of service by packet flooding: overwhelming either the 100 access bandwidth or the bandwidth of a slower link in the 101 residential network (like a slow home automation network) or the 102 CPU power of a slow IPv6 host (like networked thermostat or any 103 other sensor type nodes); 105 o denial of service by Neighbor Discovery cache exhaustion 106 [RFC6583]: the outside attacker floods the inside prefix(es) with 107 packets with a random destination address forcing the CPE to 108 exhaust its memory and its CPU in useless Neighbor Solicitations; 110 o denial of service by service requests: like sending print jobs 111 from the Internet to an ink jet printer until the ink cartridge is 112 empty or like filing some file server with junk data; 114 o unauthorized use of services: like accessing a webcam or a file 115 server which are open to anonymous access within the residential 116 network but should not be accessed from outside of the home 117 network or accessing to remote desktop or SSH with weak password 118 protection; 120 o exploiting a vulnerability in the host in order to get access to 121 data or to execute some arbitrary code in the attacked host such 122 as several against old versions of Windows; 124 o trojanized host (belonging to a Botnet) can communicate via a 125 covert channel to its master and launch attacks to Internet 126 targets. 128 3. Overview 130 The basic goal is to provide a pre-defined security policy which aims 131 to block known harmful traffic and allow the rest, restoring as much 132 of end-to-end communication as possible. This pre-defined policy can 133 be centrally updated and could also be a member of a security policy 134 menu for the subscriber. 136 3.1. Rules for Balanced Security Policy 138 These are an example set of generic rules to be applied. Each would 139 normally be configurable, either by the user directly or on behalf of 140 the user by a subscription service. 142 If we name all nodes on the residential side of the CPE as 'inside' 143 and all nodes on the Internet as 'outside', and any packet sent from 144 outside to inside as being 'inbound' and 'outbound' in the other 145 direction, then the behavior of the CPE is described by a small set 146 or rules: 148 1. Rule RejectBogon: apply ingress filtering in both directions per 149 [RFC3704] and [RFC2827] for example with unicast reverse path 150 forwarding (uRPF) checks (anti-spoofing) for all inbound and 151 outbound traffic (implicitly blocking link-local and ULA in the 152 same shot), this is basically the Section 2.1 Basic Sanitation 153 and Section 3.1 Stateless Filters of [RFC6092]; 155 2. Rule ProtectWeakServices: drop all inbound and outbound packets 156 whose layer-4 destination is part of a limited set (see 157 Section 3.2), the intent is to protect against the most common 158 unauthorized access and avoid propagation of worms (even if the 159 latter is questionable in IPv6); an advanced residential user 160 should be able to modify this pre-defined list; 162 3. Rule Openess: allow all unsolicited inbound packets with rate 163 limiting the initial packet of a new connection (such as TCP SYN, 164 SCTP INIT or DCCP-request not applicable to UDP) to provide very 165 basic protection against SYN port and address scanning attacks. 166 All transport protocols and all non-deprecated extension headers 167 are accepted. This a the major deviation from REC-11, REC-17 and 168 REC-33 of [RFC6092]. 170 4. All requirements of [RFC6092] except REC-11, REC-18 and REC-33 171 must be supported. 173 3.2. Rules example for Layer-4 Protection as Used by Swisscom 175 The rule ProtectWeakService can be implemented by using the following 176 suggestions as implemented by Swisscom in 2013: 178 +-----------+------+-----------------------------------+ 179 | Transport | Port | Description | 180 +-----------+------+-----------------------------------+ 181 | tcp | 22 | Secure Shell (SSH) | 182 | tcp | 23 | Telnet | 183 | tcp | 80 | HTTP | 184 | tcp | 3389 | Microsoft Remote Desktop Protocol | 185 | tcp | 5900 | VNC remote desktop protocol | 186 +-----------+------+-----------------------------------+ 188 Table 1: Drop Inbound 190 +-----------+------+-----------------------------------+ 191 | Transport | Port | Description | 192 +-----------+------+-----------------------------------+ 193 | tcp-udp | 88 | Kerberos | 194 | tcp | 111 | SUN Remote Procedure Call | 195 | tcp | 135 | MS Remote Procedure Call | 196 | tcp | 139 | NetBIOS Session Service | 197 | tcp | 445 | Microsoft SMB Domain Server | 198 | tcp | 513 | Remote Login | 199 | tcp | 514 | Remote Shell | 200 | tcp | 548 | Apple Filing Protocol over TCP | 201 | tcp | 631 | Internet Printing Protocol | 202 | udp | 1900 | Simple Service Discovery Protocol | 203 | tcp | 2869 | Simple Service Discovery Protocol | 204 | udp | 3702 | Web Services Dynamic Discovery | 205 | udp | 5353 | Multicast DNS | 206 | udp | 5355 | Link-Lcl Mcast Name Resolution | 207 +-----------+------+-----------------------------------+ 209 Table 2: Drop Inbound and Outbound 211 This list should evolve with the time as new protocols and new 212 threats appear, [DSHIELD] is used by Swisscom to keep those filters 213 up to date. Another source of information could be the appendix A of 214 [TR124]. The above proposal does not block GRE tunnels ([RFC2473]) 215 so this is a deviation from [RFC6092]. 217 Note: the authors believe that with this set the usual residential 218 subscriber, the proverbial grand-ma, is protected. Of course, 219 technical susbcribers should be able to open other applications 220 (identified by their TCP or UDP ports) through their CPE through some 221 kind of user interface or even select a completely different security 222 policy such as the open or 'closed' policies defined by [RFC6092]. 224 4. IANA Considerations 226 There are no extra IANA consideration for this document. 228 5. Security Considerations 230 The authors of the documents believe and the Swisscom deployment 231 shows that the following attack are mostly stopped: 233 o Unauthorized access because vulnerable ports are blocked 235 This proposal cannot help with the following attacks: 237 o Flooding of the CPE access link; 238 o Malware which is fetched by inside hosts on a hostile web site 239 (which is in 2012 the majority of infection sources). 241 6. Acknowledgements 243 The authors would like to thank several people who initiated the 244 discussion on the ipv6-ops@lists.cluenet.de mailing list, notably: 245 Tore Anderson, Lorenzo Colitti, Merike Kaeo, Simon Leinen, Eduard 246 Metz, Martin Millnert, Benedikt Stockebrand. 248 7. Informative References 250 [DSHIELD] DShield, "Port report: DShield", , . 253 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 254 IPv6 Specification", RFC 2473, December 1998. 256 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 257 Defeating Denial of Service Attacks which employ IP Source 258 Address Spoofing", BCP 38, RFC 2827, May 2000. 260 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 261 Networks", BCP 84, RFC 3704, March 2004. 263 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 264 Customer Premises Equipment (CPE) for Providing 265 Residential IPv6 Internet Service", RFC 6092, January 266 2011. 268 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 269 Neighbor Discovery Problems", RFC 6583, March 2012. 271 [TR124] Broadband Forum, "Functional Requirements for Broadband 272 Residential Gateway Devices", December 2006, . 275 Authors' Addresses 277 Martin Gysi 278 Swisscom 279 Switzerland 281 Email: Martin.Gysi@swisscom.com 282 Guillaume Leclanche 283 Swisscom 284 Switzerland 286 Email: Guillaume.Leclanche@swisscom.com 288 Eric Vyncke (editor) 289 Cisco Systems 290 De Kleetlaan 6a 291 Diegem 1831 292 Belgium 294 Phone: +32 2 778 4677 295 Email: evyncke@cisco.com 297 Ragnar Anfinsen 298 Altibox 299 Norway 301 Email: Ragnar.Anfinsen@altibox.no