idnits 2.17.00 (12 Aug 2021) /tmp/idnits62118/draft-unyte-netconf-udp-notif-dtls-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (30 July 2021) is 288 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) == Missing Reference: 'RFC-to-be' is mentioned on line 248, but not defined == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 == Outdated reference: A later version (-05) exists of draft-ietf-netconf-udp-notif-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF A. Huang Feng 3 Internet-Draft P. Francois 4 Intended status: Standards Track INSA-Lyon 5 Expires: 31 January 2022 T. Zhou 6 Huawei 7 M. Tollini 8 Swisscom 9 30 July 2021 11 DTLS for UDP-notif 12 draft-unyte-netconf-udp-notif-dtls-00 14 Abstract 16 This document describes a DTLS layer for the UDP-notif protocol. 17 DTLS allows a server and a client to exchange secured messages over 18 UDP. This transport layer permits networking devices to send secured 19 UDP-notif messages over the network. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 31 January 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Port Assignment . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Session lifecycle . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. DTLS Session Initiation . . . . . . . . . . . . . . . . . 4 65 4.2. Publish Data . . . . . . . . . . . . . . . . . . . . . . 4 66 4.3. Session termination . . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 6.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 UDP-notif [I-D.ietf-netconf-udp-notif] defines a lightweight 76 notification protocol allowing networking devices to send data over 77 UDP. This document describes a layer to secure UDP-notif messages 78 between the publisher and the receiver using the DTLS 1.3 protocol. 80 The DTLS 1.3 protocol [I-D.draft-ietf-tls-dtls13] is designed to meet 81 the requirements of applications that need to secure datagram 82 transport. 84 DTLS can be used as a secure transport to counter all the primary 85 threats to UDP-notif: 87 * Confidentiality to counter disclosure of the message contents. 89 * Integrity checking to counter modifications to a message on a hop- 90 by-hop basis. 92 * Server or mutual authentication to counter masquerade. 94 In addition, DTLS also provides: 96 * A cookie exchange mechanism during handshake to counter Denial of 97 Service attacks. 99 * A sequence number in the header to counter replay attacks. 101 This document defines the requirements for the implementation of the 102 secured layer of DTLS for UDP-notif. No DTLS 1.3 extensions are 103 defined nor needed. 105 Section 2 describes the involved layers for this mechanism. 106 Section 3 describes the port management. Section 4 details the 107 session lifecycle of DTLS within UDP-notif. 109 2. Transport 111 As shown in Figure 1, the DTLS is layered next to the UDP transport 112 providing reusable security and authentication functions over UDP. 113 No DTLS extension is required to enable UDP-notif messages over DTLS. 115 +-----------------------------+ 116 | UDP-notif Message | 117 +-----------------------------+ 118 | DTLS | 119 +-----------------------------+ 120 | UDP | 121 +-----------------------------+ 122 | IP | 123 +-----------------------------+ 125 Figure 1: Protocol Stack for DTLS secured UDP-notif 127 The application implementer will map a unique combination of the 128 remote address, remote port number, local address, and local port 129 number to a session. 131 Each UDP-notif message is delivered by the DTLS record protocol, 132 which assigns a sequence number to each DTLS record. Although the 133 DTLS implementer may adopt a queue mechanism to resolve reordering, 134 it may not assure that all the messages are delivered in order when 135 mapping on the UDP transport. 137 Since UDP is an unreliable transport, with DTLS, an originator or a 138 relay may not realize that a collector has gone down or lost its DTLS 139 connection state, so messages may be lost. 141 The DTLS record has its own sequence number, encryption and 142 decryption will be done by the DTLS layer, so that the UDP-notif 143 Message layer is not impacted by the use of DTLS. 145 3. Port Assignment 147 The Publisher is always a DTLS client, and the Receiver is always a 148 DTLS server. The Receivers MUST support accepting UDP-notif Messages 149 on the specified UDP port, but MAY be configurable to listen on a 150 different port. The Publisher MUST support sending UDP-notif 151 messages to the specified UDP port, but MAY be configurable to send 152 messages to a different port. The Publisher MAY use any source UDP 153 port for transmitting messages. 155 4. Session lifecycle 157 4.1. DTLS Session Initiation 159 The Publisher initiates a DTLS connection by sending a DTLS 160 ClientHello to the Receiver. Implementations MAY support the denial 161 of service countermeasures defined by DTLS 1.3. When these 162 countermeasures are used, the Receiver responds with a DTLS 163 HelloRetryRequest containing a stateless cookie. The Publisher MUST 164 send a new DTLS ClientHello message containing the received cookie, 165 which initiates the DTLS handshake. 167 The Publisher MUST NOT send any UDP-notif messages before the DTLS 168 handshake has successfully completed. 170 Implementations MUST support DTLS 1.3 [I-D.draft-ietf-tls-dtls13] and 171 MUST support the mandatory to implement cipher suite 172 TLS_AES_128_GCM_SHA256 and SHOULD implement TLS_AES_256_GCM_SHA384 173 and TLS_CHACHA20_POLY1305_SHA256 cipher suites, as specified in TLS 174 1.3 [RFC8446]. If additional cipher suites are supported, then 175 implementations MUST NOT negotiate a cipher suite that employs NULL 176 integrity or authentication algorithms. 178 Where privacy is REQUIRED, then implementations must either negotiate 179 a cipher suite that employs a non-NULL encryption algorithm or 180 otherwise achieve privacy by other means, such as a physically 181 secured network. 183 4.2. Publish Data 185 All UDP-notif messages MUST be published as DTLS "application_data". 186 It is possible that multiple UDP-notif messages are contained in one 187 DTLS record, or that a publication message is transferred in multiple 188 DTLS records. The application data is defined with the following 189 ABNF [RFC5234] expression: 191 APPLICATION-DATA = 1*UDP-NOTIF-FRAME 192 UDP-NOTIF-FRAME = MSG-LEN SP UDP-NOTIF-MSG 194 MSG-LEN = NONZERO-DIGIT *DIGIT 196 SP = %d32 198 NONZERO-DIGIT = %d49-57 200 DIGIT = %d48 / NONZERO-DIGIT 202 UDP-NOTIF-MSG is defined in [I-D.ietf-netconf-udp-notif]. 204 The Publisher SHOULD attempt to avoid IP fragmentation by using the 205 Segmentation Option in the UDP-notif message. 207 4.3. Session termination 209 A Publisher MUST close the associated DTLS connection if the 210 connection is not expected to deliver any UDP-notif Messages later. 211 It MUST send a DTLS close_notify alert before closing the connection. 212 A Publisher (DTLS client) MAY choose to not wait for the Receiver's 213 close_notify alert and simply close the DTLS connection. Once the 214 Receiver gets a close_notify from the Publisher, it MUST reply with a 215 close_notify. 217 When no data is received from a DTLS connection for a long time, the 218 Receiver MAY close the connection. Implementations SHOULD set the 219 timeout value to 10 minutes but application specific profiles MAY 220 recommend shorter or longer values. The Receiver (DTLS server) MUST 221 attempt to initiate an exchange of close_notify alerts with the 222 Publisher before closing the connection. Receivers that are 223 unprepared to receive any more data MAY close the connection after 224 sending the close_notify alert. 226 Although closure alerts are a component of TLS and so of DTLS, they, 227 like all alerts, are not retransmitted by DTLS and so may be lost 228 over an unreliable network. 230 5. IANA Considerations 232 This RFC requests that IANA assigns one UDP port number in the 233 "Registered Port Numbers" range with the service name "udp-notif- 234 dtls". This port will be the default port for the UDP-based 235 notification Streaming Telemetry (UDP-Notif-DTLS) for NETCONF and 236 RESTCONF. Below is the registration template following the rules of 237 [RFC6335]. 239 Service Name: udp-notif-dtls 240 Transport Protocol(s): UDP 242 Assignee: IESG 244 Contact: IETF Chair 246 Description: UDP-based Publication Streaming Telemetry 248 Reference: [RFC-to-be] 250 Port Number: TBD1 252 IANA is requested to assign a new URI from the IETF XML Registry 253 [RFC3688]. The following URI is suggested: 255 URI: urn:ietf:params:xml:ns:yang:ietf-udp-notif 256 Registrant Contact: The IESG. 257 XML: N/A; the requested URI is an XML namespace. 259 This document also requests a new YANG module name in the YANG Module 260 Names registry [RFC7950] with the following suggestion: 262 name: ietf-udp-notif 263 namespace: urn:ietf:params:xml:ns:yang:ietf-udp-notif-dtls 264 prefix: un 265 reference: RFC XXXX 267 6. References 269 6.1. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 277 DOI 10.17487/RFC3688, January 2004, 278 . 280 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 281 Specifications: ABNF", STD 68, RFC 5234, 282 DOI 10.17487/RFC5234, January 2008, 283 . 285 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 286 Cheshire, "Internet Assigned Numbers Authority (IANA) 287 Procedures for the Management of the Service Name and 288 Transport Protocol Port Number Registry", BCP 165, 289 RFC 6335, DOI 10.17487/RFC6335, August 2011, 290 . 292 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 293 RFC 7950, DOI 10.17487/RFC7950, August 2016, 294 . 296 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 297 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 298 . 300 6.2. Informative References 302 [I-D.draft-ietf-tls-dtls13] 303 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 304 Datagram Transport Layer Security (DTLS) Protocol Version 305 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 306 dtls13-43, July 2021, 307 . 310 [I-D.ietf-netconf-udp-notif] 311 Zheng, G., Zhou, T., Graf, T., Francois, P., and P. 312 Lucente, "UDP-based Transport for Configured 313 Subscriptions", Work in Progress, Internet-Draft, draft- 314 ietf-netconf-udp-notif-03, July 2021, 315 . 318 Authors' Addresses 320 Alex Huang Feng 321 INSA-Lyon 322 Lyon 323 France 325 Email: alex.huang-feng@insa-lyon.fr 327 Pierre Francois 328 INSA-Lyon 329 Lyon 330 France 331 Email: pierre.francois@insa-lyon.fr 333 Tianran Zhou 334 Huawei 335 156 Beiqing Rd., Haidian District 336 Beijing 337 China 339 Email: zhoutianran@huawei.com 341 Marco Tollini 342 Swisscom 343 Binzring 17 344 CH- Zuerich 8045 345 Switzerland 347 Email: marco.tollini1@swisscom.com