idnits 2.17.1 draft-ietf-tcpm-yang-tcp-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1027 has weird spacing: '...address ine...' == Line 1034 has weird spacing: '...nterval uin...' -- The document date (29 December 2021) is 848 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-21 == 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-13 == Outdated reference: A later version (-09) exists of draft-ietf-tcpm-ao-test-vectors-04 Summary: 2 errors (**), 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: 2 July 2022 Kloud Services 6 V. Murgai 7 Samsung 8 29 December 2021 10 A YANG Model for Transmission Control Protocol (TCP) Configuration 11 draft-ietf-tcpm-yang-tcp-05 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 2 July 2022. 41 Copyright Notice 43 Copyright (c) 2021 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 . . . . . . . . . . . . . . . 22 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 2021-12-29 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@2021-12-29.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 "2021-12-29" { 352 description 353 "Initial Version"; 354 reference 355 "RFC XXXX, 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 "Enable support of TCP-Authentication Option (TCP-AO)."; 373 } 375 leaf send-id { 376 type uint8 { 377 range "0..max"; 378 } 379 must "../enable-ao = 'true'"; 380 description 381 "The SendID is inserted as the KeyID of the TCP-AO option 382 of outgoing segments. The SendID must match the RecvID 383 at the other endpoint."; 384 reference 385 "RFC 5925: The TCP Authentication Option, Section 3.1."; 386 } 388 leaf recv-id { 389 type uint8 { 390 range "0..max"; 391 } 392 must "../enable-ao = 'true'"; 393 description 394 "The RecvID is matched against the TCP-AO KeyID of incoming 395 segments. The RecvID must match the SendID at the other 396 endpoint."; 397 reference 398 "RFC 5925: The TCP Authentication Option, Section 3.1."; 399 } 401 leaf include-tcp-options { 402 type boolean; 403 must "../enable-ao = 'true'"; 404 default true; 405 description 406 "Include TCP options in MAC calculation."; 407 reference 408 "RFC 5925: The TCP Authentication Option, Section 3.1."; 409 } 411 leaf accept-key-mismatch { 412 type boolean; 413 must "../enable-ao = 'true'"; 414 description 415 "Accept TCP segments with a Master Key Tuple (MKT) that is 416 not configured."; 417 reference 418 "RFC 5925: The TCP Authentication Option, Section 7.3."; 419 } 420 description 421 "Authentication Option (AO) for TCP."; 422 reference 423 "RFC 5925: The TCP Authentication Option."; 424 } 426 // MD5 grouping 428 grouping md5 { 429 description 430 "Grouping for use in authenticating TCP sessions using MD5."; 432 reference 433 "RFC 2385: Protection of BGP Sessions via the TCP MD5 434 Signature."; 436 leaf enable-md5 { 437 type boolean; 438 default "false"; 439 description 440 "Enables, when set to true, support of MD5 to authenticate a 441 TCP session. As the TCP MD5 signature option is obsoleted by 442 TCP-AO, it is strongly RECOMMENDED to use TCP-AO instead."; 443 } 444 } 446 // TCP configuration 448 container tcp { 449 presence "The container for TCP configuration."; 451 description 452 "TCP container."; 454 container connections { 455 list connection { 456 key "local-address remote-address local-port remote-port"; 458 leaf local-address { 459 type inet:ip-address; 460 description 461 "Local address that forms the connection identifier."; 462 } 464 leaf remote-address { 465 type inet:ip-address; 466 description 467 "Remote address that forms the connection identifier."; 468 } 470 leaf local-port { 471 type inet:port-number; 472 description 473 "Local TCP port that forms the connection identifier."; 474 } 476 leaf remote-port { 477 type inet:port-number; 478 description 479 "Remote TCP port that forms the connection identifier."; 481 } 483 container common { 484 uses tcpcmn:tcp-common-grouping; 486 choice authentication { 487 case ao { 488 uses ao; 489 description 490 "Use TCP-AO to secure the connection."; 491 } 493 case md5 { 494 uses md5; 495 description 496 "Use TCP-MD5 to secure the connection."; 497 } 498 description 499 "Choice of TCP authentication."; 500 } 501 description 502 "Common definitions of TCP configuration. This includes 503 parameters such as how to secure the connection, 504 that can be part of either the client or server."; 505 } 506 description 507 "List of TCP connections with their parameters. The list 508 is modeled as writeable, but implementations may not 509 allow creation of new TCP connections by adding entries to 510 the list. Furthermore, the behavior upon removal is 511 implementation-specific. Implementations may support 512 closing or resetting a TCP connection upon an operation 513 that removes the entry from the list."; 514 } 515 description 516 "A container of all TCP connections."; 517 } 519 container statistics { 520 if-feature statistics; 521 config false; 523 leaf active-opens { 524 type yang:counter32; 525 description 526 "The number of times that TCP connections have made a 527 direct transition to the SYN-SENT state from the CLOSED 528 state."; 530 reference 531 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 532 (TCP) Specification."; 533 } 535 leaf passive-opens { 536 type yang:counter32; 537 description 538 "The number of times TCP connections have made a direct 539 transition to the SYN-RCVD state from the LISTEN state."; 540 reference 541 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 542 (TCP) Specification."; 543 } 545 leaf attempt-fails { 546 type yang:counter32; 547 description 548 "The number of times that TCP connections have made a 549 direct transition to the CLOSED state from either the 550 SYN-SENT state or the SYN-RCVD state, plus the number of 551 times that TCP connections have made a direct transition 552 to the LISTEN state from the SYN-RCVD state."; 553 reference 554 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 555 (TCP) Specification."; 556 } 558 leaf establish-resets { 559 type yang:counter32; 560 description 561 "The number of times that TCP connections have made a 562 direct transition to the CLOSED state from either the 563 ESTABLISHED state or the CLOSE-WAIT state."; 564 reference 565 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 566 (TCP) Specification."; 567 } 569 leaf currently-established { 570 type yang:gauge32; 571 description 572 "The number of TCP connections for which the current state 573 is either ESTABLISHED or CLOSE-WAIT."; 574 reference 575 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 576 (TCP) Specification."; 577 } 578 leaf in-segments { 579 type yang:counter64; 580 description 581 "The total number of segments received, including those 582 received in error. This count includes segments received 583 on currently established connections."; 584 reference 585 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 586 (TCP) Specification."; 587 } 589 leaf out-segments { 590 type yang:counter64; 591 description 592 "The total number of segments sent, including those on 593 current connections but excluding those containing only 594 retransmitted octets."; 595 reference 596 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 597 (TCP) Specification."; 598 } 600 leaf retransmitted-segments { 601 type yang:counter32; 602 description 603 "The total number of segments retransmitted; that is, the 604 number of TCP segments transmitted containing one or more 605 previously transmitted octets."; 606 reference 607 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 608 (TCP) Specification."; 609 } 611 leaf in-errors { 612 type yang:counter32; 613 description 614 "The total number of segments received in error (e.g., bad 615 TCP checksums)."; 616 reference 617 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 618 (TCP) Specification."; 619 } 621 leaf out-resets { 622 type yang:counter32; 623 description 624 "The number of TCP segments sent containing the RST flag."; 625 reference 626 "I-D.ietf-tcpm-rfc793bis: Transmission Control Protocol 627 (TCP) Specification."; 628 } 630 action reset { 631 nacm:default-deny-all; 632 description 633 "Reset statistics action command."; 634 input { 635 leaf reset-at { 636 type yang:date-and-time; 637 description 638 "Time when the reset action needs to be 639 executed."; 640 } 641 } 642 output { 643 leaf reset-finished-at { 644 type yang:date-and-time; 645 description 646 "Time when the reset action command completed."; 647 } 648 } 649 } 650 description 651 "Statistics across all connections."; 652 } 653 } 654 } 655 657 5. IANA Considerations 659 5.1. The IETF XML Registry 661 This document registers an URI in the "ns" subregistry of the IETF 662 XML Registry [RFC3688]. Following the format in IETF XML Registry 663 [RFC3688], the following registration is requested: 665 URI: urn:ietf:params:xml:ns:yang:ietf-tcp 666 Registrant Contact: The IESG. 667 XML: N/A, the requested URI is an XML namespace. 669 5.2. The YANG Module Names Registry 671 This document registers a YANG module in the "YANG Module Names" 672 registry YANG - A Data Modeling Language [RFC6020]. Following the 673 format in YANG - A Data Modeling Language [RFC6020], the following 674 registrations are requested: 676 name: ietf-tcp 677 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp 678 prefix: tcp 679 reference: RFC XXXX 681 6. Security Considerations 683 The YANG module specified in this document defines a schema for data 684 that is designed to be accessed via network management protocols such 685 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 686 is the secure transport layer, and the mandatory-to-implement secure 687 transport is Secure Shell (SSH) described in Using the NETCONF 688 protocol over SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and 689 the mandatory-to-implement secure transport is TLS [RFC8446]. 691 The Network Configuration Access Control Model (NACM) [RFC8341] 692 provides the means to restrict access for particular NETCONF or 693 RESTCONF users to a preconfigured subset of all available NETCONF or 694 RESTCONF protocol operations and content. 696 There are a number of data nodes defined in this YANG module that are 697 writable/creatable/deletable (i.e., "config true", which is the 698 default). These data nodes may be considered sensitive or vulnerable 699 in some network environments. Write operations (e.g., edit-config) 700 to these data nodes without proper protection can have a negative 701 effect on network operations. These are the subtrees and data nodes 702 and their sensitivity/vulnerability: 704 * Common configuration included from NETCONF Client and Server 705 Models [I-D.ietf-netconf-tcp-client-server]. Unrestricted access 706 to all the nodes, e.g., keepalive idle-timer, can cause 707 connections to fail or to timeout prematurely. 709 * Authentication configuration. Unrestricted access to the nodes 710 under authentication configuration can prevent the use of 711 authenticated communication and cause connection setups to fail. 712 This can result in massive security vulnerabilities and service 713 disruption for the traffic requiring authentication. 715 Some of the readable data nodes in this YANG module may be considered 716 sensitive or vulnerable in some network environments. It is thus 717 important to control read access (e.g., via get, get-config, or 718 notification) to these data nodes. These are the subtrees and data 719 nodes and their sensitivity/vulnerability: 721 * Unrestricted access to connection information of the client or 722 server can be used by a malicious user to launch an attack, e.g. 723 MITM. 725 * Similarly, unrestricted access to statistics of the client or 726 server can be used by a malicious user to exploit any 727 vulnerabilities of the system. 729 Some of the RPC operations in this YANG module may be considered 730 sensitive or vulnerable in some network environments. It is thus 731 important to control access to these operations. These are the 732 operations and their sensitivity/vulnerability: 734 * The YANG module allows for the statistics to be cleared by 735 executing the reset action. This action should be restricted to 736 users with the right permission. 738 The module specified in this document supports MD5 to basically 739 accommodate the installed BGP base. MD5 suffers from the security 740 weaknesses discussed in Section 2 of RFC 6151 [RFC6151] or 741 Section 2.1 of RFC 6952 [RFC6952]. 743 7. References 745 7.1. Normative References 747 [I-D.ietf-netconf-tcp-client-server] 748 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 749 and TCP Servers", Work in Progress, Internet-Draft, draft- 750 ietf-netconf-tcp-client-server-11, 14 December 2021, 751 . 754 [I-D.ietf-tcpm-rfc793bis] 755 Eddy, W. M., "Transmission Control Protocol (TCP) 756 Specification", Work in Progress, Internet-Draft, draft- 757 ietf-tcpm-rfc793bis-25, 7 September 2021, 758 . 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, 763 DOI 10.17487/RFC2119, March 1997, 764 . 766 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 767 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 768 1998, . 770 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 771 DOI 10.17487/RFC3688, January 2004, 772 . 774 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 775 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 776 June 2010, . 778 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 779 the Network Configuration Protocol (NETCONF)", RFC 6020, 780 DOI 10.17487/RFC6020, October 2010, 781 . 783 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 784 and A. Bierman, Ed., "Network Configuration Protocol 785 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 786 . 788 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 789 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 790 . 792 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 793 RFC 6991, DOI 10.17487/RFC6991, July 2013, 794 . 796 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 797 RFC 7950, DOI 10.17487/RFC7950, August 2016, 798 . 800 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 801 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 802 . 804 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 805 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 806 May 2017, . 808 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 809 Zhang, "YANG Data Model for Key Chains", RFC 8177, 810 DOI 10.17487/RFC8177, June 2017, 811 . 813 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 814 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 815 . 817 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 818 Access Control Model", STD 91, RFC 8341, 819 DOI 10.17487/RFC8341, March 2018, 820 . 822 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 823 and R. Wilton, "Network Management Datastore Architecture 824 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 825 . 827 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 828 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 829 . 831 7.2. Informative References 833 [I-D.ietf-i2nsf-capability-data-model] 834 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 835 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 836 Internet-Draft, draft-ietf-i2nsf-capability-data-model-21, 837 13 November 2021, . 840 [I-D.ietf-idr-bgp-model] 841 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 842 YANG Model for Service Provider Networks", Work in 843 Progress, Internet-Draft, draft-ietf-idr-bgp-model-12, 25 844 October 2021, . 847 [I-D.ietf-opsawg-l3sm-l3nm] 848 Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., 849 and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in 850 Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-18, 851 8 October 2021, . 854 [I-D.ietf-taps-interface] 855 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 856 Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., 857 Pauly, T., and K. Rose, "An Abstract Application Layer 858 Interface to Transport Services", Work in Progress, 859 Internet-Draft, draft-ietf-taps-interface-13, 12 July 860 2021, . 863 [I-D.ietf-tcpm-ao-test-vectors] 864 Touch, J. and J. Kuusisaari, "TCP-AO Test Vectors", Work 865 in Progress, Internet-Draft, draft-ietf-tcpm-ao-test- 866 vectors-04, 19 December 2021, 867 . 870 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 871 the Transmission Control Protocol (TCP)", RFC 4022, 872 DOI 10.17487/RFC4022, March 2005, 873 . 875 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 876 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 877 2006, . 879 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 880 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 881 May 2007, . 883 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 884 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 885 RFC 6151, DOI 10.17487/RFC6151, March 2011, 886 . 888 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 889 Information Version 2 (SMIv2) MIB Modules to YANG 890 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 891 . 893 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 894 BGP, LDP, PCEP, and MSDP Issues According to the Keying 895 and Authentication for Routing Protocols (KARP) Design 896 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 897 . 899 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 900 Vinapamula, S., and Q. Wu, "A YANG Module for Network 901 Address Translation (NAT) and Network Prefix Translation 902 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 903 . 905 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 906 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 907 DOI 10.17487/RFC8513, January 2019, 908 . 910 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 911 "YANG Data Model for Network Access Control Lists (ACLs)", 912 RFC 8519, DOI 10.17487/RFC8519, March 2019, 913 . 915 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 916 Paasch, "TCP Extensions for Multipath Operation with 917 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 918 2020, . 920 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 921 Denial-of-Service Open Threat Signaling (DOTS) Data 922 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 923 May 2020, . 925 Appendix A. Acknowledgements 927 Michael Scharf was supported by the StandICT.eu project, which is 928 funded by the European Commission under the Horizon 2020 Programme. 930 The following persons have contributed to this document by reviews: 931 Mohamed Boucadair, and Tom Petch. 933 Appendix B. Examples 935 B.1. Keepalive Configuration 937 This particular example demonstrates how both a particular connection 938 can be configured for keepalives. 940 [note: '\' line wrapping for formatting only] 941 [See RFC 8792: Handling Long Lines in Content of 942 Internet-Drafts and RFCs] 944 945 950 952 953 954 192.0.2.1 955 192.0.2.2 956 1025 957 80 958 959 960 5 961 5 962 10 963 964 965 966 967 969 B.2. TCP-AO Configuration 971 The following example demonstrates how to model a TCP-AO [RFC5925] 972 configuration for the example in TCP-AO Test Vectors 973 [I-D.ietf-tcpm-ao-test-vectors]. 975 [note: '\' line wrapping for formatting only] 976 [See RFC 8792: Handling Long Lines in Content of 977 Internet-Drafts and RFCs] 979 980 985 987 988 989 2001:db8::1 990 2001:db8::2 991 1025 992 80 993 994 true 995 996 997 998 1000 1002 1003 ao-config 1004 "An example for TCP-AO configuration."\ 1006 1007 61 1008 hmac-sha-1 1009 1010 01:23:a5:93:b9:db:70:62:9b:be:2c:a6:77:cd:fd:ea:\ 1011 6f:e0:ac:ad 1012 1013 1014 1015 1017 Appendix C. Complete Tree Diagram 1019 Here is the complete tree diagram for the TCP YANG model. 1021 module: ietf-tcp 1022 +--rw tcp! 1023 +--rw connections 1024 | +--rw connection* 1025 | [local-address remote-address local-port remote-port] 1026 | +--rw local-address inet:ip-address 1027 | +--rw remote-address inet:ip-address 1028 | +--rw local-port inet:port-number 1029 | +--rw remote-port inet:port-number 1030 | +--rw common 1031 | +--rw keepalives! 1032 | | +--rw idle-time uint16 1033 | | +--rw max-probes uint16 1034 | | +--rw probe-interval uint16 1035 | +--rw (authentication)? 1036 | +--:(ao) 1037 | | +--rw enable-ao? boolean 1038 | | +--rw send-id? uint8 1039 | | +--rw recv-id? uint8 1040 | | +--rw include-tcp-options? boolean 1041 | | +--rw accept-key-mismatch? boolean 1042 | +--:(md5) 1043 | +--rw enable-md5? boolean 1044 +--ro statistics {statistics}? 1045 +--ro active-opens? yang:counter32 1046 +--ro passive-opens? yang:counter32 1047 +--ro attempt-fails? yang:counter32 1048 +--ro establish-resets? yang:counter32 1049 +--ro currently-established? yang:gauge32 1050 +--ro in-segments? yang:counter64 1051 +--ro out-segments? yang:counter64 1052 +--ro retransmitted-segments? yang:counter32 1053 +--ro in-errors? yang:counter32 1054 +--ro out-resets? yang:counter32 1055 +---x reset 1056 +---w input 1057 | +---w reset-at? yang:date-and-time 1058 +--ro output 1059 +--ro reset-finished-at? yang:date-and-time 1061 Authors' Addresses 1063 Michael Scharf 1064 Hochschule Esslingen - University of Applied Sciences 1065 Flandernstr. 101 1066 73732 Esslingen 1067 Germany 1068 Email: michael.scharf@hs-esslingen.de 1070 Mahesh Jethanandani 1071 Kloud Services 1073 Email: mjethanandani@gmail.com 1075 Vishal Murgai 1076 Samsung 1078 Email: vmurgai@gmail.com