idnits 2.17.00 (12 Aug 2021) /tmp/idnits9314/draft-dong-sacm-nid-cp-security-baseline-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-xia-sacm-nid-app-infr-layers-security-baseline], [I-D.ietf-lin-sacm-nid-mp-security-baseline]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 271 has weird spacing: '...rd-text strin...' == Line 280 has weird spacing: '...rd-text strin...' == Line 282 has weird spacing: '...in-name strin...' == Line 304 has weird spacing: '...rd-text strin...' == Line 308 has weird spacing: '...rd-type enum...' == (22 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 07, 2017) is 1710 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) == Missing Reference: 'I-D.ietf-birkholz-sacm-yang-content' is mentioned on line 127, but not defined == Missing Reference: 'I-D.ietf-lin-sacm-nid-mp-security-baseline' is mentioned on line 156, but not defined == Unused Reference: 'I-D.ietf-netconf-subscribed-notifications' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 673, but no explicit reference was found in the text == Outdated reference: draft-ietf-netconf-subscribed-notifications has been published as RFC 8639 == Outdated reference: draft-ietf-netconf-yang-push has been published as RFC 8641 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Dong 3 Internet-Draft L. Xia 4 Intended status: Standards Track Huawei 5 Expires: March 11, 2018 September 07, 2017 7 The Data Model of Network Infrastructure Device Control Plane Security 8 Baseline 9 draft-dong-sacm-nid-cp-security-baseline-00 11 Abstract 13 This document is one of the companion documents which describes the 14 control plane security baseline YANG output for network 15 infrastructure devices. The other parts of the whole document series 16 [I-D.ietf- xia-sacm-nid-dp-security-baseline], [I-D.ietf-lin-sacm- 17 nid-mp-security-baseline], [I-D.ietf-xia-sacm-nid-app-infr-layers- 18 security-baseline] cover other parts of the security baseline for 19 network infrastructure device in data plane, management plane, 20 application layer and infrastructure layer respectively. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 11, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.2. Security Baseline Data Model Design . . . . . . . . . . . 3 59 1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 63 3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Data Model Structure . . . . . . . . . . . . . . . . . . . . 5 65 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.3. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.4. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.5. Keychain . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.6. GTSM . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5. Network Infrastructure Device Security Baseline Yang Module . 14 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 9.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 1.1. Objective 84 Nowdays network infrastructure devices such as switches, routers, and 85 firewalls are always under the attack of the well-known network 86 security threats which are sammrized in [I-D.ietf-xia-sacm-dp- 87 security-profile]. Hence it is significant to ensure that the 88 devices in a specific network meet the minimal security requirements 89 according to their intended functions. In this case, the concept of 90 security baseline for the network infrastructure device has been 91 proposed in the above mentioned draft [I-D.ietf-xia-sacm-dp-security- 92 profile] as well. The security baseline refers to the basic and 93 compulsory capabilities of identifying the possible threats and 94 vulnerabilities in the device itself, and enfocing the security 95 hardening measurement. And it could be set to benchmark the security 96 posture of an individual network device. 98 Basically, the overall security baseline of a particular network 99 infrastructure device can be designed and deployed into three 100 different layers, namely the application layer, the network layer, 101 and the infrastructure layer. Moreover, the network layer security 102 baseline is further classified into data plane, control plane, and 103 management plane. In this document, we focus on the designation of 104 data model for control plane security baseline while the security 105 baseline of other layers and planes are proposed in the companion 106 documents. 108 The control plane security basedline focus on the control signaling 109 security of the network infrastructure device. The aim is to protect 110 the normal information exchange between devices against various 111 attcks (i.e. eavesdropping, tampering, spoofing and flooding attack) 112 and restrict the malicious control signaling, for ensuring the 113 correct network topology and forwading behavior. 115 1.2. Security Baseline Data Model Design 117 The security baseline of a certain device is dependent on many 118 factors including but not limited to the different device types 119 (i.e., router, switch, firewall) and their corresponding security 120 features supported, and the specific security requirements of network 121 operators. Owning to such a number of variations, it is impossible 122 to design a comprehensive set of baseline for all devices. This 123 document and the companion ones are going to propose the most 124 important and universal points of them. More points can be added in 125 future following the data model scheme specified in this document. 127 [I-D.ietf-birkholz-sacm-yang-content] defines a method of 128 constructing the YANG data model scheme for the security posture 129 assessment of the network infrastructure device by brokering of YANG 130 push telemetry via SACM statements. The basic steps are: 132 o use YANG push mechanism[I-D.ietf-netconf-yang-push]to collect the 133 created streams of notifications (telemetry) 134 [I-D.ietf-netconf-subscribed-notifications]providing SACM content 135 on SACM data plane, and the filter expressions used in the context 136 of YANG subscriptions constitute SACM content that is imperative 137 guidance consumed by SACM components on SACM management plane; 139 o then encapsulate the above YANG push output into a SACM Content 140 Element envelope, which is again encapsulated in a SACM statement 141 envelope; 143 o lastly, publish the SACM statement into a SACM domain via xmpp- 144 grid publisher. 146 In this document, we follow the same way as [I-D.ietf-birkholz-sacm- 147 yang-content] to define the YANG output for network infrastructure 148 device security baseline posture based on the SACM information model 149 definition [I-D.ietf-sacm-information-model]. 151 1.3. Summary 153 The following contents propose part of the security baseline YANG 154 output for network infrastructure device: control plane security 155 baseline. The companion documents [I-D.ietf- xia-sacm-nid-dp- 156 security-baseline], [I-D.ietf-lin-sacm-nid-mp-security-baseline], [I- 157 D.ietf-xia-sacm-nid-app-infr-layers-security-baseline] cover other 158 parts of the security baseline YANG output for network infrastructure 159 device respectively: control plane security baseline, management 160 plane security baseline, application layer and infrastructure layer 161 security baseline. 163 2. Terminology 165 2.1. Key Words 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 2.2. Definition of Terms 173 This document uses the terms defined in [I-D.draft-ietf-sacm- 174 terminology]. 176 3. Tree Diagrams 178 A simplified graphical representation of the data model is used in 179 this document. The meaning of the symbols in these diagrams is as 180 follows: 182 o Brackets "[" and "]" enclose list keys. 184 o Abbreviations before data node names: "rw" means configuration 185 (read-write) and "ro" state data (read-only). 187 o Symbols after data node names: "?" means an optional node and "*" 188 denotes a "list" and "leaf-list". 190 o Parentheses enclose choice and case nodes, and case nodes are also 191 marked with a colon (":"). 193 o Ellipsis ("...") stands for contents of subtrees that are not 194 shown. 196 4. Data Model Structure 198 A large amount of control protocols such as the typical TCP/IP stack 199 and BGP in the control plane of network infrastructure device provide 200 many operational services (i.e. farwording behavior control). These 201 control protocols could be either the target under attack or the 202 medium to attack the devices. The security baseline of several 203 widely used protocols are specified in this section. 205 4.1. BGP 207 In a BGP network, TCP is always selected as the transport layer 208 protocol. Thus it always subject to most of the attacks that 209 targeting TCP-based protocols. In order to secure the BGP network, 210 three types of functions, namely the GTSM, the RPKI, and the BGP peer 211 connection authentication, could be configured in network device. 212 This section specifies the authentication and RPKI configurations. 213 The GTSM is summarized in another individual section together with 214 some other protocols that all supports GTSM. 216 Various kinds of authentication techniques are able to be used for 217 securing the TCP connections between BGP neighbors. They only allows 218 the authorized peers to establish neighbor relationship with local 219 device so that the information exchanged between the BGP neighbors 220 via the TCP connection cannot be altered. 222 The Resource Public Key Infrastructure (RPKI) is usually applied in a 223 network equipt with a RPKI server to secure the inter-domain BGP 224 routing. The device is required to establish a connection to the 225 RPKI server and then downloads or updates the Route Origin 226 Authorizations (ROAs), which links certain IP prefixes or prefix 227 range with an autonomous system (AS), from the RPKI server. After 228 that, the received BGP route information is validated against the 229 downloaded/updated ROAs to verify whether the BGP prefixe originates 230 from the expected AS. 232 module: bgp-sec-config 233 +--rw bgp-rpki 234 | +--rw bgp-rpki-session-config* [session-ipv4-addr] 235 | | +--rw session-ipv4-addr ipv4-address 236 | | +--rw port-number unit16 237 | | +--rw cipher-password? string 238 | | +--rw aging-time? unit32 239 | | +--rw refresh-time? unit16 240 | | +--rw rpki-limit? 241 | | +--rw limit unit32 242 | | +--rw (action-type) 243 | | +--:(alert) 244 | | | +--rw enable boolean 245 | | +--:(idle-forever) 246 | | | +--rw enable boolean 247 | | +--:(idle-timeout) 248 | | +--rw timeout unit16 249 | +--rw origin-as-validate-utilization 250 | +--rw origin-validation-enable boolean 251 | +--rw origin-as-validate boolean 252 | +--rw allow-invalide boolean 253 | +--rw (peer-identification-method) 254 | +--:(group) 255 | | +--rw peer-group* [group-name] 256 | | +--rw group-name string 257 | | +--rw advertise-enable boolean 258 | +--:(ip) 259 | +--rw peer-ip* [ipv4-addr] 260 | +--rw ipv4-addr ipv4-address 261 | +--rw advertise-enable boolean 262 +--rw bgp-authentication* [bgp-as-number] 263 +--rw bgp-as-number unit16 264 +--rw (peer-identification-method) 265 +--:(group) 266 | +--rw peer-group* [group-name] 267 | +--rw group-name string 268 | +--rw (authentication-method) 269 | +--:(md5) 270 | | +--rw password-type:{plain|cipher} enumeration 271 | | +--rw password-text string 272 | +--:(keychain) 273 | +--rw keychain-name 274 +--:(ip) 275 +--rw peer-ip* [ipv4-addr] 276 +--rw ipv4-addr inet-type:ipv4-address 277 +--rw (authentication-method) 278 +--:(md5) 279 | +--rw password-type:{plain|cipher} enumeration 280 | +--rw password-text string 281 +--:(keychain) 282 +--rw keychain-name string 284 4.2. OSPF 286 There are a number of ways for spoofing procotol packet to attack 287 OSPF protocol. One possible scenario is that the rogue device inject 288 manipulated routing information to cause a Denial-of-Service attack. 290 Authentication has been demonstrated as a powerful tool to identify 291 and drop these spoofing packets to protect OSPF protocol and secure 292 the connection between the OSPF neighbors. A widely range of 293 authentication methods can be deployed in a network device such as 294 MD5, HAMC-MD5, and keychain. As shown in the following tree diagram, 295 the authentication can be deployed in either area or interface basis. 297 module:ospf-sec-config 298 +--rw ospf-authentication 299 +--rw area-authentication* [area-id] 300 | +--rw area-id unit16 301 | +--rw (authentication-method) 302 | +--:(simple-authen) 303 | | +--rw password-type:{plain|cipher} enumeration 304 | | +--rw password-text string 305 | +--:(md5-hmac-authen) 306 | | +--rw sub-mode: 307 | | | {md5|hmac-md5|hmac-sha256} enumeration 308 | | +--rw password-type enumeration 309 | | +--rw password-text string 310 | +--:(keychain-authen) 311 | +--rw keychain-name string 312 +--rw interface-authentication* [interface-number] 313 +--rw interface-type enumeration 314 +--rw interface-number unit8 315 +--rw (authentication-method) 316 +--:(simple-authen) 317 | +--rw password-type enumeration 318 | +--rw password-text string 319 +--:(md5-hmac-authen) 320 | +--rw sub-mode enumeration 321 | +--rw password-type enumeration 322 | +--rw password-text string 323 +--:(keychain-authen) 324 +--rw keychain-name string 326 4.3. IS-IS 328 IS-IS optional checksum function adds the a checksum TLV in SNP and 329 hello packet. The device firstly check the correctness of checksum 330 TVL when it receive the packet. It secure the data in data link 331 layer. 333 IS-IS authentication encapsulate the authentication information in 334 hello packet, LSP packet, and SNP packet. Only the packets passed 335 the verification will be further processed. The IS-IS authentication 336 is mainly used to secure packet in network layer. 338 module:isis-sec-config 339 +--rw isis-optional-checksum 340 | +--rw enable boolean 341 +--rw isis-authentication 342 +--rw area-authentication* [process-id] 343 | +--rw process-id unit32 344 | +--rw (authentication-method) 345 | +--:(simple) 346 | | +--rw authen-password-mode:{op|osi} enumeration 347 | | +--rw password-type:{plain|cipher} enumeration 348 | | +--rw password-text string 349 | +--:(md5) 350 | | +--rw authen-password-mode:{op|osi} enumeration 351 | | +--rw password-type:{plain|cipher} enumeration 352 | | +--rw password-text string 353 | +--:(keychain) 354 | | +--rw keychain-name string 355 | +--:(hmac-sha256) 356 | | +--rw key-id unit16 357 | | +--rw password-type:{plain|cipher} enumeration 358 | | +--rw password-text string 359 | +--rw snp-packet: 360 | | {authentication-avoid|send-only} enumeration 361 | +--rw all-send-only? boolean 362 +--rw domain-authentication* [process-id] 363 | +--rw process-id unit32 364 | +--rw (authentication-method) 365 | +--:(simple) 366 | | +--rw authen-password-mode:{op|osi} enumeration 367 | | +--rw password-type:{plain|cipher} enumeration 368 | | +--rw password-text string 369 | +--:(md5) 370 | | +--rw authen-password-mode:{op|osi} enumeration 371 | | +--rw password-type:{plain|cipher} enumeration 372 | | +--rw password-text string 373 | +--:(keychain) 374 | | +--rw keychain-name string 375 | +--:(hmac-sha256) 376 | | +--rw key-id unit16 377 | | +--rw password-type:{plain|cipher} enumeration 378 | | +--rw password-text string 379 | +--rw snp-packet enumeration 380 | +--rw all-send-only? boolean 381 +--rw interface-authentication* [interface-number] 382 +--rw interface-type enumeration 383 +--rw interface-number pub-type:ifNum 384 +--rw (authentication-method) 385 +--:(simple) 386 | +--rw authen-password-mode:{op|osi} enumeration 387 | +--rw password-type:{plain|cipher} enumeration 388 | +--rw password-text string 389 +--:(md5) 390 | +--rw authen-password-mode:{op|osi} enumeration 391 | +--rw password-type:{plain|cipher} enumeration 392 | +--rw password-text string 393 +--:(keychain) 394 | +--rw keychain-name string 395 +--:(hmac-sha256) 396 | +--rw key-id unit16 397 | +--rw password-type:{plain|cipher} enumeration 398 | +--rw password-text string 399 +--rw authen-level?:{level1|level2} enumeration 400 +--rw send-only? boolean 402 4.4. MPLS 404 RSVP authentication is suggested to configure in the device in order 405 to improve the network security and protect the local device against 406 the malicious attack. It prevent the establishment of illegal RSVP 407 peer connection in the following situation 409 The peer was unauthorized to establish connection with local 410 device; 412 The attacker establish connection with locol device via spoofing 413 RSVP packet. 415 Furthermore, it introduce a few enhancement to verify the lifetime, 416 handshake and message window size for protection of RSVP against the 417 playback attack and the termination of authentication relationships 418 caused by packet out of order problem. 420 As shown in the tree diagram, the LDP also support MD5 and keychain 421 authentication. 423 module:mpls-sec-config 424 +--rw rsvp-sec-config 425 | +--rw rsvp-authentication 426 | +--rw interface-authentication 427 | | +--rw interface-authen* [interface-number] 428 | | +--rw interface-type enumeration 429 | | +--rw interface-number pub-type:ifNum 430 | | +--rw (authentication-method) 431 | | +--:(md5) 432 | | | +--rw password-type:{plain|cipher} enumeration 433 | | | +--rw password-text string 434 | | +--:(keychain) 435 | | | +--rw keychain-name string 436 | | +--rw life-time? yang-type:timestamp 437 | | +--rw handshake-enable? boolean 438 | | +--rw window-size? unit8 439 | +--rw peer-authentication 440 | +--rw peer-authen* [peer-addr] 441 | +--rw peer-addr inet-type:ip-address 442 | +--rw (authentication-method) 443 | +--:(md5) 444 | | +--rw password-type:{plain|cipher} enumeration 445 | | +--rw password-text string 446 | +--:(keychain) 447 | | +--rw keychain-name string 448 | +--rw challenge-maximum-miss-times? unit8 449 | +--rw challenge-retrans-interval? unit16 450 | +--rw life-time? yang-type:timestamp 451 | +--rw handshake-enable? boolean 452 | +--rw window-size? unit8 453 +--rw ldp-sec-config 454 +--rw ldp-authentication 455 +--rw (authentication-method) 456 +--:(keychain) 457 | +--rw (authen-object) 458 | +--:(peer-single) 459 | | +--rw single-peer-authen* [peer-id] 460 | | +--rw peer-id dotted decimal 461 | | +--rw keychain-name string 462 | +--:(peer-group) 463 | | +--rw group-peer-authen* [ip-prefix-name] 464 | | +--rw ip-prefix-name string 465 | | +--rw keychain-name string 466 | +--:(peer-all) 467 | +--rw keychain-name string 468 | +--rw exclude-peer-id? dotted decimal 469 +--:(md5) 470 +--rw (authen-object) 471 +--:(peer-single) 472 | +--rw single-peer-authen* [peer-lsr-id] 473 | +--rw peer-lsr-id dotted decimal 474 | +--rw password-type:{plain|cipher} enumeration 475 | +--rw password-text string 476 +--:(peer-group) 477 | +--rw group-peer-authen* [ip-prefix-name] 478 | +--rw ip-prefix-name string 479 | +--rw password-type:{plain|cipher} enumeration 480 | +--rw password-text string 481 +--:(peer-all) 482 +--rw password-type:{plain|cipher} enumeration 483 +--rw password-text string 485 4.5. Keychain 487 Authentication is a widely used technique to ensure the packet 488 information are not been changed/altered by attackers. It requires 489 the information sender and receiver to share the authentication 490 information including the key and algorithm. In addition, the key 491 pairs cannot be delivered in the network (symmetric). However, in 492 order to improve the its reliability, the encryption algorithm and 493 the keys have to be renewed dynamically. It is a complicated and 494 time consuming process to change the keys and algorithm for all the 495 used protocols manually. The keychain provide an solution to renew 496 the authentication keys and algorithm periodically in a dynamic 497 fashion. 499 module:keychain-config 500 +--rw keychain-config* [keychain-name] 501 +--rw keychain-name string 502 +--rw keychain-mode: 503 | {absolute|periodic|daily| 504 | weekly|monthly|yearly} enumeration 505 +--rw receive-tolerance? 506 | +--:(finite) 507 | | +--rw tolerance-value unit16 508 | +--:(infinite) 509 | +--rw infinite-enable boolean 510 +--rw time-mode:{utc|lmt} enumeration 511 +--rw digest-length? boolean 512 +--rw keychain-id* [key-id] 513 +--rw key-id unit8 514 +--rw keychain-string-type:{plain|cipher} enumeration 515 +--rw keychain-string-text string 516 +--rw keychain-algorithm: 517 | {hmac-md5|hmac-sha-256|hmac-sha1_12| 518 | hmac-sha1_20|md5|sha-1|sha-256} enumeration 519 +--rw default-key-id? unit8 520 +--rw (send-time-mode) 521 | +--:(absolute) 522 | | +--rw start-time yang-type:timestamp 523 | | +--rw start-date yang-type:date-and-time 524 | | +--rw (count-type) 525 | | +--:(duration) 526 | | | +--rw (finite-or-infinite) 527 | | | +--:(finite) 528 | | | | +--rw duration-value unit32 529 | | | +--:(infinite) 530 | | | +--rw infinite-enable boolean 531 | | +--:(end) 532 | | +--rw end-time yang-type:timestamp 533 | | +--rw end-date yang-type:date-and-time 534 | +--:(periodic-daily) 535 | | +--rw start-time yang-type:timestamp 536 | | +--rw end-time yang-type:timestamp 537 | +--:(periodic-weekly) 538 | | +--rw (count-type) 539 | | +--:(continues) 540 | | | +--rw start-day-name enumeration 541 | | | +--rw end-day-name enumeration 542 | | +--:(discrete) 543 | | +--rw day-name* enumeration 544 | +--:(periodic-montly) 545 | | +--rw (count-type) 546 | | +--:(continues) 547 | | | +--rw start-date yang-type:date-and-time 548 | | | +--rw end-date yang-type:date-and-time 549 | | +--:(discrete) 550 | | +--rw date* yang-type:date-and-time 551 | +--:(periodic-yearly) 552 | +--rw (count-type) 553 | +--:(continues) 554 | | +--rw start-month enumeration 555 | | +--rw end-month enumeration 556 | +--:(discrete) 557 | +--rw month* enumeration 558 +--rw (receive-time-mode) 559 +--:(absolute) 560 | +--rw start-time yang-type:timestamp 561 | +--rw start-date yang-type:date-and-time 562 | +--rw (count-type) 563 | +--:(duration) 564 | | +--rw (finite-or-infinite) 565 | | +--:(finite) 566 | | | +--rw duration-value unit32 567 | | +--:(infinite) 568 | | +--rw infinite-enable boolean 569 | +--:(end) 570 | +--rw end-time yang-type:timestamp 571 | +--rw end-date yang-type:date-and-time 572 +--:(periodic-daily) 573 | +--rw start-time yang-type:timestamp 574 | +--rw end-time yang-type:timestamp 575 +--:(periodic-weekly) 576 | +--rw (count-type) 577 | +--:(continues) 578 | | +--rw start-day-name enumeration 579 | | +--rw end-day-name enumeration 580 | +--:(discrete) 581 | +--rw day-name* enumeration 582 +--:(periodic-montly) 583 | +--rw (count-type) 584 | +--:(continues) 585 | | +--rw start-date yang-type:date-and-time 586 | | +--rw end-date yang-type:date-and-time 587 | +--:(discrete) 588 | +--rw date* yang-type:date-and-type 589 +--:(periodic-yearly) 590 +--rw (count-type) 591 +--:(continues) 592 | +--rw start-month enumeration 593 | +--rw end-month enumeration 594 +--:(discrete) 595 +--rw month* enumeration 597 4.6. GTSM 599 Attackers send a large amount of forging packets to a target network 600 device. Then the forging packets are delivered to the cpu 601 straigtforward when the destinations are correctly checked. The CPU 602 will be overloaded owning to processing such a number of protocol 603 packets. In order to protect the CPU against the CPU utilization 604 attack, a GTSM (generized TTL security mechanism) function is 605 configured to check the TTL (time to live) in the IP head. The 606 packets will send to cpu for further processing only if the TTL 607 number is whithin a pre-defined range. 609 As shown in the three diagram in the following figure, the GTSM 610 function is configured separately for individual procotols. Each of 611 the protocols, even each list instances in a protocol, has its own 612 pre-defined TTL range. 614 module:gtsm 615 +--rw gtsm-config 616 +--rw default-gtsm-action:{drop|pass} 617 +--rw bgp-gtsm* [bgp-as-number] 618 | +--rw bgp-as-number unit32 619 | +--rw (peer-identification-method) 620 | +--:(group) 621 | | +--rw peer-group* [group-name] 622 | | +--rw group-name string 623 | | +--rw valid-ttl-hops unit16 624 | +--:(ip) 625 | +--rw peer-ip* [ipv4-addr] 626 | +--rw ipv4-addr inet-type:ipv4-address 627 | +--rw valid-ttl-hops unit8 628 +--rw ospf-gtsm* [vpn-instance-name] 629 | +--rw vpn-instance-name string 630 | +--rw valid-ttl-hops unit16 631 +--rw mpls-ldp-gtsm* [peer-ip-addr] 632 | +--rw peer-ip-addr inet-type:ip-address 633 | +--rw valid-ttl-hops unit16 634 +--rw rip-gtsm* [vpn-instance-name] 635 +--rw vpn-instance-name? string 636 +--rw valid-ttl-hops unit16 638 5. Network Infrastructure Device Security Baseline Yang Module 640 TBD 642 6. IANA Considerations 644 This document makes no request of IANA. 646 Note to RFC Editor: this section may be removed on publication as an 647 RFC. 649 7. Security Considerations 651 TBD. 653 8. Acknowledgements 655 TBD 657 9. References 658 9.1. Normative References 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, 662 DOI 10.17487/RFC2119, March 1997, 663 . 665 9.2. Informative References 667 [I-D.ietf-netconf-subscribed-notifications] 668 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 669 A. Tripathy, "Custom Subscription to Event Notifications", 670 draft-ietf-netconf-subscribed-notifications-03 (work in 671 progress), July 2017. 673 [I-D.ietf-netconf-yang-push] 674 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 675 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to 676 YANG datastore push updates", draft-ietf-netconf-yang- 677 push-08 (work in progress), August 2017. 679 [I-D.ietf-sacm-information-model] 680 Waltermire, D., Watson, K., Kahn, C., Lorenzin, L., Cokus, 681 M., Haynes, D., and H. Birkholz, "SACM Information Model", 682 draft-ietf-sacm-information-model-10 (work in progress), 683 April 2017. 685 Authors' Addresses 687 Yue Dong 688 Huawei 690 Email: dongyue6@huawei.com 692 Liang Xia 693 Huawei 695 Email: frank.xialiang@huawei.com