idnits 2.17.1 draft-carpenter-anima-ani-objectives-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2017) is 2622 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-09 == 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-05 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 == Outdated reference: A later version (-07) exists of draft-ietf-anima-prefix-management-02 == 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-02 Summary: 1 error (**), 0 flaws (~~), 9 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: August 17, 2017 Huawei Technologies Co., Ltd 6 February 13, 2017 8 Technical Objective Formats for the Autonomic Network Infrastructure 9 draft-carpenter-anima-ani-objectives-01 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. It also covers other initial use cases for 17 Autonomic Networking. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 17, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Objectives for Secure Bootstrap . . . . . . . . . . . . . . . 3 55 2.1. Flooded Objective for Join Registrar . . . . . . . . . . 4 56 2.2. Negotiation Alternative for Join Registrar . . . . . . . 5 57 2.3. Flooded Objective for Join Assistant . . . . . . . . . . 5 58 3. Objective for Autonomic Control Plane . . . . . . . . . . . . 6 59 3.1. Flooding Alternative . . . . . . . . . . . . . . . . . . 6 60 3.2. Negotiation Alternative . . . . . . . . . . . . . . . . . 7 61 4. Objective for Stable Connectivity of Network OAM . . . . . . 8 62 5. Objective for Intent Distribution . . . . . . . . . . . . . . 8 63 6. Objectives for Prefix Management . . . . . . . . . . . . . . 9 64 7. Flood Frequency . . . . . . . . . . . . . . . . . . . . . . . 10 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 11.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 This document defines several technical objectives for use with for 77 the Generic Autonomic Signaling Protocol (GRASP) 78 [I-D.ietf-anima-grasp]. They are intended for use by corresponding 79 Autonomic Service Agents (ASAs) that support infrastructure 80 components of the Autonomic Network Infrastructure (ANI) outlined in 81 the ANIMA reference model [I-D.ietf-anima-reference-model]. Also 82 other early use cases are in scope. 84 Note: This draft is posted to allow systematic discussion of the 85 various objectives in a consistent way. It is quite probable that 86 rather than this being published as an RFC, the various objective 87 definitions will be incorporated directly in the relevant 88 specifications. 90 The reference model identifies several infrastructure components that 91 will fit together to form the ANI, and other early use cases for 92 ANIMA are also considered: 94 Secure Bootstrap. 96 Autonomic Control Plane (ACP). 98 Stable Connectivity of Network OAM. 100 Intent Distribution. 102 Prefix Management 104 The following sections define GRASP objectives for each of these 105 cases. They are described in an informal object notation and 106 formally using CBOR data definition language (CDDL) 107 [I-D.greevenbosch-appsawg-cbor-cddl]. Undefined CDDL terms are 108 defined in [I-D.ietf-anima-grasp]. 110 2. Objectives for Secure Bootstrap 112 Three ANI components are involved in the Bootstrapping Remote Secure 113 Key Infrastructures (BRSKI) process described in 114 [I-D.ietf-anima-bootstrapping-keyinfra]: the Join Registrar, the Join 115 Assistant (or Proxy), and the Pledge (or Joining Node). In the 116 present document we only consider interactions between autonomic 117 nodes involved in BRSKI; non-autonomic nodes are expected to use 118 different methods not involving GRASP. 120 Note that since secure bootstrap takes place, by definition, on an 121 incompletely secure network, the use of any protocol needs to be kept 122 as simple and limited as possible. Therefore, only one GRASP message 123 type is used - flooding - to avoid giving away any unnecessary 124 information by any node involved. 126 Operationally, the most simple case is when proxy and pledge have a 127 link-local connection between them. In this case, mutual discovery 128 and bootstrap can happen without any prior provisioning of helper 129 information by an external mechanism. Instead, link-local multicast 130 with GRASP can and will be used. This will minimize exposure to 131 eavesdroppers and malicious nodes. On the other hand, there may be 132 multiple physical hops between the proxy and the registrar. 133 Therefore, two different GRASP objectives are required: one that is 134 used over an existing secure network (typically the ACP) between the 135 registrar and the proxy, and another that is used over an insecure 136 link-local hop between the proxy and the pledge. The security 137 aspects and the corresponding limited instances of GRASP are 138 discussed in [I-D.ietf-anima-bootstrapping-keyinfra] and 139 [I-D.ietf-anima-grasp]. 141 2.1. Flooded Objective for Join Registrar 143 A registrar announces itself to potential proxies by use of the 144 "AN_join_registrar" objective. This is a synchronization objective 145 primarily intended to be flooded throughout the network using the 146 GRASP Flood Synchronization (M_FLOOD) message. In accordance with 147 the design of the Flood message, a locator consisting of a specific 148 IP address, IP protocol number and port number will be distributed 149 with the flooded objective. An example of the objective is 150 informally: 152 ["AN_join_registrar", F_SYNCH, 5, [7, ["BRSKI-TLS"]]] 154 The formal CDDL definition is 156 registrar-objective = ["AN_join_registrar", F_SYNCH, loop-count, 157 [max-hops, [*method]]] 159 max-hops = uint ; loop-count at the source node 161 method = text ; name of the BRSKI method supported 163 The 'max-hops' parameter allows a proxy that receives this message to 164 determine its distance in hops from the registrar, by subtracting the 165 received 'loop-count' from 'max-hops'. (Note: it is an open issue 166 whether to include this parameter. Its value would be to allow a 167 proxy to choose the nearest of several registrars.) 169 The 'method' parameter indicates the specific BRSKI method(s) 170 available at the given locator. The initial possible values are 171 "BRSKI-TLS" and "BRSKI-COAP". A registrar that supports one method 172 per locator may flood multiple versions of the "AN_join_registrar" 173 objective. 175 A different objective can be flooded for each method to support the 176 case where independent ASAs are providing the registrar function for 177 different methods, or to support the case where different locators 178 support each method. For example, BRSKI-COAP would most likely be 179 focussed to help enrol non-autonomic pledges and could have a range 180 of aspects that would make implementation in a separate ASA 181 beneficial (e.g., different scale/policies for non-autonomic 182 pledges). Alternatively, several methods supported by a single 183 registrar at a single locator can be flooded as a single objective. 185 2.2. Negotiation Alternative for Join Registrar 187 This alternative usage of "AN_join_registrar" uses additional 188 features of GRASP. It requires additional complexity in the Join 189 Assistant, and causes it to announce its existence to any 190 eavesdroppers in the autonomic network via a multicast Discovery 191 message. It must therefore only be used when GRASP is running 192 securely, typically because the Join Assistant is in a node that has 193 already joined the ACP. 195 A Join Assistant discovers a Join Registrar and negotiates a BRSKI 196 method with it by use of the "AN_join_registrar" objective. First, 197 the pledge performs GRASP discovery. If multiple responses occur, it 198 chooses one by an implementation-defined method. Then the pledge 199 initiates GRASP negotiation to choose a mutually acceptable BRSKI 200 method. 202 An example of the objective is informally: 204 ["AN_join_registrar", F_NEG, 6, ["BRSKI-COAP","BRSKI-TLS"]] 206 The formal CDDL definition is: 208 registrar-objective = ["AN_join_registrar", F_NEG, loop-count, [*method]] 210 method = text ; name of the BRSKI method supported 212 The parties will negotiate until one side proposes a single BRSKI 213 method and the other side accepts. In the simplest case of immediate 214 acceptance, there will only be two messages (Request Negotiate and 215 End Negotiate). The locator (IP address, IP protocol number, port 216 number) used for the negotiation will be available for the subsequent 217 BRSKI operations, if required. 219 2.3. Flooded Objective for Join Assistant 221 A Join Assistant announces itself to potential pledges by use of the 222 "AN_join_assistant" objective. This is a synchronization objective 223 primarily intended to be flooded on a single link using the GRASP 224 Flood Synchronization (M_FLOOD) message. In accordance with the 225 design of the Flood message, a locator consisting of a specific link- 226 local IP address, IP protocol number and port number will be 227 distributed with the flooded objective. An example of the objective 228 is informally: 230 ["AN_join_assistant", F_SYNCH, 1, "BRSKI-TLS"] 232 The formal CDDL definition is: 234 assistant-objective = ["AN_join_assistant", F_SYNCH, 1, method] 236 method = text ; name of the BRSKI method supported 238 The loop-count is fixed at 1 since this is a link-local operation. 240 The 'method' parameter indicates the specific BRSKI method available 241 at the given locator. The initial possible values are "BRSKI-TLS" 242 and "BRSKI-COAP". A Join Assistant that supports more than one 243 method will flood multiple versions of the "AN_join_assistant" 244 objective. 246 3. Objective for Autonomic Control Plane 248 The Autonomic Control Plane (ACP) 249 [I-D.ietf-anima-autonomic-control-plane] constructs itself without 250 outside intervention. To achieve this, each node needs to identify 251 its link-local neighbors on all interfaces, and agree on a secure 252 connection method with each of them. There are at least two possible 253 approaches for this: a flooding mechanism, in which each node 254 announces itself and it security methods to its neighbors, or a 255 discovery and negotiation mechanism, in which each node actively 256 discovers its neighbors. For the moment this draft describes both 257 methods. 259 For either method, each node runs an ASA that supports the 260 corresponding objective. This ASA permanently, as long as the node 261 is capable of being part of the ACP, in order to discover or detect 262 new ACP neighbors or to remove failed neighbors. 264 3.1. Flooding Alternative 266 A node announces itself to potential ACP peers by use of the "AN_ACP" 267 objective. This is a synchronization objective primarily intended to 268 be flooded on a single link using the GRASP Flood Synchronization 269 (M_FLOOD) message. In accordance with the design of the Flood 270 message, a locator consisting of a specific link-local IP address, IP 271 protocol number and port number will be distributed with the flooded 272 objective. An example of the objective is informally: 274 ["AN_ACP", F_SYNCH, 1, ["IKEv2","TLS"] 276 The formal CDDL definition is: 278 acp-objective = ["AN_ACP", F_SYNCH, 1, [*method]] 280 method = text ; name of the connection method supported 282 The loop-count is fixed at 1 since this is a link-local operation. 284 The 'method' parameter indicates the specific connection method 285 available at the given locator. The initial possible values are 286 "IKEv2", "GRE-IKEv2", "TLS" and "dTLS". A node that supports more 287 than one method per locator may flood multiple versions of the 288 "AN_ACP" objective. 290 Note that a node serving both as an ACP node and BRSKI Join Assistant 291 may choose to distribute the "AN_ACP" objective and 292 "AN_join_assistant" objective in the same message, since GRASP allows 293 multiple objectives in one Flood message. 295 3.2. Negotiation Alternative 297 Each node discovers its neighbours and negotiates a connection method 298 with each one by use of the "AN_ACP" objective. First, the node 299 performs GRASP discovery, with the loop-count set to 1 and limited to 300 link-local addresses. It records each response that it receives 301 within the chosen discovery timeout. Then the pledge initiates GRASP 302 negotiation with each newly discovered peer in turn to choose a 303 mutually acceptable connection method. 305 An example of the objective is informally: 307 ["AN_ACP", F_NEG, 6, ["IKEv2","dTLS"]] 309 The formal CDDL definition is: 311 acp-objective = ["AN_ACP", F_NEG, loop-count, [*method]] 313 method = text ; name of the connection method supported 315 The parties will negotiate until one side proposes a single 316 connection method and the other side accepts. In the simplest case 317 of immediate acceptance, there will only be two messages (Request 318 Negotiate and End Negotiate). The locator (IP address, IP protocol 319 number, port number) used for the negotiation will be available for 320 the subsequent operations, if required. 322 Note that in the Discovery message, the loop count will be set to 1 323 to limit discovery to the local link. In the negotiation stage, the 324 loop count will serve its normal purpose (limiting the negotiation to 325 6 steps in the above example). 327 4. Objective for Stable Connectivity of Network OAM 329 For OAM purposes [I-D.ietf-anima-stable-connectivity], a special- 330 purpose ASA, which we will call the NOC ASA, mediates connectivity 331 between NOC systems performing OAM operations and autonomic nodes 332 that can be reached securely via the ACP. This requires a discovery 333 operation, which could be handled in two ways: the NOC ASA discovers 334 all nodes, or each node discovers the NOC ASA. The latter seems much 335 more practical. However, the NOC will need to know something about 336 each target node, so the corresponding objective is defined as a 337 negotiation objective to allow for this. 339 An example of the objective is informally: 341 ["AN_NOC", F_NEG, 6, [TBD]] 343 The formal CDDL definition is: 345 noc-objective = ["AN_NOC", F_NEG, loop-count, [TBD]] 347 TBD = any ; node information to be defined 349 When a node joins the ACP, one of its initial actions must be to 350 perform GRASP discovery for "AN_NOC" and then to send a Request 351 Negotiate message to the NOC ASA supplying TBD. If successfully 352 received, the NOC ASA must reply with an End Negotiate message. From 353 then on, any OAM communication between the NOC and the node in 354 question will proceed over the ACP using the information TBD. 356 5. Objective for Intent Distribution 358 The format and semantics of Intent are not yet defined, although some 359 aspects are discussed in [I-D.du-anima-an-intent]. Here we assume 360 that Intent is supplied to the whole network as a single file and 361 that the file is obtained by each node that needs it via a specific 362 Uniform Resource Identifier, typically a URL. We also assume that 363 Intent, within a given autonomic domain, is qualified by a 364 monotonically increasing version number, so that nodes can determine 365 if their current copy of Intent is out of date. (A timestamp is not 366 used for this purpose, since it would depend on all nodes having 367 consistent clocks.) 369 Thus, an Intent repository announces itself to all nodes by use of 370 the "AN_intent_repo" objective. This is a synchronization objective 371 primarily intended to be flooded using the GRASP Flood 372 Synchronization (M_FLOOD) message. An example of the objective is 373 informally: 375 ["AN_intent_repo", F_SYNCH, 6, 376 [12345, "https://noc.example.com/Intent/"]] 378 The formal CDDL definition is: 380 intent-objective = ["AN_intent_repo", F_SYNCH, loop-count, 381 [version-number,uri]] 383 version-number = uint 384 uri = text ; URI conforming to RFC 3986 386 A node that needs to obtain or update Intent will use the latest 387 received version of this objective to check if the version number has 388 increased, and will use the given URI to obtain the current Intent if 389 necessary. 391 6. Objectives for Prefix Management 393 An ASA for IPv6 prefix management is described in 394 [I-D.ietf-anima-prefix-management]. It requires two GRASP objectives. 395 An example of the first objective is informally: 397 ["PrefixManager", F_NEG, 6, 398 [True, 56, 0x20010db8f000ba000000000000000000]] 400 The formal CDDL definition is: 402 objective = ["PrefixManager", F_NEG, loop-count, 403 [PD-support, length, ?prefix]] 405 PD-support = true / false ; indicates whether sender supports PD 406 length = 0..128 ; requested or offered prefix length 407 prefix = bytes .size 16 ; prefix in binary format 409 The second objective is intended for flooding out non-default 410 parameters for prefix management: 412 objective = ["PrefixManager.Params", objective-flags, text] 414 loop-count = 0..255 ; as in the GRASP specification 415 objective-flags /= ; as in the GRASP specification 417 ;The text object would be the relevant parameter definitions 418 ;transmitted as a single string with all whitespace and 419 ;format characters removed. 421 7. Flood Frequency 423 Any ASA that floods one of the above objectives should do so at a 424 carefully chosen frequency. Recipient nodes may be starting up, 425 reconnecting, or waking up from sleep, so floods need to be refreshed 426 periodically. On the other hand, excessive flooding will consume 427 bandwidth, CPU and battery capacity throughout the network, and might 428 even resemble a DoS attack. A general guideline is to flood an 429 objective once immediately after its value is initialised or changed, 430 and then repeat the flood at intervals of at least 30 seconds. 431 Additionally, the flooding interval should be slightly jittered to 432 avoid synchronicity with other floods. Finally, the value of a 433 flooded objective should change as rarely as possible (on a timescale 434 of at least minutes, not seconds). 436 8. Security Considerations 438 General security issues for GRASP are covered in 439 [I-D.ietf-anima-grasp]. Specific issues that are not mentioned above 440 are discussed in the referenced drafts for each use case. 442 9. IANA Considerations 444 IANA is requested to add the following entries to the GRASP Objective 445 Names Table registry created by [I-D.ietf-anima-grasp]: 447 AN_join_registrar 448 AN_join_assistant 449 AN_ACP 450 AN_NOC 451 AN_intent_repo 452 PrefixManager 453 PrefixManager.Params 455 10. Acknowledgements 457 Toerless Eckert, Max Pritikin, Michael Richardson 459 11. References 461 11.1. Normative References 463 [I-D.greevenbosch-appsawg-cbor-cddl] 464 Vigano, C. and H. Birkholz, "CBOR data definition language 465 (CDDL): a notational convention to express CBOR data 466 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 467 in progress), September 2016. 469 [I-D.ietf-anima-grasp] 470 Bormann, C., Carpenter, B., and B. Liu, "A Generic 471 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 472 grasp-09 (work in progress), December 2016. 474 11.2. Informative References 476 [I-D.du-anima-an-intent] 477 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 478 Behringer, "ANIMA Intent Policy and Format", draft-du- 479 anima-an-intent-04 (work in progress), July 2016. 481 [I-D.ietf-anima-autonomic-control-plane] 482 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 483 Control Plane", draft-ietf-anima-autonomic-control- 484 plane-05 (work in progress), January 2017. 486 [I-D.ietf-anima-bootstrapping-keyinfra] 487 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 488 S., and K. Watsen, "Bootstrapping Remote Secure Key 489 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 490 keyinfra-04 (work in progress), October 2016. 492 [I-D.ietf-anima-prefix-management] 493 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 494 IPv6 Edge Prefix Management in Large-scale Networks", 495 draft-ietf-anima-prefix-management-02 (work in progress), 496 January 2017. 498 [I-D.ietf-anima-reference-model] 499 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 500 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 501 Reference Model for Autonomic Networking", draft-ietf- 502 anima-reference-model-02 (work in progress), July 2016. 504 [I-D.ietf-anima-stable-connectivity] 505 Eckert, T. and M. Behringer, "Using Autonomic Control 506 Plane for Stable Connectivity of Network OAM", draft-ietf- 507 anima-stable-connectivity-02 (work in progress), February 508 2017. 510 Appendix A. Change log [RFC Editor: Please remove] 512 draft-carpenter-anima-ani-objectives-01, 2017-02-13: 514 Added prefix management case 516 Updated objectives for BRSKI 517 Editorial corrections 519 draft-carpenter-anima-ani-objectives-00, 2016-11-15: 521 Initial version 523 Authors' Addresses 525 Brian Carpenter 526 Department of Computer Science 527 University of Auckland 528 PB 92019 529 Auckland 1142 530 New Zealand 532 Email: brian.e.carpenter@gmail.com 534 Bing Liu 535 Huawei Technologies Co., Ltd 536 Q22, Huawei Campus 537 No.156 Beiqing Road 538 Hai-Dian District, Beijing 100095 539 P.R. China 541 Email: leo.liubing@huawei.com