idnits 2.17.1 draft-ietf-tcpm-yang-tcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 962 has weird spacing: '...address ine...' == Line 969 has weird spacing: '...nterval uin...' == Line 980 has weird spacing: '...address ine...' == Line 985 has weird spacing: '...nterval uin...' == Line 987 has weird spacing: '...address ine...' == (1 more instance...) -- The document date (November 16, 2020) is 1257 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-08 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-09 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-10 == Outdated reference: A later version (-02) exists of draft-touch-tcpm-ao-test-vectors-01 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). 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 V. Murgai 5 Expires: May 20, 2021 Samsung 6 M. Jethanandani 7 Kloud Services 8 November 16, 2020 10 YANG Model for Transmission Control Protocol (TCP) Configuration 11 draft-ietf-tcpm-yang-tcp-01 13 Abstract 15 This document specifies a YANG model for TCP on devices that are 16 configured by network management protocols. The YANG model defines a 17 container for all TCP connections and groupings of some of the 18 parameters that can be imported and used in TCP implementations or by 19 other models that need to configure TCP parameters. The model 20 includes definitions from YANG Groupings for TCP Client and TCP 21 Servers (I-D.ietf-netconf-tcp-client-server). The model is NMDA (RFC 22 8342) compliant. 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 May 20, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3 61 3. Model Overview . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Modeling Scope . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Model Design . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 65 4. TCP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 13 68 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 13 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 72 7.2. Informative References . . . . . . . . . . . . . . . . . 16 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 74 Appendix B. Changes compared to previous versions . . . . . . . 18 75 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 19 76 C.1. Keepalive Configuration . . . . . . . . . . . . . . . . . 19 77 C.2. TCP-AO Configuration . . . . . . . . . . . . . . . . . . 20 78 Appendix D. Complete Tree Diagram . . . . . . . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 The Transmission Control Protocol (TCP) [RFC0793] is used by many 84 applications in the Internet, including control and management 85 protocols. Therefore, TCP is implemented on network elements that 86 can be configured via network management protocols such as NETCONF 87 [RFC6241] or RESTCONF [RFC8040]. This document specifies a YANG 88 [RFC7950] 1.1 model for configuring TCP on network elements that 89 support YANG data models, and is Network Management Datastore 90 Architecture (NMDA) [RFC8342] compliant. This module defines a 91 container for TCP connection, and includes definitions from YANG 92 Groupings for TCP Clients and TCP Servers 93 [I-D.ietf-netconf-tcp-client-server]. The model has a narrow scope 94 and focuses on fundamental TCP functions and basic statistics. The 95 model can be augmented or updated to address more advanced or 96 implementation-specific TCP features in the future. 98 Many protocol stacks on Internet hosts use other methods to configure 99 TCP, such as operating system configuration or policies. Many TCP/IP 100 stacks cannot be configured by network management protocols such as 101 NETCONF [RFC6241] or RESTCONF [RFC8040]. Moreover, many existing 102 TCP/IP stacks do not use YANG data models. Such TCP implementations 103 often have other means to configure the parameters listed in this 104 document, which are outside the scope of this document. 106 This specification is orthogonal to the Management Information Base 107 (MIB) for the Transmission Control Protocol (TCP) [RFC4022]. The 108 basic statistics defined in this document follow the model of the TCP 109 MIB. An TCP Extended Statistics MIB [RFC4898] is also available, but 110 this document does not cover such extended statistics. It is 111 possible also to translate a MIB into a YANG model, for instance 112 using Translation of Structure of Management Information Version 2 113 (SMIv2) MIB Modules to YANG Modules [RFC6643]. However, this 114 approach is not used in this document, as such a translated model 115 would not be up-to-date. 117 There are other existing TCP-related YANG models, which are 118 orthogonal to this specification. Examples are: 120 o TCP header attributes are modeled in other models, such as YANG 121 Data Model for Network Access Control Lists (ACLs) [RFC8519] and 122 Distributed Denial-of-Service Open Thread Signaling (DOTS) Data 123 Channel Specification [RFC8783]. 125 o TCP-related configuration of a NAT (e.g., NAT44, NAT64, 126 Destination NAT, ...) is defined in A YANG Module for Network 127 Address Translation (NAT) and Network Prefix Translation (NPT) 128 [RFC8512] and A YANG Data Model for Dual-Stack Lite (DS-Lite) 129 [RFC8513]. 131 2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 2.1. Note to RFC Editor 141 This document uses several placeholder values throughout the 142 document. Please replace them as follows and remove this note before 143 publication. 145 RFC XXXX, where XXXX is the number assigned to this document at the 146 time of publication. 148 2020-11-16 with the actual date of the publication of this document. 150 3. Model Overview 152 3.1. Modeling Scope 154 TCP is implemented on many different system architectures. As a 155 result, there are may different and often implementation-specific 156 ways to configure parameters of the TCP protocol engine. In 157 addition, in many TCP/IP stacks configuration exists for different 158 scopes: 160 o Global configuration: Many TCP implementations have configuration 161 parameters that affect all TCP connections. Typical examples 162 include enabling or disabling optional protocol features. 164 o Interface configuration: It can be useful to use different TCP 165 parameters on different interfaces, e.g., different device ports 166 or IP interfaces. In that case, TCP parameters can be part of the 167 interface configuration. Typical examples are the Maximum Segment 168 Size (MSS) or configuration related to hardware offloading. 170 o Connection parameters: Many implementations have means to 171 influence the behavior of each TCP connection, e.g., on the 172 programming interface used by applications. A typical example are 173 socket options in the socket API, such as disabling the Nagle 174 algorithm by TCP_NODELAY. If an application uses such an 175 interface, it is possible that the configuration of the 176 application or application protocol includes TCP-related 177 parameters. An example is the BGP YANG Model for Service Provider 178 Networks [I-D.ietf-idr-bgp-model]. 180 o Policies: Setting of TCP parameters can also be part of system 181 policies, templates, or profiles. An example would be the 182 preferences defined in An Abstract Application Layer Interface to 183 Transport Services [I-D.ietf-taps-interface]. 185 As a result, there is no ground truth for setting certain TCP 186 parameters, and traditionally different TCP implementation have used 187 different modeling approaches. For instance, one implementation may 188 define a given configuration parameter globally, while another one 189 uses per-interface settings, and both approaches work well for the 190 corresponding use cases. Also, different systems may use different 191 default values. In addition, TCP can be implemented in different 192 ways and design choices by the protocol engine often affect 193 configuration options. 195 Nonetheless, a number of TCP stack parameters require configuration 196 by YANG models. This document therefore defines a minimal YANG model 197 with fundamental parameters directly following from TCP standards. 199 An important use case is the TCP configuration on network elements 200 such as routers, which often use YANG data models. The model 201 therefore specifies TCP parameters that are important on such TCP 202 stacks. 204 A typical example is the support of TCP-AO [RFC5925]. TCP-AO is 205 increasingly supported on routers to secure routing protocols such as 206 BGP. In that case, TCP-AO configuration is required on routers. The 207 model includes the required TCP parameters for TCP-AO configuration. 208 The key chain for TCP-AO can be modeled by the YANG Data Model for 209 Key Chains [RFC8177]. 211 Given an installed base, the model also allows enabling of the legacy 212 TCP MD5 [RFC2385] signature option. As the TCP MD5 signature option 213 is obsoleted by TCP-AO, it is strongly RECOMMENDED to use TCP-AO. 215 Similar to the TCP MIB [RFC4022], this document also specifies basic 216 statistics and a TCP connection table. 218 o Statistics: Counters for the number of active/passive opens, sent 219 and received segments, errors, and possibly other detailed 220 debugging information 222 o TCP connection table: Access to status information for all TCP 223 connections 225 This allows implementations of TCP MIB [RFC4022] to migrate to the 226 YANG model defined in this memo. 228 3.2. Model Design 230 The YANG model defined in this document includes definitions from the 231 YANG Groupings for TCP Clients and TCP Servers 232 [I-D.ietf-netconf-tcp-client-server]. Similar to that model, this 233 specification defines YANG groupings. This allows reuse of these 234 groupings in different YANG data models. It is intended that these 235 groupings will be used either standalone or for TCP-based protocols 236 as part of a stack of protocol-specific configuration models. An 237 example could be the BGP YANG Model for Service Provider Networks 238 [I-D.ietf-idr-bgp-model]. 240 3.3. Tree Diagram 242 This section provides a abridged tree diagram for the YANG module 243 defined in this document. Annotations used in the diagram are 244 defined in YANG Tree Diagrams [RFC8340]. 246 module: ietf-tcp 247 +--rw tcp! 248 +--rw connections 249 | ... 250 +--rw server {server}? 251 | ... 252 +--rw client {client}? 253 | ... 254 +--ro statistics {statistics}? 255 ... 257 4. TCP YANG Model 259 file "ietf-tcp@2020-11-16.yang" 261 module ietf-tcp { 262 yang-version "1.1"; 263 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp"; 264 prefix "tcp"; 266 import ietf-yang-types { 267 prefix "yang"; 268 reference 269 "RFC 6991: Common YANG Data Types."; 270 } 271 import ietf-tcp-client { 272 prefix "tcpc"; 273 } 274 import ietf-tcp-server { 275 prefix "tcps"; 276 } 277 import ietf-tcp-common { 278 prefix "tcpcmn"; 279 } 280 import ietf-inet-types { 281 prefix "inet"; 282 } 284 organization 285 "IETF TCPM Working Group"; 287 contact 288 "WG Web: 289 WG List: 291 Authors: Michael Scharf (michael.scharf at hs-esslingen dot de) 292 Vishal Murgai (vmurgai at gmail dot com) 293 Mahesh Jethanandani (mjethanandani at gmail dot com)"; 295 description 296 "This module focuses on fundamental and standard TCP functions 297 that widely implemented. The model can be augmented to address 298 more advanced or implementation specific TCP features. 300 Copyright (c) 2020 IETF Trust and the persons identified as 301 authors of the code. All rights reserved. 303 Redistribution and use in source and binary forms, with or 304 without modification, is permitted pursuant to, and subject to 305 the license terms contained in, the Simplified BSD License set 306 forth in Section 4.c of the IETF Trust's Legal Provisions 307 Relating to IETF Documents 308 (https://trustee.ietf.org/license-info). 310 This version of this YANG module is part of RFC XXXX 311 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 312 for full legal notices. 314 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 315 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 316 'MAY', and 'OPTIONAL' in this document are to be interpreted as 317 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 318 they appear in all capitals, as shown here."; 320 revision "2020-11-16" { 321 description 322 "Initial Version"; 323 reference 324 "RFC XXXX, TCP Configuration."; 325 } 327 // Features 328 feature server { 329 description 330 "TCP Server configuration supported."; 331 } 333 feature client { 334 description 335 "TCP Client configuration supported."; 337 } 339 feature statistics { 340 description 341 "This implementation supports statistics reporting."; 342 } 344 // TCP-AO Groupings 346 grouping ao { 347 leaf enable-ao { 348 type boolean; 349 default "false"; 350 description 351 "Enable support of TCP-Authentication Option (TCP-AO)."; 352 } 354 leaf send-id { 355 type uint8 { 356 range "0..255"; 357 } 358 must "../enable-ao = 'true'"; 359 description 360 "The SendID is inserted as the KeyID of the TCP-AO option 361 of outgoing segments."; 362 reference 363 "RFC 5925: The TCP Authentication Option."; 364 } 366 leaf recv-id { 367 type uint8 { 368 range "0..255"; 369 } 370 must "../enable-ao = 'true'"; 371 description 372 "The RecvID is matched against the TCP-AO KeyID of incoming 373 segments."; 374 reference 375 "RFC 5925: The TCP Authentication Option."; 376 } 378 leaf include-tcp-options { 379 type boolean; 380 must "../enable-ao = 'true'"; 381 default true; 382 description 383 "Include TCP options in MAC calculation."; 384 } 385 leaf accept-key-mismatch { 386 type boolean; 387 must "../enable-ao = 'true'"; 388 description 389 "Accept TCP segments with a Master Key Tuple (MKT) that is not 390 configured."; 391 } 392 description 393 "Authentication Option (AO) for TCP."; 394 reference 395 "RFC 5925: The TCP Authentication Option."; 396 } 398 // MD5 grouping 400 grouping md5 { 401 description 402 "Grouping for use in authenticating TCP sessions using MD5."; 403 reference 404 "RFC 2385: Protection of BGP Sessions via the TCP MD5 405 Signature."; 407 leaf enable-md5 { 408 type boolean; 409 default "false"; 410 description 411 "Enable support of MD5 to authenticate a TCP session."; 412 } 413 } 415 // TCP configuration 417 container tcp { 418 presence "The container for TCP configuration."; 420 description 421 "TCP container."; 423 container connections { 424 list connection { 425 key "local-address remote-address local-port remote-port"; 427 leaf local-address { 428 type inet:ip-address; 429 description 430 "Local address that forms the connection identifier."; 431 } 432 leaf remote-address { 433 type inet:ip-address; 434 description 435 "Remote address that forms the connection identifier."; 436 } 438 leaf local-port { 439 type inet:port-number; 440 description 441 "Local TCP port that forms the connection identifier."; 442 } 444 leaf remote-port { 445 type inet:port-number; 446 description 447 "Remote TCP port that forms the connection identifier."; 448 } 450 container common { 451 uses tcpcmn:tcp-common-grouping; 453 choice authentication { 454 case ao { 455 uses ao; 456 description 457 "Use TCP-AO to secure the connection."; 458 } 460 case md5 { 461 uses md5; 462 description 463 "Use TCP-MD5 to secure the connection."; 464 } 465 description 466 "Choice of how to secure the TCP connection."; 467 } 468 description 469 "Common definitions of TCP configuration. This includes 470 parameters such as how to secure the connection, 471 that can be part of either the client or server."; 472 } 473 description 474 "Connection related parameters."; 475 } 476 description 477 "A container of all TCP connections."; 478 } 479 container server { 480 if-feature server; 481 uses tcps:tcp-server-grouping; 482 description 483 "Definitions of TCP server configuration."; 484 } 486 container client { 487 if-feature client; 488 uses tcpc:tcp-client-grouping; 489 description 490 "Definitions of TCP client configuration."; 491 } 493 container statistics { 494 if-feature statistics; 495 config false; 497 leaf active-opens { 498 type yang:counter32; 499 description 500 "The number of times that TCP connections have made a direct 501 transition to the SYN-SENT state from the CLOSED state."; 502 } 504 leaf passive-opens { 505 type yang:counter32; 506 description 507 "The number of times TCP connections have made a direct 508 transition to the SYN-RCVD state from the LISTEN state."; 509 } 511 leaf attempt-fails { 512 type yang:counter32; 513 description 514 "The number of times that TCP connections have made a direct 515 transition to the CLOSED state from either the SYN-SENT 516 state or the SYN-RCVD state, plus the number of times that 517 TCP connections have made a direct transition to the 518 LISTEN state from the SYN-RCVD state."; 519 } 521 leaf establish-resets { 522 type yang:counter32; 523 description 524 "The number of times that TCP connections have made a direct 525 transition to the CLOSED state from either the ESTABLISHED 526 state or the CLOSE-WAIT state."; 528 } 530 leaf currently-established { 531 type yang:gauge32; 532 description 533 "The number of TCP connections for which the current state 534 is either ESTABLISHED or CLOSE-WAIT."; 535 } 537 leaf in-segments { 538 type yang:counter64; 539 description 540 "The total number of segments received, including those 541 received in error. This count includes segments received 542 on currently established connections."; 543 } 545 leaf out-segments { 546 type yang:counter64; 547 description 548 "The total number of segments sent, including those on 549 current connections but excluding those containing only 550 retransmitted octets."; 551 } 553 leaf retransmitted-segments { 554 type yang:counter32; 555 description 556 "The total number of segments retransmitted; that is, the 557 number of TCP segments transmitted containing one or more 558 previously transmitted octets."; 559 } 561 leaf in-errors { 562 type yang:counter32; 563 description 564 "The total number of segments received in error (e.g., bad 565 TCP checksums)."; 566 } 568 leaf out-resets { 569 type yang:counter32; 570 description 571 "The number of TCP segments sent containing the RST flag."; 572 } 574 action reset { 575 description 576 "Reset statistics action command."; 577 input { 578 leaf reset-at { 579 type yang:date-and-time; 580 description 581 "Time when the reset action needs to be 582 executed."; 583 } 584 } 585 output { 586 leaf reset-finished-at { 587 type yang:date-and-time; 588 description 589 "Time when the reset action command completed."; 590 } 591 } 592 } 593 description 594 "Statistics across all connections."; 595 } 596 } 597 } 599 601 5. IANA Considerations 603 5.1. The IETF XML Registry 605 This document registers two URIs in the "ns" subregistry of the IETF 606 XML Registry [RFC3688]. Following the format in IETF XML Registry 607 [RFC3688], the following registrations are requested: 609 URI: urn:ietf:params:xml:ns:yang:ietf-tcp 610 Registrant Contact: The TCPM WG of the IETF. 611 XML: N/A, the requested URI is an XML namespace. 613 5.2. The YANG Module Names Registry 615 This document registers a YANG modules in the YANG Module Names 616 registry YANG - A Data Modeling Language [RFC6020]. Following the 617 format in YANG - A Data Modeling Language [RFC6020], the following 618 registrations are requested: 620 name: ietf-tcp 621 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp 622 prefix: tcp 623 reference: RFC XXXX 625 6. Security Considerations 627 The YANG module specified in this document defines a schema for data 628 that is designed to be accessed via network management protocols such 629 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 630 is the secure transport layer, and the mandatory-to-implement secure 631 transport is Secure Shell (SSH) described in Using the NETCONF 632 protocol over SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and 633 the mandatory-to-implement secure transport is TLS [RFC8446]. 635 The Network Configuration Access Control Model (NACM) [RFC8341] 636 provides the means to restrict access for particular NETCONF or 637 RESTCONF users to a preconfigured subset of all available NETCONF or 638 RESTCONF protocol operations and content. 640 There are a number of data nodes defined in this YANG module that are 641 writable/creatable/deletable (i.e., "config true", which is the 642 default). These data nodes may be considered sensitive or vulnerable 643 in some network environments. Write operations (e.g., edit-config) 644 to these data nodes without proper protection can have a negative 645 effect on network operations. These are the subtrees and data nodes 646 and their sensitivity/vulnerability: 648 o Server configuration. Unrestricted access to all the nodes under 649 server configuration, e.g. local-address or keepalive idle-timer, 650 can cause connections to the server to fail or to timeout 651 prematurely. 653 o Client configuration. Similar to server configuration, 654 unrestricted access to the nodes under client configuration can 655 cause connections from the client to fail, or connections to the 656 server to be redirected, and in case of keepalive, cause 657 connections to timeout prematurely etc. 659 Some of the readable data nodes in this YANG module may be considered 660 sensitive or vulnerable in some network environments. It is thus 661 important to control read access (e.g., via get, get-config, or 662 notification) to these data nodes. These are the subtrees and data 663 nodes and their sensitivity/vulnerability: 665 o Unrestricted access to connection information of the client or 666 server can be used by a malicious user to launch an attack, e.g. 667 MITM. 669 o Similarly, unrestricted access to statistics of the client or 670 server can be used by a malicious user to exploit any 671 vulnerabilities of the system. 673 Some of the RPC operations in this YANG module may be considered 674 sensitive or vulnerable in some network environments. It is thus 675 important to control access to these operations. These are the 676 operations and their sensitivity/vulnerability: 678 o The YANG module allows for the statistics to be cleared by 679 executing the reset action. This action should be restricted to 680 users with the right permission. 682 7. References 684 7.1. Normative References 686 [I-D.ietf-netconf-tcp-client-server] 687 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 688 and TCP Servers", draft-ietf-netconf-tcp-client-server-08 689 (work in progress), August 2020. 691 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 692 RFC 793, DOI 10.17487/RFC0793, September 1981, 693 . 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, 697 DOI 10.17487/RFC2119, March 1997, 698 . 700 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 701 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 702 1998, . 704 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 705 DOI 10.17487/RFC3688, January 2004, 706 . 708 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 709 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 710 June 2010, . 712 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 713 the Network Configuration Protocol (NETCONF)", RFC 6020, 714 DOI 10.17487/RFC6020, October 2010, 715 . 717 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 718 and A. Bierman, Ed., "Network Configuration Protocol 719 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 720 . 722 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 723 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 724 . 726 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 727 RFC 7950, DOI 10.17487/RFC7950, August 2016, 728 . 730 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 731 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 732 . 734 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 735 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 736 May 2017, . 738 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 739 Zhang, "YANG Data Model for Key Chains", RFC 8177, 740 DOI 10.17487/RFC8177, June 2017, 741 . 743 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 744 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 745 . 747 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 748 Access Control Model", STD 91, RFC 8341, 749 DOI 10.17487/RFC8341, March 2018, 750 . 752 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 753 and R. Wilton, "Network Management Datastore Architecture 754 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 755 . 757 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 758 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 759 . 761 7.2. Informative References 763 [I-D.ietf-idr-bgp-model] 764 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 765 YANG Model for Service Provider Networks", draft-ietf-idr- 766 bgp-model-09 (work in progress), June 2020. 768 [I-D.ietf-taps-interface] 769 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 770 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 771 Pauly, "An Abstract Application Layer Interface to 772 Transport Services", draft-ietf-taps-interface-10 (work in 773 progress), November 2020. 775 [I-D.touch-tcpm-ao-test-vectors] 776 Touch, J. and J. Kuusisaari, "TCP-AO Test Vectors", draft- 777 touch-tcpm-ao-test-vectors-01 (work in progress), August 778 2020. 780 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 781 the Transmission Control Protocol (TCP)", RFC 4022, 782 DOI 10.17487/RFC4022, March 2005, 783 . 785 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 786 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 787 May 2007, . 789 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 790 Information Version 2 (SMIv2) MIB Modules to YANG 791 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 792 . 794 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 795 Vinapamula, S., and Q. Wu, "A YANG Module for Network 796 Address Translation (NAT) and Network Prefix Translation 797 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 798 . 800 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 801 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 802 DOI 10.17487/RFC8513, January 2019, 803 . 805 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 806 "YANG Data Model for Network Access Control Lists (ACLs)", 807 RFC 8519, DOI 10.17487/RFC8519, March 2019, 808 . 810 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 811 Denial-of-Service Open Threat Signaling (DOTS) Data 812 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 813 May 2020, . 815 Appendix A. Acknowledgements 817 Michael Scharf was supported by the StandICT.eu project, which is 818 funded by the European Commission under the Horizon 2020 Programme. 820 The following persons have contributed to this document by reviews: 821 Mohamed Boucadair 823 Appendix B. Changes compared to previous versions 825 Changes compared to draft-scharf-tcpm-yang-tcp-04 827 o Removed congestion control 829 o Removed global stack parameters 831 Changes compared to draft-scharf-tcpm-yang-tcp-03 833 o Updated TCP-AO grouping 835 o Added congestion control 837 Changes compared to draft-scharf-tcpm-yang-tcp-02 839 o Initial proposal of a YANG model including base configuration 840 parameters, TCP-AO configuration, and a connection list 842 o Editorial bugfixes and outdated references reported by Mohamed 843 Boucadair 845 o Additional co-author Mahesh Jethanandani 847 Changes compared to draft-scharf-tcpm-yang-tcp-01 849 o Alignment with [I-D.ietf-netconf-tcp-client-server] 851 o Removing backward-compatibility to the TCP MIB 853 o Additional co-author Vishal Murgai 855 Changes compared to draft-scharf-tcpm-yang-tcp-00 857 o Editorial improvements 859 Appendix C. Examples 861 C.1. Keepalive Configuration 863 This particular example demonstrates how both a particular connection 864 can be configured for keepalives. 866 [note: '\' line wrapping for formatting only] 868 869 874 875 877 878 879 192.168.1.1 880 192.168.1.2 881 1025 882 80 883 884 885 5 886 5 887 10 888 889 890 891 892 898 899 192.168.1.1 900 901 902 192.168.1.2 903 904 905 907 C.2. TCP-AO Configuration 909 The following example demonstrates how to model a TCP-AO [RFC5925] 910 configuration for the example in TCP-AO Test Vectors 911 [I-D.touch-tcpm-ao-test-vectors], Section 5.1.1. 913 [note: '\' line wrapping for formatting only] 915 916 920 921 923 924 ao-config 925 "An example for TCP-AO configuration." 927 928 61 929 hmac-sha-1-12 930 931 01:23:a5:93:b9:db:70:62:9b:be:2c:a6:77:cd:fd:e\ 932 a:6f:e0:ac:ad 933 934 935 936 937 939 944 945 192.168.1.1 946 947 948 192.168.1.2 949 950 951 952 Appendix D. Complete Tree Diagram 954 Here is the complete tree diagram for the TCP YANG model. 956 module: ietf-tcp 957 +--rw tcp! 958 +--rw connections 959 | +--rw connection* 960 | [local-address remote-address local-port remote-port] 961 | +--rw local-address inet:ip-address 962 | +--rw remote-address inet:ip-address 963 | +--rw local-port inet:port-number 964 | +--rw remote-port inet:port-number 965 | +--rw common 966 | +--rw keepalives! 967 | | +--rw idle-time uint16 968 | | +--rw max-probes uint16 969 | | +--rw probe-interval uint16 970 | +--rw (authentication)? 971 | +--:(ao) 972 | | +--rw enable-ao? boolean 973 | | +--rw send-id? uint8 974 | | +--rw recv-id? uint8 975 | | +--rw include-tcp-options? boolean 976 | | +--rw accept-key-mismatch? boolean 977 | +--:(md5) 978 | +--rw enable-md5? boolean 979 +--rw server {server}? 980 | +--rw local-address inet:ip-address 981 | +--rw local-port? inet:port-number 982 | +--rw keepalives! 983 | +--rw idle-time uint16 984 | +--rw max-probes uint16 985 | +--rw probe-interval uint16 986 +--rw client {client}? 987 | +--rw remote-address inet:host 988 | +--rw remote-port? inet:port-number 989 | +--rw local-address? inet:ip-address 990 | +--rw local-port? inet:port-number 991 | +--rw keepalives! 992 | +--rw idle-time uint16 993 | +--rw max-probes uint16 994 | +--rw probe-interval uint16 995 +--ro statistics {statistics}? 996 +--ro active-opens? yang:counter32 997 +--ro passive-opens? yang:counter32 998 +--ro attempt-fails? yang:counter32 999 +--ro establish-resets? yang:counter32 1000 +--ro currently-established? yang:gauge32 1001 +--ro in-segments? yang:counter64 1002 +--ro out-segments? yang:counter64 1003 +--ro retransmitted-segments? yang:counter32 1004 +--ro in-errors? yang:counter32 1005 +--ro out-resets? yang:counter32 1006 +---x reset 1007 +---w input 1008 | +---w reset-at? yang:date-and-time 1009 +--ro output 1010 +--ro reset-finished-at? yang:date-and-time 1012 Authors' Addresses 1014 Michael Scharf 1015 Hochschule Esslingen - University of Applied Sciences 1016 Flandernstr. 101 1017 Esslingen 73732 1018 Germany 1020 Email: michael.scharf@hs-esslingen.de 1022 Vishal Murgai 1023 Samsung 1025 Email: vmurgai@gmail.com 1027 Mahesh Jethanandani 1028 Kloud Services 1030 Email: mjethanandani@gmail.com