idnits 2.17.1 draft-moskowitz-firstmile-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. -- The document date (March 21, 2016) is 2959 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) == Outdated reference: A later version (-06) exists of draft-ietf-netconf-yang-library-04 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-01 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-00 == Outdated reference: A later version (-26) exists of draft-ietf-mile-rfc5070-bis-17 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Hares 5 Expires: September 22, 2016 L. Xia 6 Huawei 7 March 21, 2016 9 Security alerts over the first MILE 10 draft-moskowitz-firstmile-00.txt 12 Abstract 14 This document describes a pub/sub styled protocol to send security 15 alerts to a security monitor that can feed into MILE and other 16 management platforms. It uses data structures from NETCONF, MILE, 17 and IPFIX to manage the reporting and report security alerts. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 22, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 56 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. The first mile of security alerts . . . . . . . . . . . . . . 3 58 4.1. Register . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.2. Subscribe . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.3. Publish . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. first MILE data model . . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 9.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 This document proposes a set of protocols to automate the reporting 73 of security alerts to the various monitoring systems. The intent is 74 primarily to automate the input of security events to the MILE 75 environment (RID [RFC6545] and IODEF [I-D.ietf-mile-rfc5070-bis]). 76 Any authorized monitoring system can subscribe to any of the security 77 alerts reports. 79 An Internet security defense device first registers with a security 80 alert monitoring system. At this point the content and protocol used 81 has not been identified. Since such a registration is normally at 82 'quiet time', the registration does not occur during a network 83 congested time and can use some HTTPS-based service. At this time 84 both systems exchange their X.509 identifiers to be used for the sub/ 85 pub security and identification. 87 Once a defense device is registered, the monitoring system can 88 subscribe to it for those alerts in needs to receive. The 89 subscription protocol should use NETCONF [RFC6536] with the 90 publication/subscription push service [I-D.ietf-netconf-yang-push]. 91 If the system needs a "pull" service, the NETCONF and I2RS 92 subscription service could be expanded to support a pull service. 94 Any secure NETCONF transport that this pub/sub service support can be 95 used. 97 The defense device publishes security alerts to subscribed monitors 98 using IODEF or IPFIX [RFC7011] data structures. The protocol(s) for 99 these reports are discussed within this document. 101 2. Terms and Definitions 103 2.1. Requirements Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. Problem Space 111 At the time of developing this document, there is no IETF defined set 112 of standardized security alert messages and protocols. 113 Administrators of systems which provide MILE service currently use 114 "cut-and-past" where they cut selected messages from proprietary 115 monitoring systems and past these messages into their MILE 116 environment. The intent here is to standardize and automate this 117 process. It is recognized that many of these alerts are too detailed 118 to be actionable. Some implementations of the alert monitor will 119 include analytic tools to select the actionable information from the 120 alerts. Alerts which are too detailed to be actionable or alerts 121 which include analytical tools are outside of any standardizing 122 process. 124 Many of the needed alerts are scattered throughout the various 125 standards like IPFIX and IODEF, but are not collected together as 126 recognized security alerts that should be aggregated into a reporting 127 framework. 129 4. The first mile of security alerts 131 There are three components to the first MILE process 133 o Register 135 o Subscribe 137 o Publish 139 4.1. Register 141 An Internet security defense device first registers with a security 142 alert monitoring system. This is typically done at the time the 143 device is installed, but may occur later as the device is registered 144 to more monitoring systems. There is no theoretical limit on the 145 number of monitors a device is registered to. The limit within a 146 system are practical limits based on internal limits within the 147 device. 149 Most monitors will be commercial and the registration will be based 150 on existing business relationships. One such example is the ISP's 151 security monitor. It is possible that a CERT may accept direct 152 registration without a business relationship. However this may 153 require more study to ensure that this will not introduce potential 154 attacks of false reporting to CERTs. 156 The actual content of the registration has not been determined. 157 Minimally it needs to include 159 o Identifiers (e.g. X.509 certificates) 161 o Reports available from device (i.e. what to subscribe to) 163 o Subscription protocols(s) 165 o Publication protocols(s) 167 A device can alter any of its registered information at any time as 168 well as cancel a registration. 170 4.2. Subscribe 172 Once a defense device is registered, the monitoring system can 173 subscribe to it for those alerts in needs to receive. This is 174 typically done via NETCONF, but is controlled by what the device 175 registered as supported subscript protocols. 177 A monitor can subscribe or unsubscribe for reports at any time. With 178 the first subscription, a secure communication transport will be 179 enabled from the device to the monitor. See Section 4.3 for more on 180 the this secure transport. 182 4.3. Publish 184 The defense device publishes security alerts to subscribed monitors. 185 The reports will be sent over the subscribed protocol using the 186 subscribed data model, either IODEF or IPFIX. 188 Since these alerts may be reported during an attack that degrades 189 communications, many of the DOTS requirements 190 [I-D.ietf-dots-requirements] apply here. One that doesn't is the bi- 191 directional requirement. Even so, the same security and transport 192 design used for DOTS should be used here. 194 5. first MILE data model 196 The data model will support the constraints of the NETCONF 197 publication/subscription model [I-D.ietf-netconf-yang-push], and the 198 NETCONF module library function [I-D.ietf-netconf-yang-library] which 199 indicates pub/sub support within a model. If the MILE service which 200 to utilize non-persistent (aka ephemeral) data that disappears on 201 reboot, the netconf publication/subscription model will support non- 202 persistent configuration. 204 Work on the data model is an open item. 206 6. IANA Considerations 208 No IANA considerations exist for this document at this time. 210 7. Security Considerations 212 An attacker that can disable first MILE may be able to attack a 213 device at will as those monitoring it expect these attacks to show up 214 on their monitor. As such each part of the firstMILE system will 215 need the complete security services that are defined or referenced 216 here. 218 8. Contributors 220 TBD 222 9. References 224 9.1. Normative References 226 [I-D.ietf-netconf-yang-library] 227 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 228 Library", draft-ietf-netconf-yang-library-04 (work in 229 progress), February 2016. 231 [I-D.ietf-netconf-yang-push] 232 Clemm, A., Prieto, A., Voit, E., Tripathy, A., and E. 233 Einar, "Subscribing to YANG datastore push updates", 234 draft-ietf-netconf-yang-push-01 (work in progress), 235 February 2016. 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 9.2. Informative References 244 [I-D.ietf-dots-requirements] 245 Mortensen, A., Moskowitz, R., and T. Reddy, "DDoS Open 246 Threat Signaling Requirements", draft-ietf-dots- 247 requirements-00 (work in progress), October 2015. 249 [I-D.ietf-mile-rfc5070-bis] 250 Danyliw, R., "The Incident Object Description Exchange 251 Format v2", draft-ietf-mile-rfc5070-bis-17 (work in 252 progress), March 2016. 254 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 255 Protocol (NETCONF) Access Control Model", RFC 6536, 256 DOI 10.17487/RFC6536, March 2012, 257 . 259 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 260 RFC 6545, DOI 10.17487/RFC6545, April 2012, 261 . 263 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 264 "Specification of the IP Flow Information Export (IPFIX) 265 Protocol for the Exchange of Flow Information", STD 77, 266 RFC 7011, DOI 10.17487/RFC7011, September 2013, 267 . 269 Authors' Addresses 271 Robert Moskowitz 272 HTT Consulting 273 Oak Park, MI 48237 275 Email: rgm@labs.htt-consult.com 277 Susan Hares 278 Huawei 279 7453 Hickory Hill 280 Saline, MI 48176 281 USA 283 Email: shares@ndzh.com 284 Liang Xia 285 Huawei 286 No. 101, Software Avenue, Yuhuatai District 287 Nanjing 288 China 290 Email: Frank.xialiang@huawei.com