idnits 2.17.00 (12 Aug 2021) /tmp/idnits61004/draft-ietf-netconf-udp-notif-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 are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 650 has weird spacing: '...address inet...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Note that receivers MAY NOT be already up and running when the configuration of the subscription takes effect on the monitored device. The first message MUST be a separate subscription-started notification to indicate the Receiver that the stream has started flowing. Then, the notifications can be sent immediately without delay. All the subscription state notifications, as defined in [RFC8639], MUST be encapsulated in separate notification messages. -- The document date (3 March 2022) is 72 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: draft-ietf-tls-dtls13 has been published as RFC 9147 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-18 == Outdated reference: A later version (-03) exists of draft-ietf-netconf-distributed-notif-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF G. Zheng 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: 4 September 2022 T. Graf 6 Swisscom 7 P. Francois 8 A. Huang Feng 9 INSA-Lyon 10 P. Lucente 11 NTT 12 3 March 2022 14 UDP-based Transport for Configured Subscriptions 15 draft-ietf-netconf-udp-notif-05 17 Abstract 19 This document describes an UDP-based notification mechanism to 20 collect data from networking devices. A shim header is proposed to 21 facilitate the data streaming directly from the publishing process on 22 network processor of line cards to receivers. The objective is to 23 provide a lightweight approach to enable higher frequency and less 24 performance impact on publisher and receiver processes compared to 25 already established notification mechanisms. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 4 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Configured Subscription to UDP-Notif . . . . . . . . . . . . 4 68 3. UDP-Based Transport . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Format of the UDP-Notif Message Header . . . . . . . . . 5 71 3.3. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 7 72 4. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Segmentation Option . . . . . . . . . . . . . . . . . . . 8 74 4.2. Private Encoding Option . . . . . . . . . . . . . . . . . 9 75 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.1. Congestion Control . . . . . . . . . . . . . . . . . . . 10 77 5.2. Message Size . . . . . . . . . . . . . . . . . . . . . . 10 78 5.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.4. Security Considerations . . . . . . . . . . . . . . . . . 11 80 6. Secured layer for UDP-notif . . . . . . . . . . . . . . . . . 11 81 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 13 83 6.3. Session lifecycle . . . . . . . . . . . . . . . . . . . . 13 84 6.3.1. DTLS Session Initiation . . . . . . . . . . . . . . . 13 85 6.3.2. Publish Data . . . . . . . . . . . . . . . . . . . . 13 86 6.3.3. Session termination . . . . . . . . . . . . . . . . . 14 87 7. A YANG Data Model for Management of UDP-Notif . . . . . . . . 14 88 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 93 11.2. Informative References . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 Sub-Notif [RFC8639] defines a mechanism that lets a receiver 99 subscribe to the publication of YANG-defined data maintained in a 100 YANG [RFC7950] datastore. The mechanism separates the management and 101 control of subscriptions from the transport used to deliver the data. 102 Three transport mechanisms, namely NETCONF transport [RFC8640], 103 RESTCONF transport [RFC8650], and HTTPS transport 104 [I-D.ietf-netconf-https-notif] have been defined so far for such 105 notification messages. 107 While powerful in their features and general in their architecture, 108 the currently available transport mechanisms need to be complemented 109 to support data publications at high velocity from devices that 110 feature a distributed architecture. The currently available 111 transports are based on TCP and lack the efficiency needed to 112 continuously send notifications at high velocity. 114 This document specifies a transport option for Sub-Notif that 115 leverages UDP. Specifically, it facilitates the distributed data 116 collection mechanism described in 117 [I-D.ietf-netconf-distributed-notif]. In the case of publishing from 118 multiple network processors on multiple line cards, centralized 119 designs require data to be internally forwarded from those network 120 processors to the push server, presumably on a route processor, which 121 then combines the individual data items into a single consolidated 122 stream. The centralized data collection mechanism can result in a 123 performance bottleneck, especially when large amounts of data are 124 involved. 126 What is needed is a mechanism that allows for directly publishing 127 from multiple network processors on line cards, without passing them 128 through an additional processing stage for internal consolidation. 129 The proposed UDP-based transport allows for such a distributed data 130 publishing approach. 132 * Firstly, a UDP approach reduces the burden of maintaining a large 133 amount of active TCP connections at the receiver, notably in cases 134 where it collects data from network processors on line cards from 135 a large amount of networking devices. 137 * Secondly, as no connection state needs to be maintained, UDP 138 encapsulation can be easily implemented by the hardware of the 139 publication streamer, which will further improve performance. 141 * Ultimately, such advantages allow for a larger data analysis 142 feature set, as more voluminous, finer grained data sets can be 143 streamed to the receiver. 145 The transport described in this document can be used for transmitting 146 notification messages over both IPv4 and IPv6. 148 This document describes the notification mechanism. It is intended 149 to be used in conjunction with [RFC8639], extended by 150 [I-D.ietf-netconf-distributed-notif]. 152 Section 2 describes the control of the proposed transport mechanism. 153 Section 3 details the notification mechanism and message format. 154 Section 4 describes the use of options in the notification message 155 header. Section 5 covers the applicability of the proposed 156 mechanism. Section 6 describes a mechanism to secure the protocol in 157 open networks. 159 2. Configured Subscription to UDP-Notif 161 This section describes how the proposed mechanism can be controlled 162 using subscription channels based on NETCONF or RESTCONF. 164 Following the usual approach of Sub-Notif, configured subscriptions 165 contain the location information of all the receivers, including the 166 IP address and the port number, so that the publisher can actively 167 send UDP-Notif messages to the corresponding receivers. 169 Note that receivers MAY NOT be already up and running when the 170 configuration of the subscription takes effect on the monitored 171 device. The first message MUST be a separate subscription-started 172 notification to indicate the Receiver that the stream has started 173 flowing. Then, the notifications can be sent immediately without 174 delay. All the subscription state notifications, as defined in 175 [RFC8639], MUST be encapsulated in separate notification messages. 177 3. UDP-Based Transport 179 In this section, we specify the UDP-Notif Transport behavior. 180 Section 3.1 describes the general design of the solution. 181 Section 3.2 specifies the UDP-Notif message format. Section 4 182 describes a generic optional sub TLV format. Section 4.1 uses such 183 options to provide a segmentation solution for large UDP-Notif 184 message payloads. Section 3.3 describes the encoding of the message 185 payload. 187 3.1. Design Overview 189 As specified in Sub-Notif, the telemetry data is encapsulated in the 190 NETCONF/RESTCONF notification message, which is then encapsulated and 191 carried using transport protocols such as TLS or HTTP2. This 192 document defines a UDP based transport. Figure 1 illustrates the 193 structure of an UDP-Notif message. 195 * The Message Header contains information that facilitate the 196 message transmission before deserializing the notification 197 message. 199 * Notification Message is the encoded content that the publication 200 stream transports. The common encoding methods are listed in 201 Section 3.2. [I-D.ietf-netconf-notification-messages] describes 202 the structure of the Notification Message for single notifications 203 and bundled notifications. 205 +-------+ +--------------+ +--------------+ 206 | UDP | | Message | | Notification | 207 | | | Header | | Message | 208 +-------+ +--------------+ +--------------+ 210 Figure 1: UDP-Notif Message Overview 212 3.2. Format of the UDP-Notif Message Header 214 The UDP-Notif Message Header contains information that facilitate the 215 message transmission before deserializing the notification message. 216 The data format is shown in Figure 2. 218 0 1 2 3 219 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 220 +-----+-+-------+---------------+-------------------------------+ 221 | Ver |S| MT | Header Len | Message Length | 222 +-----+-+-------+---------------+-------------------------------+ 223 | Observation-Domain-ID | 224 +---------------------------------------------------------------+ 225 | Message-ID | 226 +---------------------------------------------------------------+ 227 ~ Options ~ 228 +---------------------------------------------------------------+ 230 Figure 2: UDP-Notif Message Header Format 232 The Message Header contains the following field: 234 * Ver represents the PDU (Protocol Data Unit) encoding version. The 235 initial version value is 0. 237 * S represents the space of media type specified in the MT field. 238 When S is unset, MT represents the standard media types as defined 239 in this document. When S is set, MT represents a private space to 240 be freely used for non standard encodings. 242 * MT is a 4 bit identifier to indicate the media type used for the 243 Notification Message. 16 types of encoding can be expressed. When 244 the S bit is unset, the following values apply: 246 - 0: Reserved; 248 - 1: application/yang-data+json [RFC8040] 250 - 2: application/yang-data+xml [RFC8040] 252 - 3: application/yang-data+cbor [I-D.ietf-core-yang-cbor] 254 * Header Len is the length of the message header in octets, 255 including both the fixed header and the options. 257 * Message Length is the total length of the message within one UDP 258 datagram, measured in octets, including the message header. 260 * Observation-Domain-ID is a 32-bit identifier of the Observation 261 Domain that led to the production of the notification message, as 262 defined in [I-D.ietf-netconf-notification-messages]. This allows 263 disambiguation of an information source, such as the 264 identification of different line cards sending the notification 265 messages. The source IP address of the UDP datagrams SHOULD NOT 266 be interpreted as the identifier for the host that originated the 267 UDP-Notif message. Indeed, the streamer sending the UDP-Notif 268 message could be a relay for the actual source of data carried 269 within UDP-Notif messages. 271 * The Message ID is generated continuously by the publisher of UDP- 272 Notif messages. Different subscribers share the same Message ID 273 sequence. 275 * Options is a variable-length field in the TLV format. When the 276 Header Length is larger than 12 octets, which is the length of the 277 fixed header, Options TLVs follow directly after the fixed message 278 header (i.e., Message ID). The details of the options are 279 described in Section 4. 281 3.3. Data Encoding 283 UDP-Notif message data can be encoded in CBOR, XML or JSON format. 284 It is conceivable that additional encodings may be supported in the 285 future. This can be accomplished by augmenting the subscription data 286 model with additional identity statements used to refer to requested 287 encodings. 289 Private encodings can be supported through the use of the S bit of 290 the header. When the S bit is set, the value of the MT field is left 291 to be defined and agreed upon by the users of the private encoding. 292 An option is defined in Section 4.2 for more verbose encoding 293 descriptions than what can be described with the MT field. 295 Implementation MAY support multiple encoding methods per 296 subscription. When bundled notifications are supported between the 297 publisher and the receiver, only subscribed notifications with the 298 same encoding can be bundled in a given message. 300 4. Options 302 All the options are defined with the following format, illustrated in 303 Figure 3. 305 0 1 2 3 306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 307 +---------------+---------------+-------------------------------- 308 | Type | Length | Variable-length data 309 +---------------+---------------+-------------------------------- 311 Figure 3: Generic Option Format 313 * Type: 1 octet describing the option type; 315 * Length: 1 octet representing the total number of octets in the 316 TLV, including the Type and Length fields; 318 * Variable-length data: 0 or more octets of TLV Value. 320 When more than one option are used in the UDP-notif header, options 321 MUST be ordered by the Type value. 323 4.1. Segmentation Option 325 The UDP payload length is limited to 65535. Application level 326 headers will make the actual payload shorter. Even though binary 327 encodings such as CBOR may not require more space than what is left, 328 more voluminous encodings such as JSON and XML may suffer from this 329 size limitation. Although IPv4 and IPv6 publishers can fragment 330 outgoing packets exceeding their Maximum Transmission Unit(MTU), 331 fragmented IP packets may not be desired for operational and 332 performance reasons. 334 Consequently, implementations of the mechanism SHOULD provide a 335 configurable max-segment-size option to control the maximum size of a 336 payload. 338 0 1 2 3 339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 340 +---------------+---------------+-----------------------------+-+ 341 | Type | Length | Segment Number |L| 342 +---------------+---------------+-----------------------------+-+ 344 Figure 4: Segmentation Option Format 346 The Segmentation Option is to be included when the message content is 347 segmented into multiple pieces. Different segments of one message 348 share the same Message ID. An illustration is provided in Figure 4. 349 The fields of this TLV are: 351 * Type: Generic option field which indicates a Segmentation Option. 352 The Type value is to be assigned TBD1. 354 * Length: Generic option field which indicates the length of this 355 option. It is a fixed value of 4 octets for the Segmentation 356 Option. 358 * Segment Number: 15-bit value indicating the sequence number of the 359 current segment. The first segment of a segmented message has a 360 Segment Number value of 0. 362 * L: is a flag to indicate whether the current segment is the last 363 one of the message. When 0 is set, the current segment is not the 364 last one. When 1 is set, the current segment is the last one, 365 meaning that the total number of segments used to transport this 366 message is the value of the current Segment Number + 1. 368 An implementation of this specification MUST NOT rely on IP 369 fragmentation by default to carry large messages. An implementation 370 of this specification MUST either restrict the size of individual 371 messages carried over this protocol, or support the segmentation 372 option. 374 When a message has multiple options and is segmented using the 375 described mechanism, all the options MUST be present on the first 376 segment ordered by the options Type. The rest of segmented messages 377 MAY include all the options ordered by options type. 379 4.2. Private Encoding Option 381 The space to describe private encodings in the MT field of the UDP- 382 Notif header being limited, an option is provided to describe custom 383 encodings. The fields of this option are as follows. 385 0 1 2 3 386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 387 +---------------+---------------+-------------------------------- 388 | Type | Length | Variable length enc. descr. 389 +---------------+---------------+-------------------------------- 391 Figure 5: Private Encoding Option Format 393 * Type: Generic option field which indicates a Private Encoding 394 Option. The Type value is to be assigned TBD2. 396 * Length: Generic option field which indicates the length of this 397 option. It is a variable value. 399 * Enc. Descr: The description of the private encoding used for this 400 message. The values to be used for such private encodings is left 401 to be defined by the users of private encodings. 403 This option SHOULD only be used when the S bit of the header is set, 404 as providing a private encoding description for standard encodings is 405 meaningless. 407 5. Applicability 409 In this section, we provide an applicability statement for the 410 proposed mechanism, following the recommendations of [RFC8085]. 412 The proposed mechanism falls in the category of UDP applications 413 "designed for use within the network of a single network operator or 414 on networks of an adjacent set of cooperating network operators, to 415 be deployed in controlled environments". Implementations of the 416 proposed mechanism SHOULD thus follow the recommendations in place 417 for such specific applications. In the following, we discuss 418 recommendations on congestion control, message size guidelines, 419 reliability considerations and security considerations. 421 5.1. Congestion Control 423 The proposed application falls into the category of applications 424 performing transfer of large amounts of data. It is expected that 425 the operator using the solution configures QoS on its related flows. 426 As per [RFC8085], such applications MAY choose not to implement any 427 form of congestion control, but follow the following principles. 429 It is NOT RECOMMENDED to use the proposed mechanism over congestion- 430 sensitive network paths. The only environments where UDP-Notif is 431 expected to be used are managed networks. The deployments require 432 that the network path has been explicitly provisioned to handle the 433 traffic through traffic engineering mechanisms, such as rate limiting 434 or capacity reservations. 436 Implementation of the proposal SHOULD NOT push unlimited amounts of 437 traffic by default, and SHOULD require the users to explicitly 438 configure such a mode of operation. 440 Burst mitigation through packet pacing is RECOMMENDED. Disabling 441 burst mitigation SHOULD require the users to explicitly configure 442 such a mode of operation. 444 Applications SHOULD monitor packet losses and provide means to the 445 user for retrieving information on such losses. The UDP-Notif 446 Message ID can be used to deduce congestion based on packet loss 447 detection. Hence the receiver can notify the device to use a lower 448 streaming rate. The interaction to control the streaming rate on the 449 device is out of the scope of this document. 451 5.2. Message Size 453 [RFC8085] recommends not to rely on IP fragmentation for messages 454 whose size result in IP packets exceeding the MTU along the path. 455 The segmentation option of the current specification permits 456 segmentation of the UDP Notif message content without relying on IP 457 fragmentation. Implementation of the current specification SHOULD 458 allow for the configuration of the MTU. 460 5.3. Reliability 462 The target application for UDP-Notif is the collection of data-plane 463 information. The lack of reliability of the data streaming mechanism 464 is thus considered acceptable as the mechanism is to be used in 465 controlled environments, mitigating the risk of information loss, 466 while allowing for publication of very large amounts of data. 467 Moreover, in this context, sporadic events when incomplete data 468 collection is provided is not critical for the proper management of 469 the network, as information collected for the devices through the 470 means of the proposed mechanism is to be often refreshed. 472 A receiver implementation for this protocol SHOULD deal with 473 potential loss of packets carrying a part of segmented payload, by 474 discarding packets that were received, but cannot be re-assembled as 475 a complete message within a given amount of time. This time SHOULD 476 be configurable. 478 5.4. Security Considerations 480 [RFC8085] states that "UDP applications that need to protect their 481 communications againts eavesdropping, tampering, or message forgery 482 SHOULD employ end-to-end security services provided by other IETF 483 protocols". As mentioned above, the proposed mechanism is designed 484 to be used in controlled environments and thus, a security layer is 485 unrequired. Nevertheless, a DTLS layer SHOULD be implemented in open 486 or unsecured networks. A DTLS layered implementation is presented in 487 Section 6. 489 6. Secured layer for UDP-notif 491 In open or unsecured networks, UDP-notif messages SHOULD be secured 492 or encrypted. In this section, a mechanism using DTLS 1.3 to secure 493 UDP-notif protocol is presented. The following sections defines the 494 requirements for the implementation of the secured layer of DTLS for 495 UDP-notif. No DTLS 1.3 extensions are defined nor needed. 497 The DTLS 1.3 protocol [I-D.draft-ietf-tls-dtls13] is designed to meet 498 the requirements of applications that need to secure datagram 499 transport. 501 DTLS can be used as a secure transport to counter all the primary 502 threats to UDP-notif: 504 * Confidentiality to counter disclosure of the message contents. 506 * Integrity checking to counter modifications to a message on a hop- 507 by-hop basis. 509 * Server or mutual authentication to counter masquerade. 511 In addition, DTLS also provides: 513 * A cookie exchange mechanism during handshake to counter Denial of 514 Service attacks. 516 * A sequence number in the header to counter replay attacks. 518 Even though this security layer is unrequired, DTLS 1.3 SHOULD be 519 implemented on unsecured networks to achieve privacy. 521 6.1. Transport 523 As shown in Figure 6, the DTLS is layered next to the UDP transport 524 providing reusable security and authentication functions over UDP. 525 No DTLS extension is required to enable UDP-notif messages over DTLS. 527 +-----------------------------+ 528 | UDP-notif Message | 529 +-----------------------------+ 530 | DTLS | 531 +-----------------------------+ 532 | UDP | 533 +-----------------------------+ 534 | IP | 535 +-----------------------------+ 537 Figure 6: Protocol Stack for DTLS secured UDP-notif 539 The application implementer will map a unique combination of the 540 remote address, remote port number, local address, and local port 541 number to a session. 543 Each UDP-notif message is delivered by the DTLS record protocol, 544 which assigns a sequence number to each DTLS record. Although the 545 DTLS implementer may adopt a queue mechanism to resolve reordering, 546 it may not assure that all the messages are delivered in order when 547 mapping on the UDP transport. 549 Since UDP is an unreliable transport, with DTLS, an originator or a 550 relay may not realize that a collector has gone down or lost its DTLS 551 connection state, so messages may be lost. 553 The DTLS record has its own sequence number, encryption and 554 decryption will be done by the DTLS layer, so that the UDP-notif 555 Message layer is not impacted by the use of DTLS. 557 6.2. Port Assignment 559 When this security layer is used, the Publisher MUST always be a DTLS 560 client, and the Receiver MUST always be a DTLS server. The Receivers 561 MUST support accepting UDP-notif Messages on the specified UDP port, 562 but MAY be configurable to listen on a different port. The Publisher 563 MUST support sending UDP-notif messages to the specified UDP port, 564 but MAY be configurable to send messages to a different port. The 565 Publisher MAY use any source UDP port for transmitting messages. 567 6.3. Session lifecycle 569 6.3.1. DTLS Session Initiation 571 The Publisher initiates a DTLS connection by sending a DTLS 572 ClientHello to the Receiver. Implementations MAY support the denial 573 of service countermeasures defined by DTLS 1.3. When these 574 countermeasures are used, the Receiver responds with a DTLS 575 HelloRetryRequest containing a stateless cookie. The Publisher MUST 576 send a new DTLS ClientHello message containing the received cookie, 577 which initiates the DTLS handshake. 579 When DTLS is implemented, the Publisher MUST NOT send any UDP-notif 580 messages before the DTLS handshake has successfully completed. 582 Implementations of this security layer MUST support DTLS 1.3 583 [I-D.draft-ietf-tls-dtls13] and MUST support the mandatory to 584 implement cipher suite TLS_AES_128_GCM_SHA256 and SHOULD implement 585 TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher 586 suites, as specified in TLS 1.3 [RFC8446]. If additional cipher 587 suites are supported, then implementations MUST NOT negotiate a 588 cipher suite that employs NULL integrity or authentication 589 algorithms. 591 Where privacy is REQUIRED, then implementations must either negotiate 592 a cipher suite that employs a non-NULL encryption algorithm or 593 otherwise achieve privacy by other means, such as a physically 594 secured network. 596 6.3.2. Publish Data 598 When DTLS is used, all UDP-notif messages MUST be published as DTLS 599 "application_data". It is possible that multiple UDP-notif messages 600 are contained in one DTLS record, or that a publication message is 601 transferred in multiple DTLS records. The application data is 602 defined with the following ABNF [RFC5234] expression: 604 APPLICATION-DATA = 1*UDP-NOTIF-FRAME 605 UDP-NOTIF-FRAME = MSG-LEN SP UDP-NOTIF-MSG 607 MSG-LEN = NONZERO-DIGIT *DIGIT 609 SP = %d32 611 NONZERO-DIGIT = %d49-57 613 DIGIT = %d48 / NONZERO-DIGIT 615 UDP-NOTIF-MSG is defined in Section 3. 617 The Publisher SHOULD attempt to avoid IP fragmentation by using the 618 Segmentation Option in the UDP-notif message. 620 6.3.3. Session termination 622 A Publisher MUST close the associated DTLS connection if the 623 connection is not expected to deliver any UDP-notif Messages later. 624 It MUST send a DTLS close_notify alert before closing the connection. 625 A Publisher (DTLS client) MAY choose to not wait for the Receiver's 626 close_notify alert and simply close the DTLS connection. Once the 627 Receiver gets a close_notify from the Publisher, it MUST reply with a 628 close_notify. 630 When no data is received from a DTLS connection for a long time, the 631 Receiver MAY close the connection. Implementations SHOULD set the 632 timeout value to 10 minutes but application specific profiles MAY 633 recommend shorter or longer values. The Receiver (DTLS server) MUST 634 attempt to initiate an exchange of close_notify alerts with the 635 Publisher before closing the connection. Receivers that are 636 unprepared to receive any more data MAY close the connection after 637 sending the close_notify alert. 639 Although closure alerts are a component of TLS and so of DTLS, they, 640 like all alerts, are not retransmitted by DTLS and so may be lost 641 over an unreliable network. 643 7. A YANG Data Model for Management of UDP-Notif 645 The YANG model defined in Section 8 has two leaves augmented into one 646 place of Sub-Notif [RFC8639], plus one identity. 648 module: ietf-udp-subscribed-notifications 649 augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver: 650 +--rw address inet:ip-address 651 +--rw port inet:port-number 652 +--rw enable-segmentation? boolean 653 +--rw max-segmentation-size? uint32 655 8. YANG Module 657 file "ietf-udp-notif@2020-10-18.yang" 658 module ietf-udp-notif { 659 yang-version 1.1; 660 namespace 661 "urn:ietf:params:xml:ns:yang:ietf-udp-notif"; 662 prefix un; 663 import ietf-subscribed-notifications { 664 prefix sn; 665 reference 666 "RFC 8639: Subscription to YANG Notifications"; 667 } 668 import ietf-inet-types { 669 prefix inet; 670 reference 671 "RFC 6991: Common YANG Data Types"; 672 } 674 organization "IETF NETCONF (Network Configuration) Working Group"; 675 contact 676 "WG Web: 677 WG List: 679 Authors: Guangying Zheng 680 681 Tianran Zhou 682 683 Thomas Graf 684 685 Pierre Francois 686 687 Paolo Lucente 688 "; 690 description 691 "Defines UDP-Notif as a supported transport for subscribed 692 event notifications. 694 Copyright (c) 2018 IETF Trust and the persons identified as authors 695 of the code. All rights reserved. 697 Redistribution and use in source and binary forms, with or without 698 modification, is permitted pursuant to, and subject to the license 699 terms contained in, the Simplified BSD License set forth in Section 700 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 701 (https://trustee.ietf.org/license-info). 703 This version of this YANG module is part of RFC XXXX; see the RFC 704 itself for full legal notices."; 706 revision 2021-10-18 { 707 description 708 "Slight change to the name of two parameters."; 709 reference 710 "RFC XXXX: UDP-based Transport for Configured Subscriptions"; 711 } 713 /* 714 * FEATURES 715 */ 716 feature encode-cbor { 717 description 718 "This feature indicates that CBOR encoding of notification 719 messages is supported."; 720 } 722 /* 723 * IDENTITIES 724 */ 725 identity udp-notif { 726 base sn:transport; 727 description 728 "UDP-Notif is used as transport for notification messages 729 and state change notifications."; 730 } 732 identity encode-cbor { 733 base sn:encoding; 734 description 735 "Encode data using CBOR as described in RFC XXX."; 736 reference 737 "RFC XXX: draft-ietf-core-yang-cbor-18, CBOR Encoding of 738 Data Modeled with YANG"; 739 } 741 grouping target-receiver { 742 description 743 "Provides a reusable description of a UDP-Notif target 744 receiver."; 746 leaf address { 747 type inet:ip-address; 748 mandatory true; 749 description 750 "IP address of target UDP-Notif receiver, which can be an 751 IPv4 address or an IPV6 address."; 752 } 754 leaf port { 755 type inet:port-number; 756 description 757 "Port number of target UDP-Notif receiver, if not specified, 758 the system should use default port number."; 759 } 761 leaf enable-segmentation { 762 type boolean; 763 default false; 764 description 765 "The switch for the segmentation feature. When disabled, the 766 publisher will not allow fragment for a very large data"; 767 } 769 leaf max-segmentation-size { 770 when "../enable-segmentation = 'true'"; 771 type uint32; 772 description "UDP-Notif provides a configurable 773 max-segmentation-size to control the size of each message."; 774 } 775 } 777 augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { 778 when "derived-from(../../../transport, 'un:udp-notif')"; 779 description 780 "This augmentation allows UDP-Notif specific parameters to be 781 exposed for a subscription."; 783 uses target-receiver; 784 } 785 } 786 788 9. IANA Considerations 790 This document is creating 2 registries called "UDP-notif media types" 791 and "UDP-notif option types" under the new heading "UDP-notif 792 protocol". The registration procedure is made using the Standards 793 Action process defined in [RFC8126]. 795 The first requested registry is the following: 797 Registry Name: UDP-notif media types 798 Registry Category: UDP-notif protocol. 799 Registration Procedure: Standard Action as defined in RFC8126 800 Maximum value: 15 802 These are the initial registrations for "UDP-notif media types": 804 Value: 0 805 Description: Reserved 806 Reference: this document 808 Value: 1 809 Description: media type application/yang-data+json 810 Reference: 812 Value: 2 813 Description: media type application/yang-data+xml 814 Reference: 816 Value: 3 817 Description: media type application/yang-data+cbor 818 Reference: 820 The second requested registry is the following: 822 Registry Name: UDP-notif option types 823 Registry Category: UDP-notif protocol. 824 Registration Procedure: Standard Action as defined in RFC8126 825 Maximum value: 255 827 These are the initial registrations for "UDP-notif options types": 829 Value: 0 830 Description: Reserved 831 Reference: this document 833 Value: TBD1 (suggested value: 1) 834 Description: Segmentation Option 835 Reference: this document 836 Value: TBD2 (suggested value: 2) 837 Description: Private Encoding Option 838 Reference: this document 840 IANA is also requested to assign a new URI from the IETF XML Registry 841 [RFC3688]. The following URI is suggested: 843 URI: urn:ietf:params:xml:ns:yang:ietf-udp-notif 844 Registrant Contact: The IESG. 845 XML: N/A; the requested URI is an XML namespace. 847 This document also requests a new YANG module name in the YANG Module 848 Names registry [RFC7950] with the following suggestion: 850 name: ietf-udp-notif 851 namespace: urn:ietf:params:xml:ns:yang:ietf-udp-notif 852 prefix: un 853 reference: RFC XXXX 855 10. Acknowledgements 857 The authors of this documents would like to thank Alexander Clemm, 858 Eric Voit, Huiyang Yang, Kent Watsen, Mahesh Jethanandani, Stephane 859 Frenot, Timothy Carey, Tim Jenkins, Yunan Gu and Marco Tollini for 860 their constructive suggestions for improving this document. 862 11. References 864 11.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, 868 DOI 10.17487/RFC2119, March 1997, 869 . 871 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 872 DOI 10.17487/RFC3688, January 2004, 873 . 875 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 876 Specifications: ABNF", STD 68, RFC 5234, 877 DOI 10.17487/RFC5234, January 2008, 878 . 880 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 881 RFC 7950, DOI 10.17487/RFC7950, August 2016, 882 . 884 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 885 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 886 March 2017, . 888 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 889 Writing an IANA Considerations Section in RFCs", BCP 26, 890 RFC 8126, DOI 10.17487/RFC8126, June 2017, 891 . 893 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 894 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 895 . 897 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 898 E., and A. Tripathy, "Subscription to YANG Notifications", 899 RFC 8639, DOI 10.17487/RFC8639, September 2019, 900 . 902 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 903 E., and A. Tripathy, "Dynamic Subscription to YANG Events 904 and Datastores over NETCONF", RFC 8640, 905 DOI 10.17487/RFC8640, September 2019, 906 . 908 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 909 A. Bierman, "Dynamic Subscription to YANG Events and 910 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 911 November 2019, . 913 11.2. Informative References 915 [I-D.draft-ietf-tls-dtls13] 916 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 917 Datagram Transport Layer Security (DTLS) Protocol Version 918 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 919 dtls13-43, July 2021, 920 . 923 [I-D.ietf-core-yang-cbor] 924 Veillette, M., Petrov, I., Pelov, A., Bormann, C., and M. 925 Richardson, "CBOR Encoding of Data Modeled with YANG", 926 Work in Progress, Internet-Draft, draft-ietf-core-yang- 927 cbor-18, 19 December 2021, 928 . 931 [I-D.ietf-netconf-distributed-notif] 932 Zhou, T., Zheng, G., Voit, E., Graf, T., and P. Francois, 933 "Subscription to Distributed Notifications", Work in 934 Progress, Internet-Draft, draft-ietf-netconf-distributed- 935 notif-02, May 2021, 936 . 939 [I-D.ietf-netconf-https-notif] 940 Jethanandani, M. and K. Watsen, "An HTTPS-based Transport 941 for YANG Notifications", Work in Progress, Internet-Draft, 942 draft-ietf-netconf-https-notif-09, 24 October 2021, 943 . 946 [I-D.ietf-netconf-notification-messages] 947 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 948 Clemm, "Notification Message Headers and Bundles", Work in 949 Progress, Internet-Draft, draft-ietf-netconf-notification- 950 messages-08, 17 November 2019, 951 . 954 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 955 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 956 . 958 Authors' Addresses 960 Guangying Zheng 961 Huawei 962 101 Yu-Hua-Tai Software Road 963 Nanjing 964 Jiangsu, 965 China 966 Email: zhengguangying@huawei.com 968 Tianran Zhou 969 Huawei 970 156 Beiqing Rd., Haidian District 971 Beijing 972 China 973 Email: zhoutianran@huawei.com 974 Thomas Graf 975 Swisscom 976 Binzring 17 977 CH- Zuerich 8045 978 Switzerland 979 Email: thomas.graf@swisscom.com 981 Pierre Francois 982 INSA-Lyon 983 Lyon 984 France 985 Email: pierre.francois@insa-lyon.fr 987 Alex Huang Feng 988 INSA-Lyon 989 Lyon 990 France 991 Email: alex.huang-feng@insa-lyon.fr 993 Paolo Lucente 994 NTT 995 Siriusdreef 70-72 996 Hoofddorp, WT 2132 997 Netherlands 998 Email: paolo@ntt.net