idnits 2.17.1 draft-lear-opsawg-mud-bw-profile-01.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 278: '... packets SHOULD indicate that ...' RFC 2119 keyword, line 283: '...f the DSCP field MAY be, and how much ...' RFC 2119 keyword, line 287: '... entry MUST be made.";...' RFC 2119 keyword, line 339: '... This mechanism SHOULD NOT be used to...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 165 has weird spacing: '...meframe uin...' == Line 174 has weird spacing: '...meframe uin...' -- The document date (July 08, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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 J. Henry 4 Intended status: Experimental Cisco Systems 5 Expires: January 9, 2020 July 08, 2019 7 Bandwidth Profiling Extensions for MUD 8 draft-lear-opsawg-mud-bw-profile-01 10 Abstract 12 Manufacturer Usage Descriptions (MUD) are a means by which devices 13 can establish expectations about how they are intended to behave, and 14 how the network should treat them. Earlier work focused on access 15 control. This draft specifies a means by which manufacturers can 16 express to deployments what form of bandwidth profile devices are 17 expected to have with respect to specific services. 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 https://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 January 9, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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 (https://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 1.1. Envisioned Uses . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. What devices would use this extension? . . . . . . . . . 3 57 2. The ietf-mud-bw-profile model extension . . . . . . . . . . . 4 58 2.1. The mud-qos YANG model . . . . . . . . . . . . . . . . . 4 59 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 4.1. Manufacturer Attempts to Exhaust Available Bandwidth . . 7 62 4.2. Device lies about what it is to get more bandwidth . . . 8 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 6.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Devices connecting to networks will often exhibit certain nominal 73 behaviors that can be described. In addition, sometimes device 74 require particular network behaviors such as appropriate quality-of- 75 service treatment. Manufacturer Usage Descriptions [RFC8520] discuss 76 how to characterize access control requirements, for instance. As 77 just mentioned, access control requirements are not the only 78 requirements device manufacturers may wish to specify. This memo 79 defines an extension to the MUD YANG model by which manufacturers can 80 characterize the traffic exchanged with a Thing, and specify how much 81 bandwidth is required by a device or may be expected of a device over 82 some period of time for each given service it uses. 84 Network deployments may use this information in two ways: 86 o Provisioning of bandwidth based on device requirements; 88 o Facilitating proper traffic characterization and marking by the 89 network infrastructure 91 o Policing of devices to not permit them to exceed design 92 requirements. In particular, a device that is transmitting a DSCP 93 value that exceeds the expected value, or that manifests unusual 94 transmission patterns, should be viewed with great suspicion. 96 The basis of the model is that services may be identified by access- 97 lists, and that each service can then be assigned an attendant 98 bandwidth expectation in terms of either bits-per-second or packets- 99 per-second. In addition, a DSCP marking can be specified. 101 When a service is identified by access lists, each access list is 102 appended to the existing access list entries. N.B., as a reminder, 103 acl names in MUD files are scoped solely to those files, and may 104 conflict with acl names in _other_ MUD files. 106 1.1. Envisioned Uses 108 A luminaire may require a few packets per minute of a predictable 109 payload size (e.g. keepalives), and may expect that traffic to be 110 sent in the background, as one or more keepalive packet loss would 111 not impede the luminaire functions. Additionally, when a virtual 112 'light switch' changes its state, a burst of 3 to 4 packets over a 113 well-defined port are expected, with a QoS marking of OAM. Last, 114 occasional firmware updates may bring an exchange of a few kilobytes 115 marked as best effort. 117 A smoke detector may require at most 1 packet per second at best 118 effort (keepalive), except when there is a problem, at which point it 119 may send a frame upstream to a specific port and of a specified 120 payload size, with a DSCP marking of EF. 122 A coffee maker may be designed never set DSCP to anything other than 123 AF13 (even when it's empty, perish the thought), nor may it ever use 124 more than 5 packets of 120 bytes payload per minute, even if it has a 125 fault. 127 A different coffee maker may be designed to set DSCP to EF if the it 128 has caught fire. 130 1.2. Limitations 132 Not every device can be easily profiled. Not every service on every 133 device may be easily profiled. A manufacturer may use this extension 134 to describe those services that _are_ easily profile, and omit 135 services that the device offers or uses that are not easily profiled. 136 The local deployment is cautioned not to assume that a service not 137 profiled is in some way anomalous, even when other services are. 139 1.3. What devices would use this extension? 141 The MUD manager remains a key component of this system. To begin 142 with, it is the component that retrieves the MUD file, and would 143 identify the extension. From that point, different implementation 144 decisions can be made. For instance, the MUD manager or associated 145 infrastructure can retain the mapping between devices and MUD-URLs. 146 A dispatch function could be implemented wherever that mapping is 147 housed, such that either enforcement or monitoring functions can be 148 invoked. Enforcement functions would almost certainly begin with 149 some form of telemetry on access switches, routers or firewalls. 150 That same telemetry might be exported to an IPFIX analyzer [RFC7011] 151 that might report anomalies. 153 2. The ietf-mud-bw-profile model extension 155 To extend MUD the "qos" extension is added as an element to the 156 "extensions" node when a MUD file is generated. 158 The model augmentation appears as follows: 160 module: ietf-mud-bw-profile 161 augment /mud:mud/mud:to-device-policy: 162 +--rw bw-params 163 +--rw service* [name] 164 +--rw name string 165 +--rw timeframe uint32 166 +--rw pps? uint32 167 +--rw bps? uint64 168 +--rw dscp? inet:dscp 169 +--rw aclname? -> /acl:acls/acl/name 170 augment /mud:mud/mud:from-device-policy: 171 +--rw bw-params 172 +--rw service* [name] 173 +--rw name string 174 +--rw timeframe uint32 175 +--rw pps? uint32 176 +--rw bps? uint64 177 +--rw dscp? inet:dscp 178 +--rw aclname? -> /acl:acls/acl/name 180 2.1. The mud-qos YANG model 182 file "ietf-mud-bw-profile@2019-07-08.yang" 183 module ietf-mud-bw-profile { 184 yang-version 1.1; 185 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-bw-profile"; 186 prefix mud-qos; 188 import ietf-access-control-list { 189 prefix acl; 190 } 191 import ietf-inet-types { 192 prefix inet; 193 } 194 import ietf-mud { 195 prefix mud; 196 } 198 organization 199 "IETF OPSAWG (Ops Area) Working Group"; 200 contact 201 "WG Web: http://tools.ietf.org/wg/opsawg/ 202 WG List: opsawg@ietf.org 203 Author: Eliot Lear 204 lear@cisco.com 205 Author: Jerome Henry 206 jerhenry@cisco.com 207 "; 208 description 210 "This YANG module augments the ietf-mud model to provide the 211 network with some understanding as to the QoS requirements and 212 anticipated behavior of a device. 214 The to-device-policy and from-device-policy containers are 215 augmented with one additional container, which expresses how many 216 packets per second a device is expected to transmit, how much 217 bandwidth it is expected to use, and what QoS is required, and 218 how much bandwidth is to be expected to be prioritized. An 219 access-list is further specified to indicate how QoS should be 220 marked on ingress and egress. 222 Copyright (c) 2016,2017,2018 IETF Trust and the persons 223 identified as the document authors. All rights reserved. 224 Redistribution and use in source and binary forms, with or 225 without modification, is permitted pursuant to, and subject 226 to the license terms contained in, the Simplified BSD 227 License set forth in Section 4.c of the IETF Trust's Legal 228 Provisions Relating to IETF Documents 229 (http://trustee.ietf.org/license-info). 230 This version of this YANG module is part of RFC XXXX; see 231 the RFC itself for full legal notices."; 233 revision 2019-07-08 { 234 description 235 "Initial proposed standard."; 236 reference "RFC XXXX: Bandwidth Descriptions for MUD Specification"; 237 } 239 grouping mud-bw-params { 240 description 241 "QoS and Bandwidth additions for MUD"; 242 container bw-params { 243 description 244 "Expected Bandwidth to/from device"; 245 list service { 246 key "name"; 247 description 248 "a list of services that are being described."; 249 leaf name { 250 type string; 251 description 252 "Service Name"; 253 } 254 leaf timeframe { 255 type uint32; 256 mandatory true; 257 description 258 "the period of time in seconds one 259 expects a service to burst at described rates"; 260 } 261 leaf pps { 262 type uint32; 263 description 264 "number of packets per second to be expected."; 265 } 266 leaf bps { 267 type uint64; 268 description 269 "number of bits per second to be expected."; 270 } 271 leaf dscp { 272 type inet:dscp; 273 description 274 "The DSCP that packets for this service should 275 treated with. N.B., just because the manufacturer 276 wants this, doesn't mean it will get it. However, 277 manufacturers who do set the DSCP value in their 278 packets SHOULD indicate that in this description. 280 This field differs from the dscp field in the matches 281 portion of the access-list in that here the field is 282 populated when the manufacturer states what the nominal 283 value of the DSCP field MAY be, and how much bandwidth 284 can be used when it is set. Note that it is possible 285 that the same service may use multiple DSCP values, 286 depending on the circumstances. In this case, service 287 entry MUST be made."; 289 } 290 leaf aclname { 291 type leafref { 292 path "/acl:acls/acl:acl/acl:name"; 293 } 294 description 295 "The name of the ACL that will match packets 296 for a given service."; 297 } 298 } 299 } 300 } 302 augment "/mud:mud/mud:to-device-policy" { 303 description 304 "add inbound QoS parameters"; 305 uses mud-bw-params; 306 } 307 augment "/mud:mud/mud:from-device-policy" { 308 description 309 "add outbound QoS parameters"; 310 uses mud-bw-params; 311 } 312 } 313 315 3. Examples 317 TBD 319 4. Security Considerations 321 4.1. Manufacturer Attempts to Exhaust Available Bandwidth 323 An attacking manufacturer claims a device would require substantial 324 bandwidth or QoS for use. This attack would be effected when a 325 device is installed into a local deployment and its MUD file 326 interpreted. The impact of a device demanding excessive bandwidth 327 could be overprovisioning of the network or denial of service to 328 other uses. 330 This attack is remediated by a human being reviewing the bandwidth 331 consumption projections suggested by the MUD file when they are in 332 some way beyond the norm for any device being installed. 334 4.2. Device lies about what it is to get more bandwidth 336 If the device is emitting a MUD-URL via insecure, it is possible for 337 an attacker to modify it. Devices emitting such URLs should already 338 receive additional scrutiny from administrators as they are 339 onboarded. This mechanism SHOULD NOT be used to admit devices into 340 privileged queues without them having been securely admitted to the 341 network, through means such as IEEE 802.1X. 343 5. IANA Considerations 345 The IANA is requested to add "qos" to the MUD extensions registry as 346 follows: 348 Extension Name: MUD 349 Standard reference: This document 351 6. References 353 6.1. Normative References 355 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 356 Description Specification", RFC 8520, 357 DOI 10.17487/RFC8520, March 2019, 358 . 360 6.2. Informative References 362 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 363 "Specification of the IP Flow Information Export (IPFIX) 364 Protocol for the Exchange of Flow Information", STD 77, 365 RFC 7011, DOI 10.17487/RFC7011, September 2013, 366 . 368 Appendix A. Changes from Earlier Versions 370 Draft -01: 372 o Very modest changes. 374 Draft -00: 376 o Initial revision 378 Authors' Addresses 380 Eliot Lear 381 Cisco Systems 382 Richtistrasse 7 383 Wallisellen CH-8304 384 Switzerland 386 Phone: +41 44 878 9200 387 Email: lear@cisco.com 389 Jerome Henry 390 Cisco Systems 391 170 W. Tasman Dr. 392 San Jose, CA 95134 393 United States 395 Email: ofriel@cisco.com