idnits 2.17.1 draft-sajjad-t2trg-colsec-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Intended status: Standards Track Riphah Institute of Systems Engineering', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (July 22, 2018) is 2104 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 T2TRG Syed. M. Sajjad, Ed. 3 Internet-Draft M. Yousaf 4 Intended status: Standards Track Riphah Institute of Systems Engineering 5 Expires: January 23, 2019 July 22, 2018 7 An Architecture for Collaborative Security and Proactive Defence against 8 IoT Botnets 9 draft-sajjad-t2trg-colsec-00 11 Abstract 13 This document proposes an architecture for Collaborative Security and 14 Proactive Defence against IoT Botnets. The proposed architecture is 15 based on the violation of the Manufacturer Usage Description policy. 16 This architecture provides a means of sharing the attacker 17 information including its Command and Control Server information with 18 the peers in order to not only achieve proactive defense against 19 Internet of Things botnets but also mitigate them at its source end. 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 https://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 23, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Motivation and Use cases . . . . . . . . . . . . . . . . . . 3 57 2.1. Usecase-01: Timely Sharing of IoT Botnets source Command 58 and Control Server domain in order to proactively 59 safeguard devices from its access . . . . . . . . . . . . 3 60 2.2. Usecase-02: Timely sharing of Threat Intelligence data 61 between manufacturers and Vendors . . . . . . . . . . . . 3 62 2.3. Usecase-03: Timely Sharing of IoT Botnets source Command 63 and Control Server domain with Attacker ISP for its 64 Source Mitigation . . . . . . . . . . . . . . . . . . . . 4 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Limitations of Existing Techniques . . . . . . . . . . . . . 5 67 5. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 Distributed Denial of Service (DDoS) attacks is generally detected 82 and mitigated at the destination end. Companies are deploying costly 83 detection appliances to safeguard themselves from DDoS so as to 84 continue their routine critical business processes. Destination end 85 DDoS detection and mitigation have implementation complexities and 86 cost overhead. It is also to be noted that destination end detection 87 and mitigation does not detect and mitigate the source of the DDoS 88 attack. There is a need to detect and mitigate Distributed Denial of 89 Service (DDoS) attacks at its source end. Individual Security 90 Systems, deployed on the premises of different organization for the 91 detection of emerging threats, works on the attack knowledge gained 92 in a specific locality. Moreover scalable and sophisticated 93 techniques used by the attacker make it difficult for individual 94 security systems to provide effective security. Slow reaction to 95 zero-day attacks and inconspicuousness to newer emerging attacks are 96 threats to security systems. To handle these challenges, 97 collaborative security mechanisms are used in which each 98 participating entity performs a specific task in order to strengthen 99 the security of the network. Collaborative Security is a method that 100 is categorized by five important features: 102 Raising Confidence and Protecting Opportunities: The aim of 103 security is to increase confidence on the Internet and to make 104 sure the constant realization of the Internet as a driver for 105 social and economic novelties. 107 Collective Responsibility: Internet users share an obligation 108 towards the smooth functioning of the system. 110 Essential Properties and Values: Security systems should be well- 111 suited with fundamental human rights and reserve the essential 112 properties of the internet. 114 Development and Consensus: Operative security depends on active 115 evolutionary actions based on the expertise of wide-range 116 participants. 118 Think Globally, Act Locally: Most effective solutions are expected 119 to be achieved by means of voluntary approaches. 121 2. Motivation and Use cases 123 IoT Devices acting as bots go unnoticed and undetected, causing a 124 huge loss at the destination end. There is a need to not only detect 125 ddos at its source end but also mitigate it. This section discusses 126 three usecases of the proposed architecture. 128 2.1. Usecase-01: Timely Sharing of IoT Botnets source Command and 129 Control Server domain in order to proactively safeguard devices 130 from its access 132 In the First phase, command and control server of the Internet of 133 Things botnets scans for vulnerable devices. Timely disposing of the 134 attacker command and control domain will alert the receiver. The 135 receiver will block the CNC access to its deployed IoT devices. 137 2.2. Usecase-02: Timely sharing of Threat Intelligence data between 138 manufacturers and Vendors 140 This architecture may also be used for sharing of threat intelligence 141 data in order to protect their customers from different attacks. 143 2.3. Usecase-03: Timely Sharing of IoT Botnets source Command and 144 Control Server domain with Attacker ISP for its Source Mitigation 146 Attacker command and control server is a domain against a public IPs 147 or pole of public IPs. These IPs are obtained from an Internet 148 Service Provider. If the command and control server information is 149 shared with the attacker ISP in the bot propagation phase, the ISP 150 will take down the malicious CNC before causing any major attack. 152 3. Requirements 154 There are Certain requirements for the sharing of attack data with 155 the peers: 157 Trust Establishment: Trust should be established while sharing 158 threat information between senders and receivers. 160 Temper Proof Integrity: Temper Proof integrity of the shared 161 information must be maintained. 163 Confidentiality: The data shared must be encrypted in order to 164 ensure its confidentiality. 166 Non-Repudiation: There should be a defined mechanism by which a 167 user cannot deny the data sharing. 169 Correctness: Temper proof integrity and encryption provides 170 correctness in the shared data. 172 Legal Written Contract Between Participants: Attack report 173 exploits of the vulnerabilities and weakness present in the 174 deployment of any organization. public exposing of such kind of 175 sensitive information may lead to serious privacy concerns. There 176 must be a written agreement between the entities and vendors 177 involved in the sharing of attack data. 179 Lightweight and low-cost Mud based Architecture: The proposed 180 Architecture must be MUD based, light-weight, having low 181 implementation complexity. 183 Proactive Defense: Timely sharing of attack detection reports with 184 the peers should provide a means of proactive defense. 186 Accuracy: The shared data must be accurate. 188 4. Limitations of Existing Techniques 190 There are Certain limitations of existing techniques designed for 191 attack data sharing: 193 Design and Implementation Complexity: Mostly attack data sharing 194 standards are designed for enterprise-level networks. They have 195 Implementation complexities. For IoT, there is a need for 196 lightweight protocol requirement using detection based on MUD 197 policy violation. 199 Lack of a Written Legal Contract/agreement: There isn't any 200 written legal agreement between the participants in the existing 201 attack sharing mechanisms. 203 5. Terminologies 205 MUD Monitor: System that monitors current access on devices and 206 compares it with MUD policies. In case of Mud policy violation, 207 compile the attack vector, take hash of it, encrypt it and 208 securely send it to all the participants in the network. 210 MUD Policy Violation: MUD defines access policies for IoT devices. 211 Any access attempt not defined in MUD policy is termed as MUD 212 Policy Violation. 214 Smart Contract: A computer code running on top of a blockchain 215 containing a set of rules under which the parties to that smart 216 contract agree to interact with each other. If and when the 217 predefined rules are met, the agreement is automatically enforced. 218 The smart contract code facilitates, verifies, and enforces the 219 negotiation or performance of an agreement or transaction. 221 Non-Repudiation: There should be a defined mechanism by which a 222 user cannot deny the data sharing. 224 Participants: Any entity which is a signatory of the smart 225 contract e.g Manufacturer, Vendors, Internet Service Providers, 226 End User etc. 228 Command and Control Server: Server Machine having Public IPs and 229 domain name acting and controlling authority of the Bots. 231 Proactive Defense: Proactively safeguarding devices from an attack 232 in advance. 234 6. Architecture 236 We propose a block-chain and smart contract based collaborative 237 mitigation framework. The block-chain is a distributed structure of 238 data that is shared among the members present in the network. The 239 smart contract is a software-based set of contract or negotiation 240 agreed by all the parties, which is able to be executed, confirmed 241 and reinforced automatically. The main idea of the proposed 242 collaborative mitigation system is to send the IP addresses of the 243 attacker and details of the attacked ports, identified by the 244 detection system, with multiple members using smart contract and 245 block-chain. The proposed Collaborative mitigation system is 246 depicted in the Figure 1. In the proposed collaborative mitigation 247 system, each participant in the smart contract has agreed to share 248 the attack information with the member of the network. Each member 249 has its own detection system. Upon receiving the attacker 250 information, the member takes preventive measures through mitigator. 251 Following are the steps of the Proposed Celebrative Mitigation. 253 As a first step, a block-chain based smart contract is formed. 254 This smart contract contains the condition of sharing attack 255 detection report with the member of the contract, in case there is 256 an attack on IoTs devices of any member. 258 Different vendors of IoTs devices having global threat 259 intelligence capabilities, Manufacturers and Internet Service 260 Providers join the smart contract. 262 In case of an attack on any of vendor IoTs devices, MUD Monitor 263 detects the attack based on mud policy violation. 265 MUD Monitor digitally signs the attack report with its private 266 key. 268 MUD Monitor then encrypt digitally signed transaction with 269 receivers public keys one by one and send it to all the members 270 present in the block-chain smart contract. 272 The receiver Mud Monitor decrypts the receiving transaction with 273 its private key. 275 The receiver Mud Monitor then verifies the digital signature of 276 the receiver by decrypting the signed message with the sender 277 public key. 279 Upon receipt of attacker information, MUD Monitor adds the 280 attacker information to its global threat intelligence and take 281 precautionary mitigating measures. 283 ......................... 284 .Manufacturer 1/Vender 1. 285 ________ . ______ ___________ . 286 | | .| | | | . 287 |Attacker| .|Device| |Mud Policy | . 288 | |------>| | | Monitor | . 289 | | .| | | | . 290 |________| .|______| |___________| . 291 ....................|.... 292 | 293 .............. _______________ | 294 . ________ . | |<--| 295 . | | . | Smart | 296 . | Mud |--->| Contract | 297 . | Policy | . | |<---| 298 . |Monitor | . |_______________| | 299 . |________| . | 300 . . | 301 . _______ . .....................|...... 302 . | | . . _______ _________|___ . 303 . |Device | . .| | | | . 304 . | | . .|Device | | Mud Policy | . 305 . | | . .| | | Monitor | . 306 . |_______| . .| | | | . 307 .Manufac- . .|_______| |_____________| . 308 .turer 3 . . . 309 .Vender 3 . .Manufacturer 3/ Vender 3 . 310 .............. ............................ 312 Figure 1 314 7. Security Considerations 316 Some of the benefits of the block-chain based smart contract 317 collaborative mitigation mechanism are: 319 Trust Establishment: Trust establishment is one of the main 320 challenges in sharing threat information. Block-chain based smart 321 contract provides a means of mutual trust to all the 322 collaborators. 324 Temper Proof Integrity: Digital Signature of the receiver and 325 hashes of transaction provides temper proof integrity. 327 Confidentiality: Encrypting the digitally signed transaction with 328 receivers public keys to provide confidentiality. 330 Non-Repudiation: A user cannot deny a transaction as it is signed 331 by it. 333 Correctness: Temper proof integrity and encryption provides 334 correctness in the shared data. 336 Proactive Defense: Timely sharing of attack detection reports with 337 the peers provides a means of proactive defense. 339 Accuracy: Temper proof integrity and encryption also provides 340 accuracy of the shared data. 342 8. Acknowledgements 344 9. IANA Considerations 346 10. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997, 351 . 353 Authors' Addresses 355 Syed Muhammad Sajjad (editor) 356 Riphah Institute of Systems Engineering 357 Aga Khan Road, Sector F-5/1 358 Islamabad, Federal Capital 44000 359 Pakistan 361 Email: abuammarhashmi@gmail.com 363 Muhammad Yousaf 364 Riphah Institute of Systems Engineering 365 Aga Khan Road, Sector F-5/1 366 Islamabad, Federal Capital 44000 367 Pakistan 369 Email: Muhammad.Yousaf@riu.edu.pk