idnits 2.17.1 draft-lear-network-helps-00.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 (October 29, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-03 == Outdated reference: A later version (-25) exists of draft-ietf-opsawg-mud-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft October 29, 2016 4 Intended status: Informational 5 Expires: May 2, 2017 7 Time To End The War on Network Protection 8 draft-lear-network-helps-00.txt 10 Abstract 12 Since the Edward Snowden's release of secret information, some in the 13 IETF have taken an approach that the network is such a useful tool 14 that it is also an enemy. With several high visibility attacks that 15 have been based on low end systems (Things), it is now clear that not 16 only is the network not the enemy. When the network has at least 17 some information about a device, we get a second chance to limit 18 attacks against the device and, in some cases, a third chance to 19 limit attacks from the device. This memo discusses ways in which 20 network protection assists in protection of devices, and some caveats 21 around that protection, and suggests considerations implementers and 22 protocol developers should consider as connectivity continues to 23 expand to new applications. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 2, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. What might be shared (and why) . . . . . . . . . . . . . . . 3 61 2.1. Application-layer information sharing in flight . . . . . 3 62 2.2. Transport Layer information . . . . . . . . . . . . . . . 4 63 2.3. IP Layer Information . . . . . . . . . . . . . . . . . . 5 64 2.4. Sharing of Device Profile Information . . . . . . . . . . 5 65 3. How Information Sharing Could Stop Some Attacks . . . . . . . 6 66 3.1. DVRs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Electrical Grid Attacks . . . . . . . . . . . . . . . . . 7 68 3.3. Mobile Medical Devices . . . . . . . . . . . . . . . . . 8 69 3.4. Mobile Phones . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Encryption and Sharing . . . . . . . . . . . . . . . . . . . 8 71 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 75 9. Informative References . . . . . . . . . . . . . . . . . . . 9 76 Appendix A. Example MUD File for a DVR . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 In June of 2013 Edward Snowden released a vast trove of secret NSA 82 documents that demonstrated numerous vulnerabilities of the Internet 83 architecture, that included collection of aggregate information, 84 tapping of communication lines, hacking of devices in transit, and 85 other means. Many of these vulnerabilities were known to be possible 86 in theory, although the scale of such an attack was unprecedented. 88 The Internet Architecture Board held a plenary meeting in November 89 2013 in which we openly discussed these attacks, and what we would do 90 about them. The result was [RFC7258], which states that pervasive 91 surveillance should be treated formally as a form of attack. 93 Since that time HTTP2 has been released, and work has begun on QUIC 94 [QUIC], a transport protocol that reside atop UDP. 96 The premise of much of this work has been that if the network has 97 visibility to ANY meta-information, then it is possible for a 98 government or other similarly well-funded entity to effect a 99 pervasive surveillance attack. The conclusion in some minds has been 100 that the network has aided and abetted attackers to the point that 101 its indistinguishable from an attacker. A natural, yet flawed, 102 conclusion was endpoints alone can and must be responsible for their 103 own protection. 105 Since 2013, the Internet of Things has come into its own, as 106 connection capabilities have developed on everything from dolls to 107 door bells. While the ability to connect to the Internet has 108 developed, ability to maintain a secure device has not kept up. If 109 the network cannot be part of the solution, and the device is unable 110 to secure itself, then the device by definition will be open to 111 attack. 113 This document is structured as follows. First Section 2 provides a 114 general overview of the value and risks of sharing at various layer. 115 Next Section 3 provides an overview of different classes of devices 116 and the forms of attacks that occur where some amount of sharing 117 might have provided some useful defense. We then review the role of 118 encryption in Section 4. A basic principle is that information 119 sharing should take place as a matter, and not as an accident, of 120 design. 122 Finally we make recommendations for how devices and networks should 123 collaborate under several different use cases. 125 This document considers how to address privacy considerations 126 [RFC6973] in the context of Things. While we do not pull terminology 127 from that document, the concepts should be readily identifiable. 129 2. What might be shared (and why) 131 Within the Internet architecture it is possible for any piece of 132 information to be shared. This includes application-layer 133 information, TCP/UDP port information, source/destination IP 134 addresses, intended communication direction, and L2 information. In 135 addition to information shared in flight, profile information can 136 also be shared. The following discussion motivates why these pieces 137 of information might be shared. 139 2.1. Application-layer information sharing in flight 141 When application information is shared with a firewall or similar 142 system, that system is in a position to validate application layer 143 exchanges for correctness. For example, an end-to-end banking 144 transaction authorized by a trader may be open to audit in order to 145 avoid fraud, or the setting of a valve in an oil well should be 146 validated to be within a set of parameters in order to avoid a spill 147 or worse. Some content discrimination may be necessary. For 148 instance, some parameters may be transparent and others encrypted. 149 The trader's order might be clear, but authentication information 150 would be encrypted. 152 The challenge with this approach are threefold: 154 o The network access point and the end points must have an identical 155 and up-to-date semantic understanding of the information being 156 shared. 158 o In addition, the level of trust conferred to the network access 159 point is absolute. If it is compromised, all information is 160 revealed. 162 o This level of sharing also presents scaling problems whereby the 163 network must expend processing power to determine appropriate 164 actions. 166 When such an approach is used, it must be explicitly configured, and 167 there must be an automated means to update both end points and 168 network access points such that transactions are always properly 169 interpreted by all parties. In addition, appropriate resources must 170 be available on the network access points. 172 2.2. Transport Layer information 174 At this layer service information is revealed. This might indicate 175 what applications are running in some instances, but not the content 176 being exchanged. Layer 4 is generally considered to be so-called 177 "meta-information", although it is information that is exposed, 178 nonetheless. Sharing of Layer 4 information generally provides 179 network access points with a basic understanding of services the 180 device is using. Combined with directional information, sharing at 181 this layer usually is sufficient to indicate which end has initiated 182 a conversation. The simplest example is TCP packets that have or 183 lack the ACK flag. More advance forms retain flow state. 185 Directionality is a key ingredient to being able to stop unwanted 186 traffic, including malware. Simply put, "if I didn't ask for it, I 187 don't want it." Now we apply this axiom in the context of the 188 firehose we call the Internet. Directionality can be detected in the 189 transport layer and as a function of the first packet seen from a 190 particular interface. Each of these mechanisms has limitations, but 191 each provides some level of protection. Directionality is 192 particularly important in environments where highly constrained 193 devices can have their resources overwhelmed or drained, a simple 194 example being an energy-harvesting light switch. Only the network 195 can enforce an approach if an end node listens to any traffic at all. 197 A common pattern of communication for devices is that they would need 198 DNS, NTP and perhaps either outbound or inbound web services. Use of 199 protocols like Port Control Protocol (PCP) [RFC6887] is predicated on 200 the assumption that meaningful protection is provided by restricting 201 access to other ports. 203 This information is not quite as sensitive as application layer 204 information, in that usernames, passwords, and other private pieces 205 of information usually are not available to be exchanged. Processing 206 requirements at this layer vary based on the transport protocol used 207 and the level of protection required. 209 2.3. IP Layer Information 211 The IP layer consists of source and destination addresses. This 212 information can be considerably more revealing than transport layer 213 information. Based on this information, an observer may often 214 discern who the parties of a communication are, based on reverse 215 address lookups or by examination of the IPv6 Interface 216 Identifier(IID). IP addresses are, conversely, the primary 217 discriminators that many firewalls use to determine whether a 218 communication should be allowed. A common design pattern is that an 219 system may offer a certain set of inbound services, perhaps even from 220 anywhere, communicate outbound to a certain set of devices, and then 221 not require any other communications. Many firewall rule sets are 222 built upon this premise. 224 Cloud-based applications that make use of short TTL values of DNS 225 records for load distribution have changed the nature of this game 226 somewhat in that it is no longer sufficient to simply attend to IP 227 addresses to authorize a service- one must also pay attention to an 228 ever-changing mapping between address and name. 230 IP addresses also provide some hint at geographic location. This 231 function is used today for many purposes, such as determining 232 timezones or rights to certain content. That location information 233 may be abused to track individuals. 235 2.4. Sharing of Device Profile Information 237 A device profile consists of information that describes what a device 238 does. That information may be of a general nature shared by a 239 manufacturer such as Manufacturer Usage Descriptions (MUD) 241 [I-D.ietf-opsawg-mud] or it may be of a more specific nature unique 242 to an individual deployment or owner. The more specific the 243 information revealed, the more sensitive. For instance, telling the 244 network that a device is a printer may reveal very little. Telling 245 the network that it is Eliot Lear's printer reveals ownership, and 246 that he may have some relationship to the location in which the 247 printer resides (like perhaps owning the or renting it). 249 General information along the lines of MUD provides no information 250 about who owns the device, but does reveal what the device is. 251 However, with the information, a network access point is in a positon 252 to apply an appropriate set of access lists to limit the scope of 253 attack against the end node. 255 Who has access to this information will depend on the means in which 256 the profile is communicated. For instance, if a device inventory 257 system makes use of TLS, the information is shared only with that 258 system. The same can be used if information is shared over EAP-TLS 259 [RFC5216]. 261 3. How Information Sharing Could Stop Some Attacks 263 3.1. DVRs 265 One recent attack based on the Mirai code [Krebs-MIRAI] that was made 266 available on Github address itself to digital video recorders, 267 cameras, and home Internet routers. Some of these devices are said 268 to be old and not upgradable. Attempts to take over the device 269 occurred through known telnet, SSH, and HTTP where known passwords 270 were used. It is also said that these devices, in their normal 271 function, make use of one or two ports. 273 Had the device manufacturer made use of Manufacturer Usage 274 Descriptions (MUD), an access point could have blocked them from 275 accessing the DVR, even though it had old firmware. An Example MUD 276 file is given in Appendix A. Note that this file may not have 277 stopped an already-infected device from attacking, and it requires 278 that local deployment information be filled in for the class named 279 "http://dvr264.example.com/controller". 281 As [I-D.ietf-opsawg-mud] specifies, there are numerous ways for a 282 device to indicate the URL by which to retrieve that file. Some of 283 those methods might reveal to an observer the type of device. To 284 generalize guidance in this space we might say the following of 285 network devices: 287 o Information about a device should not be volunteered in insecure 288 environments. 290 o Where possible, such information should be encrypted to an 291 authorized recipient. 293 o Information that is intended for a router, such as DHCP requests, 294 should only be forwarded to authorized DHCP servers, and not to 295 all ports on a network. 297 As we will discuss below, it may not always be possible to encrypt 298 information. Thus a risk tradeoff must be made: will the information 299 cause substantial harm through leakage. In the case of DHCP, the 300 risk is that a local device is eavesdropping. However, in this 301 circumstance, even if the device emitted a DHCP option that was 302 broadcast to all local devices, there would have been no additional 303 damage, because a probe was used to determine that a device was 304 vulnerable. As we raise the bar, however, we may wish to consider 305 how to better protect such information through the use of other 306 mechanisms. 308 3.2. Electrical Grid Attacks 310 A large country has already seen its electrical grid attacked. The 311 attack was multifaceted, but specifically targeted the industrial 312 control systems (ICSes). In one attack, breakers were opened to 313 cause a failure. If the network between the control system and the 314 circuit breaker actuator were gatewayed by a firewall observing 315 commands, that attack may well have been thwarted. As discussed 316 above, such protection comes at a high cost. In particular, the 317 firewall itself becomes a point of attack. It also requires that the 318 firewall understands not only the commands, but how and when it is 319 safe for them to be executed. A poorly configured firewall might 320 prevent a necessary emergency shutdown. 322 Thus we might derive some general rules of thumb regarding use of 323 application information: 325 o These mechanisms should, when at all possible, be explicitly 326 authorized, where encryption is used between all components. 328 o Where encryption is not possible, substantial additional levels of 329 security should be placed around the control system so as to 330 otherwise limit unauthorized access. This might include, for 331 instance, a limitation on remote connectivity or use of VPNs, 332 where access of the physical communication path cannot be 333 controlled. 335 o There must be clear parameters as to what reasonable values are, 336 and what to do in exceptional circumstances. 338 3.3. Mobile Medical Devices 340 A number of medical devices that have transceivers may now be 341 implanted in humans. These devices are as mobile as their patients 342 are. Such devices may be subject to nearly all classes of attack, 343 such as unauthorized access to denial of service. All such attacks 344 could prove deadly to the patient. The problem is complicated by the 345 fact that these devices are generally battery operated where intended 346 communication is expected to be rare, but responsive when needed. 347 One approach used to address this limitation is to only enable near 348 field communications, so that remote attacks are not possible. 349 Another is to require a magnetic field to enable remote access, as is 350 done with pacemakers. In these cases, ad hoc connectivity is then 351 established. Examining the threat model, if someone is going to 352 attack a person with a magnet, they may well have other ways to 353 effect an attack. The key is that the magnet is essentially used as 354 an electrical switch to enable communication. Having some local 355 activation mechanism can prevent resource drain, where no information 356 is gratuitously shared. 358 Such an approach may not be practicable in all circumstances. When 359 that is the case, the network should be used to detect and prevent 360 denial of service attacks, without the need to reveal identifying 361 about the patient. 363 3.4. Mobile Phones 365 Mobile phones have been well studied. Risks associated with these 366 devices often involve users taking actions not in their best 367 interests, such as installing malware, or permitting excessive rights 368 to an app.[EGEL12]. Mobile Service providers typically already have 369 information as to devices attached to the network, in part because 370 they often sell those devices at reduced prices with contracts. 372 4. Encryption and Sharing 374 When data is obscured via encryption, then it must be shared 375 explicitly with intended recipients. When practicable, this is a 376 preferred approach, but a number of problems often arise: 378 o Trust between parties. While some ongoing work is exploring 379 trusted introduction [I-D.ietf-anima-bootstrapping-keyinfra], due 380 to memory and connectivity constraints it is often difficult to 381 establish trust between two or more parties. 383 o Even once a trusted introduction has occurred, ongoing key 384 management and algorithm selection remains a challenge. The 385 entire device lifecycle must be taken into account. 387 Because of poor interactions between network components and devices, 388 many services now reside on TCP port 443, meaning that when 389 encryption is possible, it is not possible for a firewall to filter 390 based on service as it has been in the past. 392 In order to avoid tracking, a number of mobile devices are now 393 regularly changing their L2 MAC addresses, where possible. This 394 makes filtering based on MAC address impracticable. Similarly, 395 devices deploying IPv6 have the ability to make use of different IPv6 396 Interface Identifier (IID). [RFC7721] discusses the privacy 397 implications and threats of using stable IIDs. As that document 398 mentions, if the IID is part of an authentication paradigm, its 399 change means that the device itself must be reauthenticated, and may 400 add to system fragility. 402 5. Conclusions 404 When networks take on certain functions there are some risks that 405 must be considered. The same is true when only devices attempt to 406 provide for their own security. An systemic and architectural 407 approach is needed that makes use of both device and network 408 capabilities in good measure. Such an approach must take into 409 account both privacy and security requirements, where appropriate 410 balances can be made. 412 6. Security Considerations 414 This document discusses the security of the Internet. 416 7. IANA Considerations 418 This section may be removed upon publication. There are no IANA 419 considerations. 421 8. Acknowledgments 423 9. Informative References 425 [EGEL12] Egelman, S., Felt, A., and D. Wagner, "Choice Architecture 426 and Smartphone Privacy: There's A Price for That", 2012, 427 . 430 [I-D.ietf-anima-bootstrapping-keyinfra] 431 Pritikin, M., Richardson, M., Behringer, M., and S. 432 Bjarnason, "Bootstrapping Remote Secure Key 433 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 434 keyinfra-03 (work in progress), June 2016. 436 [I-D.ietf-opsawg-mud] 437 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 438 Description Specification", draft-ietf-opsawg-mud-01 (work 439 in progress), September 2016. 441 [Krebs-MIRAI] 442 "Source Code for IoT Botnet 'Mirai' Released", October 443 2016, . 446 [QUIC] "QUIC Working Group Charter", 2016, 447 . 449 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 450 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 451 March 2008, . 453 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 454 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 455 DOI 10.17487/RFC6887, April 2013, 456 . 458 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 459 Morris, J., Hansen, M., and R. Smith, "Privacy 460 Considerations for Internet Protocols", RFC 6973, 461 DOI 10.17487/RFC6973, July 2013, 462 . 464 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 465 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 466 2014, . 468 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 469 Considerations for IPv6 Address Generation Mechanisms", 470 RFC 7721, DOI 10.17487/RFC7721, March 2016, 471 . 473 Appendix A. Example MUD File for a DVR 475 { 476 "ietf-mud:meta-info": { 477 "lastUpdate": "2016-10-23T14:11:52+02:00", 478 "systeminfo": "DVR H.264", 479 "cacheValidity": 1440 480 }, 481 "ietf-acl:access-lists": { 482 "ietf-acl:access-list": [ 483 { 484 "acl-name": "mud-10387-v4in", 485 "acl-type": "ipv4-acl", 486 "ietf-mud:packet-direction": "to-device", 487 "access-list-entries": { 488 "ace": [ 489 { 490 "rule-name": "clout0-in", 491 "matches" : { 492 "ietf-mud:direction-initiated" : "from-device" 493 }, 494 "actions": { 495 "permit": [ 496 null 497 ] 498 } 499 }, 500 { 501 "rule-name": "entin0-in", 502 "matches": { 503 "ietf-mud:controller": 504 "http://dvr264.example.com/controller", 505 "ietf-mud:direction-initiated" : "to-device" 506 }, 507 "actions": { 508 "permit": [ 509 null 510 ] 511 } 512 } 513 ] 514 } 515 }, 516 { 517 "acl-name": "mud-10387-v4out", 518 "acl-type": "ipv4-acl", 519 "ietf-mud:packet-direction": "from-device", 520 "access-list-entries": { 521 "ace": [ 522 { 523 "rule-name": "clout0-in", 524 "matches": { 525 "ietf-mud:direction-initiated" : "from-device" 526 }, 527 "actions": { 528 "permit": [ 529 null 530 ] 531 } 533 }, 534 { 535 "rule-name": "entin0-in", 536 "matches": { 537 "ietf-mud:controller": "http://dvr264.example.com/controller", 538 "ietf-mud:direction-initiated" : "to-device" 539 }, 540 "actions": { 541 "permit": [ 542 null 543 ] 544 } 545 } 546 ] 547 } 548 } 549 ] 550 } 551 } 553 Author's Address 555 Eliot Lear 557 Email: lear@ofcourseimright.com