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