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