idnits 2.17.1 draft-ietf-anima-grasp-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 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2015) is 3123 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 (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-06 ** Downref: Normative reference to an Informational draft: draft-greevenbosch-appsawg-cbor-cddl (ref. 'I-D.greevenbosch-appsawg-cbor-cddl') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-04) exists of draft-behringer-anima-reference-model-03 == Outdated reference: A later version (-02) exists of draft-eckert-anima-stable-connectivity-01 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-00 == Outdated reference: A later version (-12) exists of draft-ietf-homenet-dncp-10 == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-09 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-07 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track B. Carpenter, Ed. 5 Expires: April 11, 2016 Univ. of Auckland 6 B. Liu, Ed. 7 Huawei Technologies Co., Ltd 8 October 9, 2015 10 A Generic Autonomic Signaling Protocol (GRASP) 11 draft-ietf-anima-grasp-01 13 Abstract 15 This document establishes requirements for a signaling protocol that 16 enables autonomic devices and autonomic service agents to dynamically 17 discover peers, to synchronize state with them, and to negotiate 18 parameter settings mutually with them. The document then defines a 19 general protocol for discovery, synchronization and negotiation, 20 while the technical objectives for specific scenarios are to be 21 described in separate documents. An Appendix briefly discusses 22 existing protocols with comparable features. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 11, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirement Analysis of Discovery, Synchronization and 60 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Requirements for Discovery . . . . . . . . . . . . . . . 4 62 2.2. Requirements for Synchronization and Negotiation 63 Capability . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Specific Technical Requirements . . . . . . . . . . . . . 8 65 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 9 66 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 11 68 3.3. GRASP Protocol Basic Properties and Mechanisms . . . . . 15 69 3.3.1. Required External Security Mechanism . . . . . . . . 15 70 3.3.2. Transport Layer Usage . . . . . . . . . . . . . . . . 15 71 3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16 72 3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 18 73 3.3.5. Synchronization Procedure . . . . . . . . . . . . . . 19 74 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 20 75 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 20 76 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 21 77 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 21 78 3.7.1. GRASP Message Format . . . . . . . . . . . . . . . . 21 79 3.7.2. Discovery Message . . . . . . . . . . . . . . . . . . 22 80 3.7.3. Response Message . . . . . . . . . . . . . . . . . . 23 81 3.7.4. Request Message . . . . . . . . . . . . . . . . . . . 23 82 3.7.5. Negotiation Message . . . . . . . . . . . . . . . . . 24 83 3.7.6. Negotiation-ending Message . . . . . . . . . . . . . 24 84 3.7.7. Confirm-waiting Message . . . . . . . . . . . . . . . 25 85 3.8. GRASP General Options . . . . . . . . . . . . . . . . . . 25 86 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 25 87 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 25 88 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 26 89 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 26 90 3.8.5. Waiting Time Option . . . . . . . . . . . . . . . . . 27 91 3.8.6. Device Identity Option . . . . . . . . . . . . . . . 27 92 3.8.7. Locator Options . . . . . . . . . . . . . . . . . . . 27 93 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 29 94 3.9.1. Format of Objective Options . . . . . . . . . . . . . 29 95 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 30 96 3.9.3. General Considerations for Objective Options . . . . 30 97 3.9.4. Organizing of Objective Options . . . . . . . . . . . 31 98 3.9.5. Experimental and Example Objective Options . . . . . 32 99 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 101 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 38 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 104 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 42 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 107 10.2. Informative References . . . . . . . . . . . . . . . . . 44 108 Appendix A. Capability Analysis of Current Protocols . . . . . . 48 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 111 1. Introduction 113 The success of the Internet has made IP-based networks bigger and 114 more complicated. Large-scale ISP and enterprise networks have 115 become more and more problematic for human based management. Also, 116 operational costs are growing quickly. Consequently, there are 117 increased requirements for autonomic behavior in the networks. 118 General aspects of autonomic networks are discussed in [RFC7575] and 119 [RFC7576]. A reference model for autonomic networking is given in 120 [I-D.behringer-anima-reference-model]. In order to fulfil autonomy, 121 devices that embody autonomic service agents have specific signaling 122 requirements. In particular they need to discover each other, to 123 synchronize state with each other, and to negotiate parameters and 124 resources directly with each other. There is no restriction on the 125 type of parameters and resources concerned, which include very basic 126 information needed for addressing and routing, as well as anything 127 else that might be configured in a conventional non-autonomic 128 network. The atomic unit of synchronization or negotiation is 129 referred to as a technical objective, i.e, a configurable parameter 130 or set of parameters (defined more precisely in Section 3.1). 132 Following this Introduction, Section 2 describes the requirements for 133 discovery, synchronization and negotiation. Negotiation is an 134 iterative process, requiring multiple message exchanges forming a 135 closed loop between the negotiating devices. State synchronization, 136 when needed, can be regarded as a special case of negotiation, 137 without iteration. Section 3.2 describes a behavior model for a 138 protocol intended to support discovery, synchronization and 139 negotiation. The design of GeneRic Autonomic Signaling Protocol 140 (GRASP) in Section 3 of this document is mainly based on this 141 behavior model. The relevant capabilities of various existing 142 protocols are reviewed in Appendix A. 144 The proposed discovery mechanism is oriented towards synchronization 145 and negotiation objectives. It is based on a neighbor discovery 146 process, but also supports diversion to off-link peers. Although 147 many negotiations will occur between horizontally distributed peers, 148 many target scenarios are hierarchical networks, which is the 149 predominant structure of current large-scale managed networks. 150 However, when a device starts up with no pre-configuration, it has no 151 knowledge of the topology. The protocol itself is capable of being 152 used in a small and/or flat network structure such as a small office 153 or home network as well as a professionally managed network. 154 Therefore, the discovery mechanism needs to be able to allow a device 155 to bootstrap itself without making any prior assumptions about 156 network structure. 158 Because GRASP can be used to perform a decision process among 159 distributed devices or between networks, it must run in a secure and 160 strongly authenticated environment. 162 It is understood that in realistic deployments, not all devices will 163 support GRASP. It is expected that some autonomic service agents 164 will directly manage a group of non-autonomic nodes, and that other 165 non-autonomic nodes will be managed traditionally. Such mixed 166 scenarios are not discussed in this specification. 168 2. Requirement Analysis of Discovery, Synchronization and Negotiation 170 This section discusses the requirements for discovery, negotiation 171 and synchronization capabilities. The primary user of the protocol 172 is an autonomic service agent (ASA), so the requirements are mainly 173 expressed as the features needed by an ASA. A single physical device 174 might contain several ASAs, and a single ASA might manage several 175 technical objectives. 177 Note that requirements for ASAs themselves, such as the processing of 178 Intent [RFC7575] or interfaces for coordination between ASAs are out 179 of scope for the present document. 181 2.1. Requirements for Discovery 183 1. ASAs may be designed to manage anything, as required in 184 Section 2.2. A basic requirement is therefore that the protocol can 185 represent and discover any kind of technical objective among 186 arbitrary subsets of participating nodes. 188 In an autonomic network we must assume that when a device starts up 189 it has no information about any peer devices, the network structure, 190 or what specific role it must play. The ASA(s) inside the device are 191 in the same situation. In some cases, when a new application session 192 starts up within a device, the device or ASA may again lack 193 information about relevant peers. It might be necessary to set up 194 resources on multiple other devices, coordinated and matched to each 195 other so that there is no wasted resource. Security settings might 196 also need updating to allow for the new device or user. The relevant 197 peers may be different for different technical objectives. Therefore 198 discovery needs to be repeated as often as necessary to find peers 199 capable of acting as counterparts for each objective that a discovery 200 initiator needs to handle. From this background we derive the next 201 three requirements: 203 2. When an ASA first starts up, it has no knowledge of the specific 204 network to which it is attached. Therefore the discovery process 205 must be able to support any network scenario, assuming only that the 206 device concerned is bootstrapped from factory condition. 208 3. When an ASA starts up, it must require no information about any 209 peers in order to discover them. 211 4. If an ASA supports multiple technical objectives, relevant peers 212 may be different for different discovery objectives, so discovery 213 needs to be repeated to find counterparts for each objective. Thus, 214 there must be a mechanism by which an ASA can separately discover 215 peer ASAs for each of the technical objectives that it needs to 216 manage, whenever necessary. 218 5. Following discovery, an ASA will normally perform negotiation or 219 synchronization for the corresponding objectives. The design should 220 allow for this by associating discovery, negotiation and 221 synchronization objectives. It may provide an optional mechanism to 222 combine discovery and negotiation/synchronization in a single call. 224 6. Some objectives may only be significant on the local link, but 225 others may be significant across the routed network and require off- 226 link operations. Thus, the relevant peers might be immediate 227 neighbors on the same layer 2 link, or they might be more distant and 228 only accessible via layer 3. The mechanism must therefore provide 229 both on-link and off-link discovery of ASAs supporting specific 230 technical objectives. 232 7. The discovery process should be flexible enough to allow for 233 special cases, such as the following: 235 o In some networks, as mentioned above, there will be some 236 hierarchical structure, at least for certain synchronization or 237 negotiation objectives, but this is unknown in advance. The 238 discovery protocol must therefore operate regardless of 239 hierarchical structure, which is an attribute of individual 240 technical objectives and not of the autonomic network as a whole. 241 This is part of the more general requirement to discover off-link 242 peers. 244 o During initialisation, a device must be able to establish mutual 245 trust with the rest of the network and join an authentication 246 mechanism. Although this will inevitably start with a discovery 247 action, it is a special case precisely because trust is not yet 248 established. This topic is the subject of 249 [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once 250 trust has been established for a device, all ASAs within the 251 device inherit the device's credentials and are also trusted. 253 o Depending on the type of network involved, discovery of other 254 central functions might be needed, such as the Network Operations 255 Center (NOC) [I-D.eckert-anima-stable-connectivity]. The protocol 256 must be capable of supporting such discovery during 257 initialisation, as well as discovery during ongoing operation. 259 8. The discovery process must not generate excessive (multicast) 260 traffic and must take account of sleeping nodes in the case of a 261 resource-constrained network [RFC7228]. 263 2.2. Requirements for Synchronization and Negotiation Capability 265 As background, consider the example of routing protocols, the closest 266 approximation to autonomic networking already in widespread use. 267 Routing protocols use a largely autonomic model based on distributed 268 devices that communicate repeatedly with each other. The focus is 269 reachability, so current routing protocols mainly consider simple 270 link status, i.e., up or down, and an underlying assumption is that 271 all nodes need a consistent view of the network topology in order for 272 the routing algorithm to converge. Thus, routing is mainly based on 273 information synchronization between peers, rather than on bi- 274 directional negotiation. Other information, such as latency, 275 congestion, capacity, and particularly unused capacity, would be 276 helpful to get better path selection and utilization rate, but is not 277 normally used in distributed routing algorithms. Additionally, 278 autonomic networks need to be able to manage many more dimensions, 279 such as security settings, power saving, load balancing, etc. Status 280 information and traffic metrics need to be shared between nodes for 281 dynamic adjustment of resources and for monitoring purposes. While 282 this might be achieved by existing protocols when they are available, 283 the new protocol needs to be able to support parameter exchange, 284 including mutual synchronization, even when no negotiation as such is 285 required. In general, these parameters do not apply to all 286 participating nodes, but only to a subset. 288 9. A basic requirement for the protocol is therefore the ability to 289 represent, discover, synchronize and negotiate almost any kind of 290 network parameter among arbitrary subsets of participating nodes. 292 10. Negotiation is a request/response process that must be 293 guaranteed to terminate (with success or failure) and if necessary it 294 must contain tie-breaking rules for each technical objective that 295 requires them. While these must be defined specifically for each use 296 case, the protocol should have some general mechanisms in support of 297 loop and deadlock prevention, such as hop count limits or timeouts. 299 11. Synchronization might concern small groups of nodes or very 300 large groups. Different solutions might be needed at different 301 scales. 303 12. To avoid "reinventing the wheel", the protocol should be able to 304 carry the message formats used by existing configuration protocols 305 (such as NETCONF/YANG) in cases where that is convenient. 307 13. Human intervention in complex situations is costly and error- 308 prone. Therefore, synchronization or negotiation of parameters 309 without human intervention is desirable whenever the coordination of 310 multiple devices can improve overall network performance. It 311 therefore follows that the protocol, as part of the Autonomic 312 Networking Infrastructure, must be capable of running in any device 313 that would otherwise need human intervention. 315 14. Human intervention in large networks is often replaced by use of 316 a top-down network management system (NMS). It therefore follows 317 that the protocol, as part of the Autonomic Networking 318 Infrastructure, must be capable of running in any device that would 319 otherwise be managed by an NMS, and that it can co-exist with an NMS, 320 and with protocols such as SNMP and NETCONF. 322 15. Some features are expected to be implemented by individual ASAs, 323 but the protocol must be general enough to allow them: 325 o Dependencies and conflicts: In order to decide a configuration on 326 a given device, the device may need information from neighbors. 327 This can be established through the negotiation procedure, or 328 through synchronization if that is sufficient. However, a given 329 item in a neighbor may depend on other information from its own 330 neighbors, which may need another negotiation or synchronization 331 procedure to obtain or decide. Therefore, there are potential 332 dependencies and conflicts among negotiation or synchronization 333 procedures. Resolving dependencies and conflicts is a matter for 334 the individual ASAs involved. To allow this, there need to be 335 clear boundaries and convergence mechanisms for negotiations. 337 Also some mechanisms are needed to avoid loop dependencies. In 338 such a case, the protocol's role is limited to signaling between 339 ASAs. 341 o Recovery from faults and identification of faulty devices should 342 be as automatic as possible. The protocol's role is limited to 343 the ability to handle discovery, synchronization and negotiation 344 at any time, in case an ASA detects an anomaly such as a 345 negotiation counterpart failing. 347 o Since the goal is to minimize human intervention, it is necessary 348 that the network can in effect "think ahead" before changing its 349 parameters. In other words there must be a possibility of 350 forecasting the effect of a change by a "dry run" mechanism before 351 actually installing the change. This will be an application of 352 the protocol rather than a feature of the protocol itself. 354 o Management logging, monitoring, alerts and tools for intervention 355 are required. However, these can only be features of individual 356 ASAs. Another document [I-D.eckert-anima-stable-connectivity] 357 discusses how such agents may be linked into conventional OAM 358 systems via an Autonomic Control Plane 359 [I-D.ietf-anima-autonomic-control-plane]. 361 16. The protocol will be able to deal with a wide variety of 362 technical objectives, covering any type of network parameter. 363 Therefore the protocol will need either an explicit information model 364 describing its messages, or at least a flexible and easily extensible 365 message format. One design consideration is whether to adopt an 366 existing information model or to design a new one. 368 2.3. Specific Technical Requirements 370 17. It should be convenient for ASA designers to define new 371 technical objectives and for programmers to express them, without 372 excessive impact on run-time efficiency and footprint. The classes 373 of device in which the protocol might run is discussed in 374 [I-D.behringer-anima-reference-model]. 376 18. The protocol should be easily extensible in case the initially 377 defined discovery, synchronization and negotiation mechanisms prove 378 to be insufficient. 380 19. To be a generic platform, the protocol payload format should be 381 independent of the transport protocol or IP version. In particular, 382 it should be able to run over IPv6 or IPv4. However, some functions, 383 such as multicasting or broadcasting on a link, might need to be IP 384 version dependent. In case of doubt, IPv6 should be preferred. 386 20. The protocol must be able to access off-link counterparts via 387 routable addresses, i.e., must not be restricted to link-local 388 operation. 390 21. It must also be possible for an external discovery mechanism to 391 be used, if appropriate for a given technical objective. In other 392 words, GRASP discovery must not be a prerequisite for GRASP 393 negotiation or synchronization; the prerequisite is discovering a 394 peer's locator by any method. 396 22. ASAs and the signaling protocol engine need to run 397 asynchronously when wait states occur. 399 23. Intent: There must be provision for general Intent rules to be 400 applied by all devices in the network (e.g., security rules, prefix 401 length, resource sharing rules). However, Intent distribution might 402 not use the signaling protocol itself, but its design should not 403 exclude such use. 405 24. Management monitoring, alerts and intervention: Devices should 406 be able to report to a monitoring system. Some events must be able 407 to generate operator alerts and some provision for emergency 408 intervention must be possible (e.g. to freeze synchronization or 409 negotiation in a mis-behaving device). These features might not use 410 the signaling protocol itself, but its design should not exclude such 411 use. 413 25. The protocol needs to be fully secured against forged messages 414 and man-in-the middle attacks, and secured as much as reasonably 415 possible against denial of service attacks. It needs to be capable 416 of encryption in order to resist unwanted monitoring, although this 417 capability may not be required in all deployments. However, it is 418 not required that the protocol itself provides these security 419 features; it may depend on an existing secure environment. 421 3. GRASP Protocol Overview 423 3.1. Terminology 425 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 426 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 427 "OPTIONAL" in this document are to be interpreted as described in 428 [RFC2119] when they appear in ALL CAPS. When these words are not in 429 ALL CAPS (such as "should" or "Should"), they have their usual 430 English meanings, and are not to be interpreted as [RFC2119] key 431 words. 433 This document uses terminology defined in [RFC7575]. 435 The following additional terms are used throughout this document: 437 o Autonomic Device: identical to Autonomic Node. 439 o Discovery: a process by which an ASA discovers peers according to 440 a specific discovery objective. The discovery results may be 441 different according to the different discovery objectives. The 442 discovered peers may later be used as negotiation counterparts or 443 as sources of synchronization data. 445 o Negotiation: a process by which two (or more) ASAs interact 446 iteratively to agree on parameter settings that best satisfy the 447 objectives of one or more ASAs. 449 o State Synchronization: a process by which two (or more) ASAs 450 interact to agree on the current state of parameter values stored 451 in each ASA. This is a special case of negotiation in which 452 information is sent but the ASAs do not request their peers to 453 change parameter settings. All other definitions apply to both 454 negotiation and synchronization. 456 o Technical Objective (usually abbreviated as Objective): A 457 technical objective is a configurable parameter or set of 458 parameters of some kind, which occurs in three contexts: 459 Discovery, Negotiation and Synchronization. In the protocol, an 460 objective is represented by an identifier (actually a GRASP option 461 number) and if relevant a value. Normally, a given objective will 462 occur during discovery and negotiation, or during discovery and 463 synchronization, but not in all three contexts. 465 * One ASA may support multiple independent objectives. 467 * The parameter described by a given objective is naturally based 468 on a specific service or function or action. It may in 469 principle be anything that can be set to a specific logical, 470 numerical or string value, or a more complex data structure, by 471 a network node. That node is generally expected to contain an 472 ASA which may itself manage other nodes. 474 * Discovery Objective: if a node needs to synchronize or 475 negotiate a specific objective but does not know a peer that 476 supports this objective, it starts a discovery process. The 477 objective is called a Discovery Objective during this process. 479 * Synchronization Objective: an objective whose specific 480 technical content needs to be synchronized among two or more 481 ASAs. 483 * Negotiation Objective: an objective whose specific technical 484 content needs to be decided in coordination with another ASA. 486 o Discovery Initiator: an ASA that spontaneously starts discovery by 487 sending a discovery message referring to a specific discovery 488 objective. 490 o Discovery Responder: a peer ASA which responds to the discovery 491 objective initiated by the discovery initiator. 493 o Synchronization Initiator: an ASA that spontaneously starts 494 synchronization by sending a request message referring to a 495 specific synchronization objective. 497 o Synchronization Responder: a peer ASA which responds with the 498 value of a synchronization objective. 500 o Negotiation Initiator: an ASA that spontaneously starts 501 negotiation by sending a request message referring to a specific 502 negotiation objective. 504 o Negotiation Counterpart: a peer with which the Negotiation 505 Initiator negotiates a specific negotiation objective. 507 3.2. High-Level Design Choices 509 This section describes a behavior model and some considerations for 510 designing a generic signaling protocol initially supporting 511 discovery, synchronization and negotiation, which can act as a 512 platform for different technical objectives. 514 NOTE: An earlier version of this protocol used type-length-value 515 formats and was prototyped by Huawei and the Beijing University of 516 Posts and Telecommunications. 518 o A generic platform 520 The protocol is designed as a generic platform, which is 521 independent from the synchronization or negotiation contents. It 522 takes care of the general intercommunication between counterparts. 523 The technical contents will vary according to the various 524 technical objectives and the different pairs of counterparts. 526 o The protocol is expected to form part of an Autonomic Networking 527 Infrastructure [I-D.behringer-anima-reference-model]. It will 528 provide services to ASAs via a suitable application programming 529 interface, which will reflect the protocol elements but will not 530 necessarily be in one-to-one correspondence to them. It is 531 expected that the protocol engine and each ASA will run as 532 independent asynchronous processes. 534 o Security infrastructure and trust relationship 536 Because this negotiation protocol may directly cause changes to 537 device configurations and bring significant impacts to a running 538 network, this protocol is assumed to run within an existing secure 539 environment with strong authentication. 541 On the other hand, a limited negotiation model might be deployed 542 based on a limited trust relationship. For example, between two 543 administrative domains, ASAs might also exchange limited 544 information and negotiate some particular configurations based on 545 a limited conventional or contractual trust relationship. 547 o Discovery, synchronization and negotiation are designed together. 549 The discovery method and the synchronization and negotiation 550 methods are designed in the same way and can be combined when this 551 is useful. These processes can also be performed independently 552 when appropriate. 554 * GRASP discovery is always available for efficient discovery of 555 GRASP peers and allows a rapid mode of operation described in 556 Section 3.3.3. For some objectives, especially those concerned 557 with application layer services, another discovery mechanism 558 such as the future DNS Service Discovery [RFC7558] or Service 559 Location Protocol [RFC2608] MAY be used. The choice is left to 560 the designers of individual ASAs. 562 o A uniform pattern for technical contents 564 The synchronization and negotiation contents are defined according 565 to a uniform pattern. They could be carried either in simple 566 binary format or in payloads described by a flexible language. 567 The basic protocol design uses the Concise Binary Object 568 Representation (CBOR) [RFC7049]. The format is extensible for 569 unknown future requirements. 571 o A flexible model for synchronization 572 GRASP supports bilateral synchronization, which could be used to 573 perform synchronization among a small number of nodes. It also 574 supports an unsolicited flooding mode when large groups of nodes, 575 possibly including all autonomic nodes, need data for the same 576 technical objective. 578 * There may be some network parameters for which a more 579 traditional flooding mechanism such as DNCP 580 [I-D.ietf-homenet-dncp] is considered more appropriate. GRASP 581 can coexist with DNCP. 583 o A simple initiator/responder model for negotiation 585 Multi-party negotiations are too complicated to be modeled and 586 there might be too many dependencies among the parties to converge 587 efficiently. A simple initiator/responder model is more feasible 588 and can complete multi-party negotiations by indirect steps. 590 o Organizing of synchronization or negotiation content 592 Naturally, the technical content will be organized according to 593 the relevant function or service. The content from different 594 functions or services is kept independent from each other. They 595 are not combined into a single option or single session because 596 these contents may be negotiated or synchronized with different 597 counterparts or may be different in response time. 599 o Self-aware network device 601 Every autonomic device will be pre-loaded with various functions 602 and ASAs and will be aware of its own capabilities, typically 603 decided by the hardware, firmware or pre-installed software. Its 604 exact role may depend on Intent and on the surrounding network 605 behaviors, which may include forwarding behaviors, aggregation 606 properties, topology location, bandwidth, tunnel or translation 607 properties, etc. The surrounding topology will depend on the 608 network planning. Following an initial discovery phase, the 609 device properties and those of its neighbors are the foundation of 610 the synchronization or negotiation behavior of a specific device. 611 A device has no pre-configuration for the particular network in 612 which it is installed. 614 o Requests and responses in negotiation procedures 615 The initiator can negotiate with its relevant negotiation 616 counterpart ASAs, which may be different according to the specific 617 negotiation objective. It can request relevant information from 618 the negotiation counterpart so that it can decide its local 619 configuration to give the most coordinated performance. It can 620 request the negotiation counterpart to make a matching 621 configuration in order to set up a successful communication with 622 it. It can request certain simulation or forecast results by 623 sending some dry run conditions. 625 Beyond the traditional yes/no answer, the responder can reply with 626 a suggested alternative if its answer is 'no'. This would start a 627 bi-directional negotiation ending in a compromise between the two 628 ASAs. 630 o Convergence of negotiation procedures 632 To enable convergence, when a responder makes a suggestion of a 633 changed condition in a negative reply, it should be as close as 634 possible to the original request or previous suggestion. The 635 suggested value of the third or later negotiation steps should be 636 chosen between the suggested values from the last two negotiation 637 steps. In any case there must be a mechanism to guarantee 638 convergence (or failure) in a small number of steps, such as a 639 timeout or maximum number of iterations. 641 * End of negotiation 643 A limited number of rounds, for example three, or a timeout, is 644 needed on each ASA for each negotiation objective. It may be 645 an implementation choice, a pre-configurable parameter, or 646 network Intent. These choices might vary between different 647 types of ASA. Therefore, the definition of each negotiation 648 objective MUST clearly specify this, so that the negotiation 649 can always be terminated properly. 651 * Failed negotiation 653 There must be a well-defined procedure for concluding that a 654 negotiation cannot succeed, and if so deciding what happens 655 next (deadlock resolution, tie-breaking, or revert to best- 656 effort service). Again, this MUST be specified for individual 657 negotiation objectives, as an implementation choice, a pre- 658 configurable parameter, or network Intent. 660 3.3. GRASP Protocol Basic Properties and Mechanisms 662 3.3.1. Required External Security Mechanism 664 The protocol SHOULD run within a secure Autonomic Control Plane (ACP) 665 [I-D.ietf-anima-autonomic-control-plane]. The ACP MUST provide a 666 status indicator to inform GRASP that the ACP is operational. 668 If there is no ACP, the protocol MUST use another form of strong 669 authentication and SHOULD use a form of strong encryption. TLS 670 [RFC5246] or DTLS [RFC6347] are RECOMMENDED for this purpose, based 671 on a local Public Key Infrastructure (PKI) [RFC5280] managed within 672 the autonomic network itself. 674 Link-local multicast is used for discovery messages. It is expected 675 that the ACP will handle these and distribute them securely to all 676 on-link ACP nodes only. However, in the absence of an ACP they 677 cannot be secured. Responses to discovery messages MUST be secured. 679 During initialisation, before a node has joined the applicable trust 680 infrastructure, e.g., [I-D.ietf-anima-bootstrapping-keyinfra], it 681 might be impossible to secure certain messages. Such messages MUST 682 be limited to the strictly necessary minimum. A full analysis of the 683 secure bootstrap process is out of scope for the present document. 685 3.3.2. Transport Layer Usage 687 The protocol is capable of running over UDP or TCP, except for link- 688 local multicast discovery messages, which can only run over UDP and 689 MUST NOT be fragmented, and therefore cannot exceed the link MTU 690 size. 692 When running within a secure ACP, UDP SHOULD be used for messages not 693 exceeding the minimum IPv6 path MTU, and TCP MUST be used for longer 694 messages. In other words, IPv6 fragmentation is avoided. If a node 695 receives a UDP message but the reply is too long, it MUST open a TCP 696 connection to the peer for the reply. 698 When running without an ACP, TLS MUST be supported and used by 699 default, except for multicast discovery messages. DTLS MAY be 700 supported as an alternative but the details are out of scope for this 701 document. 703 For all transport protocols, the GRASP protocol listens to the GRASP 704 Listen Port (Section 3.5). 706 3.3.3. Discovery Mechanism and Procedures 708 o Separated discovery and negotiation mechanisms 710 Although discovery and negotiation or synchronization are 711 defined together in the GRASP, they are separated mechanisms. 712 The discovery process could run independently from the 713 negotiation or synchronization process. Upon receiving a 714 discovery (Section 3.7.2) or request (Section 3.7.4) message, 715 the recipient ASA should return a message in which it either 716 indicates itself as a discovery responder or diverts the 717 initiator towards another more suitable ASA. 719 The discovery action will normally be followed by a negotiation 720 or synchronization action. The discovery results could be 721 utilized by the negotiation protocol to decide which ASA the 722 initiator will negotiate with. 724 o Discovery Procedures 726 Discovery starts as an on-link operation. The Divert option 727 can tell the discovery initiator to contact an off-link ASA for 728 that discovery objective. Every Discovery message is sent by a 729 discovery initiator via UDP to the ALL_GRASP_NEIGHBOR multicast 730 address (Section 3.5). Every network device that supports the 731 GRASP always listens to a well-known UDP port to capture the 732 discovery messages. 734 If an ASA in the neighbor device supports the requested 735 discovery objective, it MAY respond with a Response message 736 (Section 3.7.3) with locator option(s). Otherwise, if the 737 neighbor has cached information about an ASA that supports the 738 requested discovery objective (usually because it discovered 739 the same objective before), it SHOULD respond with a Response 740 message with a Divert option pointing to the appropriate 741 Discovery Responder. 743 If no discovery response is received within a reasonable 744 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), 745 the Discovery message MAY be repeated, with a newly generated 746 Session ID (Section 3.6). An exponential backoff SHOULD be 747 used for subsequent repetitions, in order to mitigate possible 748 denial of service attacks. 750 After a GRASP device successfully discovers a Discovery 751 Responder supporting a specific objective, it MUST cache this 752 information. This cache record MAY be used for future 753 negotiation or synchronization, and SHOULD be passed on when 754 appropriate as a Divert option to another Discovery Initiator. 755 The cache lifetime is an implementation choice that MAY be 756 modified by network Intent. 758 If multiple Discovery Responders are found for the same 759 objective, they SHOULD all be cached, unless this creates a 760 resource shortage. The method of choosing between multiple 761 responders is an implementation choice. 763 A GRASP device with multiple link-layer interfaces (typically a 764 router) MUST support discovery on all interfaces. If it 765 receives a Discovery message on a given interface for a 766 specific objective that it does not support and for which it 767 has not previously discovered a Discovery Responder, it MUST 768 relay the query by re-issuing the same Discovery message on its 769 other interfaces. Before this, it MUST decrement the loop 770 count within the objective, and discard the Discovery message 771 if the result is zero. Also, it MUST limit the total rate at 772 which it relays discovery messages to a reasonable value, in 773 order to mitigate possible denial of service attacks. It MUST 774 cache the Session ID value of each relayed discovery message 775 and, to prevent loops, MUST NOT relay a Discovery message which 776 carries such a cached Session ID. These precautions avoid 777 discovery loops and mitigate potential overload. 779 This relayed discovery mechanism, with caching of the results, 780 should be sufficient to support most network bootstrapping 781 scenarios. 783 o A complete discovery process will start with multicast on the 784 local link; a neighbor might divert it to an off-link destination, 785 which could be a default higher-level gateway in a hierarchical 786 network. Then discovery would continue with a unicast to that 787 gateway; if that gateway is still not the right counterpart, it 788 should divert to another gateway, which is in principle closer to 789 the right counterpart. Finally the right counterpart responds to 790 start the negotiation or synchronization process. 792 o Rapid Mode (Discovery/Negotiation binding) 794 A Discovery message MAY include one or more Negotiation 795 Objective option(s). This allows a rapid mode of negotiation 796 described in Section 3.3.4. A similar mechanism is defined for 797 synchronization in Section 3.3.5. 799 3.3.4. Negotiation Procedures 801 A negotiation initiator sends a negotiation request to a counterpart 802 ASA, including a specific negotiation objective. It may request the 803 negotiation counterpart to make a specific configuration. 804 Alternatively, it may request a certain simulation or forecast result 805 by sending a dry run configuration. The details, including the 806 distinction between dry run and an actual configuration change, will 807 be defined separately for each type of negotiation objective. 809 If no reply message of any kind is received within a reasonable 810 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 811 negotiation request MAY be repeated, with a newly generated Session 812 ID (Section 3.6). An exponential backoff SHOULD be used for 813 subsequent repetitions. 815 If the counterpart can immediately apply the requested configuration, 816 it will give an immediate positive (accept) answer. This will end 817 the negotiation phase immediately. Otherwise, it will negotiate. It 818 will reply with a proposed alternative configuration that it can 819 apply (typically, a configuration that uses fewer resources than 820 requested by the negotiation initiator). This will start a bi- 821 directional negotiation to reach a compromise between the two ASAs. 823 The negotiation procedure is ended when one of the negotiation peers 824 sends a Negotiation Ending message, which contains an accept or 825 decline option and does not need a response from the negotiation 826 peer. Negotiation may also end in failure (equivalent to a decline) 827 if a timeout is exceeded or a loop count is exceeded. 829 A negotiation procedure concerns one objective and one counterpart. 830 Both the initiator and the counterpart may take part in simultaneous 831 negotiations with various other ASAs, or in simultaneous negotiations 832 about different objectives. Thus, GRASP is expected to be used in a 833 multi-threaded mode. Certain negotiation objectives may have 834 restrictions on multi-threading, for example to avoid over-allocating 835 resources. 837 Rapid Mode (Discovery/Negotiation linkage) 839 A Discovery message MAY include a Negotiation Objective option. 840 In this case the Discovery message also acts as a Request message 841 to indicate to the Discovery Responder that it could directly 842 reply to the Discovery Initiator with a Negotiation message for 843 rapid processing, if it could act as the corresponding negotiation 844 counterpart. However, the indication is only advisory not 845 prescriptive. 847 This rapid mode could reduce the interactions between nodes so 848 that a higher efficiency could be achieved. This rapid 849 negotiation function SHOULD be configured off by default and MAY 850 be configured on or off by Intent. 852 3.3.5. Synchronization Procedure 854 A synchronization initiator sends a synchronization request to a 855 counterpart, including a specific synchronization objective. The 856 counterpart responds with a Response message containing the current 857 value of the requested synchronization objective. No further 858 messages are needed. 860 If no reply message of any kind is received within a reasonable 861 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 862 synchronization request MAY be repeated, with a newly generated 863 Session ID (Section 3.6). An exponential backoff SHOULD be used for 864 subsequent repetitions. 866 In the case just described, the message exchange is unicast and 867 concerns only one synchronization objective. For large groups of 868 nodes requiring the same data, synchronization flooding is available. 869 For this, a synchronization responder MAY send an unsolicited 870 Response message containing one or more Synchronization Objective 871 option(s), if and only if the specification of those objectives 872 permits it. This is sent as a multicast message to the 873 ALL_GRASP_NEIGHBOR multicast address (Section 3.5). To ensure that 874 flooding does not result in a loop, the originator of the Response 875 message MUST set the loop count in the objective to a suitable value 876 (the default is GRASP_DEF_LOOPCT). In this case a suitable mechanism 877 is needed to avoid excessive multicast traffic. This mechanism MUST 878 be defined as part of the specification of the synchronization 879 objective(s) concerned. It might be a simple rate limit or a more 880 complex mechanism such as the Trickle algorithm [RFC6206]. 882 A GRASP device with multiple link-layer interfaces (typically a 883 router) MUST support synchronization flooding on all interfaces. If 884 it receives a multicast unsolicited Response message on a given 885 interface, it MUST relay it by re-issuing the same Response message 886 on its other interfaces. Before this, it MUST decrement the loop 887 count within the objective, and discard the Response message if the 888 result is zero. Also, it MUST limit the total rate at which it 889 relays Response messages to a reasonable value, in order to mitigate 890 possible denial of service attacks. It MUST cache the Session ID 891 value of each relayed Response message and, to prevent loops, MUST 892 NOT relay a Response message which carries such a cached Session ID. 893 These precautions avoid synchronization loops and mitigate potential 894 overload. 896 Note that this mechanism is unreliable in the case of sleeping nodes. 897 Sleeping nodes that require an objective subject to synchronization 898 flooding SHOULD periodically initiate normal synchronization for that 899 objective. 901 Rapid Mode (Discovery/Synchronization linkage) 903 A Discovery message MAY include one or more Synchronization 904 Objective option(s). In this case the Discovery message also acts 905 as a Request message to indicate to the Discovery Responder that 906 it could directly reply to the Discovery Initiator with a Response 907 message with synchronization data for rapid processing, if the 908 discovery target supports the corresponding synchronization 909 objective(s). However, the indication is only advisory not 910 prescriptive. 912 This rapid mode could reduce the interactions between nodes so 913 that a higher efficiency could be achieved. This rapid 914 synchronization function SHOULD be configured off by default and 915 MAY be configured on or off by Intent. 917 3.4. High Level Deployment Model 919 It is expected that a GRASP implementation will reside in an 920 autonomic node that also contains both the appropriate security 921 environment (preferably the ACP) and one or more Autonomic Service 922 Agents (ASAs). In the minimal case of a single-purpose device, these 923 three components might be fully integrated. A more common model is 924 expected to be a multi-purpose device capable of containing several 925 ASAs. In this case it is expected that the ACP, GRASP and the ASAs 926 will be implemented as separate processes, which are probably multi- 927 threaded to support asynchronous operation. It is expected that 928 GRASP will access the ACP by using a typical socket interface. Well 929 defined Application Programming Interfaces (APIs) will be needed 930 between GRASP and the ASAs. For further details of possible 931 deployment models, see [I-D.behringer-anima-reference-model]. 933 3.5. GRASP Constants 935 o ALL_GRASP_NEIGHBOR 937 A link-local scope multicast address used by a GRASP-enabled 938 device to discover GRASP-enabled neighbor (i.e., on-link) devices 939 . All devices that support GRASP are members of this multicast 940 group. 942 * IPv6 multicast address: TBD1 943 * IPv4 multicast address: TBD2 945 o GRASP_LISTEN_PORT (TBD3) 947 A UDP and TCP port that every GRASP-enabled network device always 948 listens to. 950 o GRASP_DEF_TIMEOUT (60000 milliseconds) 952 The default timeout used to determine that a discovery etc. has 953 failed to complete. 955 o GRASP_DEF_LOOPCT (6) 957 The default loop count used to determine that a negotiation has 958 failed to complete, and to avoid looping messages. 960 3.6. Session Identifier (Session ID) 962 This is an up to 24-bit opaque value used to distinguish multiple 963 sessions between the same two devices. A new Session ID MUST be 964 generated for every new Discovery or Request message, and for every 965 unsolicited Response message. All follow-up messages in the same 966 discovery, synchronization or negotiation procedure, which is 967 initiated by the request message, MUST carry the same Session ID. 969 The Session ID SHOULD have a very low collision rate locally. It 970 MUST be generated by a pseudo-random algorithm using a locally 971 generated seed which is unlikely to be used by any other device in 972 the same network [RFC4086]. 974 3.7. GRASP Messages 976 This section defines the GRASP message format and message types. 977 Message types not listed here are reserved for future use. 979 3.7.1. GRASP Message Format 981 GRASP messages share an identical header format and a variable format 982 area for options. GRASP message headers and options are transmitted 983 in Concise Binary Object Representation (CBOR) [RFC7049]. In this 984 specification, they are described using CBOR data definition language 985 (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is 986 used to describe each item in this section. A complete and normative 987 CDDL specification of GRASP is given in Section 6. 989 Every GRASP message carries a Session ID (Section 3.6). Options are 990 then presented serially in the options field. 992 In fragmentary CDDL, every GRASP message follows the pattern: 994 message /= [MESSAGE_TYPE, session-id, *option] 996 MESSAGE_TYPE = ; a defined constant 997 session-id = 0..16777215 998 option /= ; one of the options defined below 1000 3.7.2. Discovery Message 1002 In fragmentary CDDL, a Discovery message follows the pattern: 1004 discovery-message = [M_DISCOVERY, session-id, objective] 1006 M_DISCOVERY = ; a defined constant 1007 session-id = 0..16777215 1008 objective /= ; defined below 1010 A discovery initiator sends a Discovery message to initiate a 1011 discovery process. 1013 The discovery initiator sends the Discovery messages to the link- 1014 local ALL_GRASP_NEIGHBOR multicast address for discovery, and stores 1015 the discovery results (including responding discovery objectives and 1016 corresponding unicast addresses or FQDNs). 1018 A Discovery message MUST include exactly one of the following: 1020 o a discovery objective option (Section 3.9.1). Its loop count must 1021 be set to a suitable value to prevent discovery loops (default 1022 value is GRASP_DEF_LOOPCT). 1024 o a negotiation objective option (Section 3.9.1) to indicate to the 1025 discovery target that it MAY directly reply to the discovery 1026 initiatior with a Negotiation message for rapid processing, if it 1027 could act as the corresponding negotiation counterpart. The 1028 sender of such a Discovery message MUST initialize a negotiation 1029 timer and loop count in the same way as a Request message 1030 (Section 3.7.4). 1032 o one or more synchronization objective options (Section 3.9.1) to 1033 indicate to the discovery target that it MAY directly reply to the 1034 discovery initiator with a Response message for rapid processing, 1035 if it could act as the corresponding synchronization counterpart. 1037 3.7.3. Response Message 1039 In fragmentary CDDL, a Response message follows the pattern: 1041 response-message = [M_RESPONSE, session-id, 1042 (+locator-option // divert-option // objective)] 1044 M_RESPONSE = ; a defined constant 1045 session-id = 0..16777215 1046 locator-option /= ; defined below 1047 divert-option = ; defined below 1048 objective /= ; defined below 1050 A node which receives a Discovery message sends a Response message to 1051 respond to a discovery. It MUST contain the same Session ID as the 1052 Discovery message. It MAY include a copy of the discovery objective 1053 from the Discovery message. 1055 If the responding node supports the discovery objective of the 1056 discovery, it MUST include at least one kind of locator option 1057 (Section 3.8.7) to indicate its own location. A combination of 1058 multiple kinds of locator options (e.g. IP address option + FQDN 1059 option) is also valid. 1061 If the responding node itself does not support the discovery 1062 objective, but it knows the locator of the discovery objective, then 1063 it SHOULD respond to the discovery message with a divert option 1064 (Section 3.8.2) embedding a locator option or a combination of 1065 multiple kinds of locator options which indicate the locator(s) of 1066 the discovery objective. 1068 A node which receives a synchronization request sends a Response 1069 message with the synchronization data, in the form of GRASP Option(s) 1070 for the specific synchronization objective(s). 1072 3.7.4. Request Message 1074 In fragmentary CDDL, a Request message follows the pattern: 1076 discovery-message = [M_REQUEST, session-id, objective] 1078 M_REQUEST = ; a defined constant 1079 session-id = 0..16777215 1080 objective /= ; defined below 1082 A negotiation or synchronization requesting node sends the Request 1083 message to the unicast address (directly stored or resolved from the 1084 FQDN) of the negotiation or synchronization counterpart (selected 1085 from the discovery results). 1087 A request message MUST include the relevant objective option, with 1088 the requested value in the case of negotiation. 1090 When an initiator sends a Request message, it MUST initialize a 1091 negotiation timer for the new negotiation thread with the value 1092 GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is modified by a 1093 Confirm-waiting message (Section 3.7.7), the initiator will consider 1094 that the negotiation has failed when the timer expires. 1096 When an initiator sends a Request message, it MUST initialize the 1097 loop count of the objective option with a value defined in the 1098 specification of the option or, if no such value is specified, with 1099 GRASP_DEF_LOOPCT. 1101 3.7.5. Negotiation Message 1103 In fragmentary CDDL, a Negotiation message follows the pattern: 1105 discovery-message = [M_NEGOTIATE, session-id, objective] 1107 M_NEGOTIATE = ; a defined constant 1108 session-id = 0..16777215 1109 objective /= ; defined below 1111 A negotiation counterpart sends a Negotiation message in response to 1112 a Request message, a Negotiation message, or a Discovery message in 1113 Rapid Mode. A negotiation process MAY include multiple steps. 1115 The Negotiation message MUST include the relevant Negotiation 1116 Objective option, with its value updated according to progress in the 1117 negotiation. The sender MUST decrement the loop count by 1. If the 1118 loop count becomes zero both parties will consider that the 1119 negotiation has failed. 1121 3.7.6. Negotiation-ending Message 1123 In fragmentary CDDL, a Negotiation-ending message follows the 1124 pattern: 1126 end-message = [M_END, session-id, accept-option / decline-option] 1128 M_END = ; a defined constant 1129 session-id = 0..16777215 1130 accept-option = ; defined below 1131 decline-option ; defined below 1133 A negotiation counterpart sends an Negotiation-ending message to 1134 close the negotiation. It MUST contain one, but only one of accept/ 1135 decline option, defined in Section 3.8.3 and Section 3.8.4. It could 1136 be sent either by the requesting node or the responding node. 1138 3.7.7. Confirm-waiting Message 1140 In fragmentary CDDL, a Confirm-waiting message follows the pattern: 1142 wait-message = [M_WAIT, session-id, waiting-time-option] 1144 M_WAIT = ; a defined constant 1145 session-id = 0..16777215 1146 waiting-time-option = ; defined below 1148 A responding node sends a Confirm-waiting message to indicate the 1149 requesting node to wait for a further negotiation response. It might 1150 be that the local process needs more time or that the negotiation 1151 depends on another triggered negotiation. This message MUST NOT 1152 include any other options than the Waiting Time Option 1153 (Section 3.8.5). 1155 3.8. GRASP General Options 1157 This section defines the GRASP general options for the negotiation 1158 and synchronization protocol signaling. Additional option types are 1159 reserved for GRASP general options defined in the future. 1161 3.8.1. Format of GRASP Options 1163 GRASP options are CBOR objects that MUST start with an unsigned 1164 integer identifying the specific option type carried in this option. 1165 Apart from that the only format requirement is each option MUST be a 1166 well-formed CBOR object. In general a CBOR array format is 1167 RECOMMENDED to limit overhead. 1169 GRASP options are usually scoped by using encapsulation. However, 1170 this is not a requirement 1172 3.8.2. Divert Option 1174 The Divert option is used to redirect a GRASP request to another 1175 node, which may be more appropriate for the intended negotiation or 1176 synchronization. It may redirect to an entity that is known as a 1177 specific negotiation or synchronization counterpart (on-link or off- 1178 link) or a default gateway. The divert option MUST only be 1179 encapsulated in Response messages. If found elsewhere, it SHOULD be 1180 silently ignored. 1182 In fragmentary CDDL, the Divert option follows the pattern: 1184 divert-option = [O_DIVERT, +locator-option] 1186 O_DIVERT = ; a defined constant 1187 locator-option = ; defined below 1189 The embedded Locator Option(s) (Section 3.8.7) point to diverted 1190 destination target(s) in response to a Discovery message. 1192 Note: Currently the need for this option is disputed. It might be 1193 removed or modified. 1195 3.8.3. Accept Option 1197 The accept option is used to indicate to the negotiation counterpart 1198 that the proposed negotiation content is accepted. 1200 The accept option MUST only be encapsulated in Negotiation-ending 1201 messages. If found elsewhere, it SHOULD be silently ignored. 1203 In fragmentary CDDL, the Accept option follows the pattern: 1205 accept-option = [O_ACCEPT] 1207 O_ACCEPT = ; a defined constant 1209 3.8.4. Decline Option 1211 The decline option is used to indicate to the negotiation counterpart 1212 the proposed negotiation content is declined and end the negotiation 1213 process. 1215 The decline option MUST only be encapsulated in Negotiation-ending 1216 messages. If found elsewhere, it SHOULD be silently ignored. 1218 In fragmentary CDDL, the Decline option follows the pattern: 1220 decline-option = [O_DECLINE] 1222 O_DECLINE = ; a defined constant 1224 Notes: there are scenarios where a negotiation counterpart wants to 1225 decline the proposed negotiation content and continue the negotiation 1226 process. For these scenarios, the negotiation counterpart SHOULD use 1227 a Negotiate message, with either an objective option that contains a 1228 data field set to indicate a meaningless initial value, or a specific 1229 objective option that provides further conditions for convergence. 1231 3.8.5. Waiting Time Option 1233 The waiting time option is used to indicate that the negotiation 1234 counterpart needs to wait for a further negotiation response, since 1235 the processing might need more time than usual or it might depend on 1236 another triggered negotiation. 1238 The waiting time option MUST only be encapsulated in Confirm-waiting 1239 messages. If found elsewhere, it SHOULD be silently ignored. When 1240 received, its value overwrites the negotiation timer (Section 3.7.4). 1242 The counterpart SHOULD send a Negotiation, Negotiation-Ending or 1243 another Confirm-waiting message before the negotiation timer expires. 1244 If not, the initiator MUST abandon or restart the negotiation 1245 procedure, to avoid an indefinite wait. 1247 In fragmentary CDDL, the Waiting-time option follows the pattern: 1249 waiting-time-option = [O_WAITING, option-waiting-time] 1251 O_WAITING = ; a defined constant 1252 option-waiting-time = 0..4294967295 ; in milliseconds 1254 3.8.6. Device Identity Option 1256 The Device Identity option carries the identities of the sender and 1257 of the domain(s) that it belongs to. 1259 In fragmentary CDDL, the Device Identity option follows the pattern: 1261 option-device-id = [O_DEVICE_ID, bytes] 1263 O_DEVICE_ID = ; a defined constant 1265 The option contains a variable-length field containing the device 1266 identity and one or more domain identities. The format is not yet 1267 defined. 1269 Note: Currently this option is a placeholder. It might be removed or 1270 modified. 1272 3.8.7. Locator Options 1274 These locator options are used to present reachability information 1275 for an ASA, a device or an interface. They are Locator IPv4 Address 1276 Option, Locator IPv6 Address Option, Locator FQDN (Fully Qualified 1277 Domain Name) Option and Uniform Resource Locator Option. 1279 Note: It is assumed that all locators are in scope throughout the 1280 GRASP domain. GRASP is not intended to work across disjoint 1281 addressing or naming realms. 1283 3.8.7.1. Locator IPv4 address option 1285 In fragmentary CDDL, the IPv4 address option follows the pattern: 1287 ipv4-locator-option = bytes .size 4 1289 The content of this option is a binary IPv4 address. 1291 Note: If an operator has internal network address translation for 1292 IPv4, this option MUST NOT be used within the Divert option. 1294 3.8.7.2. Locator IPv6 address option 1296 In fragmentary CDDL, the IPv6 address option follows the pattern: 1298 ipv6-locator-option = bytes .size 16 1300 The content of this option is a binary IPv6 address. 1302 Note: A link-local IPv6 address MUST NOT be used when this option is 1303 used within the Divert option. 1305 3.8.7.3. Locator FQDN option 1307 In fragmentary CDDL, the FQDN option follows the pattern: 1309 fqdn-locator-option = [O_FQDN_LOCATOR, text] 1311 O_FQDN_LOCATOR = ; a defined constant 1313 The content of this option is the Fully Qualified Domain Name of the 1314 target. 1316 Note: Any FQDN which might not be valid throughout the network in 1317 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1318 when this option is used within the Divert option. 1320 3.8.7.4. Locator URL option 1322 In fragmentary CDDL, the URL option follows the pattern: 1324 url-locator-option = [O_URL_LOCATOR, text] 1326 O_URL_LOCATOR = ; a defined constant 1328 The content of this option is the Uniform Resource Locator of the 1329 target [RFC3986]. 1331 Note: Any URL which might not be valid throughout the network in 1332 question, such as one based on a Multicast DNS name [RFC6762], MUST 1333 NOT be used when this option is used within the Divert option. 1335 3.9. Objective Options 1337 3.9.1. Format of Objective Options 1339 An objective option is used to identify objectives for the purposes 1340 of discovery, negotiation or synchronization. All objectives must 1341 follow one of two common formats as follows, described in fragmentary 1342 CDDL: 1344 generic-obj = [objective-name, objective-flags, loop-count, ?any] 1345 vendor-obj = [{"PEN":pen}, objective-name, objective-flags, 1346 loop-count, ?any] 1348 objective-name = tstr 1349 pen = 0..4294967295 1350 loop-count = 0..255 1351 objective-flags \= ; defined below 1353 All objectives are identified by a unique name which is a UTF-8 1354 string. The names of generic objectives MUST be registered with 1355 IANA. 1357 The name "PEN" and the value following it MUST be prepended to 1358 indicate vendor-defined objectives. The associated value uniquely 1359 identifies the enterprise that defines the option, in the form of a 1360 registered 32 bit Private Enterprise Number (PEN) 1361 [I-D.liang-iana-pen]. There is no default value for this field. 1362 Note that it is not used during discovery. It MUST be verified 1363 during negotiation or synchronization. 1365 The 'loop-count' field is used for terminating negotiation as 1366 described in Section 3.7.5. It is also used for terminating 1367 discovery as described in Section 3.3.3, and for terminating flooding 1368 as described in FLOODING. 1370 The 'any' field is to express the actual value of a negotiation or 1371 synchronization objective. Its format is defined in the 1372 specification of the objective and may be a single value or a data 1373 structure of any kind. It is optional because it is optional in a 1374 Discovery or Response message. 1376 3.9.2. Objective flags 1378 An objective may be relevant for discovery, negotiation or 1379 synchronization. This is expressed in the objective by logical 1380 flags: 1382 objective-flags = uint .bits objective-flag 1383 objective-flag = &( 1384 D: 0 ; valid for discovery only 1385 N: 1 ; valid for discovery and negotiation 1386 S: 2 ; valid for discovery and synchronization 1387 ) 1389 3.9.3. General Considerations for Objective Options 1391 As mentioned above, generic Objective Options MUST be assigned a 1392 unique name. As long as vendor-defined Objective Options start with 1393 a valid PEN, this document does not restrict their choice of name, 1394 but the vendor SHOULD publish the names in use. 1396 All Objective Options MUST respect the CBOR patterns defined above as 1397 "generic-obj" or "vendor-obj" and MUST replace the "any" field with a 1398 valid CBOR data definition for the relevant use case and application. 1400 An Objective Option that contains no additional fields beyond its 1401 "loop-count" can only be a discovery objective and MUST only be used 1402 in Discovery and Response messages. 1404 The Negotiation Objective Options contain negotiation objectives, 1405 which vary according to different functions/services. They MUST be 1406 carried by Discovery, Request or Negotiation Messages only. The 1407 negotiation initiator MUST set the initial "loop-count" to a value 1408 specified in the specification of the objective or, if no such value 1409 is specified, to GRASP_DEF_LOOPCT. 1411 For most scenarios, there should be initial values in the negotiation 1412 requests. Consequently, the Negotiation Objective options MUST 1413 always be completely presented in a Request message, or in a 1414 Discovery message in rapid mode. If there is no initial value, the 1415 bits in the value field SHOULD all be set to indicate a meaningless 1416 value, unless this is inappropriate for the specific negotiation 1417 objective. 1419 Synchronization Objective Options are similar, but MUST be carried by 1420 Discovery, Request or Response messages only. They include value 1421 fields only in Response messages. 1423 3.9.4. Organizing of Objective Options 1425 Generic objective options MUST be specified in documents available to 1426 the public and MUST be designed to use either the negotiation or the 1427 synchronization mechanism described above. 1429 As noted earlier, one negotiation objective is handled by each GRASP 1430 negotiation thread. Therefore, a negotiation objective, which is 1431 based on a specific function or action, SHOULD be organized as a 1432 single GRASP option. It is NOT RECOMMENDED to organize multiple 1433 negotiation objectives into a single option, nor to split a single 1434 function or action into multiple negotiation objectives. 1436 It is important to understand that GRASP negotiation does not support 1437 transactional integrity. If transactional integrity is needed for a 1438 specific objective, this must be ensured by the ASA. For example, an 1439 ASA might need to ensure that it only participates in one negotiation 1440 thread at the same time. Such an ASA would need to stop listening 1441 for incoming negotiation requests before generating an outgoing 1442 negotiation request. 1444 A synchronization objective SHOULD be organized as a single GRASP 1445 option. 1447 Some objectives will support more than one operational mode. An 1448 example is a negotiation objective with both a "dry run" mode (where 1449 the negotiation is to find out whether the other end can in fact make 1450 the requested change without problems) and a "live" mode. Such modes 1451 will be defined in the specification of such an objective. These 1452 objectives SHOULD include flags indicating the applicable mode(s). 1454 An objective may have multiple parameters. Parameters can be 1455 categorized into two classes: the obligatory ones presented as fixed 1456 fields; and the optional ones presented in CBOR sub-options or some 1457 other form of data structure embedded in CBOR. The format might be 1458 inherited from an existing management or configuration protocol, the 1459 objective option acting as a carrier for that format. The data 1460 structure might be defined in a formal language, but that is a matter 1461 for the specifications of individual objectives. There are many 1462 candidates, according to the context, such as ABNF, RBNF, XML Schema, 1463 possibly YANG, etc. The GRASP protocol itself is agnostic on these 1464 questions. 1466 It is NOT RECOMMENDED to split parameters in a single objective into 1467 multiple options, unless they have different response periods. An 1468 exception scenario may also be described by split objectives. 1470 All objectives MUST support GRASP discovery. However, as mentioned 1471 in Section 3.2, it is acceptable for an ASA to use an alternative 1472 method of discovery. 1474 Normally, a GRASP objective will refer to specific technical 1475 parameters as explained in Section 3.1. However, it is acceptable to 1476 define an abstract objective for the purpose of managing or 1477 coordinating ASAs. It is also acceptable to define a special-purpose 1478 objective for purposes such as trust bootstrapping or formation of 1479 the ACP. 1481 3.9.5. Experimental and Example Objective Options 1483 The names "EX0" through "EX9" have been reserved for experimental 1484 options. Multiple names have been assigned because a single 1485 experiment may use multiple options simultaneously. These 1486 experimental options are highly likely to have different meanings 1487 when used for different experiments. Therefore, they SHOULD NOT be 1488 used without an explicit human decision and SHOULD NOT be used in 1489 unmanaged networks such as home networks. 1491 These names are also RECOMMENDED for use in documentation examples. 1493 4. Open Issues 1495 There are various unresolved design questions that are worthy of more 1496 work in the near future, as listed below (statically numbered in 1497 historical order for reference purposes, with the resolved issues 1498 retained for reference): 1500 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 1501 as message transport mechanisms. This is not clarified yet. UDP 1502 is good for short conversations, is necessary for multicast 1503 discovery, and generally fits the discovery and divert scenarios 1504 well. However, it will cause problems with large messages. TCP 1505 is good for stable and long sessions, with a little bit of time 1506 consumption during the session establishment stage. If messages 1507 exceed a reasonable MTU, a TCP mode will be required in any case. 1508 This question may be affected by the security discussion. 1510 RESOLVED by specifying UDP for short message and TCP for longer 1511 one. 1513 o 2. DTLS or TLS vs built-in security mechanism. For now, this 1514 specification has chosen a PKI based built-in security mechanism 1515 based on asymmetric cryptography. However, (D)TLS might be chosen 1516 as security solution to avoid duplication of effort. It also 1517 allows essentially similar security for short messages over UDP 1518 and longer ones over TCP. The implementation trade-offs are 1519 different. The current approach requires expensive asymmetric 1520 cryptographic calculations for every message. (D)TLS has startup 1521 overheads but cheaper crypto per message. DTLS is less mature 1522 than TLS. 1524 RESOLVED by specifying external security (ACP or (D)TLS). 1526 o The following open issues apply only if the current security model 1527 is retained: 1529 * 2.1. For replay protection, GRASP currently requires every 1530 participant to have an NTP-synchronized clock. Is this OK for 1531 low-end devices, and how does it work during device 1532 bootstrapping? We could take the Timestamp out of signature 1533 option, to become an independent and OPTIONAL (or RECOMMENDED) 1534 option. 1536 * 2.2. The Signature Option states that this option could be any 1537 place in a message. Wouldn't it be better to specify a 1538 position (such as the end)? That would be much simpler to 1539 implement. 1541 RESOLVED by changing security model. 1543 o 3. DoS Attack Protection needs work. 1545 RESOLVED by adding text. 1547 o 4. Should we consider preferring a text-based approach to 1548 discovery (after the initial discovery needed for bootstrapping)? 1549 This could be a complementary mechanism for multicast based 1550 discovery, especially for a very large autonomic network. 1551 Centralized registration could be automatically deployed 1552 incrementally. At the very first stage, the repository could be 1553 empty; then it could be filled in by the objectives discovered by 1554 different devices (for example using Dynamic DNS Update). The 1555 more records are stored in the repository, the less the multicast- 1556 based discovery is needed. However, if we adopt such a mechanism, 1557 there would be challenges: stateful solution, and security. 1559 RESOLVED for now by adding optional use of DNS-SD by ASAs. 1561 o 5. Need to expand description of the minimum requirements for the 1562 specification of an individual discovery, synchronization or 1563 negotiation objective. 1565 RESOLVED for now by extra wording. 1567 o 6. Use case and protocol walkthrough. A description of how a 1568 node starts up, performs discovery, and conducts negotiation and 1569 synchronisation for a sample use case would help readers to 1570 understand the applicability of this specification. Maybe it 1571 should be an artificial use case or maybe a simple real one, based 1572 on a conceptual API. However, the authors have not yet decided 1573 whether to have a separate document or have it in the protocol 1574 document. 1576 RESOLVED: recommend a separate document. 1578 o 7. Cross-check against other ANIMA WG documents for consistency 1579 and gaps. 1581 o 8. Consideration of ADNCP proposal. 1583 RESOLVED by adding optional use of DNCP for flooding-type 1584 synchronization. 1586 o 9. Clarify how a GDNP instance knows whether it is running inside 1587 the ACP. (Sheng) 1589 RESOLVED by improved text. 1591 o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. 1592 (Sheng) 1594 RESOLVED by improved text and declaring DTLS out of scope for this 1595 draft. 1597 o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - 1598 Brian] 1600 RESOLVED by improved text. 1602 o 12. Justify that IP address within ACP or (D)TLS environment is 1603 sufficient to prove AN identity; or explain how Device Identity 1604 Option is used. (Sheng) 1605 RESOLVED for now: we assume that all ASAs in a device are trusted 1606 as soon as the device is trusted, so they share credentials. In 1607 that case the Device Identity Option is useless. This needs to be 1608 reviewed later. 1610 o 13. Emphasise that negotiation/synchronization are independent 1611 from discovery, although the rapid discovery mode includes the 1612 first step of a negotiation/synchronization. (Sheng) 1614 RESOLVED by improved text. 1616 o 14. Do we need an unsolicited flooding mechanism for discovery 1617 (for discovery results that everyone needs), to reduce scaling 1618 impact of flooding discovery messages? (Toerless) 1620 RESOLVED: Yes, added to requirements and solution. 1622 o 15. Do we need flag bits in Objective Options to distinguish 1623 distinguish Synchronization and Negotiation "Request" or rapid 1624 mode "Discovery" messages? (Bing) 1626 RESOLVED: yes, work on the API showed that these flags are 1627 essential. 1629 o 16. (Related to issue 14). Should we revive the "unsolicited 1630 Response" for flooding synchronisation data? This has to be done 1631 carefully due to the well-known issues with flooding, but it could 1632 be useful, e.g. for Intent distribution, where DNCP doesn't seem 1633 applicable. 1635 RESOLVED: Yes, see #14. 1637 o 17. Ensure that the discovery mechanism is completely proof 1638 against loops and protected against duplicate responses. 1640 RESOLVED: Added loop count mechanism. 1642 o 18. Discuss the handling of multiple valid discovery responses. 1644 o 19. Should we use a text-oriented format such as JSON/CBOR 1645 instead of native binary TLV format? 1647 RESOLVED: Yes, changed to CBOR 1649 o 20. Is the Divert option needed? If a discovery response 1650 provides a valid IP address or FQDN, the recipient doesn't gain 1651 any extra knowledge from the Divert. On the other hand, the 1652 presence of Divert informs the receiver that the target is off- 1653 link, which might be useful sometimes. 1655 o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling 1656 Protocol)? 1658 RESOLVED: Yes, name changed. 1660 o 22. Does discovery mechanism scale robustly as needed? Need hop 1661 limit on relaying? 1663 RESOLVED: Added hop limit. 1665 o 23. Need more details on TTL for caching discovery responses. 1667 RESOLVED: Done. 1669 o 24. Do we need "fast withdrawal" of discovery responses? 1671 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? 1673 o 26. Add a URL type to the locator options (for security 1674 bootstrap) 1676 RESOLVED: Done. 1678 o 27. Security of unsolicited Response multicasts (Section 3.3.5). 1680 o 28. Does ACP support multicast? 1682 o 29. PEN is used to distinguish vendor options. Would it be 1683 better to use a domain name? Anything unique will do. 1685 o 30. Does response to discovery require randomized delays to 1686 mitigate amplification attacks? 1688 o 31. We have specified repeats for failed discovery etc. Is that 1689 sufficient to deal with sleeping nodes? 1691 o 32. We have one-to-one synchronization and flooding 1692 synchronization. Do we also need selective flooding to a subset 1693 of nodes? 1695 5. Security Considerations 1697 It is obvious that a successful attack on negotiation-enabled nodes 1698 would be extremely harmful, as such nodes might end up with a 1699 completely undesirable configuration that would also adversely affect 1700 their peers. GRASP nodes and messages therefore require full 1701 protection. 1703 - Authentication 1705 A cryptographically authenticated identity for each device is 1706 needed in an autonomic network. It is not safe to assume that a 1707 large network is physically secured against interference or that 1708 all personnel are trustworthy. Each autonomic node MUST be 1709 capable of proving its identity and authenticating its messages. 1710 GRASP relies on a separate external certificate-based security 1711 mechanism to support authentication, data integrity protection, 1712 and anti-replay protection. 1714 Since GRASP is intended to be deployed in a single administrative 1715 domain operating its own trust anchor and CA, there is no need for 1716 a trusted public third party. In a network requiring "air gap" 1717 security, such a dependency would be unacceptable. 1719 If GRASP is used temporarily without an external security 1720 mechanism, for example during system bootstrap (Section 3.3.1), 1721 the Session ID (Section 3.6) will act as a nonce to provide 1722 limited protection against third parties injecting responses. A 1723 full analysis of the secure bootstrap process is out of scope for 1724 the present document. 1726 - Privacy and confidentiality 1728 Generally speaking, no personal information is expected to be 1729 involved in the signaling protocol, so there should be no direct 1730 impact on personal privacy. Nevertheless, traffic flow paths, 1731 VPNs, etc. could be negotiated, which could be of interest for 1732 traffic analysis. Also, operators generally want to conceal 1733 details of their network topology and traffic density from 1734 outsiders. Therefore, since insider attacks cannot be excluded in 1735 a large network, the security mechanism for the protocol MUST 1736 provide message confidentiality. 1738 - DoS Attack Protection 1740 GRASP discovery partly relies on insecure link-local multicast. 1741 Since routers participating in GRASP sometimes relay discovery 1742 messages from one link to another, this could be a vector for 1743 denial of service attacks. Relevant mitigations are specified in 1744 Section 3.3.3. Additionally, it is of great importance that 1745 firewalls prevent any GRASP messages from entering the domain from 1746 an untrusted source. 1748 - Security during bootstrap and discovery 1750 A node cannot authenticate GRASP traffic from other nodes until it 1751 has identified the trust anchor and can validate certificates for 1752 other nodes. Also, until it has succesfully enrolled 1753 [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that 1754 other nodes are able to authenticate its own traffic. Therefore, 1755 GRASP discovery during the bootstrap phase for a new device will 1756 inevitably be insecure and GRASP synchronization and negotiation 1757 will be impossible until enrollment is complete. 1759 6. CDDL Specification of GRASP 1761 1763 grasp-message = message 1765 session-id = 0..16777215 1766 ; that is up to 24 bits 1768 message /= discovery-message 1769 discovery-message = [M_DISCOVERY, session-id, objective] 1771 message /= response-message 1772 response-message = [M_RESPONSE, session-id, 1773 (+locator-option // divert-option // objective)] 1775 message /= request-message 1776 request-message = [M_REQUEST, session-id, objective] 1778 message /= negotiation-message 1779 negotiation-message = [M_NEGOTIATE, session-id, objective] 1781 message /= end-message 1782 end-message = [M_END, session-id, (accept-option / decline-option)] 1784 message /= wait-message 1785 wait-message = [M_WAIT, session-id, waiting-time-option] 1787 divert-option = [O_DIVERT, +locator-option] 1789 accept-option = [O_ACCEPT] 1790 decline-option = [O_DECLINE] 1792 waiting-time-option = [O_WAITING, option-waiting-time] 1793 option-waiting-time = 0..4294967295 ; in milliseconds 1795 option-device-id = [O_DEVICE_ID, bytes] 1797 locator-option /= ipv4-locator-option 1798 ipv4-locator-option = bytes .size 4 1799 ; this is simpler than [O_IPv4_LOCATOR, bytes .size 4] 1801 locator-option /= ipv6-locator-option 1802 ipv6-locator-option = bytes .size 16 1804 locator-option /= fqdn-locator-option 1805 fqdn-locator-option = [O_FQDN_LOCATOR, text] 1807 locator-option /= url-locator-option 1808 url-locator-option = [O_URL_LOCATOR, text] 1810 objective-flags = uint .bits objective-flag 1812 objective-flag = &( 1813 D: 0 1814 N: 1 1815 S: 2 1816 ) 1818 ; D means valid for discovery only 1819 ; N means valid for discovery and negotiation 1820 ; S means valid for discovery and synchronization 1822 objective /= generic-obj 1823 generic-obj = [objective-name, objective-flags, loop-count, ?any] 1825 objective /= vendor-obj 1826 vendor-obj = [{"PEN":pen}, objective-name, objective-flags, 1827 loop-count, ?any] 1829 ; A PEN is used to distinguish vendor-specific options. 1831 pen = 0..4294967295 1832 objective-name = tstr 1833 loop-count = 0..255 1835 ; Constants 1837 M_DISCOVERY = 1 1838 M_RESPONSE = 2 1839 M_REQUEST = 3 1840 M_NEGOTIATE = 4 1841 M_END = 5 1842 M_WAIT = 6 1844 O_DIVERT = 100 1845 O_ACCEPT = 101 1846 O_DECLINE = 102 1847 O_WAITING = 103 1848 O_DEVICE_ID = 104 1849 O_FQDN_LOCATOR = 105 1850 O_URL_LOCATOR = 106 1852 1854 7. IANA Considerations 1856 Section 3.5 defines the following link-local multicast addresses, 1857 which have been assigned by IANA for use by GRASP: 1859 ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in 1860 the IPv6 Link-Local Scope Multicast Addresses registry. 1862 ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in 1863 the IPv4 Multicast Local Network Control Block. 1865 (Note in draft: alternatively, we could use 224.0.0.1, currently 1866 defined as All Systems on this Subnet.) 1868 Section 3.5 defines the following UDP and TCP port, which has been 1869 assigned by IANA for use by GRASP: 1871 GRASP_LISTEN_PORT: (TBD3) 1873 This document defines the General Discovery and Negotiation Protocol 1874 (GRASP). The IANA is requested to create a GRASP Parameter Registry. 1875 The IANA is also requested to add two new registry tables to the 1876 newly-created GRASP Parameter Registry. The two tables are the GRASP 1877 Messages and Options Table and the GRASP Objective Names Table. 1879 GRASP Messages and Options Table. The values in this table are names 1880 paired with decimal integers. Future values MUST be assigned using 1881 the Standards Action policy defined by [RFC5226]. The following 1882 initial values are assigned by this document: 1884 M_DISCOVERY = 1 1885 M_RESPONSE = 2 1886 M_REQUEST = 3 1887 M_NEGOTIATE = 4 1888 M_END = 5 1889 M_WAIT = 6 1891 O_DIVERT = 100 1892 O_ACCEPT = 101 1893 O_DECLINE = 102 1894 O_WAITING = 103 1895 O_DEVICE_ID = 104 1896 O_FQDN_LOCATOR = 105 1897 O_URL_LOCATOR = 106 1899 GRASP Objective Names Table. The values in this table are UTF-8 1900 strings. Future values MUST be assigned using the Specification 1901 Required policy defined by [RFC5226]. The following initial values 1902 are assigned by this document: 1904 EX0 1905 EX1 1906 EX2 1907 EX3 1908 EX4 1909 EX5 1910 EX6 1911 EX7 1912 EX8 1913 EX9 1914 PEN 1916 8. Acknowledgements 1918 A major contribution to the original version of this document was 1919 made by Sheng Jiang. 1921 Valuable comments were received from Michael Behringer, Jeferson 1922 Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Zhenbin Li, 1923 Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Michael 1924 Richardson, Markus Stenberg, Rene Struik, Dacheng Zhang, and other 1925 participants in the NMRG research group and the ANIMA working group. 1927 This document was produced using the xml2rfc tool [RFC2629]. 1929 9. Change log [RFC Editor: Please remove] 1931 draft-ietf-anima-grasp-01, 2015-10-09: 1933 Updated requirements after list discussion. 1935 Changed from TLV to CBOR format - many detailed changes, added co- 1936 author. 1938 Tightened up loop count and timeouts for various cases. 1940 Noted that GRASP does not provide transactional integrity. 1942 Various other clarifications and editorial fixes. 1944 draft-ietf-anima-grasp-00, 2015-08-14: 1946 File name and protocol name changed following WG adoption. 1948 Added URL locator type. 1950 draft-carpenter-anima-gdn-protocol-04, 2015-06-21: 1952 Tuned wording around hierarchical structure. 1954 Changed "device" to "ASA" in many places. 1956 Reformulated requirements to be clear that the ASA is the main 1957 customer for signaling. 1959 Added requirement for flooding unsolicited synch, and added it to 1960 protocol spec. Recognized DNCP as alternative for flooding synch 1961 data. 1963 Requirements clarified, expanded and rearranged following design team 1964 discussion. 1966 Clarified that GDNP discovery must not be a prerequisite for GDNP 1967 negotiation or synchronization (resolved issue 13). 1969 Specified flag bits for objective options (resolved issue 15). 1971 Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 1972 9,10,11). 1974 Updated DNCP description from latest DNCP draft. 1976 Editorial improvements. 1978 draft-carpenter-anima-gdn-protocol-03, 2015-04-20: 1980 Removed intrinsic security, required external security 1982 Format changes to allow DNCP co-existence 1984 Recognized DNS-SD as alternative discovery method. 1986 Editorial improvements 1988 draft-carpenter-anima-gdn-protocol-02, 2015-02-19: 1990 Tuned requirements to clarify scope, 1992 Clarified relationship between types of objective, 1994 Clarified that objectives may be simple values or complex data 1995 structures, 1997 Improved description of objective options, 1999 Added loop-avoidance mechanisms (loop count and default timeout, 2000 limitations on discovery relaying and on unsolicited responses), 2002 Allow multiple discovery objectives in one response, 2004 Provided for missing or multiple discovery responses, 2006 Indicated how modes such as "dry run" should be supported, 2008 Minor editorial and technical corrections and clarifications, 2010 Reorganized future work list. 2012 draft-carpenter-anima-gdn-protocol-01, restructured the logical flow 2013 of the document, updated to describe synchronization completely, add 2014 unsolicited responses, numerous corrections and clarifications, 2015 expanded future work list, 2015-01-06. 2017 draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- 2018 config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 2019 02, 2014-10-08. 2021 10. References 2022 10.1. Normative References 2024 [I-D.greevenbosch-appsawg-cbor-cddl] 2025 Vigano, C. and H. Birkholz, "CBOR data definition 2026 language: a notational convention to express CBOR data 2027 structures.", draft-greevenbosch-appsawg-cbor-cddl-06 2028 (work in progress), July 2015. 2030 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2031 Requirement Levels", BCP 14, RFC 2119, 2032 DOI 10.17487/RFC2119, March 1997, 2033 . 2035 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2036 Resource Identifier (URI): Generic Syntax", STD 66, 2037 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2038 . 2040 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2041 "Randomness Requirements for Security", BCP 106, RFC 4086, 2042 DOI 10.17487/RFC4086, June 2005, 2043 . 2045 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2046 (TLS) Protocol Version 1.2", RFC 5246, 2047 DOI 10.17487/RFC5246, August 2008, 2048 . 2050 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2051 Housley, R., and W. Polk, "Internet X.509 Public Key 2052 Infrastructure Certificate and Certificate Revocation List 2053 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2054 . 2056 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2057 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2058 January 2012, . 2060 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2061 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2062 October 2013, . 2064 10.2. Informative References 2066 [I-D.behringer-anima-reference-model] 2067 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 2068 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 2069 for Autonomic Networking", draft-behringer-anima- 2070 reference-model-03 (work in progress), June 2015. 2072 [I-D.chaparadza-intarea-igcp] 2073 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 2074 Mahkonen, "IP based Generic Control Protocol (IGCP)", 2075 draft-chaparadza-intarea-igcp-00 (work in progress), July 2076 2011. 2078 [I-D.eckert-anima-stable-connectivity] 2079 Eckert, T. and M. Behringer, "Using Autonomic Control 2080 Plane for Stable Connectivity of Network OAM", draft- 2081 eckert-anima-stable-connectivity-01 (work in progress), 2082 March 2015. 2084 [I-D.ietf-anima-autonomic-control-plane] 2085 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 2086 Autonomic Control Plane", draft-ietf-anima-autonomic- 2087 control-plane-01 (work in progress), October 2015. 2089 [I-D.ietf-anima-bootstrapping-keyinfra] 2090 Pritikin, M., Richardson, M., Behringer, M., and S. 2091 Bjarnason, "Bootstrapping Key Infrastructures", draft- 2092 ietf-anima-bootstrapping-keyinfra-00 (work in progress), 2093 August 2015. 2095 [I-D.ietf-homenet-dncp] 2096 Stenberg, M. and S. Barth, "Distributed Node Consensus 2097 Protocol", draft-ietf-homenet-dncp-10 (work in progress), 2098 September 2015. 2100 [I-D.ietf-homenet-hncp] 2101 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2102 Control Protocol", draft-ietf-homenet-hncp-09 (work in 2103 progress), August 2015. 2105 [I-D.ietf-netconf-restconf] 2106 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2107 Protocol", draft-ietf-netconf-restconf-07 (work in 2108 progress), July 2015. 2110 [I-D.liang-iana-pen] 2111 Liang, P., Melnikov, A., and D. Conrad, "Private 2112 Enterprise Number (PEN) practices and Internet Assigned 2113 Numbers Authority (IANA) registration considerations", 2114 draft-liang-iana-pen-06 (work in progress), July 2015. 2116 [I-D.stenberg-anima-adncp] 2117 Stenberg, M., "Autonomic Distributed Node Consensus 2118 Protocol", draft-stenberg-anima-adncp-00 (work in 2119 progress), March 2015. 2121 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2122 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2123 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2124 September 1997, . 2126 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 2127 "Service Location Protocol, Version 2", RFC 2608, 2128 DOI 10.17487/RFC2608, June 1999, 2129 . 2131 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2132 DOI 10.17487/RFC2629, June 1999, 2133 . 2135 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2136 "Remote Authentication Dial In User Service (RADIUS)", 2137 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2138 . 2140 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2141 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2142 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2143 . 2145 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2146 C., and M. Carney, "Dynamic Host Configuration Protocol 2147 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2148 2003, . 2150 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 2151 for the Simple Network Management Protocol (SNMP)", 2152 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 2153 . 2155 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2156 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2157 DOI 10.17487/RFC4861, September 2007, 2158 . 2160 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2161 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2162 DOI 10.17487/RFC5226, May 2008, 2163 . 2165 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2166 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2167 October 2010, . 2169 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 2170 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 2171 March 2011, . 2173 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2174 and A. Bierman, Ed., "Network Configuration Protocol 2175 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2176 . 2178 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2179 Ed., "Diameter Base Protocol", RFC 6733, 2180 DOI 10.17487/RFC6733, October 2012, 2181 . 2183 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2184 DOI 10.17487/RFC6762, February 2013, 2185 . 2187 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2188 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2189 . 2191 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2192 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2193 DOI 10.17487/RFC6887, April 2013, 2194 . 2196 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2197 Constrained-Node Networks", RFC 7228, 2198 DOI 10.17487/RFC7228, May 2014, 2199 . 2201 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 2202 "Requirements for Scalable DNS-Based Service Discovery 2203 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 2204 DOI 10.17487/RFC7558, July 2015, 2205 . 2207 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2208 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2209 Networking: Definitions and Design Goals", RFC 7575, 2210 DOI 10.17487/RFC7575, June 2015, 2211 . 2213 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 2214 Analysis for Autonomic Networking", RFC 7576, 2215 DOI 10.17487/RFC7576, June 2015, 2216 . 2218 Appendix A. Capability Analysis of Current Protocols 2220 This appendix discusses various existing protocols with properties 2221 related to the above negotiation and synchronisation requirements. 2222 The purpose is to evaluate whether any existing protocol, or a simple 2223 combination of existing protocols, can meet those requirements. 2225 Numerous protocols include some form of discovery, but these all 2226 appear to be very specific in their applicability. Service Location 2227 Protocol (SLP) [RFC2608] provides service discovery for managed 2228 networks, but requires configuration of its own servers. DNS-SD 2229 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 2230 small networks with a single link layer. [RFC7558] aims to extend 2231 this to larger autonomous networks but this is not yet standardized. 2232 However, both SLP and DNS-SD appear to target primarily application 2233 layer services, not the layer 2 and 3 objectives relevant to basic 2234 network configuration. Both SLP and DNS-SD are text-based protocols. 2236 Routing protocols are mainly one-way information announcements. The 2237 receiver makes independent decisions based on the received 2238 information and there is no direct feedback information to the 2239 announcing peer. This remains true even though the protocol is used 2240 in both directions between peer routers; there is state 2241 synchronization, but no negotiation, and each peer runs its route 2242 calculations independently. 2244 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 2245 response model not well suited for peer negotiation. Network 2246 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 2247 does allow positive or negative responses from the target system, but 2248 this is still not adequate for negotiation. 2250 There are various existing protocols that have elementary negotiation 2251 abilities, such as Dynamic Host Configuration Protocol for IPv6 2252 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 2253 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 2254 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 2255 configuration or management protocols. However, they either provide 2256 only a simple request/response model in a master/slave context or 2257 very limited negotiation abilities. 2259 There are some signaling protocols with an element of negotiation. 2260 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 2261 designed for negotiating quality of service parameters along the path 2262 of a unicast or multicast flow. RSVP is a very specialised protocol 2263 aimed at end-to-end flows. However, it has some flexibility, having 2264 been extended for MPLS label distribution [RFC3209]. A more generic 2265 design is General Internet Signalling Transport (GIST) [RFC5971], but 2266 it is complex, tries to solve many problems, and is also aimed at 2267 per-flow signaling across many hops rather than at device-to-device 2268 signaling. However, we cannot completely exclude extended RSVP or 2269 GIST as a synchronization and negotiation protocol. They do not 2270 appear to be directly useable for peer discovery. 2272 We now consider two protocols that are works in progress at the time 2273 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 2274 protocol intended to convey NETCONF information expressed in the YANG 2275 language via HTTP, including the ability to transit HTML 2276 intermediaries. While this is a powerful approach in the context of 2277 centralised configuration of a complex network, it is not well 2278 adapted to efficient interactive negotiation between peer devices, 2279 especially simple ones that are unlikely to include YANG processing 2280 already. 2282 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 2283 [I-D.ietf-homenet-dncp]. This is defined as a generic form of state 2284 synchronization protocol, with a proposed usage profile being the 2285 Home Networking Control Protocol (HNCP) [I-D.ietf-homenet-hncp] for 2286 configuring Homenet routers. A specific application of DNCP for 2287 autonomic networking was proposed in [I-D.stenberg-anima-adncp]. 2289 DNCP "is designed to provide a way for each participating node to 2290 publish a set of TLV (Type-Length-Value) tuples, and to provide a 2291 shared and common view about the data published... DNCP is most 2292 suitable for data that changes only infrequently... If constant rapid 2293 state changes are needed, the preferable choice is to use an 2294 additional point-to-point channel..." 2296 Specific features of DNCP include: 2298 o Every participating node has a unique node identifier. 2300 o DNCP messages are encoded as a sequence of TLV objects, sent over 2301 unicast UDP or TCP, with or without (D)TLS security. 2303 o Multicast is used only for discovery of DNCP neighbors when lower 2304 security is acceptable. 2306 o Synchronization of state is maintained by a flooding process using 2307 the Trickle algorithm. There is no bilateral synchronization or 2308 negotiation capability. 2310 o The HNCP profile of DNCP is designed to operate between directly 2311 connected neighbors on a shared link using UDP and link-local IPv6 2312 addresses. 2314 DNCP does not meet the needs of a general negotiation protocol, 2315 because it is designed specifically for flooding synchronization. 2316 Also, in its HNCP profile it is limited to link-local messages and to 2317 IPv6. However, at the minimum it is a very interesting test case for 2318 this style of interaction between devices without needing a central 2319 authority, and it is a proven method of network-wide state 2320 synchronization by flooding. 2322 A proposal was made some years ago for an IP based Generic Control 2323 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 2324 information exchange and negotiation but not directly at peer 2325 discovery. However, it has many points in common with the present 2326 work. 2328 None of the above solutions appears to completely meet the needs of 2329 generic discovery, state synchronization and negotiation in a single 2330 solution. Many of the protocols assume that they are working in a 2331 traditional top-down or north-south scenario, rather than a fluid 2332 peer-to-peer scenario. Most of them are specialized in one way or 2333 another. As a result, we have not identified a combination of 2334 existing protocols that meets the requirements in Section 2. Also, 2335 we have not identified a path by which one of the existing protocols 2336 could be extended to meet the requirements. 2338 Authors' Addresses 2339 Carsten Bormann 2340 Universitaet Bremen TZI 2341 Postfach 330440 2342 D-28359 Bremen 2343 Germany 2345 Email: cabo@tzi.org 2347 Brian Carpenter (editor) 2348 Department of Computer Science 2349 University of Auckland 2350 PB 92019 2351 Auckland 1142 2352 New Zealand 2354 Email: brian.e.carpenter@gmail.com 2356 Bing Liu (editor) 2357 Huawei Technologies Co., Ltd 2358 Q14, Huawei Campus 2359 No.156 Beiqing Road 2360 Hai-Dian District, Beijing 100095 2361 P.R. China 2363 Email: leo.liubing@huawei.com