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