-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-netconf-tcp-client-server.xml
976 lines (901 loc) · 43.9 KB
/
draft-ietf-netconf-tcp-client-server.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
consensus="true"
submissionType="IETF"
docName="draft-ietf-netconf-tcp-client-server-latest"
ipr="trust200902">
<front>
<title abbrev="Groupings for TCP Clients and Servers">YANG Groupings for
TCP Clients and TCP Servers</title>
<author fullname="Kent Watsen" initials="K." surname="Watsen">
<organization>Watsen Networks</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Michael Scharf" initials="M." surname="Scharf">
<organization abbrev="Hochschule Esslingen">
Hochschule Esslingen - University of Applied Sciences
</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<abstract>
<t>This document presents three YANG 1.1 modules
to support the configuration of TCP clients and TCP servers. The modules
include basic parameters of a TCP connection relevant for client or server
applications, as well as client configuration required for traversing proxies.
The modules can be used either standalone or in conjunction with configuration
of other stack protocol layers.</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>This draft contains placeholder values that need to be replaced
with finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.</t>
<t>Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
<list style="symbols">
<t><spanx style="verb">AAAA</spanx> --> the assigned RFC value for draft-ietf-netconf-crypto-types</t>
<t><spanx style="verb">DDDD</spanx> --> the assigned RFC value for this draft</t>
</list>
</t>
<t>Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement:
<list style="symbols">
<t><spanx style="verb">YYYY-MM-DD</spanx> --> the publication date of this draft</t>
</list>
</t>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> contains
the text "one or more YANG modules" and, later, "modules". This text is sourced
from a file in a context where it is unknown how many modules a draft defines.
The text is not wrong as is, but it may be improved by stating more directly how
many modules are defined.</t>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> contains
a self-reference to this draft, along with a corresponding reference in
the Appendix. Please replace the self-reference in this section with "This RFC"
(or similar) and remove the self-reference in the "Normative/Informative References"
section, whichever it is in.</t>
<t>Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792.
However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested
suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded
examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify
what looks ugly and ask the authors to make the adjustment.</t>
<t>The following Appendix section is to be removed prior to publication:
<list style="symbols">
<t><xref target="change-log"/>. Change Log</t>
</list>
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document defines three YANG 1.1 <xref target="RFC7950"/> modules
to support the configuration of TCP clients and TCP servers (TCP is
defined in <xref target="RFC9293"/>), either as standalone or in
conjunction with configuration of other stack protocol layers.</t>
<t>The modules focus on three different types of base TCP parameters that matter
for TCP-based applications: First, the modules cover fundamental configuration of a
TCP client or TCP server application, such as addresses and port numbers. Second, a
reusable grouping enables modification of application-specific parameters for a TCP
connections, such as use of TCP keep-alives. And third, client configuration for
traversing proxies is included as well. In each case, the modules have a very narrow
scope and focus on a minimum set of required parameters.</t>
<t>Please be advised that while this document presents support for some TCP
proxy techniques, there are other TCP proxy techniques that are not part
of this document, but could be added by augmenting the YANG module.</t>
INSERT_TEXT_FROM_FILE(../common-intro-snippet.xml,150)
<section title="Adherence to the NMDA">
<t>This document is compliant with the Network Management Datastore
Architecture (NMDA) <xref target="RFC8342"/>. It does not define
any protocol accessible nodes that are "config false".</t>
</section>
</section>
<section anchor="tcp-common-model" title="The "ietf-tcp-common" Module">
<t>This section defines a YANG 1.1 module called
"ietf-tcp-common". A high-level overview of the module is provided in
<xref target="common-overview"/>. Examples illustrating the module's use
are provided in <xref target="common-examples">Examples</xref>. The YANG
module itself is defined in <xref target="common-yang-module"/>.</t>
<section title="Data Model Overview" anchor="common-overview">
<t>This section provides an overview of the "ietf-tcp-common" module
in terms of its features and groupings.</t>
<section title="Model Scope" toc="exclude">
<t>This document presents a common "grouping" statement for basic TCP connection
parameters that matter to applications. It is "common" in that this grouping
is used by both the "ietf-tcp-client" and "ietf-tcp-server" modules. In some
TCP stacks, such parameters can also directly be set by an application using
system calls, such as the sockets API. The base YANG model in this document
focuses on modeling TCP keep-alives. This base model can be extended as needed.</t>
</section>
<section title="Features" anchor="common-features" toc="exclude">
<t>The following diagram lists all the "feature" statements
defined in the "ietf-tcp-common" module:</t>
<t>
<figure>
<artwork><![CDATA[
Features:
+-- keepalives-supported
]]></artwork>
</figure>
</t>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t>
<!--</aside>-->
</section>
<section title="Groupings" toc="exclude">
<t>The "ietf-tcp-common" module defines the following "grouping" statement:</t>
<ul spacing="compact">
<li>tcp-common-grouping</li>
</ul>
<t>This grouping is presented in the following subsection.</t>
<section title="The "tcp-common-grouping" Grouping" anchor="tcp-common-grouping">
<t>The following tree diagram <xref target="RFC8340"/> illustrates the
"tcp-common-grouping" grouping:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-tcp-common-grouping.no-expand.txt)
]]></artwork>
</figure>
</t>
<t>Comments:</t>
<ul>
<li>The "keepalives" node is a "presence" container so that the mandatory descendant nodes
do not imply that keepalives must be configured.</li>
<li>The "idle-time", "max-probes", and "probe-interval" nodes have the
common meanings. Please see the YANG module in <xref target="common-yang-module"/>
for details.</li>
</ul>
</section>
</section>
<section title="Protocol-accessible Nodes" toc="exclude">
<t>The "ietf-tcp-common" module defines only "grouping" statements that are used by
other modules to instantiate protocol-accessible nodes. Thus this module, when
implemented, does not itself define any protocol-accessible nodes.</t>
</section>
<section title="Guidelines for Configuring TCP Keep-Alives" toc="exclude">
<t>Network stacks may include "keep-alives" in their TCP implementations,
although this practice is not universally implemented. If keep-alives are
included, <xref target="RFC9293"/> mandates that the application MUST be
able to turn them on or off for each TCP connection, and that they MUST
default to off.</t>
<t>Keep-alive mechanisms exist in many protocols. Depending on the protocol
stack, TCP keep-alives may only be one out of several alternatives. Which
mechanism(s) to use depends on the use case and application requirements. If
keep-alives are needed by an application, it is RECOMMENDED that the
liveness check happens only at the protocol layers that are meaningful
to the application.</t>
<t>A TCP keep-alive mechanism SHOULD only be invoked in server applications
that might otherwise hang indefinitely and consume resources unnecessarily
if a client crashes or aborts a connection during a network failure <xref target="RFC9293"/>.
TCP keep-alives may consume significant resources both in the network and
in endpoints (e.g., battery power). In addition, frequent keep-alives
risk network congestion. The higher the frequency of keep-alives, the
higher the overhead.</t>
<t>
Given the cost of keep-alives, parameters have to be configured carefully:
<list style="symbols">
<t>The default idle interval (leaf "idle-time") is two hours, i.e.,
7200 seconds <xref target="RFC9293"/>. A lower value MAY be
configured, but idle intervals SHOULD NOT be smaller than 15
seconds. Longer idle intervals SHOULD be used when possible.</t>
<t>The maximum number of sequential keep-alive probes that can fail
(leaf "max-probes") trades off responsiveness and robustness against
packet loss. ACK segments that contain no data are not reliably
transmitted by TCP. Consequently, if a keep-alive mechanism is
implemented it MUST NOT interpret failure to respond to any
specific probe as a dead connection <xref target="RFC9293"/>.
Typically, a single-digit number should suffice.</t>
<t>TCP implementations may include a parameter for the number of
seconds between TCP keep-alive probes (leaf "probe-interval"). In
order to avoid congestion, the time interval between probes MUST NOT
be smaller than one second. Significantly longer intervals SHOULD be
used. It is important to note that keep-alive probes (or replies)
can get dropped due to network congestion. Sending further probe
messages into a congested path after a short interval, without
backing off timers, could cause harm and result in a congestion
collapse. Therefore it is essential to pick a large, conservative
value for this interval.</t>
</list>
</t>
</section>
</section>
<section title="Example Usage" anchor="common-examples">
<t>This section presents an example showing the "tcp-common-grouping"
populated with some data.</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-tcp-common.xml)
]]></artwork>
</figure></t>
</section>
<section anchor="common-yang-module" title="YANG Module">
<t>The ietf-tcp-common YANG module references <xref target="RFC6991"/>
and <xref target="RFC9293"/>.</t>
<t><figure>
<preamble><CODE BEGINS> file "[email protected]"</preamble>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE([email protected])
]]></artwork>
<postamble><CODE ENDS></postamble>
</figure></t>
</section>
</section>
<section anchor="tcp-client-model" title="The "ietf-tcp-client" Module">
<t>This section defines a YANG 1.1 module called
"ietf-tcp-client". A high-level overview of the module is provided in
<xref target="client-overview"/>. Examples illustrating the module's use
are provided in <xref target="client-examples">Examples</xref>. The YANG
module itself is defined in <xref target="client-yang-module"/>.</t>
<section title="Data Model Overview" anchor="client-overview">
<t>This section provides an overview of the "ietf-tcp-client" module
in terms of its features and groupings.</t>
<section title="Features" anchor="features" toc="exclude">
<t>The following diagram lists all the "feature" statements
defined in the "ietf-tcp-client" module:</t>
<t>
<figure>
<artwork><![CDATA[
Features:
+-- local-binding-supported
+-- tcp-client-keepalives
+-- proxy-connect
+-- socks4-supported {proxy-connect}?
+-- socks4a-supported {proxy-connect}?
+-- socks5-supported {proxy-connect}?
+-- socks5-gss-api {socks5-supported}?
+-- socks5-username-password {socks5-supported}?
]]></artwork>
</figure>
<t>Comments:</t>
<ul>
<li>The "local-binding-supported" feature indicates that
the server supports configuring local bindings (i.e.,
the local address and local port) for TCP clients."</li>
<li>The "tcp-client-keepalives" feature indicates that
per socket TCP keepalive parameters are configurable for
TCP clients on the server implementing this feature.</li>
<li>The "proxy-connect" feature indicates the TCP-client
supports connecting through TCP proxies.</li>
<li>The "socks4-supported" feature indicates the
TCP-client supports Socks4-based proxies.</li>
<li>The "socks4a-supported" feature indicates the
TCP-client supports Socks4a-based proxies. The difference
between Socks4 and Socks4a is that Socks4a enables the
"remote-address" to be specified using a hostname, in
addition to an IP address.</li>
<li>The "socks5-supported" feature indicates the
TCP-client supports Socks5-based proxies.</li>
<li>The "socks5-gss-api" feature indicates that
the server, when acting as a TCP-client, supports
authenticating to a SOCKS Version 5 proxy server
using GSSAPI credentials.</li>
<li>The "socks5-username-password" feature indicates
that the server, when acting as a TCP-client,
supports authenticating to a SOCKS Version 5
proxy server using 'username' and 'password'
credentials."</li>
</ul>
</t>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t>
<!--</aside>-->
</section>
<section title="Groupings" toc="exclude">
<t>The "ietf-tcp-client" module defines the following "grouping" statement:</t>
<ul spacing="compact">
<li>tcp-client-grouping</li>
</ul>
<t>This grouping is presented in the following subsection.</t>
<section title="The "tcp-client-grouping" Grouping" anchor="tcp-client-grouping">
<t>The following tree diagram <xref target="RFC8340"/> illustrates the
"tcp-client-grouping" grouping:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-tcp-client-grouping.no-expand.txt)
]]></artwork>
</figure>
</t>
<t>Comments:</t>
<ul>
<li>The "remote-address" node, which is mandatory, may be configured as
an IPv4 address, an IPv6 address, or a hostname.</li>
<li>The "remote-port" leaf is defined with neither a "default" nor
a "mandatory" statement. YANG models using this grouping SHOULD
refine the grouping with a "default" statement, usually with the
port allocated by IANA, or a "mandatory" statement, if the ports
needs to be always present.</li>
<li>The "local-address" node, which is enabled by the "local-binding-supported"
feature (<xref target="common-features"/>), may be configured as
an IPv4 address, an IPv6 address, or a wildcard value.</li>
<li>The "local-port" node, which is enabled by the "local-binding-supported"
feature (<xref target="common-features"/>), is not mandatory. Its default
value is '0', indicating that the operating system can pick an
arbitrary port number.</li>
<li>The "proxy-server" node is enabled by a "feature" statement and, for
servers that enable it, is a "presence" container so that the descendant
"mandatory true" choice node does not imply that the proxy-server node
must be configured. The proxy-server node uses a "choice" statement
to allow one of several types of proxies to be configured. The choices
presented in this document include Socks4, Socks4a, and Socks5, each
enabled by a YANG feature (see <xref target="features"/>). Other proxy
types may be added by future work.</li>
<li>This grouping uses the "password-grouping" grouping discussed in
<xref target="I-D.ietf-netconf-crypto-types"/>.</li>
<li>This grouping uses the "tcp-common-grouping" grouping discussed in
<xref target="tcp-common-grouping"/>.</li>
</ul>
</section>
</section>
<section title="Protocol-accessible Nodes" toc="exclude">
<t>The "ietf-tcp-client" module defines only "grouping" statements that are used by
other modules to instantiate protocol-accessible nodes. Thus this module, when
implemented, does not itself define any protocol-accessible nodes.</t>
</section>
</section>
<section title="Example Usage" anchor="client-examples">
<t>This section presents two examples showing the "tcp-client-grouping"
populated with some data. This example shows a TCP-client configured to
not connect via a proxy:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-tcp-client.xml)
]]></artwork>
</figure>
</t>
<t>This example shows a TCP-client configured to connect via a proxy:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-tcp-client-proxy.xml)
]]></artwork>
</figure>
</t>
</section>
<section anchor="client-yang-module" title="YANG Module">
<t>The ietf-tcp-client YANG module references <xref target="SOCKS 4A"/>, <xref target="RFC1928"/>,
<xref target="RFC1929"/>, <xref target="RFC2743"/>, <xref target="RFC6991"/>,
<xref target="RFC9293"/>, and <xref target="I-D.ietf-netconf-crypto-types"/>.</t>
<t><figure>
<preamble><CODE BEGINS> file "[email protected]"</preamble>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE([email protected])
]]></artwork>
<postamble><CODE ENDS></postamble>
</figure></t>
</section>
</section>
<section anchor="tcp-server-model" title="The "ietf-tcp-server" Module">
<t>This section defines a YANG 1.1 module called
"ietf-tcp-server". A high-level overview of the module is provided in
<xref target="server-overview"/>. Examples illustrating the module's use
are provided in <xref target="server-examples">Examples</xref>. The YANG
module itself is defined in <xref target="server-yang-module"/>.</t>
<section title="Data Model Overview" anchor="server-overview">
<t>This section provides an overview of the "ietf-tcp-server" module
in terms of its features and groupings.</t>
<section title="Features" toc="exclude">
<t>The following diagram lists all the "feature" statements
defined in the "ietf-tcp-server" module:</t>
<t>
<figure>
<artwork><![CDATA[
Features:
+-- tcp-server-keepalives
]]></artwork>
</figure>
</t>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t>
<!--</aside>-->
</section>
<section title="Groupings" toc="exclude">
<t>The "ietf-tcp-server" module defines the following "grouping" statement:</t>
<ul spacing="compact">
<li>tcp-server-grouping</li>
</ul>
<t>This grouping is presented in the following subsection.</t>
<section title="The "tcp-server-grouping" Grouping" anchor="tcp-server-grouping">
<t>The following tree diagram <xref target="RFC8340"/> illustrates the
"tcp-server-grouping" grouping:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-tcp-server-grouping.no-expand.txt)
]]></artwork>
</figure>
</t>
<t>Comments:</t>
<ul>
<li>The "local-address" node, which is mandatory, may be configured as
an IPv4 address, an IPv6 address, or a wildcard value.</li>
<li>The "local-port" leaf is defined with neither a "default" nor a
"mandatory" statement. YANG models using this grouping SHOULD
refine the grouping with a "default" statement, usually with
the port allocated by IANA, or a "mandatory" statement, if the
port needs to be always present.</li>
<li>This grouping uses the "tcp-common-grouping" grouping discussed in
<xref target="tcp-common-grouping"/>.</li>
</ul>
</section>
</section>
<section title="Protocol-accessible Nodes" toc="exclude">
<t>The "ietf-tcp-server" module defines only "grouping" statements that are used by
other modules to instantiate protocol-accessible nodes. Thus this module, when
implemented, does not itself define any protocol-accessible nodes.</t>
</section>
</section>
<section title="Example Usage" anchor="server-examples">
<t>This section presents an example showing the "tcp-server-grouping"
populated with some data.</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-tcp-server.xml)
]]></artwork>
</figure></t>
</section>
<section anchor="server-yang-module" title="YANG Module">
<t>The ietf-tcp-server YANG module references <xref target="RFC6991"/>
and <xref target="RFC9293"/>.</t>
<t>
<figure>
<preamble><CODE BEGINS> file "[email protected]"</preamble>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE([email protected])
]]></artwork>
<postamble><CODE ENDS></postamble>
</figure></t>
</section>
</section>
<section title="Security Considerations">
<t>The three YANG modules in this document define groupings and will
not be deployed as standalone modules. Their security implications
may be context dependent based on their use in other modules. The
designers of modules which import these grouping must conduct their
own analysis of the security considerations.</t>
<section title='Considerations for the "ietf-tcp-common" YANG Module'>
<t>This section follows the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>
<t>The "ietf-tcp-common" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS)
with mutual authentication.</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/>
provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and
content.</t>
<t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules
for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t>
<t>None of the readable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments.
The NACM "default-deny-all" extension has not been set for
any data nodes defined in this module.</t>
<t>None of the writable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments.
The NACM "default-deny-write" extension has not been set for
any data nodes defined in this module.</t>
<t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t>
</section>
<section title='Considerations for the "ietf-tcp-client" YANG Module'>
<t>This section follows the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>
<t>The "ietf-tcp-client" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS)
with mutual authentication.</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/>
provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and
content.</t>
<t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules
for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t>
<t>One readable data node defined in this YANG module may be considered
sensitive or vulnerable in some network environments. This
node is as follows:
<list style="symbols">
<t>The "proxy-server/socks5-parameters/authentication-parameters/username-password/password" node:
<ul empty="true">
<li>The "password" node defined in the "tcp-client-grouping"
grouping is defined using the "password-grouping" grouping
presented in <xref target="I-D.ietf-netconf-crypto-types"/>.
This grouping enables both cleartext and encrypted passwords
to be configured. As the referenced document states, configuration
of cleartext passwords is NOT RECOMMENDED. However, in the
case cleartext values are configured, this node is additionally
sensitive to read operations such that, in normal use cases,
it should never be returned to a client. For this reason, the
NACM extension "default-deny-all" has been applied to it.</li>
</ul>
</t>
</list>
</t>
<t>None of the writable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments.
The NACM "default-deny-write" extension has not been set for
any data nodes defined in this module.</t>
<t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t>
<t>Implementations are RECOMMENDED to implement the "local-binding-supported"
feature for cryptographically-secure protocols, so as to enable more
granular ingress/egress firewall rulebases. It is NOT RECOMMENDED to
implement this feature for unsecure protocols, as per <xref target="RFC6056"/>.</t>
</section>
<section title='Considerations for the "ietf-tcp-server" YANG Module'>
<t>This section follows the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>
<t>The "ietf-tcp-server" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS)
with mutual authentication.</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/>
provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and
content.</t>
<t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules
for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t>
<t>None of the readable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments.
The NACM "default-deny-all" extension has not been set for
any data nodes defined in this module.</t>
<t>None of the writable data nodes defined in this YANG module are
considered sensitive or vulnerable in network environments.
The NACM "default-deny-write" extension has not been set for
any data nodes defined in this module.</t>
<t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t>
</section>
</section>
<section title="IANA Considerations">
<section title='The "IETF XML" Registry'>
<t>This document registers three URIs in the "ns" subregistry of the
IETF XML Registry <xref target="RFC3688"/>. Following the format in
<xref target="RFC3688"/>, the following registrations are
requested:</t>
<t><figure>
<artwork>
URI: urn:ietf:params:xml:ns:yang:ietf-tcp-common
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace.
</artwork>
</figure></t>
</section>
<section title='The "YANG Module Names" Registry'>
<t>This document registers three YANG modules in the YANG Module Names
registry <xref target="RFC6020"/>. Following the format in <xref
target="RFC6020"/>, the following registrations are requested:</t>
<t><figure>
<artwork>
name: ietf-tcp-common
namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common
prefix: tcpcmn
reference: RFC DDDD
name: ietf-tcp-client
namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client
prefix: tcpc
reference: RFC DDDD
name: ietf-tcp-server
namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server
prefix: tcps
reference: RFC DDDD
</artwork>
</figure></t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.6020.xml"?>
<?rfc include="reference.RFC.6991.xml"?>
<?rfc include="reference.RFC.7950.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.8341.xml"?>
<?rfc include="reference.RFC.9293.xml"?>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-crypto-types.xml"/>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1928.xml"?>
<?rfc include="reference.RFC.1929.xml"?>
<?rfc include="reference.RFC.2743.xml"?>
<?rfc include="reference.RFC.3688.xml"?>
<?rfc include="reference.RFC.6056.xml"?>
<?rfc include="reference.RFC.6241.xml"?>
<?rfc include="reference.RFC.8040.xml"?>
<?rfc include="reference.RFC.8340.xml"?>
<?rfc include="reference.RFC.8342.xml"?>
<?rfc include="reference.RFC.8407.xml"?>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-trust-anchors.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-keystore.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-tcp-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-ssh-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-tls-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-http-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-netconf-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-restconf-client-server.xml"/>
<reference anchor="SOCKS 4A" target="https://www.openssh.com/txt/socks4a.protocol">
<front>
<title>SOCKS 4A: A Simple Extension to SOCKS 4 Protocol</title>
<author fullname="The OpenSSH Project"/>
</front>
</reference>
</references>
<section title="Change Log" anchor="change-log">
<section title="00 to 01">
<t>
<list style="symbols">
<t>Added 'local-binding-supported' feature to TCP-client model.</t>
<t>Added 'keepalives-supported' feature to TCP-common model.</t>
<t>Added 'external-endpoint-values' container and 'external-endpoints' feature to TCP-server model.</t>
</list>
</t>
</section>
<section title="01 to 02">
<t>
<list style="symbols">
<t>Removed the 'external-endpoint-values' container and 'external-endpoints' feature from the TCP-server model.</t>
</list>
</t>
</section>
<section title="02 to 03">
<t>
<list style="symbols">
<t>Moved the common model section to be before the client and server specific sections.</t>
<t>Added sections "Model Scope" and "Usage Guidelines for Configuring TCP Keep-Alives" to
the common model section.</t>
</list>
</t>
</section>
<section title="03 to 04">
<t>
<list style="symbols">
<t>Fixed a few typos.</t>
</list>
</t>
</section>
<section title="04 to 05">
<t>
<list style="symbols">
<t>Removed commented out "grouping tcp-system-grouping" statement kept for reviewers.</t>
<t>Added a "Note to Reviewers" note to first page.</t>
</list>
</t>
</section>
<section title="05 to 06">
<t>
<list style="symbols">
<t>Added support for TCP proxies.</t>
</list>
</t>
</section>
<section title="06 to 07">
<t>
<list style="symbols">
<t>Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams].</t>
<t>Updated the Security Considerations section.</t>
</list>
</t>
</section>
<section title="07 to 08">
<t>
<list style="symbols">
<t>Added missing IANA registration for "ietf-tcp-common"</t>
<t>Added "mandatory true" for the "username" and "password" leafs</t>
<t>Added an example of a TCP-client configured to connect via a proxy</t>
<t>Fixed issues found by the SecDir review of the "keystore" draft.</t>
<t>Updated the "ietf-tcp-client" module to use the new "password-grouping"
grouping from the "crypto-types" module.</t>
</list>
</t>
</section>
<section title="08 to 09">
<t>
<list style="symbols">
<t>Addressed comments raised by YANG Doctor in the ct/ts/ks drafts.</t>
</list>
</t>
</section>
<section title="09 to 10">
<t>
<list style="symbols">
<t>Updated Abstract and Intro to address comments by Tom Petch.</t>
<t>Removed the "tcp-connection-grouping" grouping (now models use the "tcp-common-grouping" directly).</t>
<t>Added XML-comment above examples explaining the reason for the unusual top-most element's presence.</t>
<t>Added Securty Considerations section for the "local-binding-supported" feature.</t>
<t>Replaced some hardcoded refs to <xref> elements.</t>
<t>Fixed nits found by YANG Doctor reviews.</t>
<t>Aligned modules with `pyang -f` formatting.</t>
<t>Added an "Acknowledgements" secetion.</t>
</list>
</t>
</section>
<section title="10 to 11">
<t>
<list style="symbols">
<t>Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.</t>
<t>Minor editorial nits</t>
</list>
</t>
</section>
<section title="11 to 12">
<t>
<list style="symbols">
<t>Fixed up the 'WG Web' and 'WG List' lines in YANG module(s)</t>
<t>Fixed up copyright (i.e., s/Simplified/Revised/) in YANG module(s)</t>
</list>
</t>
</section>
<section title="12 to 13">
<t>
<list style="symbols">
<t>NO UPDATE.</t>
</list>
</t>
</section>
<section title="13 to 14">
<t>
<list style="symbols">
<t>Updated per Shepherd reviews impacting the suite of drafts.</t>
</list>
</t>
</section>
<section title="14 to 15">
<t>
<list style="symbols">
<t>Updated per Shepherd reviews impacting the suite of drafts.</t>
</list>
</t>
</section>
<section title="15 to 16">
<t>
<list style="symbols">
<t>Updated per Tom Petch review.</t>
<t>Added refs to RFC9293 and SOCKS 4A.</t>
<t>Fixed examples to use IETF-sanctioned values for examples.</t>
</list>
</t>
</section>
<section title="16 to 17">
<t>
<list style="symbols">
<t>Addresses AD review comments.</t>
<t>Added note to Editor to fix line foldings.</t>
<t>Added Security Considerations text to also look a SC-section from imported modules.</t>
<t>Fixed bug: s/augment "keepalives"/refine "keepalives"/</t>
<t>Set defaults for idle-time, max-probes, and probe-interval (removed "mandatory true").</t>
<t>Updated examples to use IETF recommended values for examples.</t>
</list>
</t>
</section>
<section title="18 to 19">
<t>
<list style="symbols">
<t>Addresses AD review by Rob Wilton.</t>
</list>
</t>
</section>
<section title="18 to 19">
<t>
<list style="symbols">
<t>Replace RFC 1122 with RFC 9293.</t>
</list>
</t>
</section>
<section title="19 to 20">
<t>
<list style="symbols">
<t>Addresses 1st-round of IESG reviews.</t>
</list>
</t>
</section>
<section title="20 to 22">
<t>
<list style="symbols">
<t>Addresses issues found in OpsDir review of the ssh-client-server draft.</t>
<t>Updated to address Mallory Knodel's Gen-ART review.</t>
<t>Renamed Security Considerations section s/Template for/Considerations for/</t>
<t>s/defines/presents/ in a few places.</t>
<t>Add refs to where the 'operational' and 'system' datastores are defined.</t>
<t>Added more 'feature' statements and descriptions for them</t>
<t>Added Security Considaration for the "password" node</t>
</list>
</t>
</section>
<section title="22 to 23">
<t>
<list style="symbols">
<t>Address IESG review comments.</t>
</list>
</t>
</section>
<section title="23 to 24">
<t>
<list style="symbols">
<t>Nothing changed. Bumped only for automation.</t>
</list>
</t>
</section>
<section title="24 to 25">
<t>
<list style="symbols">
<t>Updated to support dual-stacks</t>
</list>
</t>
</section>
<section title="25 to 26">
<t>
<list style="symbols">
<t>Updated to ensure at least one local-bind is specified.</t>
</list>
</t>
</section>
</section>
<section title="Acknowledgements" numbered="no">
<t>The authors would like to thank the following for lively discussions
on list and in the halls (ordered by first name):
Éric Vyncke,
Joe Clarke,
Jürgen Schönwälder,
Ladislav Lhotka,
Mallory Knodel,
Martin Duke,
Michael Tüxen,
Mohamed Boucadair,
Nancy Cam-Winget,
Nick Hancock,
Per Andersson,
Rob Wilton,
Roman Danyliw,
Tom Petch,
Wim Henderickx.
</t>
</section>
</back>
</rfc>