idnits 2.17.1 draft-carpenter-anima-ani-objectives-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2017) is 2476 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-07 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-07 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-04 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational B. Liu 5 Expires: January 17, 2018 Huawei Technologies Co., Ltd 6 July 16, 2017 8 Technical Objective Formats for the Autonomic Network Infrastructure 9 draft-carpenter-anima-ani-objectives-03 11 Abstract 13 This document defines the formats of several technical objectives for 14 the Generic Autonomic Signaling Protocol (GRASP) used by components 15 of the Autonomic Networking Infrastructure outlined in the ANIMA 16 reference model. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 17, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Objectives for Secure Bootstrap . . . . . . . . . . . . . . . 3 54 2.1. Additional value for GRASP message syntax . . . . . . . . 3 55 2.2. Discovered Sychronization Objective for the Join 56 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Flooded Objective for Join Proxy . . . . . . . . . . . . 5 58 3. Objective for Autonomic Control Plane . . . . . . . . . . . . 6 59 4. Objective for Stable Connectivity of Network OAM . . . . . . 7 60 5. Flood Frequency . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 9.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 This document defines several technical objectives for use with for 73 the Generic Autonomic Signaling Protocol (GRASP) 74 [I-D.ietf-anima-grasp]. They are intended for use by corresponding 75 Autonomic Service Agents (ASAs) that support infrastructure 76 components of the Autonomic Network Infrastructure (ANI) outlined in 77 the ANIMA reference model [I-D.ietf-anima-reference-model]. 79 Note: This draft is posted to allow systematic discussion of the 80 various objectives in a consistent way. It is possible that rather 81 than this being published as an RFC, the various objective 82 definitions will be incorporated directly in the relevant 83 specifications. 85 The reference model identifies several infrastructure components that 86 will fit together with GRASP to form the ANI: 88 Secure Bootstrap. 90 Autonomic Control Plane (ACP). 92 Stable Connectivity of Network OAM. 94 The following sections define GRASP objectives for each of these 95 cases. They are described in an informal object notation and 96 formally using CBOR data definition language (CDDL) 98 [I-D.greevenbosch-appsawg-cbor-cddl]. Undefined CDDL terms are 99 defined in [I-D.ietf-anima-grasp]. 101 2. Objectives for Secure Bootstrap 103 Three ANI components are involved in the Bootstrapping Remote Secure 104 Key Infrastructures (BRSKI) process described in 105 [I-D.ietf-anima-bootstrapping-keyinfra]: the Join Registrar, the Join 106 Proxy, and the Pledge (a node joining the domain). In the present 107 document we only consider interactions between autonomic nodes 108 involved in BRSKI; non-autonomic nodes are expected to use different 109 methods not involving GRASP. 111 Note that since secure bootstrap takes place, by definition, on an 112 incompletely secure network, the use of any protocol needs to be kept 113 as simple and limited as possible. Between the proxy and the pledge, 114 therefore, only one GRASP message type is used - flooding - to avoid 115 giving away any unnecessary information. The proxy and pledge have a 116 link-local connection between them. Mutual discovery and bootstrap 117 can happen without any prior provisioning of helper information by an 118 external mechanism. Instead, link-local multicast with GRASP is 119 used. This will minimize exposure to eavesdroppers and malicious 120 nodes. On the other hand, there may be multiple physical hops 121 between the proxy and the registrar. Therefore, two different GRASP 122 objectives are required: one that is used over an existing secure 123 network (typically the ACP) between the registrar and the proxy, and 124 another that is used over an insecure link-local hop between the 125 proxy and the pledge. Furher security aspects are discussed in 126 [I-D.ietf-anima-bootstrapping-keyinfra] and [I-D.ietf-anima-grasp]. 128 2.1. Additional value for GRASP message syntax 130 This document extends the syntax of the GRASP protocol 131 [I-D.ietf-anima-grasp] by adding an additional value for the 132 "transport-proto" element: 134 transport-proto /= IPPROTO_IPV6 135 IPPROTO_IPV6 = 41 137 This value indicates IP-in-IP encapsulation. 139 2.2. Discovered Sychronization Objective for the Join Registrar 141 The Join Proxy discovers a Join Registrar by using the 142 "AN_join_registrar" GRASP objective. It must only be used when GRASP 143 is running securely, typically because the Join Proxy is in a node 144 that has already joined the ACP. The value of the objective will 145 indicate the BRSKI methods supported by the registrar and the 146 corresponding locators for BRSKI traffic. 148 First, the pledge performs GRASP discovery. If multiple responses 149 occur, it chooses one by an implementation-defined method. Then the 150 pledge initiates GRASP synchronization to obtain the BRSKI methods 151 supported by the discovered registrar. Alternatively, if 152 implemented, GRASP rapid mode could be used to combine the two 153 operations. 155 An example of the objective is informally: 157 ["AN_join_registrar", 5, 6, [["BRSKI-TCP", [O_IPv6_LOCATOR, 158 fd45:1345::6789, 6, 443]]]] 160 The formal CDDL definition is: 162 registrar-objective = ["AN_join_registrar", objective-flags, 163 loop-count, [*[method, locator-option]]] 165 objective-flags = ; as in the GRASP specification 166 loop-count = ; as in the GRASP specification 167 locator-option = ; as in the GRASP specification 168 method = "BRSKI-TCP" / "BRSKI-UDP" / "BRSKI-IPIP" 169 ; name of the BRSKI method supported 171 The objective-flags field is set to indicate synchronization. 173 The loop-count is set to a suitable value to limit the scope of 174 discovery. A suggested default value is 6. 176 The Join Proxy, upon receiving this objective, will select one or 177 more of the methods for announcement to Pledges. It will store the 178 provided locator for each method for subsequent BRSKI operations. 179 Note that this locator is distinct from the locator for the Join 180 Registrar's ASA, which is used only for GRASP operations. 182 Thus, locators for "BRSKI-TCP", "BRSKI-UDP" and "BRSKI-IPIP" could 183 be: 185 [O_IPv6_LOCATOR, ipv6-address, IPPROTO_TCP, rport1] 187 [O_IPv6_LOCATOR, ipv6-address, IPPROTO_UDP, rport2] 189 [O_IPv6_LOCATOR, ipv6-address, IPPROTO_IPV6, null] 191 where 'ipv6-address' is the address of the registrar (typically an 192 ACP address), and 'rport1' and 'rport2' are the appropriate TCP and 193 UDP ports at the registrar. 195 2.3. Flooded Objective for Join Proxy 197 A Join Proxy announces itself to potential pledges by use of the 198 "AN_join_proxy" objective. This is a synchronization objective 199 intended only to be flooded on a single link using the GRASP Flood 200 Synchronization (M_FLOOD) message. In accordance with the design of 201 the Flood message, a locator consisting of a specific link-local IP 202 address, IP protocol number and port number will be distributed with 203 the flooded objective. An example of the objective is informally: 205 ["AN_join_proxy", 5, 1, "BRSKI-TCP"] 207 The formal CDDL definition is: 209 proxy-objective = ["AN_join_proxy", objective-flags, loop-count, 210 method] 212 objective-flags = ; as in the GRASP specification 213 loop-count = 1 ; limit to link-local operation 214 method = "BRSKI-TCP" / "BRSKI-UDP" 216 The objective-flags field is set to indicate synchronization. 218 The loop-count is fixed at 1 since this is a link-local operation. 220 A Join Proxy that supports more than one method will flood multiple 221 versions of the "AN_join_proxy" objective. As specified for the 222 GRASP M_FLOOD message, a locator may be attached to each version. 223 The 'method' parameter indicates the specific BRSKI method available 224 at the given locator. 226 Thus, locators for "BRSKI-TCP" and "BRSKI-UDP" would be: 228 [O_IPv6_LOCATOR, ipv6-address, IPPROTO_TCP, pport1] 230 [O_IPv6_LOCATOR, ipv6-address, IPPROTO_UDP, pport2] 232 where 'ipv6-address' is the link-local address of the proxy and 233 'pport1' and 'pport2' are the appropriate TCP and UDP ports at the 234 proxy. 236 Note that the BRSKI-IPIP method is never announced to the Pledges, 237 because it applies exclusively between the Proxy and the Join 238 Registrar, being used to encapsulate one of the other methods. 240 By this mechanism, a proxy may announce one or more connection 241 methods to all pledges, each with an associated link-local address, 242 protocol number and port number. 244 This objective is only to be used in a Discovery Unsolicited Link- 245 Local (DULL) instance of GRASP [I-D.ietf-anima-grasp]. 247 3. Objective for Autonomic Control Plane 249 The Autonomic Control Plane (ACP) 250 [I-D.ietf-anima-autonomic-control-plane] constructs itself without 251 outside intervention. To achieve this, each node needs to identify 252 its link-local neighbors on all interfaces, and agree on a secure 253 connection method with each of them. As for the Join Proxy, a 254 flooding mechanism, in which each node announces itself and it 255 security methods to its neighbors, is used. 257 Thus each autonomic node runs an ASA that supports the corresponding 258 objective. This ASA runs permanently, as long as the node is capable 259 of being part of the ACP, in order to discover or detect new ACP 260 neighbors or to remove failed neighbors. 262 A node announces itself to potential ACP peers by use of the "AN_ACP" 263 objective. This is a synchronization objective intended to be 264 flooded on a single link using the GRASP Flood Synchronization 265 (M_FLOOD) message. In accordance with the design of the Flood 266 message, a locator consisting of a specific link-local IP address, IP 267 protocol number and port number will be distributed with the flooded 268 objective. An example of the objective is informally: 270 ["AN_ACP", 5, 1, ["IKEv2","dTLS"]] 272 The formal CDDL definition is: 274 acp-objective = ["AN_ACP", objective-flags, loop-count, method] 276 objective-flags = ; as in the GRASP specification 277 loop-count = 1 ; limit to link-local operation 278 method = "IKEv2" / "dTLS" ; connection method supported 280 The objective-flags field is set to indicate synchronization. 282 The loop-count is fixed at 1 since this is a link-local operation. 284 A node that supports more than one method may flood multiple versions 285 of the "AN_ACP" objective, each accompanied by its own locator, 286 similar to "AN_join_proxy". The 'method' parameter indicates the 287 specific connection method available at the given locator. The 288 initial possible values are "IKEv2" and "dTLS". 290 This objective is only to be used in a Discovery Unsolicited Link- 291 Local (DULL) instance of GRASP [I-D.ietf-anima-grasp]. 293 Note that a node serving both as an ACP node and BRSKI Join Proxy may 294 choose to distribute the "AN_ACP" objective and "AN_join_proxy" 295 objective in the same flood message, since GRASP allows multiple 296 objectives in one Flood message. 298 4. Objective for Stable Connectivity of Network OAM 300 For OAM purposes [I-D.ietf-anima-stable-connectivity], a special- 301 purpose ASA, which we will call the NOC ASA, mediates connectivity 302 between NOC systems performing OAM operations and autonomic nodes 303 that can be reached securely via the ACP. This requires a discovery 304 operation, which could be handled in two ways: the NOC ASA discovers 305 all nodes, or each node discovers the NOC ASA. The latter seems much 306 more practical since nodes might join or leave the network at any 307 time. However, the NOC might need to know something about each 308 target node, so the corresponding objective is defined as a 309 negotiation objective to allow for this: each node can pass data to 310 the NOC in an M_REQ_NEG message, and receive data from the NOC in an 311 M_NEGOTIATE message. 313 An example of the objective is informally: 315 ["AN_NOC", 3, 6, [TBD]] 317 The formal CDDL definition is: 319 noc-objective = ["AN_NOC", objective-flags, loop-count, [TBD]] 321 objective-flags = ; as in the GRASP specification 322 TBD = any ; node information to be defined 324 The objective-flags field is set to indicate negotiation. 326 Dry run mode must not be used. 328 The loop-count is set to a suitable value to limit the scope of 329 discovery. A suggested default value is 6. 331 When a node joins the ACP, one of its initial actions must be to 332 perform GRASP discovery for "AN_NOC" and then to send a Request 333 Negotiate message to the NOC ASA supplying the value TBD. If 334 successfully received, the NOC ASA should reply with a Negotiate 335 message, providing a value TBD in return. This value will inform the 336 requesting node of various NOC parameters. The requesting node must 337 then send an End Negotiate message. From then on, any OAM 338 communication between NOC services and the node in question will 339 proceed over the ACP using the information TBD. 341 5. Flood Frequency 343 Any ASA that floods one of the above objectives should do so at a 344 carefully chosen frequency. Recipient nodes may be starting up, 345 reconnecting, or waking up from sleep, so floods need to be refreshed 346 periodically. On the other hand, excessive flooding will consume 347 bandwidth, CPU and battery capacity throughout the network, and might 348 even resemble a DoS attack. A general guideline is to flood an 349 objective once immediately after its value is initialised or changed, 350 and then repeat the flood at intervals of at least 30 seconds. 351 Additionally, the flooding interval should be slightly jittered to 352 avoid synchronicity with other floods. Finally, the value of a 353 flooded objective should change as rarely as possible (on a timescale 354 of at least minutes, not seconds). 356 6. Security Considerations 358 General security issues for GRASP are covered in 359 [I-D.ietf-anima-grasp]. The objectives "AN_join_proxy" and "AN_ACP" 360 must be implemented using a DULL instance of GRASP. Specific issues 361 not mentioned above are discussed in the referenced drafts for each 362 use case. 364 7. IANA Considerations 366 IANA is requested to add the following entries to the GRASP Objective 367 Names Table registry created by [I-D.ietf-anima-grasp]: 369 AN_join_registrar 370 AN_join_proxy 371 AN_ACP 372 AN_NOC 374 8. Acknowledgements 376 Valuable comments were made by Toerless Eckert, Max Pritikin, and 377 Michael Richardson. 379 9. References 381 9.1. Normative References 383 [I-D.greevenbosch-appsawg-cbor-cddl] 384 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 385 definition language (CDDL): a notational convention to 386 express CBOR data structures", draft-greevenbosch-appsawg- 387 cbor-cddl-11 (work in progress), July 2017. 389 [I-D.ietf-anima-grasp] 390 Bormann, C., Carpenter, B., and B. Liu, "A Generic 391 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 392 grasp-15 (work in progress), July 2017. 394 9.2. Informative References 396 [I-D.ietf-anima-autonomic-control-plane] 397 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 398 Control Plane", draft-ietf-anima-autonomic-control- 399 plane-07 (work in progress), July 2017. 401 [I-D.ietf-anima-bootstrapping-keyinfra] 402 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 403 S., and K. Watsen, "Bootstrapping Remote Secure Key 404 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 405 keyinfra-07 (work in progress), July 2017. 407 [I-D.ietf-anima-reference-model] 408 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 409 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 410 Reference Model for Autonomic Networking", draft-ietf- 411 anima-reference-model-04 (work in progress), July 2017. 413 [I-D.ietf-anima-stable-connectivity] 414 Eckert, T. and M. Behringer, "Using Autonomic Control 415 Plane for Stable Connectivity of Network OAM", draft-ietf- 416 anima-stable-connectivity-03 (work in progress), July 417 2017. 419 Appendix A. Change log [RFC Editor: Please remove] 421 draft-carpenter-anima-ani-objectives-03, 2017-07-16: 423 Align with latest BRSKI and ACP drafts and discussions, various 424 details corrected. 426 draft-carpenter-anima-ani-objectives-02, 2017-06-30: 428 Limited scope to initial ANI components 430 Updated details and removed alternatives 432 draft-carpenter-anima-ani-objectives-01, 2017-02-13: 434 Added prefix management case 436 Updated objectives for BRSKI 438 Editorial corrections 440 draft-carpenter-anima-ani-objectives-00, 2016-11-15: 442 Initial version 444 Authors' Addresses 446 Brian Carpenter 447 Department of Computer Science 448 University of Auckland 449 PB 92019 450 Auckland 1142 451 New Zealand 453 Email: brian.e.carpenter@gmail.com 455 Bing Liu 456 Huawei Technologies Co., Ltd 457 Q22, Huawei Campus 458 No.156 Beiqing Road 459 Hai-Dian District, Beijing 100095 460 P.R. China 462 Email: leo.liubing@huawei.com