idnits 2.17.1 draft-vyncke-advanced-ipv6-security-03.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 : ---------------------------------------------------------------------------- ** 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 237: '... GUI MUST be provided to educate...' RFC 2119 keyword, line 246: '... connection MUST be inspected by ...' RFC 2119 keyword, line 248: '...m as a guest), then the flow SHOULD be...' RFC 2119 keyword, line 249: '...tects an attack, then the flow MUST be...' RFC 2119 keyword, line 251: '... 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 (October 31, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2993' is defined on line 334, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet E. Vyncke 3 Internet-Draft A. Yourtchenko 4 Intended status: Informational M. Townsley 5 Expires: May 3, 2012 Cisco Systems 6 October 31, 2011 8 Advanced Security for IPv6 CPE 9 draft-vyncke-advanced-ipv6-security-03.txt 11 Abstract 13 This document describes how an IPv6 residential Customer Premise 14 Equipment (CPE) can leverage modern security techniques to have 15 strong security, while retaining as much of the end-to-end 16 reachability of IPv6 as possible. 18 It is a re-submission in the framework of the HOMENET working group. 19 The reputation part of this document should leverage the work done in 20 the REPUTE working group of the Application are. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Rules for Security Policy . . . . . . . . . . . . . . . . . 5 60 3.2. Security Analysis . . . . . . . . . . . . . . . . . . . . . 6 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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 addresses allowing more than one device in the home, but at 75 the cost of losing end-to-end reachability. IPv6 allows all devices 76 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 85 is to provide an example of a security model which allows most 86 traffic, including incoming unsolicited packets and connections, to 87 traverse the CPE unless the CPE identifies the traffic as potentially 88 harmful based on a set of signatures (and other correlation data and 89 heuristics) that are kept up to date on a regular basis. The 90 computational resources necessary to support some, not all, 91 functionalities of this model are likely more intensive than those 92 described in [RFC6092], but are easily within the realm of what is 93 commonly available in 2011 on medium to high-end network based 94 firewall systems for small and medium businesses, or host-based 95 commercial firewalls that run on laptop and desktop PCs. This set of 96 techniques is also known as Universal Threat Mitigation (UTM). 98 2. Threats 100 For a typical residential network connected to the Internet over a 101 broadband connection, the threats can be classified into: 103 o denial of service by packet flooding: overwhelming either the 104 access bandwidth or the bandwidth of a slower link in the 105 residential network (like a slow home automation network) or the 106 CPU power of a slow IPv6 host (like networked thermostat or any 107 other sensor type nodes) 109 o denial of service by service requests: like sending print jobs 110 from the Internet to an ink jet printer until the ink cartridge is 111 empty or like filing some file server with junk data 113 o unauthorized use of services: like accessing a webcam or a file 114 server which are open to anonymous access within the residential 115 network but should not be accessed freely and anonymously from 116 outside of the home network 118 o exploiting a vulnerability in the host in order to get access to 119 data or to execute some arbitrary code in the attacked host. 120 Exploitation can be further divided in two classes: 122 1. day-0 attack when this attack has never been seen before 123 (hence nothing can really detect it) and 125 2. day+n attack where this attack is known and can be detected by 126 the use of an attack signature 128 o trojanized host (belonging to a Botnet) can communicate via a 129 covert channel to its master and launch attacks to Internet 130 targets. 132 3. Overview 134 The basic goal is to provide an adaptive security policy which aims 135 to block known harmful traffic and allow the rest, restoring as much 136 of end-to-end communication as possible. In addition, new protocols 137 may evolve and be deployed over time; only if they become a threat 138 vector does the CPE firewall receive a signature update (including 139 dynamic correlation data) to classify and block them. This is in 140 direct contrast to [RFC6092], which requires built-in knowledge of a 141 number of protocols, or requires Internet communication to be limited 142 to a handful of protocols that the CPE understands how to process. 144 o Intrusion Prevention System (IPS) is a signature-based technology 145 which inspects a pre-defined set of protocols at all layers (from 146 layer-3 to layer-7) and uses a vast set of heuristics to detect 147 attacks within one or several flow. Upon detection, the flow is 148 terminated and an event is logged for further optional auditing. 149 As exploits are added every day, the signature database must be 150 updated daily and is usually quite large (more than 100 MB). This 151 requires both large local storage (large flash or even a hard 152 disk) and a subscription to an update service. 154 o Reputation database is a centralized database which gives a 155 reputation score to any IPv6 address (or prefix). The score 156 varies from untrusted to trusted. Untrusted IPv6 addresses are 157 typically addresses of a well-known attacker or from a Botnet 158 member or from an ISP with a poor track of security... Protocols 159 exist to dynamically request a reputation (based on DNS or HTTP). 160 This usually requires a subscription. Note: in IPv6 the 161 reputation database concept is still in its infancy, for example, 162 little experience exists on the scope of the reputation: a host 163 /128, a LAN prefix /64 or a delegated prefix size of /56 or /48... 165 o Local correlation uses another set of heuristics (like TCP 166 distribution of Initial Sequence Number or used TCP ports or 167 protocol handshake banners) to assert the variety of local hosts 168 (namely operating system (OS) version and set of application) and 169 raise or decrease the importance of a specific attack signature. 170 For example, if the OS of host A is OS-A, then there is no point 171 to inspect traffic to or from host A for attacks which are only 172 relevant to OS-B. 174 o Global correlation leverage all IPS distributed on the Internet to 175 build the reputation database as well as changing the relevance of 176 an IPS signature (for example, a propagating worm will trigger a 177 lot of identical signatures on several IPS, this should raise the 178 relevance of a specific signature up to the point of blocking all 179 inbound/outbound connections on a specific layer-4 port). 181 The above techniques are common in the large network where budget is 182 enough to buy firewalls, IPS and subscribe to signature or reputation 183 source. The authors of this document believes that competition and 184 Moore's law will make the set of those techniques (commonly referred 185 to as 'Universal Threat Mitigation') affordable for consumer space. 187 3.1. Rules for Security Policy 189 These are an example set of rules to be applied. Each would normally 190 be configurable, either by the user directly or on behalf of the user 191 by a subscription service. The default preferred state hasn't been 192 listed, though it is expected that all rules would be on by default. 194 If we named all hosts on the residential side of the CPE as 'inside' 195 and all hosts on the Internet as 'outside', then the behavior of the 196 CPE is described by a small set or rules: 198 1. Rule RejectBogon: apply unicast reverse path forwarding (RPF) 199 checks (anti-spoofing) for all inbound and outbound traffic 200 (implicitly blocking link-local and ULA in the same shot) 202 2. Rule BlockBadReputation: block all inbound and outbound packets 203 whose outside IPv6 address has a bad reputation score 205 3. Rule AllowReturn: inspect all outbound traffic and allow the 206 return traffic matching the states (5-tuple + TCP sequence number 207 or any layer-4 state), apply IPS on the outbound (to block 208 Botnet) and inbound (to block malicious/cracked servers which 209 could inject malware) with IPS. If the protocol is not 210 supported/recognized by the IPS, accept it anyway. 212 4. Rule AllowToPublicDnsHost: allow all inbound traffic to any 213 inside address which is listed in the public DNS with a AAAA 214 record (this requires that the CPE/RG can do a zone transfer, 215 i.e., that the CPE/RG appears like a secondary name server), all 216 inbound traffic is also inspected with IPS. If the protocol is 217 not supported/recognized by the IPS, accept it anyway. 219 5. Rule ProtectLocalOnly: block all inbound traffic to any inside 220 address as long as the inside address has never sent a packet to 221 the outside. The intent is to protect local-only devices like 222 thermostat or printers. Most (if not all) hosts expecting 223 inbound connections have to send a couple of outbound packets to 224 the outside (registration, DNS request, ...). This is the usual 225 IPv4 firewall behavior augmented with IPS and reputation 227 6. Rule CrypoIntercept: at the exception of IPsec, all inbound 228 connections that are encrypted (notably TLS [RFC5246]) must be 229 intercepted (this is terminated by the CPE that will present its 230 own self-signed certificate to the remote party which should have 231 installed the CPE self-signed certificate in a secure way in its 232 trust anchors store) in order to allow for further inspection. 233 The decrypted flow is then passed again through those rules and 234 encrypted again before being forwarded to the local host. This 235 is actually a Man-in-the-Middle attack done for a good reason: 236 protect the naive residential user. Of course, documentation and 237 GUI MUST be provided to educate the user and help him/her to 238 understand how to do it in a secure way. Note: this technique 239 is also used nowadays by large enterprise web proxies with the 240 self-signed certificate being securely distributed to all 241 clients. 243 7. Rule ParanoidOpeness: allow all unsolicited inbound connections 244 rate limited to protect against port and address scanning attacks 245 or overloading devices or slow links within the home. The 246 connection MUST be inspected by the IPS engine. If the 247 connection is anonymous or using a default password (like 248 connecting to a webcam as a guest), then the flow SHOULD be 249 dropped. If the IPS detects an attack, then the flow MUST be 250 closed. If the protocol is not recognized as supported by the 251 IPS, the flow MAY be allowed. 253 3.2. Security Analysis 255 This proposal of 'paranoid openness' stops the following attacks: 257 o unauthorized use of services/denial of service: because all 258 anonymous access to inside servers are blocked. 260 o Denial of services on low bandwidth or low CPU inside hosts IFF 261 those hosts never access the Internet 263 o Exploiting of a day+1 attack, those attacks are blocked with the 264 IPS signature and address reputation database 266 The CryptoIntercept part can also be leveraged as a small 267 Certification Authority (CA) that could generate RSA key pairs and 268 X.509 certificates at the CPE/RG owner's request. Those key pairs 269 and certificates can then be given to trusted devices or users (like 270 the owner's laptop so that he/she could easily and safely connect 271 from the outside). 273 This proposal cannot help with the following attacks: 275 o flooding the access link to the Internet, this is exactly the same 276 as with the old layers-3/4 firewall approach as only the ISP can 277 effectively stop the flooding of the CE-PE link; 279 o weak password on inside services, of course the IPS component will 280 detect multiple failed attempts (dictionary attack) and report the 281 offender to the Global Correlation system; 283 o exploiting of day-0 attack: until now, these day-0 attacks are 284 caused either by rapidly propagating worms (then the global 285 correlation of unusual traffic pattern will raise an alert and 286 block the traffic after a couple of hundred's of successful 287 attacks) or by targeted attacks against high-profile targets (like 288 Government or banks or ;..) which should be protected by 289 conventional less open security policies; 291 o exploiting a vulnerability in a rare or new protocol (not yet 292 supported by the IPS), this case will probably never occur on a 293 wide scale in a residential use of Internet. 295 4. IANA Considerations 297 There are no extra IANA consideration for this document. 299 5. Security Considerations 301 All security considerations have been done in the Security Analysis 302 Section 3.2. 304 It is also advisable that the inbound rate limiter system could be 305 added to the [RFC6092] as it is light and does not depend on a 306 centralized policy server. 308 6. Acknowledgements 310 Many thanks to Ole Troan, Stuart Cheshire, Dave Oran and Eliot Lear 311 for the review of the -00 version and to Ron Bonica, Sam Hartmans, 312 Lee Howard, Greg Lebovitz, Jordi Palet, Tina Tsou and others for 313 their comments during and after the first presentation at the 314 Hiroshima IETF meeting in November 2009. 316 A previous IETF work has similar ideas 317 [I-D.palet-v6ops-ipv6security]. 319 7. References 321 7.1. Normative References 323 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 324 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 326 7.2. Informative References 328 [I-D.palet-v6ops-ipv6security] 329 Palet, J., Vives, A., Martinez, G., and A. Gomez, "IPv6 330 distributed security requirements", 331 draft-palet-v6ops-ipv6security-02 (work in progress), 332 February 2005. 334 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 335 November 2000. 337 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 338 Customer Premises Equipment (CPE) for Providing 339 Residential IPv6 Internet Service", RFC 6092, 340 January 2011. 342 Authors' Addresses 344 Eric Vyncke 345 Cisco Systems 346 De Kleetlaan 6a 347 Diegem 1831 348 Belgium 350 Phone: +32 2 778 4677 351 Email: evyncke@cisco.com 353 Andrew Yourtchenko 354 Cisco Systems 355 De Kleetlaan 6a 356 Diegem 1831 357 Belgium 359 Phone: +32 2 704 5494 360 Email: ayourtch@cisco.com 362 Mark Townsley 363 Cisco Systems 364 11, Rue Camille Desmoulins 365 Issy Les Moulineaux 92782 366 France 368 Phone: +33 15 804 3483 369 Email: townsley@cisco.com