idnits 2.17.1 draft-carpenter-anima-ani-objectives-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 : ---------------------------------------------------------------------------- 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 (November 18, 2016) is 2687 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-09 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-08 == Outdated reference: A later version (-05) exists of draft-du-anima-an-intent-04 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-04 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-02 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-01 Summary: 0 errors (**), 0 flaws (~~), 8 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: May 22, 2017 Huawei Technologies Co., Ltd 6 November 18, 2016 8 Technical Objectives for the Autonomic Network Infrastructure 9 draft-carpenter-anima-ani-objectives-00 11 Abstract 13 This document defines several technical objectives for the Generic 14 Autonomic Signaling Protocol (GRASP) for use by components of the 15 Autonomic Networking Infrastructure outlined in the ANIMA reference 16 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 May 22, 2017. 35 Copyright Notice 37 Copyright (c) 2016 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. Flooding Alternative for Proxy . . . . . . . . . . . . . 4 55 2.2. Negotiation Alternative for Proxy . . . . . . . . . . . . 4 56 3. Objective for Autonomic Control Plane . . . . . . . . . . . . 5 57 3.1. Flooding Alternative . . . . . . . . . . . . . . . . . . 5 58 3.2. Negotiation Alternative . . . . . . . . . . . . . . . . . 6 59 4. Objective for Stable Connectivity of Network OAM . . . . . . 7 60 5. Objectives for Intent Distribution . . . . . . . . . . . . . 7 61 6. Objective for Prefix Management . . . . . . . . . . . . . . . 8 62 7. Flood Frequency . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 11.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 This document defines several technical objectives for use with for 75 the Generic Autonomic Signaling Protocol (GRASP) 76 [I-D.ietf-anima-grasp]. They are intended for use by corresponding 77 Autonomic Service Agents (ASAs) that realise infrastructure 78 components of the Autonomic Network Infrastructure (ANI) outlined in 79 the ANIMA reference model [I-D.ietf-anima-reference-model]. Also 80 other early use cases are in scope. 82 Note: This draft is posted to allow systematic discussion of the 83 various objectives in a consistent way. It is quite probable that 84 rather than this being published as an RFC, the various objective 85 definitions will be incorporated directly in the relevant 86 specifications. 88 The reference model identifies several infrastructure components that 89 will fit together to form the ANI, and early use cases for ANIMA are 90 also considered: 92 Secure Bootstrap. 94 Autonomic Control Plane (ACP). 96 Stable Connectivity of Network OAM. 98 Intent Distribution. 100 Prefix Management 102 The following sections define GRASP objectives for each of these 103 cases. They are described an informal object notation and formally 104 using CBOR data definition language (CDDL) 105 [I-D.greevenbosch-appsawg-cbor-cddl]. Undefined CDDL terms are 106 defined in [I-D.ietf-anima-grasp]. 108 2. Objectives for Secure Bootstrap 110 Three components are involved in the Bootstrapping Remote Secure Key 111 Infrastructures (BRSKI) process described in 112 [I-D.ietf-anima-bootstrapping-keyinfra]: the Registrar, the Join 113 Assistant (or Proxy), and the Joining Node (or Pledge). The proxy 114 and the pledge are attached to the same link-layer and use link-local 115 communications only, to minimize exposure to eavesdroppers and 116 malicious nodes. There may be multiple hops between the proxy and 117 the registrar. Therefore, two different GRASP objectives are 118 required: one that is used over an existing secure network between 119 the registrar and the proxy, and another that is used over an 120 insecure link-local hop between the proxy and the pledge. The 121 security aspects and the corresponding limited instances of GRASP are 122 discussed in [I-D.ietf-anima-bootstrapping-keyinfra] and 123 [I-D.ietf-anima-grasp]. 125 Note that since secure bootstrap takes place, by definition, on an 126 incompletely secure network, the use of any protocol needs to be kept 127 as simple and limited as possible. Therefore, only one GRASP message 128 type is used - flooding - to avoid giving away any unnecessary 129 information by any node involved. 131 A registrar announces itself to potential proxies by use of the 132 "AN_registrar" objective. This is a synchronization objective 133 primarily intended to be flooded throughout the network using the 134 GRASP Flood Synchronization (M_FLOOD) message. In accordance with 135 the design of the Flood message, a locator consisting of a specific 136 IP address, IP protocol number and port number will be distributed 137 with the flooded objective. An example of the objective is 138 informally: 140 ["AN_registrar", F_SYNCH, loop_count, [7, "BRSKI-TLS"]] 142 The formal CDDL definition is 144 registrar-objective = ["AN_registrar", F_SYNCH, loop-count, [radius, 145 method]] 146 radius = uint ; loop-count at the source node 147 method = text ; name of the BRSKI method supported 149 The 'radius' parameter allows a proxy that receives this message to 150 determine its distance in hops from the registrar, by subtracting the 151 received 'loop-count' from 'radius'. 153 The 'method' parameter indicates the specific BRSKI method available 154 at the given locator. The initial possible values are "BRSKI-TLS" 155 and "BRSKI-COAP". A registrar that supports more than one method 156 will flood multiple versions of the "AN_registrar" objective. 158 2.1. Flooding Alternative for Proxy 160 A proxy announces itself to potential pledges by use of the 161 "AN_proxy" objective. This is a synchronization objective primarily 162 intended to be flooded on a single link using the GRASP Flood 163 Synchronization (M_FLOOD) message. In accordance with the design of 164 the Flood message, a locator consisting of a specific link-local IP 165 address, IP protocol number and port number will be distributed with 166 the flooded objective. An example of the objective is informally: 168 ["AN_proxy", F_SYNCH, 1, "BRSKI-TLS"] 170 The formal CDDL definition is 172 proxy-objective = ["AN_proxy", F_SYNCH, 1, method] 173 method = text ; name of the BRSKI method supported 175 The loop-count is fixed at 1 since this is a link-local operation. 177 The 'method' parameter indicates the specific BRSKI method available 178 at the given locator. The initial possible values are "BRSKI-TLS" 179 and "BRSKI-COAP". A proxy that supports more than one method will 180 flood multiple versions of the "AN_proxy" objective. 182 2.2. Negotiation Alternative for Proxy 184 This alternative to "AN_proxy" uses additional features of GRASP. It 185 requires additional complexity in the pledge, and requires the pledge 186 to announce its existence to any on-link eavesdroppers via a 187 Discovery message. It is therefore not recommended on security 188 grounds, but is defined here for completeness. 190 A pledge discovers a local proxy and negotiates a BRSKI method with 191 it by use of the "AN_join" objective. First, the pledge performs 192 GRASP discovery, with the loop-count set to 1 and limited to link- 193 local addresses. If multiple responses occur, it chooses one by an 194 implementation-defined method. Then the pledge initiates GRASP 195 negotiation to choose a mutually acceptable BRSKI method. 197 An example of the objective is informally: 199 ["AN_join", F_NEG, 6, ["BRSKI-COAP","BRSKI-TLS"]] 201 The formal CDDL definition is 203 join-objective = ["AN_join", F_NEG, loop-count, [*method]] 204 method = text ; name of the BRSKI method supported 206 The parties will negotiate until one side proposes a single BRSKI 207 method and the other side accepts. In the simplest case of immediate 208 acceptance, there will only be two messages (Request Negotiate and 209 End Negotiate). The locator (IP address, IP protocol number, port 210 number) used for the negotiation will be available for the subsequent 211 BRSKI operations, if required. 213 Note that in the Discovery message, the loop count will be set to 1 214 to limit discovery to the local link. In the negotiation stage, the 215 loop count will serve its normal purpose (limiting the negotiation to 216 6 steps in the above example). 218 3. Objective for Autonomic Control Plane 220 The Autonomic Control Plane (ACP) 221 [I-D.ietf-anima-autonomic-control-plane] constructs itself without 222 outside intervention. To achieve this, each node needs to identify 223 its link-local neighbors on all interfaces, and agree on a secure 224 connection method with each of them. There are at least two possible 225 approaches for this: a flooding mechanism, in which each node 226 announces itself and it security methods to its neighbors, or a 227 discovery and negotiation mechanism, in which each node actively 228 discovers its neighbors. For the moment this draft describes both 229 methods. 231 For either method, each node runs an ASA that supports the 232 corresponding objective. This ASA runs permanently, in order to 233 discover or detect new ACP neighbors or to remove failed neighbors. 235 3.1. Flooding Alternative 237 A node announces itself to potential ACP peers by use of the "AN_ACP" 238 objective. This is a synchronization objective primarily intended to 239 be flooded on a single link using the GRASP Flood Synchronization 240 (M_FLOOD) message. In accordance with the design of the Flood 241 message, a locator consisting of a specific link-local IP address, IP 242 protocol number and port number will be distributed with the flooded 243 objective. An example of the objective is informally: 245 ["AN_ACP", F_SYNCH, 1, "IKEv2"] 247 The formal CDDL definition is 249 acp-objective = ["AN_ACP", F_SYNCH, 1, method] 250 method = text ; name of the connection method supported 252 The loop-count is fixed at 1 since this is a link-local operation. 254 The 'method' parameter indicates the specific connection method 255 available at the given locator. The initial possible values are 256 "IKEv2" and "TLS". A node that supports more than one method will 257 flood multiple versions of the "AN_ACP" objective. 259 Note that a node serving both as an ACP node and BRSKI proxy may 260 choose to distribute the "AN_ACP" objectives and "AN_proxy" 261 objectives in the same message, since GRASP allows multiple 262 objectives in one Flood message. 264 3.2. Negotiation Alternative 266 Each node discovers its neighbours and negotiates a connection method 267 with each one by use of the "AN_ACP" objective. First, the node 268 performs GRASP discovery, with the loop-count set to 1 and limited to 269 link-local addresses. It records each response that it receives 270 within the chosen discovery timeout. Then the pledge initiates GRASP 271 negotiation with each newly discovered peer in turn to choose a 272 mutually acceptable connection method. 274 An example of the objective is informally: 276 ["AN_ACP", F_NEG, 6, ["IKEv2","TLS"]] 278 The formal CDDL definition is 280 acp-objective = ["AN_ACP", F_NEG, loop-count, [*method]] 281 method = text ; name of the connection method supported 283 The parties will negotiate until one side proposes a single 284 connection method and the other side accepts. In the simplest case 285 of immediate acceptance, there will only be two messages (Request 286 Negotiate and End Negotiate). The locator (IP address, IP protocol 287 number, port number) used for the negotiation will be available for 288 the subsequent operations, if required. 290 Note that in the Discovery message, the loop count will be set to 1 291 to limit discovery to the local link. In the negotiation stage, the 292 loop count will serve its normal purpose (limiting the negotiation to 293 6 steps in the above example). 295 4. Objective for Stable Connectivity of Network OAM 297 For OAM purposes [I-D.ietf-anima-stable-connectivity], a special- 298 purpose ASA, which we will call the NOC ASA, mediates connectivity 299 between NOC systems performing OAM operations and autonomic nodes 300 that can be reached securely via the ACP. This is requires s 301 discovery operation, which could be handled in two ways: the NOC ASA 302 discovers all nodes, or each node discovers the NOC ASA. The latter 303 seems much more practical. However, the NOC will need to know 304 something about each target node, so the corresponding objective is 305 defined as a negotiation objective to allow for this. 307 An example of the objective is informally: 309 ["AN_NOC", F_NEG, 6, [TBD]] 311 The formal CDDL definition is 313 noc-objective = ["AN_NOC", F_NEG, loop-count, [TBD]] 314 TBD = any ; node information to be defined 316 When a node joins the ACP, one of its initial actions must be to 317 perform GRASP discovery for "AN_NOC" and then to send a Request 318 Negotiate message to the NOC ASA supplying TBD. If successfully 319 received, the NOC ASA must rely with an End Negotiate message. From 320 then on, any OAM communication between the NOC and the node in 321 question will proceed over the ACP using the information TBD. 323 5. Objectives for Intent Distribution 325 The format and semantics of Intent are not yet defined, although some 326 aspects are discussed in [I-D.du-anima-an-intent]. Here we assume 327 that Intent is supplied to the whole network as a single file and 328 that the file is obtained by each node that needs it via a specific 329 Uniform Resource Identifier, typically a URL. We also assume that 330 Intent, within a given autonomic domain, is qualified by a 331 monotonically increasing version number, so that nodes can determine 332 if their current copy of Intent is out of date. (A timestamp is not 333 used for this purpose, since it would depend on all nodes having 334 consistent clocks.) 336 Thus, a source of Intent announces itself to all nodes by use of the 337 "AN_intent" objective. This is a synchronization objective primarily 338 intended to be flooded using the GRASP Flood Synchronization 339 (M_FLOOD) message. An example of the objective is informally: 341 ["AN_intent", F_SYNCH, loop_count, [12345, "https://noc.example.com/ 342 Intent/"] 344 The formal CDDL definition is 346 intent-objective = ["AN_Intent", F_SYNCH, loop-count, [version- 347 number,uri]] 348 version-number = uint 349 uri = text ; URI conforming to RFC 3986 351 A node that needs to obtain or update Intent will use the latest 352 received version of this objective to check if the version number has 353 increased, and will use the given URI to obtain the current Intent if 354 necessary. 356 6. Objective for Prefix Management 358 TBD 360 7. Flood Frequency 362 Any ASA that floods one of the above objectives should do so at a 363 carefully chosen frequency. Recipient nodes may be starting up, 364 reconnecting, or waking up from sleep, so floods need to be refreshed 365 periodically. On the other hand, excessive flooding will consume 366 bandwidth, CPU and battery capacity throughout the network, and might 367 even resemble a DoS attack. A general guideline is to flood an 368 objective once immediately after its value is initialised or changed, 369 and then repeat the flood at intervals of at least 30 seconds. 370 Additionally, the flooding interval should be slightly jittered to 371 avoid synchronicity with other floods. Finally, the value of a 372 flooded objective should change as rarely as possible (on a timescale 373 of at least minutes, not seconds). 375 8. Security Considerations 377 General security issues for GRASP are covered in 378 [I-D.ietf-anima-grasp]. Specific issues that are not mentioned above 379 are discussed in the referenced drafts for BRSKI, ACP, stable 380 connectivity and Intent. 382 9. IANA Considerations 384 IANA is requested to add the following entries to the GRASP Objective 385 Names Table registry created by [I-D.ietf-anima-grasp]: 386 AN_registrar 387 AN_proxy 388 AN_ACP 389 AN_NOC 390 AN_intent 392 10. Acknowledgements 394 TBD. 396 11. References 398 11.1. Normative References 400 [I-D.greevenbosch-appsawg-cbor-cddl] 401 Vigano, C. and H. Birkholz, "CBOR data definition language 402 (CDDL): a notational convention to express CBOR data 403 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 404 in progress), September 2016. 406 [I-D.ietf-anima-grasp] 407 Bormann, C., Carpenter, B., and B. Liu, "A Generic 408 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 409 grasp-08 (work in progress), October 2016. 411 11.2. Informative References 413 [I-D.du-anima-an-intent] 414 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 415 Behringer, "ANIMA Intent Policy and Format", draft-du- 416 anima-an-intent-04 (work in progress), July 2016. 418 [I-D.ietf-anima-autonomic-control-plane] 419 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 420 Control Plane", draft-ietf-anima-autonomic-control- 421 plane-04 (work in progress), October 2016. 423 [I-D.ietf-anima-bootstrapping-keyinfra] 424 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 425 S., and K. Watsen, "Bootstrapping Remote Secure Key 426 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 427 keyinfra-04 (work in progress), October 2016. 429 [I-D.ietf-anima-reference-model] 430 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 431 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 432 Reference Model for Autonomic Networking", draft-ietf- 433 anima-reference-model-02 (work in progress), July 2016. 435 [I-D.ietf-anima-stable-connectivity] 436 Eckert, T. and M. Behringer, "Using Autonomic Control 437 Plane for Stable Connectivity of Network OAM", draft-ietf- 438 anima-stable-connectivity-01 (work in progress), July 439 2016. 441 Appendix A. Change log [RFC Editor: Please remove] 443 draft-carpenter-anima-ani-objectives-00, 2018-11-15: 445 Initial version 447 Authors' Addresses 449 Brian Carpenter 450 Department of Computer Science 451 University of Auckland 452 PB 92019 453 Auckland 1142 454 New Zealand 456 Email: brian.e.carpenter@gmail.com 458 Bing Liu 459 Huawei Technologies Co., Ltd 460 Q14, Huawei Campus 461 No.156 Beiqing Road 462 Hai-Dian District, Beijing 100095 463 P.R. China 465 Email: leo.liubing@huawei.com