idnits 2.17.1 draft-vyncke-advanced-ipv6-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 236: '... connection MUST be inspected by ...' RFC 2119 keyword, line 238: '...m as a guest), then the flow SHOULD be...' RFC 2119 keyword, line 239: '...tects an attack, then the flow MUST be...' RFC 2119 keyword, line 241: '... IPS, the flow MAY be allowed....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2010) is 5135 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2993' is defined on line 330, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-09 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations E. Vyncke 3 Internet-Draft M. Townsley 4 Intended status: Informational Cisco Systems 5 Expires: September 8, 2010 March 7, 2010 7 Advanced Security for IPv6 CPE 8 10 Abstract 12 This document describes how an IPv6 residential Customer Premise 13 Equipment (CPE) can leverage modern security techniques to have 14 strong security, while retaining as much of the end-to-end 15 reachability of IPv6 as possible. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 8, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Rules for Security Policy . . . . . . . . . . . . . . . . . 5 61 3.2. Security Analysis . . . . . . . . . . . . . . . . . . . . . 6 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Internet access in residential IPv4 deployments generally consist of 73 a single IPv4 address provided by the service provider for each home. 74 Residential CPE then translates the single address into multiple 75 private addresses allowing more than one device in the home, but at 76 the cost of losing end-to-end reachability. IPv6 allows all devices 77 to have a unique, global, IP address, restoring end-to-end 78 reachability directly between any device. Such reachability is very 79 powerful for ubiquitous global connectivity, and is often heralded as 80 one of the significant advantages to IPv6 over IPv4. Despite this, 81 concern about exposure to inbound packets from the IPv6 Internet 82 (which would otherwise be dropped by the address translation function 83 if they had been sent from the IPv4 Internet) remain. This document 84 describes firewall functionality for an IPv6 CPE which departs from 85 the "simple security" model described in 86 [I-D.ietf-v6ops-cpe-simple-security] . The intention is to provide 87 an example of a security model which allows most traffic, including 88 incoming unsolicited packets and connections, to traverse the CPE 89 unless the CPE identifies the traffic as potentially harmful based on 90 a set of signatures (and other correlation data and heuristics) that 91 are kept up to date on a regular basis. The computational resources 92 necessary to support some, not all, functionalities of this model are 93 likely more intensive than those described in 94 [I-D.ietf-v6ops-cpe-simple-security], but are easily within the realm 95 of what is commonly available in 2010 on medium to high-end network 96 based firewall systems for small and medium businesses, or host-based 97 commercial firewalls that run on laptop and desktop PCs. This set of 98 techniques is also known as Universal Threat Mitigation (UTM). 100 2. Threats 102 For a typical residential network connected to the Internet over a 103 broadband connection, the threats can be classified into: 105 o denial of service by packet flooding: overwhelming either the 106 access bandwidth or the bandwidth of a slower link in the 107 residential network (like a slow home automation network) or the 108 CPU power of a slow IPv6 host (like networked thermostat or any 109 other sensor type nodes) 111 o denial of service by service requests: like sending print jobs 112 from the Internet to an ink jet printer until the ink cartridge is 113 empty or like filing some file server with junk data 115 o unauthorized use of services: like accessing a webcam or a file 116 server which are open to anonymous access within the residential 117 network but should not be accessed from outside of the home 118 network 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. 122 Exploitation can be further divided in two classes: 124 1. day-0 attack when this attack has never been seen before 125 (hence nothing can really detect it) and 127 2. day+n attack where this attack is known and can be detected by 128 the use of an attack signature 130 o trojanized host (belonging to a Botnet) can communicate via a 131 covert channel to its master and launch attacks to Internet 132 targets. 134 3. Overview 136 The basic goal is to provide an adaptive security policy which aims 137 to block known harmful traffic and allow the rest, restoring as much 138 of end-to-end communication as possible. In addition, new protocols 139 may evolve and be deployed over time; only if they become a threat 140 vector does the CPE firewall receive a signature update (including 141 dynamic correlation data) to classify and block them. This is in 142 direct contrast to [I-D.ietf-v6ops-cpe-simple-security], which 143 requires built-in knowledge of a number of protocols, or requires 144 Internet communication to be limited to a handful of protocols that 145 the CPE understands how to process. 147 o Intrusion Prevention System (IPS) is a signature-based technology 148 which inspects a pre-defined set of protocols at all layers (from 149 layer-3 to layer-7) and uses a vast set of heuristics to detect 150 attacks within one or several flow. Upon detection, the flow is 151 terminated and an event is logged for further optional auditing. 152 As exploits are added every day, the signature database must be 153 updated daily and is usually quite large (more than 100 MB). This 154 requires both large local storage (large flash or even a hard 155 disk) and a subscription to an update service. 157 o Reputation database is a centralized database which gives a 158 reputation score to any IPv6 address (or prefix). The score 159 varies from untrusted to trusted. Untrusted IPv6 addresses are 160 typically addresses of a well-known attacker or from a Botnet 161 member or from an ISP with a poor track of security... Protocols 162 exist to dynamically request a reputation (based on DNS or HTTP). 163 This usually requires a subscription. Note: in IPv6 the 164 reputation database concept is still in its infancy, for example, 165 little experience exists on the scope of the reputation: a host 166 /128, a LAN prefix /64 or a delegated prefix size of /56 or /48... 168 o Local correlation uses another set of heuristics (like TCP 169 distribution of Initial Sequence Number or used TCP ports or 170 protocol handshake banners) to assert the variety of local hosts 171 (namely operating system (OS) version and set of application) and 172 raise or decrease the importance of a specific attack signature. 173 For example, if the OS of host A is OS-A, then there is no point 174 to inspect traffic to or from host A for attacks which are only 175 relevant to OS-B. 177 o Global correlation leverage all IPS distributed on the Internet to 178 build the reputation database as well as changing the relevance of 179 an IPS signature (for example, a propagating worm will trigger a 180 lot of identical signatures on several IPS, this should raise the 181 relevance of a specific signature up to the point of blocking all 182 inbound/outbound connections on a specific layer-4 port). 184 3.1. Rules for Security Policy 186 These are an example set of rules to be applied. Each would normally 187 be configurable, either by the user directly or on behalf of the user 188 by a subscription service. The default preferred state hasn't been 189 listed, though it is expected that all rules would be on by default. 191 If we named all hosts on the residential side of the CPE as 'inside' 192 and all hosts on the Internet as 'outside', then the behavior of the 193 CPE is described by a small set or rules: 195 1. Rule RejectBogon: apply unicast reverse path forwarding (RPF) 196 checks (anti-spoofing) for all inbound and outbound traffic 197 (implicitly blocking link-local and ULA in the same shot) 199 2. Rule BlockBadReputation: block all inbound and outbound packets 200 whose outside IPv6 address has a bad reputation score 202 3. Rule AllowReturn: inspect all outbound traffic and allow the 203 return traffic matching the states (5-tuple + TCP sequence number 204 or any layer-4 state), apply IPS on the outbound (to block 205 Botnet) and inbound (to block malicious/cracked servers which 206 could inject malware) with IPS. If the protocol is not 207 supported/recognized by the IPS, accept it anyway. 209 4. Rule AllowToPublicDnsHost: allow all inbound traffic to any 210 inside address which is listed in the public DNS with a AAAA 211 record (this requires that the CPE/RG can do a zone transfer, 212 i.e., that the CPE/RG appears like a secondary name server), all 213 inbound traffic is also inspected with IPS. If the protocol is 214 not supported/recognized by the IPS, accept it anyway. 216 5. Rule ProtectLocalOnly: block all inbound traffic to any inside 217 address as long as the inside address has never sent a packet to 218 the outside. The intent is to protect local-only devices like 219 thermostat or printers. Most (if not all) hosts expecting 220 inbound connections have to send a couple of outbound packets to 221 the outside (registration, DNS request, ...). This is the usual 222 IPv4 firewall behavior augmented with IPS and reputation 224 6. Rule CrypoIntercept: at the exception of IPsec, all inbound 225 connections that are encrypted (notably TLS [RFC5246]) must be 226 intercepted (this is terminated by the CPE that will present its 227 own self-signed certificate to the remote party which should have 228 installed the CPE self-signed certificate in a secure way in its 229 trust anchors store) in order to allow for further inspection. 230 The decrypted flow is then passed again through those rules and 231 encrypted again before being forwarded to the local host. 233 7. Rule ParanoidOpeness: allow all unsolicited inbound connections 234 rate limited to protect against port and address scanning attacks 235 or overloading devices or slow links within the home. The 236 connection MUST be inspected by the IPS engine. If the 237 connection is anonymous or using a default password (like 238 connecting to a webcam as a guest), then the flow SHOULD be 239 dropped. If the IPS detects an attack, then the flow MUST be 240 closed. If the protocol is not recognized as supported by the 241 IPS, the flow MAY be allowed. 243 3.2. Security Analysis 245 This proposal of 'paranoid openness' stops the following attacks: 247 o unauthorized use of services/denial of service: because all 248 anonymous access to inside servers are blocked. 250 o Denial of services on low bandwidth or low CPU inside hosts IFF 251 those hosts never access the Internet 253 o Exploiting of a day+1 attack, those attacks are blocked with the 254 IPS signature and address reputation database 256 The CryptoIntercept part can also be leveraged as a small 257 Certification Authority (CA) that could generate RSA key pairs and 258 X.509 certificates at the CPE/RG owner's request. Those key pairs 259 and certificates can then be given to trusted devices or users (like 260 the owner's laptop so that he/she could easily and safely connect 261 from the outside). 263 This proposal cannot help with the following attacks: 265 o flooding the access link to the Internet, this is exactly the same 266 as with the old layers-3/4 firewall approach as only the ISP can 267 effectively stop the flooding of the CE-PE link; 269 o weak password on inside services, of course the IPS component will 270 detect multiple failed attempts (dictionary attack) and report the 271 offender to the Global Correlation system; 273 o exploiting of day-0 attack: until now, these day-0 attacks are 274 caused either by rapidly propagating worms (then the global 275 correlation of unusual traffic pattern will raise an alert and 276 block the traffic after a couple of hundred's of successful 277 attacks) or by targeted attacks against high-profile targets (like 278 Government or banks or ;..) which should be protected by 279 conventional less open security policies; 281 o exploiting a vulnerability in a rare or new protocol (not yet 282 supported by the IPS), this case will probably never occur on a 283 wide scale in a residential use of Internet. 285 4. IANA Considerations 287 There are no extra IANA consideration for this document. 289 5. Security Considerations 291 All security considerations have been done in the Security Analysis 292 Section 3.2. 294 It is also advisable that the inbound rate limiter system could be 295 added to the [I-D.ietf-v6ops-cpe-simple-security] as it is light and 296 does not depend on a centralized policy server. 298 6. Acknowledgements 300 Many thanks to Ole Troan, Stuart Cheshire, Dave Oran and Eliot Lear 301 for the review of the -00 version and to Ron Bonica, Sam Hartmans, 302 Lee Howard, Greg Lebovitz, Jordi Palet, Tina Tsou and others for 303 their comments during and after the first presentation at the 304 Hiroshima IETF meeting in November 2009. 306 A previous IETF work has similar ideas 307 [I-D.palet-v6ops-ipv6security]. 309 7. References 311 7.1. Normative References 313 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 314 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 316 7.2. Informative References 318 [I-D.ietf-v6ops-cpe-simple-security] 319 Woodyatt, J., "Recommended Simple Security Capabilities in 320 Customer Premises Equipment for Providing Residential IPv6 321 Internet Service", draft-ietf-v6ops-cpe-simple-security-09 322 (work in progress), February 2010. 324 [I-D.palet-v6ops-ipv6security] 325 Palet, J., Vives, A., Martinez, G., and A. Gomez, "IPv6 326 distributed security requirements", 327 draft-palet-v6ops-ipv6security-02 (work in progress), 328 February 2005. 330 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 331 November 2000. 333 Authors' Addresses 335 Eric Vyncke 336 Cisco Systems 337 De Kleetlaan 6a 338 Diegem 1831 339 Belgium 341 Phone: +32 2 778 4677 342 Email: evyncke@cisco.com 343 Mark Townsley 344 Cisco Systems 345 11, Rue Camille Desmoulins 346 Issy Les Moulineaux 92782 347 France 349 Phone: +33 15 804 3483 350 Email: townsley@cisco.com