idnits 2.17.00 (12 Aug 2021) /tmp/idnits49684/draft-eckert-anima-services-dns-autoconfig-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 142: '...ures described in this document SHOULD...' RFC 2119 keyword, line 152: '...utoconfiguration SHOULD be enabled whe...' RFC 2119 keyword, line 195: '...in this document SHOULD default to the...' RFC 2119 keyword, line 196: '...These parameters MAY all be configurab...' RFC 2119 keyword, line 215: '... objective-value MUST comply with the ...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (4 March 2022) is 71 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-eckert-anima-grasp-dnssd-02 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 8368 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA T.T.E. Eckert 3 Internet-Draft Futurewei 4 Intended status: Standards Track M. Boucadair 5 Expires: 5 September 2022 C. Jacquenet 6 Orange 7 M. Behringer 8 4 March 2022 10 Autoconfiguration of infrastructure services in ACP networks via DNS-SD 11 over GRASP 12 draft-eckert-anima-services-dns-autoconfig-01 14 Abstract 16 This document defines standards that enable autoconfiguration of 17 fundamental centralized or decentralized network infrastructure 18 services on ACP network nodes via GRASP. These are primarily the 19 services required for initial bootstrapping of a network but will 20 persist through the lifecycles of the network. These services 21 include secure remote access to zero-touch bootstrapped ANI devices 22 via SSH/Netconf with Radius/Diameter authentication and authorization 23 and provides lifecycle autoconfiguration for other crucial services 24 such as syslog, NTP (clock synchronization) and DNS for operational 25 purposes. 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 5 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.2. ACP nodes supporting services autoconfiguration . . . . . 3 63 1.3. Use of ACP GRASP for autoconfiguration . . . . . . . . . 4 64 1.4. GRASP parameters . . . . . . . . . . . . . . . . . . . . 5 65 2. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.1. Syslog . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.2. NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 2.3. DNS for operations . . . . . . . . . . . . . . . . . . . 12 69 2.4. Radius . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 2.5. Diameter . . . . . . . . . . . . . . . . . . . . . . . . 14 71 2.6. SSH server . . . . . . . . . . . . . . . . . . . . . . . 15 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 74 5. Change log [RFC Editor: Please remove] . . . . . . . . . . . 16 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 77 6.2. Informative References . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 1.1. Overview 84 This document defines to support the autoconfiguration of Autonomic 85 Control Plane (ACP, [RFC8994]) nodes for fundamental decentralized 86 network services via DNS-SD GRASP, utilizing a new proposal mapping 87 of DNS-SD ([RFC6763]) onto GRASP as its hop-by-hop multicast 88 transport and encoding of messages. 90 One key purpose of this autoconfiguration is the seamless step from 91 zero-touch bootstrap in ANI devices over to a securely remotely 92 manageable ACP node. 94 Bootstrapping ANI devices via BRSKI into a running ACP can be seen as 95 so-called "Day-0" bootstrap. If devices do not have BRSKI, then this 96 "Day-0" may include pre-staging of devices with the required ACP 97 domain credentials. The mechanisms described in this document then 98 start with what maybe could be called "Day-1" bootstrap: Auto- 99 configuring the required functions for remote, secure access to ANI/ 100 ACP devices. 102 The services identified to be required for "Day-1" start with 103 bootstrapping NTP clock synchronization across ACP/ANI nodes 104 sufficient to validate certificates used across the ACP, 105 establishment of user/role based authentication via Radius or 106 diameter, autoconfiguration of the required remote-access methods to 107 remotely access ACP/ANI nodes, SSH and NetConf with user/role based 108 authentication. Last, but not least, in the absence of better 109 registration mechanisms, syslog, which is also proposed to be 110 autoconfigured via the mechanisms of this document can also serve as 111 a "Day-1" mechanism to inform other sysems about the status of ACP/ 112 ANI devices. 114 All autoconfiguration provided for Day-1 stays valuable and continues 115 to operate through the lifetime of the ANI/ACP devices, so called 116 "Day-N" services. This allows especially to change decentralized 117 servers such as diameter/radius/NTP/syslog servers in case of 118 failures, load-balancing or when moving devices to different 119 locations in the network where better local server instances should 120 be used. 122 [RFC8368] was written on the simple assumption that all server 123 instances for services described in this document, NTP, Radius/ 124 Diameter, Syslog and so on are located in a so called 'Network 125 Operations Center'. This was at the writing of [RFC8368] how this 126 was done and called in various, mostly Enterprise networks, but is 127 today not necessarily a good way to capture all possible deployment 128 options. For example, server instances can today with distributed 129 Point of Presence (POP) and edge data-centers much easier 130 decentralized for resilience, performance and cost. Therefore, this 131 document avoids limiting its applicability to just one "NOC" 132 deployment option. 134 1.2. ACP nodes supporting services autoconfiguration 136 This document introduces the term ACPna nodes to indicate nodes 137 supporting ACP that also support the requirements described in this 138 document: ACP (n)oc (a)utoconfigurable. 140 If an ACPna node supports zero-touch bootstrap of the ACP where no 141 configuration is possible before the ACP is enabled, then the 142 services autoconfiguration features described in this document SHOULD 143 be enabled by default on such an ACPna node after this zero-touch 144 bootstrap, because the autoconfiguration of these services can be the 145 only method for the ACPna node to become operationally accessible 146 from OAM systems so that it can further be configured. ANI nodes are 147 nodes supporting ACP and BRSKI ([RFC8995]). BRSKI bootstrap is an 148 instance of such a zero-touch bootstrap requiring auto-enablement of 149 autoconfiguration after zero-toch bootstrap. 151 If an ACPna node was not zero-touch bootstrapped, then 152 autoconfiguration SHOULD be enabled whenever ACP is enabled but may 153 be separately configurable. 155 1.3. Use of ACP GRASP for autoconfiguration 157 Autoconfiguration of ACNna services utilizes the ACP instance of 158 GRASP, ([RFC8990] as defined in [RFC8994]. It leverages and extends 159 the GRASP objective definitions of [I-D.eckert-anima-grasp-dnssd]. 160 Thos objective elements allow to create DNS-SD compatible service 161 announcements with flexible priority/weight and distance based 162 selection across multiple service instances and per-service 163 parameters. 165 Nodes supporting a particular service announce it via the appropriate 166 GRASP objective into ACP GRASP. The nodes therefore need to have 167 access to the ACP, either directly because they are ACP nodes or 168 because they use the ACP connect function (see [RFC8994]). ACPna 169 nodes receive these announcements and auto-configure the services 170 tied to them. In most instances, the service announcement is from 171 server that a client instance on the ACPna node connects to, for 172 example a syslog server in the POP/NOC or other location with 173 compute. In another instance, the service is that of an 174 authentication service and the ACPna nodes will enable a server 175 instance that leverages the authentication service elsewhere in the 176 network. 178 Note: Currently, this document does not define the option of an mDNS/ 179 DNS-SD -> ACP GRASP gateway function to enable service nodes without 180 GRASP implementations to utilize mDNS/DNS-SD to announce their 181 services and then expect an appropriate translation function to 182 convert these announcements into GRASP objectives. This document 183 does define all the GRASP objectives so that that it would be 184 possible to define such a gateway function, but some loss of 185 functionality would exist. For once, GRASP does support network 186 distance based service selection (e.g., select a server from the 187 closest service node location), whereas no such mechanism exists in 188 DNS-SD. In addition, this documen believes that support of GRASP 189 software to announce services from service systems is very easy to 190 accomplish. 192 1.4. GRASP parameters 194 Unless otherwise described, all GRASP objective announcements 195 described in this document SHOULD default to the following GRASP 196 parameters. These parameters MAY all be configurable on the service 197 nodes. 199 * M_FLOOD GRASP message, periodicially sent once every 60 second. 200 Random phase vs. full minutes (so different service announcements 201 are distributed over time in the network). 203 * ttl of 210000 msec (3.5 times 60 seconds). 205 * locator-option is the ACP address of the announcing node unless 206 the nnouncement is done from a third-party, for exmple if the 207 announcing server does not support GRASP but GRASP is run on 208 another service node. 210 * objective-name is 'SRV.', where is an [RFC6335] 211 registered service name for the service in question. 213 * objective-flags is sync-only, loop-count is 255. 215 * objective-value MUST comply with the requirements of 216 [I-D.eckert-anima-grasp-dnssd]. 218 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 219 ["SRV.syslog", 4, 255, 220 { rfcXXXX: { 221 &(sender-loop-count:1) => 255, 222 &(srv-element:2) => { 223 &(msg-type:1) => &(describe: 0), 224 &(service:2) => "syslog", 225 &(instance:3) => "east-coast-primary", 226 &(priority:5) => 0, 227 &(weight:6) => 65535, 228 &(kvpairs:7) => { "replicate" => 2 }, 229 &(range:8) => 2, 230 } 231 } } 232 ], 233 [O_IPv6_LOCATOR, 234 h'fd89b714f3db0000200000064000001', TLS12, 514] 235 ] 237 Figure 1: SRV.syslog example 239 The above example shows the default values for a "syslog" service 240 announcement using the objective-value elements defined in 241 [I-D.eckert-anima-grasp-dnssd]. SRV.syslog is the standard objective 242 name for the "syslog" service, as is SRV. for the service. 243 The announcer of this objective also provides the syslog service as 244 it is announcing its own address in the locator option. It provides 245 syslog on the standard syslog TCP port 514 using TLS12. 247 The DNS-SD equivalent service attributes are carried in the srv- 248 element. The msg-type indicates that this objective is a service 249 announcement. The instance of "" indicates that this service 250 annuncement for the ACP itself, and not for e.g. the data-plane. It 251 is shown here just for illustration purposes and can be left out in 252 encoding because it is the default. Likewise, the service element is 253 redundant and shown only for illustrative purposes. Priority and 254 weight have the same semantic as in DNS-SD SRV records. In this 255 case, the service announcement indicates the highest priority (0) and 256 the highest weight (65535). Kvpairs includes service specific 257 options. 259 Going beyond the capabilities, the range parameter indicates that the 260 client of this service should select this announced service not only 261 by priority/weight but primarily by the distance in terms of network 262 hop-count between this service announcer and the client: The client 263 is expected to select the best service announcement by priority adn 264 weight only between alternatives that are not more than two network 265 hops apart in distance to the client. Otherwise the client should 266 pick the closer one. 268 To allow the client to know the distance to a service announcement, 269 the sender-loop-count parameter is included in the announcement. It 270 MUST be set by the sender to the same value (255 in this example) as 271 the loop-count in the GRASP header. The loop-count in the header is 272 hop-by-hop reduced. When the GRASP message arrives at the client, 273 the difference between sender-loop-count and loop-count is the 274 distance to the service announcer in hops. 276 ; 277 ; Following GRASP header definitions from GRASP 278 ; 279 flood-message = [M_FLOOD, session-id, initiator, ttl, 280 +[objective, (locator-option / [])]] 281 objective = ["SRV.", objective-flags, loop-count, 282 objective-value] 284 objective-flags = sync-only ; as in GRASP spec 285 sync-only = 4 ; M_FLOOD only requires synchronization 286 loop-count = 255 ; recommended 287 ; 288 ; Following GRASP objective-value definitions from GRASP DNS-SD 289 ; 290 objective-value = { 1*elements } 291 elements = ( @rfcXXXX: { 1*relement } ) 292 relement //= ( &(sender-loop-count:1) => 1..255 ) 293 relement //= ( &(srv-element:2) => context-element ) 294 context-element = { 295 ?( &(private:0) => any), 296 ?( &(msg-type:1 => msg-type), 297 ?( &(service:2) => tstr), 298 *( &(instance:3) => tstr), 299 ?( &(domain:4) => tstr), 300 ?( &(priority:5) => 0..65535 ), 301 ?( &(weight:6) => 0..65535 ), 302 *( &(kvpairs:7) => { *(tstr: any) }, 303 ?( &(range:8) => 0..255 ), 304 *( &(clocator:9) => clocator), 305 } 306 ; 307 TLS12 = 257 309 Figure 2: GRASP service definition 311 The above picture shows the complete CDDL defition of a GRASP M_FLOOD 312 message indicating a service together with the objective-value 313 encoding. Som of the context-element options are not used in this 314 document (TBD - remove before going RFC). 316 The value 257 is defined to indicate TLS12 ([RFC5246]) to be used in 317 the protocol field of GRASP locators to indicate that a TCP port is 318 intended to be used with TLS version 1.2. Values 1..255 are reserved 319 for IP protocol numbers. 321 2. Services 323 2.1. Syslog 325 ACPna nodes SHOULD support autoconfiguring of syslog via the 326 SRV.syslog objective. 328 When an ACPna node discovers one or more SRV.syslog announcements 329 across the ACP, it SHOULD perform syslog operations to the best 330 available discovered server. 332 Local configuration of syslog on the ACPna node SHOULD have no impact 333 on the autoconfigured syslog operations, or else, misconfiguration 334 could cause to failure of the autoconfigured syslog operations. 335 Instead, configured syslog operations should just operate as ships- 336 in-the-night to the GRASP learned autoconfigured syslog operations. 338 Severity of syslog messages SHOULD be 5 (Notice) (see [RFC5424]), and 339 all messages that are necessary to support normal remote operations 340 of the node should be assigned severities higher (numerically lower) 341 or equal to 5/Notice. 343 Syslog service announcements SHOULD include the instance option, 344 indicating the unique name of the service instance described by the 345 GRASP objective. This serves diagnostics and avoids having to 346 identify service instances by the address(es) in the locator-options. 347 In the example Figure 1, the instance name is "east-coast-primary". 349 The syslog facility value is a choice of the ACPna node, the 350 autoconfigured syslog server must be able to deal with any syslog 351 facility code received. If an ACPna node has no pre-established 352 standard for the facility-code, then the value of local7 (23) MAY be 353 used. 355 For resilience, it may be appropriate to receive syslog messages on 356 more than one server. A server can indicate this via the "replicate" 357 keyword in the GRASP objective-value kvpair element. The value of 358 the "replicate" keyword indicates the maximum number of syslog 359 servers that the client SHOULD autoconfigure syslog to. After 360 selecting the best service announcement, the client looks up the 361 value N of the "replicate" keyword of that best servers announcement 362 and selects the best N-1 service announcements and ultimately logs to 363 all N. ACPna nodes SHOULD support autoconfigured syslog to up to 3 364 servers simultaneously. 366 Autoconfigured syslog SHOULD support TLS1.2, TCP and UDP. Because 367 ACP provides encryption, use of just TCP instead of TLS should be 368 sufficient and may achieve higher performance. Use of UDP should be 369 avoided because of the potential to loose packets and not supporting 370 congestion control. 372 If a syslog server supports more than one transport option (TLS1.2, 373 TCP, UDP), it SHOULD announce them via a single GRASP objective and 374 list them via clocator options of the srv-element because the 375 locator-option in the GRASP header (as shown in example Figure 1) 376 allows only one locator-option. The order of the clocator options in 377 the indicates the preference of the server. From this list, the 378 client supports the first option supported also by the client and 379 ignore the others. The context of the clocator would normally be "", 380 indicating that the locator-option address is reachable via the ACP. 382 Instead of (or in addition to) using multiple clocator options, a 383 server can also announce multiple SRV.syslog objectives, but in that 384 case each of them would be considered to be a different service 385 instance considered by the the client when selecting the (set of) 386 best service instances. If a service announcement indicates via the 387 "replicate" keyword that the client should log to three service 388 instances, and announce three separate SRV.syslog objectives, each 389 one with a different locator-option, then the client might select to 390 log to all three of them - instead of - which is more likely the 391 desired option - for the client to log to actually three different 392 servers. Hence the use of multiple clocator options that are 393 examined by clients only after server selection is done. 395 When a client uses TLS, it MUST use its ACP domain certificate for 396 authentication. Likewise, the syslog server MUSTS use its ACP domain 397 certificate. 399 Logging by default uses the ACP, in the clocator option, this is 400 indicated via a context value of "". Servers may also indicate 401 support for logging across the data-plane, which may provide higher 402 performance but may fail if reachability in the data-plane does not 403 exist, so care must be taken when announcing this option. For 404 example, in managed MPLS/VPN networks where the ACP extends across P/ 405 PE and CE devices, the global routing table on a CE device is often 406 not the same as that on P/PE devices, and therefore CE devices may 407 not be able to log to "0". In this case, the syslog server should 408 instead announce a deployment choosen name for the context, such as 409 "VRF0". Clients would only take such a clocator into account if 410 there is a local configuration that maps the context name to a 411 routing table. In this example, only P/PE nodes would have this 412 configuration, therefore allowing the CE nodes to ignore this 413 clocator; And if this clocator was the only locator-option in the 414 GRASP objective, then the whole objective MUST be ignored by the 415 client when selecting the best possible service instance. Note that 416 for contexts other than the ACP (""), both IPv4 and IPv6 are 417 possible, depending on what version(s) of IP are deployed in the 418 data-plane. 420 Failure to connect to a choosen service instance SHOULD be taken into 421 accounts by clients when selecting service instances to log to. For 422 UDP locator-options, ICMP/ICMPv6 error indications are such 423 connection failures. For TCP/TLS connections, connection failure 424 includes TCP and TLS failures as well as keepalive failures. When 425 failures occur, clients should attempt to re-connect with exponential 426 timeouts, starting with 5 seconds and staying at 320 seconds or until 427 the GRASP service announcement expires and is not refreshed. 429 When connecting to a server fails, the ACPna client SHOULD connect to 430 the next best available server in the meantime. ACPna client SHOULD 431 support connecting to up to four service instances if any connections 432 fail. If for example the client is logging to two service instances 433 because 2 is indicated in the "replicate" option of the service 434 announcements, and one fails, the client will attempt to re-connect 435 to it while in parallel establishing syslog connection to a third- 436 best service-instance. 438 When establishing connection to a new syslog service instance, ACPna 439 clients SHOULD log with severity 5 an indication of this event, 440 indicating its own ACP address, the ACP address and if existing 441 instance name of the new syslog service instance and the reason. 442 Like any other autoconfigured syslog message, this would go to all 443 syslog connections and therefore show up on the redundant syslog 444 servers, allowing to recognize failure of connectivity to another 445 syslog server - and tracing of client logs across syslog servers if 446 the client changes them. 448 Examples: 450 ACP: fd89:b714:f3db::0200:0000:6400:0042 start logging to: 451 fd89:b714:f3db::0200:0000:6400:0001/east-coast-primary,TLS reason: 452 starting up 454 ACP: fd89:b714:f3db::0200:0000:6400:0042 start logging to: 455 fd89:b714:f3db::0200:0000:6400:0001/east-coast-primary,TLS reason: 456 new better service instance 458 ACP: fd89:b714:f3db::0200:0000:6400:0042 stop logging to: 459 fd89:b714:f3db::0200:0000:6400:0001/east-coast-secondary,TLS reason: 460 connection failure 461 When failures to deliver syslog messages to ANY syslog servers 462 happen, clients SHOULD track the this and indicate loss of messages 463 via the next working syslog connection. Note that due to the 464 possibility of ICMP/ICMPv6 errors, only the successful delivery of 465 messages via TLS or TCP should be tracked. TBD: need to check if 466 this can reasonably be recommended, pending on availability of e.g. 467 TAPS API spec to know whethrer a TCP write was sent and acknowledged 468 by the receiver (given how there are no reply messages in syslog). 470 2.2. NTP 472 Time synchronization is one of the most fundamental functionality for 473 network devices for a variety of functions to work and also for 474 diagnostics to be comparable across the network. If problems 475 propagate fast across the network, the client generated timestamp of 476 events in syslog messages (or other diagnostics function) allows to 477 trace event propagation and decude causality. This may require 478 network clock synchronization in the order of milliseconds, something 479 which is easily achievable in todays network devices via NTP. 481 ACPna nodes SHOULD support autoconfiguration of clock synchronization 482 through NTP ([RFC5905]) with the following autoconfiguration 483 semantics. 485 The GRASP objective for NTP is SRV.ntp. This does not distinguish 486 between NTPv4 and NTPv3 because NTPv4 is fully backward compatible 487 with NTPv3, so server and client will negotiate between these two 488 versions. 490 The kvpair key "stratum" has a numeric value and indicates the 491 stratum or level of a server in a synchronization tree. The value of 492 1 indicates the root of the distribution tree. Servers that 493 synchronize from the master have a stratum of 2, and so on. 495 The kvpair key "minpoll" indicates the lowest periodic polling that 496 the client will perform against the server. Announcing a large 497 numeric value allows for a server to reduce the amount of NTP 498 messages from clients, but slows down convergence time of 499 clientsnumber of service instances that simultaneously bootstrap. 501 The kvpair key "key" indicates the NTPv3 authentication mechanism. 502 When present, clients MUST use the value as the key to perform NTPv3 503 (MD5) hash authentication of message with this service instance. 504 Note that the encryption of the ACP serves as protection of 505 distributing such a cleartext symmetric key via GRASP to clients. 507 TBD: Understand NTPv4 autokey and define appropriate kvpair to enable 508 auto-configuring it, especially when the service instance 509 announcement indicates the use of the data-plane. 511 The autoconfiguration described in the following paragraphs is for 512 leafs of the clock distribution graph, e.g., nodes that do only aim 513 to obtain synchronized time from a server. Configuration of the 514 server hierarchy is left to explicit configuration. 516 Clients SHOULD select service instance(s) with the worst (highest) 517 stratum value. In the face of multiple equal options, clients have 518 to pick the best ones based on the standard selection criteria 519 priority/weight and range, allowing for distributed NTP server 520 deployment by e.e., setting range to 1, or via centralized deployment 521 with multiple servers, setting range to 255 and priority/weight 522 accordingly. Making the stratum the primary selection criteria 523 allows in the future to also introduce autoconfiguration of servers 524 in the NTP clock distribution tree without incurring the problem that 525 a large number of clients would then select higher stratum servers 526 (and overload them). 528 Like most other autoconfigured services, the autoconfigured NTP time 529 synchronization SHOULD take precedence over explicit configured NTP 530 options to ensure that time synchronization is not subject to 531 misconfiguration of individual nodes (but only subject to 532 misconfiguration of servers). 534 The kvpair "TZ" option allows to signal the time zone of the ACP 535 network to clients. Its value is a string indicating the time zone 536 of all nodes in the ACP network. Care must be taken not to use this 537 option in networks extending across multiple time zones. Because 538 time zone distribution does not work automatically across larger 539 networks with multiple time zones, overriding the signalled time zone 540 SHOULD be possible through local configuration. 542 TBD: references for time zone spec standards and also for DST rule 543 indications. 545 2.3. DNS for operations 547 Availability of DNS names for network operations/troubleshooting is 548 today mostly an convenience in network operations, but with IPv6 549 evolving the need to use DNS names even in CLI based network 550 diagnostics is raising - because IPv6 addresses often are more 551 difficult to memorize by operators. More and more network features 552 also support configurtion that instead of addresses include domain 553 names or URLs, and ultimately, any non-fully autoconfigured functions 554 should rather rely on domain-names and URLs instead of just addresses 555 for greater flexibility and relilability in the face of address 556 changes. 558 In thw face of this, ACPna nodes SHOULD support autoconfiguration of 559 DNS for operational purposes. "For operation purposes" implies that 560 the use of of the autoconfigured DNS servers SHOULD NOT be used for 561 DNS services offered to users of the data plane, such as DNS proxy 562 services. This would cause the ACP to effectively carry user 563 traffic, whenever a client DNS request to an ACPna node with a DNS 564 proxy would be forwrded to an autoconfigured server via the ACP. 566 The GRASP objective name for such OAM use of DNS is OAM-DNS. It is 567 explicitly not SRV.dns to highlight that this instance of DNS is 568 coped for operational purposes only to isolate it from user issues 569 (performance across the ACP and attacks). Utilizing different DNS 570 contexts also allows to set up split-horizon DNS where all the 571 operationally relevant DNS names are only made available via the DNS 572 servers or zones available across the ACP. 574 The value of the "search-list" kvpair option is a ";" (semicolon) 575 separated list of domain name prefixes that should be searched by the 576 client for non-FQDN that they need to resolve. "local-arpa" is the 577 prefix to use for reverse IPv4/IPv6 address lookups. If for example 578 "local-arpa" is set to "arpa.example.com", then the clients should 579 first look up IPv4/IPv6 addresses in "ipv6.arpa.example.com."/"in- 580 addr.arpa.example.com." before resorting to lookup in the Internet 581 global "ipv6.arpa."/"in-addr.arpa.". For RFC1918/ULA addresses, no 582 fallback to the global reverse lookup prefixes should be done. 584 ACPna nodes SHOULD look up their name via a reverse lookup of their 585 ACP address, and then auto-configure this name. 587 There are no service specifics for the selection of DNS servers. A 588 ACPna node simply uses the standard priority/weight/range options to 589 select a DNS server. It MAY prefer a server with TCP locator-option 590 simply because that allows in most cases faster discovery of 591 connectivity problems than a UDP connection. 593 TBD: Note that it is fairly easy to re-use the autoconfiguration 594 scheme described here to provide auto-configuration of DNS for user 595 DNS services with the help of the ACP. The objective name would have 596 to be changed and the clocators would have to indicate a data-plane 597 context, so that user requests are carried across the data-plane from 598 DNS proxies to DNS servers. It is unclear if this service should be 599 described in this document though. 601 2.4. Radius 603 Radius [RFC2865] is a protocol used for AAA service - Authentication, 604 Authorization and Accounting. Autodiscovery of Radius servers across 605 the ACP for ACPna nodes serves the purpose to enable authentication 606 and authorization of other ACPna autoconfigured services such as 607 below described Section 2.6. 609 ACPna nodes MUST support Radius and/or Diameter autoconfiguration if 610 they support any of the autoconfigured services depending on such an 611 authentication service. 613 The GRASP objective naem is SRV.radius. The UDP or TCP port of the 614 locator-option in the GRASP header or the clocator option indicate 615 the UDP or TCP port of the Radius servers authentication connection. 616 The context of a clocator MUST be "" to indicate the ACP - because 617 the Radius connections MUST pass across the ACP to be protected 618 against eavesdropping - and the radius security methods described 619 here are not sufficiently secure to allow passing them across the 620 data-plane. 622 The kvpair "secret_key" string value indicates the secret key to use 623 on the connection to the Radius server. The optional "acct_port" 624 numeric value indicate the UDP/TCP port of any accounting connection 625 supported by the radius server. The protocol (UDP vs. TCP) is the 626 same as the one in the choosen locator-option/clocator. 628 There are no service specific selection rules. TCP is preferred for 629 faster recognition of a failed server and reselection of an 630 alternative server. 632 The specific data/authentication/authorization configuration required 633 on the Radius server depends on the OAM service authenticated/ 634 authorized and is described in its section in this document. 636 TBD: Should we define AVpair or different objective names to 637 distinguish what services canb e authenticated ? Would be easier if 638 we found another service than SSH/Netconf. 640 2.5. Diameter 642 TBD. Alternative to Radius. Author would welcome suggesting what 643 parameters are relevant for a diameter authentication service. 645 2.6. SSH server 647 ACPna nodes supporting SSH server functionality for remote management 648 access via CLI, NETCONF or other methods SHOULD auto-enable SSH 649 server functionality across the ACP whenever they are aware from ACP 650 GRASP of RADIUS (Section 2.4) or DIAMETER (Section 2.5) 651 authentication servers. ACPna nodes that support ACPna SSH server 652 functionality MUST support authentication via either RADIUS and/or 653 Diameter. 655 If both protocols are supported by the ACPna node, the ACPna node 656 SHOULD select the authentication server based on the service priority 657 parameters across both protocols. E.g., if a RADIUS server has a 658 higher priority in GRASP than the DIAMETER server, the ACPna node 659 should authenticate against the RADIUS server. 661 When valid authentication server(s) are discovered, the SSH server is 662 autoconfigured. It SHOULD only listen to the standard SSH port with 663 the ACP address of the node but not be reachable from the data-plane. 664 It MUST NOT be modifyable by configuration (only by auto- 665 configuration). If autoconfiguration of an SSH server on the 666 standard SSH port conflicts with explicitly configured SSH server for 667 the data-plane due to software limitations or complexity, the 668 autoconfigured SSH server MAY be started on a node-type specific and 669 not dynamically selected port number. This port number must be well- 670 known to OAM operations as there is no method provided to signal it 671 to the SSH client side. 673 Note that this document does not define any standards for the exact 674 message options for authentication or authorization. Especially 675 authorization, such as privilege level that permits to change 676 configuration is likely using vendor specific methods, and Radius/ 677 Diameter servers must be capable to recognize the type of client as 678 they had to without this autoconfiguration. 680 3. Security Considerations 682 There is no protection against "unauthorized" ACP nodes to generate 683 service announcements, because there is no authorization scheme in 684 GRASP. Discovery of unauthorized announcers is easy though because 685 the service announcements are flooded across the ACP and are 686 therefore easily visible on nodes that may specifically oberve 687 announcements to discover unauthorized ones. 689 A possible framework to define authorization could rely on defining 690 roles for ACP nodes either through additional parameters in thei ACP 691 domain certificate or following initial provisioning, and then lock 692 down the ability for later configuration to enable services (and 693 their GRASP announcements) to only those included in the role 694 assigned to the node. This is outside the scope of this document. 696 4. Acknowledgments 698 Thanks to Ignas Bagdonas for deployment / applicability / terminology 699 input and to Balaji BL, Ravi Kumar Vadapalli for their original 700 implementation of the concept. 702 5. Change log [RFC Editor: Please remove] 704 draft-eckert-anima-services-dns-autoconfig 706 01: Refresh. 708 00: Renaming from 'noc-autoconfig' after a long discussion with 709 Ignas Bagdonas: replaced all mention of NOC with "infrastructure / 710 decentralized" services, because the term NOC seems to be a 711 terminology that does not well match how it is called in many type 712 of networks. 714 draft-eckert-anima-noc-autoconfig (2018) 716 00: Initial version. 718 6. References 720 6.1. Normative References 722 [I-D.eckert-anima-grasp-dnssd] 723 Eckert, T., Boucadair, M., Jacquenet, C., and M. H. 724 Behringer, "DNS-SD Compatible Service Discovery in GeneRic 725 Autonomic Signaling Protocol (GRASP)", Work in Progress, 726 Internet-Draft, draft-eckert-anima-grasp-dnssd-02, 12 July 727 2021, . 730 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 731 "Remote Authentication Dial In User Service (RADIUS)", 732 RFC 2865, DOI 10.17487/RFC2865, June 2000, 733 . 735 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 736 (TLS) Protocol Version 1.2", RFC 5246, 737 DOI 10.17487/RFC5246, August 2008, 738 . 740 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 741 DOI 10.17487/RFC5424, March 2009, 742 . 744 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 745 "Network Time Protocol Version 4: Protocol and Algorithms 746 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 747 . 749 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 750 Cheshire, "Internet Assigned Numbers Authority (IANA) 751 Procedures for the Management of the Service Name and 752 Transport Protocol Port Number Registry", BCP 165, 753 RFC 6335, DOI 10.17487/RFC6335, August 2011, 754 . 756 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 757 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 758 . 760 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 761 Control Plane for Stable Connectivity of Network 762 Operations, Administration, and Maintenance (OAM)", 763 RFC 8368, DOI 10.17487/RFC8368, May 2018, 764 . 766 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 767 Autonomic Signaling Protocol (GRASP)", RFC 8990, 768 DOI 10.17487/RFC8990, May 2021, 769 . 771 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 772 Autonomic Control Plane (ACP)", RFC 8994, 773 DOI 10.17487/RFC8994, May 2021, 774 . 776 6.2. Informative References 778 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 779 and K. Watsen, "Bootstrapping Remote Secure Key 780 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 781 May 2021, . 783 Authors' Addresses 785 Toerless Eckert 786 Futurewei Technologies USA Inc. 787 2220 Central Expressway 788 Santa Clara, 95050 789 United States of America 790 Email: tte+ietf@cs.fau.de 792 Mohamed Boucadair 793 Orange 794 35000 Rennes 795 France 796 Email: mohamed.boucadair@orange.com 798 Christian Jacquenet 799 Orange 800 Email: christian.jacquenet@orange.com 802 Michael H. Behringer 803 Email: michael.h.behringer@gmail.com