idnits 2.17.1 draft-ietf-tcpm-yang-tcp-06.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 == Line 1040 has weird spacing: '...address ine...' == Line 1047 has weird spacing: '...nterval uin...' -- The document date (3 February 2022) is 812 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 (-26) exists of draft-ietf-netconf-tcp-client-server-11 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-25 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-22 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-12 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-14 == Outdated reference: A later version (-09) exists of draft-ietf-tcpm-ao-test-vectors-06 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM M. Scharf 3 Internet-Draft Hochschule Esslingen 4 Intended status: Standards Track M. Jethanandani 5 Expires: 7 August 2022 Kloud Services 6 V. Murgai 7 Samsung 8 3 February 2022 10 A YANG Model for Transmission Control Protocol (TCP) Configuration 11 draft-ietf-tcpm-yang-tcp-06 13 Abstract 15 This document specifies a minimal YANG model for TCP on devices that 16 are configured by network management protocols. The YANG model 17 defines a container for all TCP connections and groupings of 18 authentication parameters that can be imported and used in TCP 19 implementations or by other models that need to configure TCP 20 parameters. The model also includes basic TCP statistics. The model 21 is compliant with Network Management Datastore Architecture (NMDA) 22 (RFC 8342). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 7 August 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 4 60 3. YANG Module Overview . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Model Design . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 64 4. TCP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 14 67 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 15 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 71 7.2. Informative References . . . . . . . . . . . . . . . . . 18 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 73 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20 74 B.1. Keepalive Configuration . . . . . . . . . . . . . . . . . 20 75 B.2. TCP-AO Configuration . . . . . . . . . . . . . . . . . . 21 76 Appendix C. Complete Tree Diagram . . . . . . . . . . . . . . . 23 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 79 1. Introduction 81 The Transmission Control Protocol (TCP) [I-D.ietf-tcpm-rfc793bis] is 82 used by many applications in the Internet, including control and 83 management protocols. As such, TCP is implemented on network 84 elements that can be configured via network management protocols such 85 as NETCONF [RFC6241] or RESTCONF [RFC8040]. 87 This document specifies a minimal YANG 1.1 [RFC7950] model for 88 configuring TCP on network elements that support YANG. This YANG 89 module is compliant with Network Management Datastore Architecture 90 (NMDA) [RFC8342]. 92 The YANG module has a narrow scope and focuses on a subset of 93 fundamental TCP functions and basic statistics. It defines a 94 container for TCP connection that includes definitions from YANG 95 Groupings for TCP Clients and TCP Servers 96 [I-D.ietf-netconf-tcp-client-server]. This model adheres to the 97 recommendation in BGP/MPLS IP Virtual Private Networks [RFC4364] as 98 it allows enabling of TCP-AO [RFC5925], and accommodates the 99 installed base that makes use of MD5. The module can be augmented or 100 updated to address more advanced or implementation-specific TCP 101 features in the future. 103 Many protocol stacks on IP hosts use other methods to configure TCP, 104 such as operating system configuration or policies. Many TCP/IP 105 stacks cannot be configured by network management protocols such as 106 NETCONF [RFC6241] or RESTCONF [RFC8040]. Moreover, many existing 107 TCP/IP stacks do not use YANG data models. Such TCP implementations 108 often have other means to configure the parameters listed in this 109 document. Such other means are outside the scope of this document. 111 This specification is orthogonal to the Management Information Base 112 (MIB) for the Transmission Control Protocol (TCP) [RFC4022]. The 113 basic statistics defined in this document follow the model of the TCP 114 MIB. An TCP Extended Statistics MIB [RFC4898] is also available, but 115 this document does not cover such extended statistics. The YANG 116 module also omits some selected parameters included in TCP MIB, most 117 notably the configured Retransmission Timeout (RTO) algorithm. This 118 is conscious decision as these parameters hardly matter in a state- 119 of-the-art TCP implementation. It would also be possible also to 120 translate a MIB into a YANG module, for instance using Translation of 121 Structure of Management Information Version 2 (SMIv2) MIB Modules to 122 YANG Modules [RFC6643]. However, this approach is not used in this 123 document, because a translated model would not be up-to-date. 125 There are other existing TCP-related YANG models, which are 126 orthogonal to this specification. Examples are: 128 * TCP header attributes are modeled in other security-related 129 models, such as YANG Data Model for Network Access Control Lists 130 (ACLs) [RFC8519], Distributed Denial-of-Service Open Thread 131 Signaling (DOTS) Data Channel Specification [RFC8783], or I2NSF 132 Capability YANG Data Model [I-D.ietf-i2nsf-capability-data-model]. 134 * TCP-related configuration of a NAT (e.g., NAT44, NAT64, 135 Destination NAT) is defined in A YANG Module for Network Address 136 Translation (NAT) and Network Prefix Translation (NPT) [RFC8512] 137 and A YANG Data Model for Dual-Stack Lite (DS-Lite) [RFC8513]. 139 * TCP-AO and TCP MD5 configuration for Layer 3 VPNs is modeled in A 140 Layer 3 VPN Network YANG Model [I-D.ietf-opsawg-l3sm-l3nm]. This 141 model assumes that TCP-AO specific parameters are preconfigured in 142 addition to the keychain parameters. This issue is further 143 discussed below. 145 2. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 2.1. Note to RFC Editor 155 This document uses several placeholder values throughout the 156 document. Please replace them as follows and remove this note before 157 publication. 159 RFC XXXX, where XXXX is the number assigned to this document at the 160 time of publication. 162 2022-02-04 with the actual date of the publication of this document. 164 3. YANG Module Overview 166 3.1. Scope 168 TCP is implemented on different system architectures. As a result, 169 there are many different and often implementation-specific ways to 170 configure parameters of the TCP engine. In addition, in many TCP/IP 171 stacks configuration exists for different scopes: 173 * Global configuration: Many TCP implementations have configuration 174 parameters that affect all TCP connections. Typical examples 175 include enabling or disabling optional protocol features. 177 * Interface configuration: It can be useful to use different TCP 178 parameters on different interfaces, e.g., different device ports 179 or IP interfaces. In that case, TCP parameters can be part of the 180 interface configuration. Typical examples are the Maximum Segment 181 Size (MSS) or configuration related to hardware offloading. 183 * Connection parameters: Many implementations have means to 184 influence the behavior of each TCP connection, e.g., on the 185 programming interface used by applications. Typical examples are 186 socket options in the socket API, such as disabling the Nagle 187 algorithm by TCP_NODELAY. If an application uses such an 188 interface, it is possible that the configuration of the 189 application or application protocol includes TCP-related 190 parameters. An example is the BGP YANG Model for Service Provider 191 Networks [I-D.ietf-idr-bgp-model]. 193 * Policies: Setting of TCP parameters can also be part of system 194 policies, templates, or profiles. An example would be the 195 preferences defined in An Abstract Application Layer Interface to 196 Transport Services [I-D.ietf-taps-interface]. 198 As a result, there is no ground truth for setting certain TCP 199 parameters, and traditionally different TCP implementation have used 200 different modeling approaches. For instance, one implementation may 201 define a given configuration parameter globally, while another one 202 uses per-interface settings, and both approaches work well for the 203 corresponding use cases. Also, different systems may use different 204 default values. In addition, TCP can be implemented in different 205 ways and design choices by the protocol engine often affect 206 configuration options. 208 Nonetheless, a number of TCP stack parameters require configuration 209 by YANG models. This document therefore defines a minimal YANG model 210 with fundamental parameters directly following from TCP standards. 212 An important use case is the TCP configuration on network elements 213 such as routers, which often use YANG data models. The model 214 therefore specifies TCP parameters that are important on such TCP 215 stacks. 217 This in particular applies to the support of TCP-AO [RFC5925]. TCP 218 Authentication Option (TCP-AO) is used on routers to secure routing 219 protocols such as BGP. In that case, a YANG model for TCP-AO 220 configuration is required. The model defined in this document 221 includes the required parameters for TCP-AO configuration, such as 222 the values of SendID and RecvID. The keychain for TCP-AO can be 223 modeled by the YANG Data Model for Key Chains [RFC8177]. The 224 groupings defined in this document can be imported and used as part 225 of such a preconfiguration. 227 Given an installed base, the model also allows enabling of the legacy 228 TCP MD5 [RFC2385] signature option. As the TCP MD5 signature option 229 is obsoleted by TCP-AO, it is strongly RECOMMENDED to use TCP-AO. 231 Similar to the TCP MIB [RFC4022], this document also specifies basic 232 statistics and a TCP connection table. 234 * Statistics: Counters for the number of active/passive opens, sent 235 and received segments, errors, and possibly other detailed 236 debugging information 238 * TCP connection table: Access to status information for all TCP 239 connections. Note, the connection table is modeled as a list that 240 is read-writeable, even though a connection cannot be created by 241 adding entries to the table. Similarly, deletion of connections 242 from this list is implementation-specific. 244 This allows implementations of TCP MIB [RFC4022] to migrate to the 245 YANG model defined in this memo. Note that the TCP MIB does not 246 include means to reset statistics, which are defined in this 247 document. This is not a major addition, as a reset can simply be 248 implemented by storing offset values for the counters. 250 This version of the module does not cover Multipath TCP [RFC8684]. 252 3.2. Model Design 254 The YANG model defined in this document includes definitions from the 255 YANG Groupings for TCP Clients and TCP Servers 256 [I-D.ietf-netconf-tcp-client-server]. Similar to that model, this 257 specification defines YANG groupings. This allows reuse of these 258 groupings in different YANG data models. It is intended that these 259 groupings will be used either standalone or for TCP-based protocols 260 as part of a stack of protocol-specific configuration models. An 261 example could be the BGP YANG Model for Service Provider Networks 262 [I-D.ietf-idr-bgp-model]. 264 3.3. Tree Diagram 266 This section provides an abridged tree diagram for the YANG module 267 defined in this document. Annotations used in the diagram are 268 defined in YANG Tree Diagrams [RFC8340]. 270 module: ietf-tcp 271 +--rw tcp! 272 +--rw connections 273 | ... 274 +--ro statistics {statistics}? 275 ... 277 4. TCP YANG Model 279 This YANG module references The TCP Authentication Option [RFC5925], 280 Protection of BGP Sessions via the TCP MD5 Signature [RFC2385], 281 Transmission Control Protocol (TCP) Specification 282 [I-D.ietf-tcpm-rfc793bis], and imports Common YANG Data Types 283 [RFC6991], The NETCONF Access Control Model [RFC8341], and YANG 284 Groupings for TCP Clients and TCP Servers 285 [I-D.ietf-netconf-tcp-client-server]. 287 file "ietf-tcp@2022-02-04.yang" 288 module ietf-tcp { 289 yang-version "1.1"; 290 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp"; 291 prefix "tcp"; 293 import ietf-yang-types { 294 prefix "yang"; 295 reference 296 "RFC 6991: Common YANG Data Types."; 297 } 298 import ietf-tcp-common { 299 prefix "tcpcmn"; 300 reference 301 "I-D.ietf-netconf-tcp-client-server: YANG Groupings for TCP 302 Clients and TCP Servers."; 303 } 304 import ietf-inet-types { 305 prefix "inet"; 306 reference 307 "RFC 6991: Common YANG Data Types."; 308 } 309 import ietf-netconf-acm { 310 prefix nacm; 311 reference 312 "RFC 8341: Network Configuration Access Control Model"; 313 } 315 organization 316 "IETF TCPM Working Group"; 318 contact 319 "WG Web: 320 WG List: 322 Authors: Michael Scharf (michael.scharf at hs-esslingen dot de) 323 Mahesh Jethanandani (mjethanandani at gmail dot com) 324 Vishal Murgai (vmurgai at gmail dot com)"; 326 description 327 "This module focuses on fundamental TCP functions and basic 328 statistics. The model can be augmented to address more advanced 329 or implementation specific TCP features. 331 Copyright (c) 2021 IETF Trust and the persons identified as 332 authors of the code. All rights reserved. 334 Redistribution and use in source and binary forms, with or 335 without modification, is permitted pursuant to, and subject to 336 the license terms contained in, the Simplified BSD License set 337 forth in Section 4.c of the IETF Trust's Legal Provisions 338 Relating to IETF Documents 339 (https://trustee.ietf.org/license-info). 341 This version of this YANG module is part of RFC XXXX 342 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 343 for full legal notices. 345 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 346 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 347 'MAY', and 'OPTIONAL' in this document are to be interpreted as 348 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 349 they appear in all capitals, as shown here."; 351 revision "2022-02-04" { 352 description 353 "Initial Version"; 354 reference 355 "RFC XXXX, A YANG Model for Transmission Control Protocol (TCP) 356 Configuration."; 357 } 359 // Features 360 feature statistics { 361 description 362 "This implementation supports statistics reporting."; 363 } 365 // TCP-AO Groupings 367 grouping ao { 368 leaf enable-ao { 369 type boolean; 370 default "false"; 371 description 372 "When set to true, TCP-Authentication Option (TCP-AO) is 373 enabled."; 374 } 376 leaf send-id { 377 type uint8 { 378 range "0..max"; 379 } 380 must "../enable-ao = 'true'"; 381 description 382 "The SendID is inserted as the KeyID of the TCP-AO option 383 of outgoing segments. The SendID must match the RecvID 384 at the other endpoint."; 385 reference 386 "RFC 5925: The TCP Authentication Option, Section 3.1."; 387 } 389 leaf recv-id { 390 type uint8 { 391 range "0..max"; 392 } 393 must "../enable-ao = 'true'"; 394 description 395 "The RecvID is matched against the TCP-AO KeyID of incoming 396 segments. The RecvID must match the SendID at the other 397 endpoint."; 398 reference 399 "RFC 5925: The TCP Authentication Option, Section 3.1."; 400 } 402 leaf include-tcp-options { 403 type boolean; 404 must "../enable-ao = 'true'"; 405 default true; 406 description 407 "When set to true, TCP options are included in MAC 408 calculation."; 409 reference 410 "RFC 5925: The TCP Authentication Option, Section 3.1."; 411 } 413 leaf accept-key-mismatch { 414 type boolean; 415 must "../enable-ao = 'true'"; 416 description 417 "Accept, when set to true, TCP segments with a Master Key 418 Tuple (MKT) that is not configured."; 419 reference 420 "RFC 5925: The TCP Authentication Option, Section 7.3."; 421 } 422 description 423 "Authentication Option (AO) for TCP."; 424 reference 425 "RFC 5925: The TCP Authentication Option."; 426 } 428 // MD5 grouping 430 grouping md5 { 431 description 432 "Grouping for use in authenticating TCP sessions using MD5."; 433 reference 434 "RFC 2385: Protection of BGP Sessions via the TCP MD5 435 Signature."; 437 leaf enable-md5 { 438 type boolean; 439 default "false"; 440 description 441 "Enables, when set to true, support of MD5 to authenticate a 442 TCP session. As the TCP MD5 signature option is obsoleted by 443 TCP-AO, it is strongly RECOMMENDED to use TCP-AO instead."; 444 } 445 } 447 // TCP configuration 449 container tcp { 450 presence "The container for TCP configuration."; 452 description 453 "TCP container."; 455 container connections { 456 list connection { 457 key "local-address remote-address local-port remote-port"; 459 leaf local-address { 460 type inet:ip-address; 461 description 462 "Identifies the address that is used by the local 463 endpoint for the connection, and is one of the four 464 elements that form the connection identifier."; 465 } 467 leaf remote-address { 468 type inet:ip-address; 469 description 470 "Identifies the address that is used by the remote 471 endpoint for the connection, and is one of the four 472 elements that form the connection identifier."; 473 } 475 leaf local-port { 476 type inet:port-number; 477 description 478 "Identifies the local TCP port used for the connection, 479 and is one of the four elements that form the 480 connection identifier."; 481 } 483 leaf remote-port { 484 type inet:port-number; 485 description 486 "Identifies the remote TCP port used for the connection, 487 and is one of the four elements that form the 488 connection identifier."; 489 } 491 container common { 492 uses tcpcmn:tcp-common-grouping; 494 choice authentication { 495 case ao { 496 uses ao; 497 description 498 "Use TCP-AO to secure the connection."; 499 } 501 case md5 { 502 uses md5; 503 description 504 "Use TCP-MD5 to secure the connection."; 505 } 506 description 507 "Choice of TCP authentication."; 508 } 509 description 510 "Common definitions of TCP configuration. This includes 511 parameters such as how to secure the connection, 512 that can be part of either the client or server."; 513 } 514 description 515 "List of TCP connections with their parameters. The list 516 is modeled as writeable, but implementations may not 517 allow creation of new TCP connections by adding entries to 518 the list. Furthermore, the behavior upon removal is 519 implementation-specific. Implementations may support 520 closing or resetting a TCP connection upon an operation 521 that removes the entry from the list."; 522 } 523 description 524 "A container of all TCP connections."; 525 } 526 container statistics { 527 if-feature statistics; 528 config false; 530 leaf active-opens { 531 type yang:counter32; 532 description 533 "The number of times that TCP connections have made a 534 direct transition to the SYN-SENT state from the CLOSED 535 state."; 536 reference 537 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 538 (TCP) Specification."; 539 } 541 leaf passive-opens { 542 type yang:counter32; 543 description 544 "The number of times TCP connections have made a direct 545 transition to the SYN-RCVD state from the LISTEN state."; 546 reference 547 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 548 (TCP) Specification."; 549 } 551 leaf attempt-fails { 552 type yang:counter32; 553 description 554 "The number of times that TCP connections have made a 555 direct transition to the CLOSED state from either the 556 SYN-SENT state or the SYN-RCVD state, plus the number of 557 times that TCP connections have made a direct transition 558 to the LISTEN state from the SYN-RCVD state."; 559 reference 560 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 561 (TCP) Specification."; 562 } 564 leaf establish-resets { 565 type yang:counter32; 566 description 567 "The number of times that TCP connections have made a 568 direct transition to the CLOSED state from either the 569 ESTABLISHED state or the CLOSE-WAIT state."; 570 reference 571 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 572 (TCP) Specification."; 573 } 574 leaf currently-established { 575 type yang:gauge32; 576 description 577 "The number of TCP connections for which the current state 578 is either ESTABLISHED or CLOSE-WAIT."; 579 reference 580 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 581 (TCP) Specification."; 582 } 584 leaf in-segments { 585 type yang:counter64; 586 description 587 "The total number of segments received, including those 588 received in error. This count includes segments received 589 on currently established connections."; 590 reference 591 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 592 (TCP) Specification."; 593 } 595 leaf out-segments { 596 type yang:counter64; 597 description 598 "The total number of segments sent, including those on 599 current connections but excluding those containing only 600 retransmitted octets."; 601 reference 602 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 603 (TCP) Specification."; 604 } 606 leaf retransmitted-segments { 607 type yang:counter32; 608 description 609 "The total number of segments retransmitted; that is, the 610 number of TCP segments transmitted containing one or more 611 previously transmitted octets."; 612 reference 613 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 614 (TCP) Specification."; 615 } 617 leaf in-errors { 618 type yang:counter32; 619 description 620 "The total number of segments received in error (e.g., bad 621 TCP checksums)."; 623 reference 624 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 625 (TCP) Specification."; 626 } 628 leaf out-resets { 629 type yang:counter32; 630 description 631 "The number of TCP segments sent containing the RST flag."; 632 reference 633 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 634 (TCP) Specification."; 635 } 637 action reset { 638 nacm:default-deny-all; 639 description 640 "Reset statistics action command."; 641 input { 642 leaf reset-at { 643 type yang:date-and-time; 644 description 645 "Time when the reset action needs to be 646 executed."; 647 } 648 } 649 output { 650 leaf reset-finished-at { 651 type yang:date-and-time; 652 description 653 "Time when the reset action command completed."; 654 } 655 } 656 } 657 description 658 "Statistics across all connections."; 659 } 660 } 661 } 662 664 5. IANA Considerations 666 5.1. The IETF XML Registry 668 This document registers an URI in the "ns" subregistry of the IETF 669 XML Registry [RFC3688]. Following the format in IETF XML Registry 670 [RFC3688], the following registration is requested: 672 URI: urn:ietf:params:xml:ns:yang:ietf-tcp 673 Registrant Contact: The IESG. 674 XML: N/A, the requested URI is an XML namespace. 676 5.2. The YANG Module Names Registry 678 This document registers a YANG module in the "YANG Module Names" 679 registry YANG - A Data Modeling Language [RFC6020]. Following the 680 format in YANG - A Data Modeling Language [RFC6020], the following 681 registration is requested: 683 name: ietf-tcp 684 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp 685 prefix: tcp 686 reference: RFC XXXX 688 The registration is not maintained by IANA. 690 6. Security Considerations 692 The YANG module specified in this document defines a schema for data 693 that is designed to be accessed via network management protocols such 694 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 695 is the secure transport layer, and the mandatory-to-implement secure 696 transport is Secure Shell (SSH) described in Using the NETCONF 697 protocol over SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and 698 the mandatory-to-implement secure transport is TLS [RFC8446]. 700 The Network Configuration Access Control Model (NACM) [RFC8341] 701 provides the means to restrict access for particular NETCONF or 702 RESTCONF users to a preconfigured subset of all available NETCONF or 703 RESTCONF protocol operations and content. 705 There are a number of data nodes defined in this YANG module that are 706 writable/creatable/deletable (i.e., "config true", which is the 707 default). These data nodes may be considered sensitive or vulnerable 708 in some network environments. Write operations (e.g., edit-config) 709 to these data nodes without proper protection can have a negative 710 effect on network operations. These are the subtrees and data nodes 711 and their sensitivity/vulnerability: 713 * Common configuration included from NETCONF Client and Server 714 Models [I-D.ietf-netconf-tcp-client-server]. Unrestricted access 715 to all the nodes, e.g., keepalive idle-timer, can cause 716 connections to fail or to timeout prematurely. 718 * Authentication configuration. Unrestricted access to the nodes 719 under authentication configuration can prevent the use of 720 authenticated communication and cause connection setups to fail. 721 This can result in massive security vulnerabilities and service 722 disruption for the traffic requiring authentication. 724 Some of the readable data nodes in this YANG module may be considered 725 sensitive or vulnerable in some network environments. It is thus 726 important to control read access (e.g., via get, get-config, or 727 notification) to these data nodes. These are the subtrees and data 728 nodes and their sensitivity/vulnerability: 730 * Unrestricted access to connection information of the client or 731 server can be used by a malicious user to launch an attack, e.g. 732 MITM. 734 * Similarly, unrestricted access to statistics of the client or 735 server can be used by a malicious user to exploit any 736 vulnerabilities of the system. 738 Some of the RPC operations in this YANG module may be considered 739 sensitive or vulnerable in some network environments. It is thus 740 important to control access to these operations. These are the 741 operations and their sensitivity/vulnerability: 743 * The YANG module allows for the statistics to be cleared by 744 executing the reset action. This action should be restricted to 745 users with the right permission. 747 The module specified in this document supports MD5 to basically 748 accommodate the installed BGP base. MD5 suffers from the security 749 weaknesses discussed in Section 2 of RFC 6151 [RFC6151] or 750 Section 2.1 of RFC 6952 [RFC6952]. 752 7. References 754 7.1. Normative References 756 [I-D.ietf-netconf-tcp-client-server] 757 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 758 and TCP Servers", Work in Progress, Internet-Draft, draft- 759 ietf-netconf-tcp-client-server-11, 14 December 2021, 760 . 763 [I-D.ietf-tcpm-rfc793bis] 764 Eddy, W. M., "Transmission Control Protocol (TCP) 765 Specification", Work in Progress, Internet-Draft, draft- 766 ietf-tcpm-rfc793bis-25, 7 September 2021, 767 . 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, 772 DOI 10.17487/RFC2119, March 1997, 773 . 775 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 776 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 777 1998, . 779 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 780 DOI 10.17487/RFC3688, January 2004, 781 . 783 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 784 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 785 June 2010, . 787 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 788 the Network Configuration Protocol (NETCONF)", RFC 6020, 789 DOI 10.17487/RFC6020, October 2010, 790 . 792 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 793 and A. Bierman, Ed., "Network Configuration Protocol 794 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 795 . 797 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 798 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 799 . 801 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 802 RFC 6991, DOI 10.17487/RFC6991, July 2013, 803 . 805 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 806 RFC 7950, DOI 10.17487/RFC7950, August 2016, 807 . 809 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 810 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 811 . 813 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 814 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 815 May 2017, . 817 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 818 Zhang, "YANG Data Model for Key Chains", RFC 8177, 819 DOI 10.17487/RFC8177, June 2017, 820 . 822 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 823 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 824 . 826 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 827 Access Control Model", STD 91, RFC 8341, 828 DOI 10.17487/RFC8341, March 2018, 829 . 831 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 832 and R. Wilton, "Network Management Datastore Architecture 833 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 834 . 836 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 837 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 838 . 840 7.2. Informative References 842 [I-D.ietf-i2nsf-capability-data-model] 843 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 844 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 845 Internet-Draft, draft-ietf-i2nsf-capability-data-model-22, 846 22 January 2022, . 849 [I-D.ietf-idr-bgp-model] 850 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 851 YANG Model for Service Provider Networks", Work in 852 Progress, Internet-Draft, draft-ietf-idr-bgp-model-12, 25 853 October 2021, . 856 [I-D.ietf-opsawg-l3sm-l3nm] 857 Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., 858 and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in 859 Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-18, 860 8 October 2021, . 863 [I-D.ietf-taps-interface] 864 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 865 Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., 866 Pauly, T., and K. Rose, "An Abstract Application Layer 867 Interface to Transport Services", Work in Progress, 868 Internet-Draft, draft-ietf-taps-interface-14, 3 January 869 2022, . 872 [I-D.ietf-tcpm-ao-test-vectors] 873 Touch, J. and J. Kuusisaari, "TCP-AO Test Vectors", Work 874 in Progress, Internet-Draft, draft-ietf-tcpm-ao-test- 875 vectors-06, 30 January 2022, 876 . 879 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 880 the Transmission Control Protocol (TCP)", RFC 4022, 881 DOI 10.17487/RFC4022, March 2005, 882 . 884 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 885 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 886 2006, . 888 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 889 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 890 May 2007, . 892 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 893 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 894 RFC 6151, DOI 10.17487/RFC6151, March 2011, 895 . 897 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 898 Information Version 2 (SMIv2) MIB Modules to YANG 899 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 900 . 902 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 903 BGP, LDP, PCEP, and MSDP Issues According to the Keying 904 and Authentication for Routing Protocols (KARP) Design 905 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 906 . 908 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 909 Vinapamula, S., and Q. Wu, "A YANG Module for Network 910 Address Translation (NAT) and Network Prefix Translation 911 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 912 . 914 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 915 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 916 DOI 10.17487/RFC8513, January 2019, 917 . 919 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 920 "YANG Data Model for Network Access Control Lists (ACLs)", 921 RFC 8519, DOI 10.17487/RFC8519, March 2019, 922 . 924 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 925 Paasch, "TCP Extensions for Multipath Operation with 926 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 927 2020, . 929 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 930 Denial-of-Service Open Threat Signaling (DOTS) Data 931 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 932 May 2020, . 934 Appendix A. Acknowledgements 936 Michael Scharf was supported by the StandICT.eu project, which is 937 funded by the European Commission under the Horizon 2020 Programme. 939 The following persons have contributed to this document by reviews: 940 Mohamed Boucadair, and Tom Petch. 942 Appendix B. Examples 944 B.1. Keepalive Configuration 946 This particular example demonstrates how both a particular connection 947 can be configured for keepalives. 949 NOTE: '\' line wrapping per RFC 8792 951 952 957 959 960 961 192.0.2.1 962 192.0.2.2 963 1025 964 80 965 966 967 5 968 5 969 10 970 971 972 973 974 976 B.2. TCP-AO Configuration 978 The following example demonstrates how to model a TCP-AO [RFC5925] 979 configuration for the example in TCP-AO Test Vectors 980 [I-D.ietf-tcpm-ao-test-vectors]. 982 NOTE: '\' line wrapping per RFC 8792 984 985 990 992 993 994 fd00::1 995 fd00::2 996 1025 997 179 998 999 true 1000 61 1001 84 1002 1003 1004 1005 1007 1009 1010 ao-config 1011 "An example for TCP-AO configuration."\ 1013 1014 61 1015 hmac-sha-1 1016 1017 testvector 1018 1019 1020 1021 84 1022 hmac-sha-1 1023 1024 testvector 1025 1026 1027 1028 1030 Appendix C. Complete Tree Diagram 1032 Here is the complete tree diagram for the TCP YANG model. 1034 module: ietf-tcp 1035 +--rw tcp! 1036 +--rw connections 1037 | +--rw connection* 1038 | [local-address remote-address local-port remote-port] 1039 | +--rw local-address inet:ip-address 1040 | +--rw remote-address inet:ip-address 1041 | +--rw local-port inet:port-number 1042 | +--rw remote-port inet:port-number 1043 | +--rw common 1044 | +--rw keepalives! 1045 | | +--rw idle-time uint16 1046 | | +--rw max-probes uint16 1047 | | +--rw probe-interval uint16 1048 | +--rw (authentication)? 1049 | +--:(ao) 1050 | | +--rw enable-ao? boolean 1051 | | +--rw send-id? uint8 1052 | | +--rw recv-id? uint8 1053 | | +--rw include-tcp-options? boolean 1054 | | +--rw accept-key-mismatch? boolean 1055 | +--:(md5) 1056 | +--rw enable-md5? boolean 1057 +--ro statistics {statistics}? 1058 +--ro active-opens? yang:counter32 1059 +--ro passive-opens? yang:counter32 1060 +--ro attempt-fails? yang:counter32 1061 +--ro establish-resets? yang:counter32 1062 +--ro currently-established? yang:gauge32 1063 +--ro in-segments? yang:counter64 1064 +--ro out-segments? yang:counter64 1065 +--ro retransmitted-segments? yang:counter32 1066 +--ro in-errors? yang:counter32 1067 +--ro out-resets? yang:counter32 1068 +---x reset 1069 +---w input 1070 | +---w reset-at? yang:date-and-time 1071 +--ro output 1072 +--ro reset-finished-at? yang:date-and-time 1074 Authors' Addresses 1075 Michael Scharf 1076 Hochschule Esslingen - University of Applied Sciences 1077 Flandernstr. 101 1078 73732 Esslingen 1079 Germany 1081 Email: michael.scharf@hs-esslingen.de 1083 Mahesh Jethanandani 1084 Kloud Services 1086 Email: mjethanandani@gmail.com 1088 Vishal Murgai 1089 Samsung 1091 Email: vmurgai@gmail.com