idnits 2.17.1 draft-ietf-anima-grasp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2016) is 2984 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) == Unused Reference: 'RFC7217' is defined on line 1903, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-07 ** 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 (-30) exists of draft-ietf-anima-autonomic-control-plane-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-01 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-09 -- 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 (~~), 6 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: August 27, 2016 Univ. of Auckland 6 B. Liu, Ed. 7 Huawei Technologies Co., Ltd 8 February 24, 2016 10 A Generic Autonomic Signaling Protocol (GRASP) 11 draft-ietf-anima-grasp-03 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 August 27, 2016. 41 Copyright Notice 43 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . 10 66 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . 16 71 3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16 72 3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 19 73 3.3.5. Synchronization and Flooding Procedure . . . . . . . 20 74 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 21 75 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 22 76 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 22 77 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 23 78 3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 23 79 3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 23 80 3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 24 81 3.7.4. Discovery Response Message . . . . . . . . . . . . . 25 82 3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 25 83 3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 26 84 3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 26 85 3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 27 86 3.7.9. Synchronization Message . . . . . . . . . . . . . . . 27 87 3.7.10. Flood Synchronization Message . . . . . . . . . . . . 27 88 3.7.11. No Operation Message . . . . . . . . . . . . . . . . 28 89 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 28 90 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 28 91 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 28 92 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 29 93 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 29 94 3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 29 95 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 31 96 3.9.1. Format of Objective Options . . . . . . . . . . . . . 31 97 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 32 98 3.9.3. General Considerations for Objective Options . . . . 32 99 3.9.4. Organizing of Objective Options . . . . . . . . . . . 33 100 3.9.5. Experimental and Example Objective Options . . . . . 34 101 4. Security Considerations . . . . . . . . . . . . . . . . . . . 34 102 5. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 36 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 104 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 106 8.1. Normative References . . . . . . . . . . . . . . . . . . 40 107 8.2. Informative References . . . . . . . . . . . . . . . . . 41 108 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 44 109 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 45 110 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 51 111 Appendix D. Capability Analysis of Current Protocols . . . . . . 54 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 114 1. Introduction 116 The success of the Internet has made IP-based networks bigger and 117 more complicated. Large-scale ISP and enterprise networks have 118 become more and more problematic for human based management. Also, 119 operational costs are growing quickly. Consequently, there are 120 increased requirements for autonomic behavior in the networks. 121 General aspects of autonomic networks are discussed in [RFC7575] and 122 [RFC7576]. 124 One approach is to largely decentralize the logic of network 125 management by migrating it into network elements. A reference model 126 for autonomic networking on this basis is given in 127 [I-D.behringer-anima-reference-model]. In order to fulfil autonomy, 128 devices that embody autonomic service agents have specific signaling 129 requirements. In particular they need to discover each other, to 130 synchronize state with each other, and to negotiate parameters and 131 resources directly with each other. There is no restriction on the 132 type of parameters and resources concerned, which include very basic 133 information needed for addressing and routing, as well as anything 134 else that might be configured in a conventional non-autonomic 135 network. The atomic unit of synchronization or negotiation is 136 referred to as a technical objective, i.e, a configurable parameter 137 or set of parameters (defined more precisely in Section 3.1). 139 Following this Introduction, Section 2 describes the requirements for 140 discovery, synchronization and negotiation. Negotiation is an 141 iterative process, requiring multiple message exchanges forming a 142 closed loop between the negotiating devices. State synchronization, 143 when needed, can be regarded as a special case of negotiation, 144 without iteration. Section 3.2 describes a behavior model for a 145 protocol intended to support discovery, synchronization and 146 negotiation. The design of GeneRic Autonomic Signaling Protocol 147 (GRASP) in Section 3 of this document is mainly based on this 148 behavior model. The relevant capabilities of various existing 149 protocols are reviewed in Appendix D. 151 The proposed discovery mechanism is oriented towards synchronization 152 and negotiation objectives. It is based on a neighbor discovery 153 process, but also supports diversion to off-link peers. Although 154 many negotiations will occur between horizontally distributed peers, 155 many target scenarios are hierarchical networks, which is the 156 predominant structure of current large-scale managed networks. 157 However, when a device starts up with no pre-configuration, it has no 158 knowledge of the topology. The protocol itself is capable of being 159 used in a small and/or flat network structure such as a small office 160 or home network as well as a professionally managed network. 161 Therefore, the discovery mechanism needs to be able to allow a device 162 to bootstrap itself without making any prior assumptions about 163 network structure. 165 Because GRASP can be used to perform a decision process among 166 distributed devices or between networks, it must run in a secure and 167 strongly authenticated environment. 169 It is understood that in realistic deployments, not all devices will 170 support GRASP. It is expected that some autonomic service agents 171 will directly manage a group of non-autonomic nodes, and that other 172 non-autonomic nodes will be managed traditionally. Such mixed 173 scenarios are not discussed in this specification. 175 2. Requirement Analysis of Discovery, Synchronization and Negotiation 177 This section discusses the requirements for discovery, negotiation 178 and synchronization capabilities. The primary user of the protocol 179 is an autonomic service agent (ASA), so the requirements are mainly 180 expressed as the features needed by an ASA. A single physical device 181 might contain several ASAs, and a single ASA might manage several 182 technical objectives. 184 Note that requirements for ASAs themselves, such as the processing of 185 Intent [RFC7575] or interfaces for coordination between ASAs are out 186 of scope for the present document. 188 2.1. Requirements for Discovery 190 D1. ASAs may be designed to manage anything, as required in 191 Section 2.2. A basic requirement is therefore that the protocol can 192 represent and discover any kind of technical objective among 193 arbitrary subsets of participating nodes. 195 In an autonomic network we must assume that when a device starts up 196 it has no information about any peer devices, the network structure, 197 or what specific role it must play. The ASA(s) inside the device are 198 in the same situation. In some cases, when a new application session 199 starts up within a device, the device or ASA may again lack 200 information about relevant peers. It might be necessary to set up 201 resources on multiple other devices, coordinated and matched to each 202 other so that there is no wasted resource. Security settings might 203 also need updating to allow for the new device or user. The relevant 204 peers may be different for different technical objectives. Therefore 205 discovery needs to be repeated as often as necessary to find peers 206 capable of acting as counterparts for each objective that a discovery 207 initiator needs to handle. From this background we derive the next 208 three requirements: 210 D2. When an ASA first starts up, it has no knowledge of the specific 211 network to which it is attached. Therefore the discovery process 212 must be able to support any network scenario, assuming only that the 213 device concerned is bootstrapped from factory condition. 215 D3. When an ASA starts up, it must require no information about any 216 peers in order to discover them. 218 D4. If an ASA supports multiple technical objectives, relevant peers 219 may be different for different discovery objectives, so discovery 220 needs to be repeated to find counterparts for each objective. Thus, 221 there must be a mechanism by which an ASA can separately discover 222 peer ASAs for each of the technical objectives that it needs to 223 manage, whenever necessary. 225 D5. Following discovery, an ASA will normally perform negotiation or 226 synchronization for the corresponding objectives. The design should 227 allow for this by associating discovery, negotiation and 228 synchronization objectives. It may provide an optional mechanism to 229 combine discovery and negotiation/synchronization in a single call. 231 D6. Some objectives may only be significant on the local link, but 232 others may be significant across the routed network and require off- 233 link operations. Thus, the relevant peers might be immediate 234 neighbors on the same layer 2 link, or they might be more distant and 235 only accessible via layer 3. The mechanism must therefore provide 236 both on-link and off-link discovery of ASAs supporting specific 237 technical objectives. 239 D7. The discovery process should be flexible enough to allow for 240 special cases, such as the following: 242 o In some networks, as mentioned above, there will be some 243 hierarchical structure, at least for certain synchronization or 244 negotiation objectives, but this is unknown in advance. The 245 discovery protocol must therefore operate regardless of 246 hierarchical structure, which is an attribute of individual 247 technical objectives and not of the autonomic network as a whole. 248 This is part of the more general requirement to discover off-link 249 peers. 251 o During initialisation, a device must be able to establish mutual 252 trust with the rest of the network and join an authentication 253 mechanism. Although this will inevitably start with a discovery 254 action, it is a special case precisely because trust is not yet 255 established. This topic is the subject of 256 [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once 257 trust has been established for a device, all ASAs within the 258 device inherit the device's credentials and are also trusted. 260 o Depending on the type of network involved, discovery of other 261 central functions might be needed, such as the Network Operations 262 Center (NOC) [I-D.eckert-anima-stable-connectivity]. The protocol 263 must be capable of supporting such discovery during 264 initialisation, as well as discovery during ongoing operation. 266 D8. The discovery process must not generate excessive traffic and 267 must take account of sleeping nodes in the case of a constrained-node 268 network [RFC7228]. 270 D9. There must be a mechanism for handling stale discovery results. 272 2.2. Requirements for Synchronization and Negotiation Capability 274 As background, consider the example of routing protocols, the closest 275 approximation to autonomic networking already in widespread use. 276 Routing protocols use a largely autonomic model based on distributed 277 devices that communicate repeatedly with each other. The focus is 278 reachability, so current routing protocols mainly consider simple 279 link status, i.e., up or down, and an underlying assumption is that 280 all nodes need a consistent view of the network topology in order for 281 the routing algorithm to converge. Thus, routing is mainly based on 282 information synchronization between peers, rather than on bi- 283 directional negotiation. Other information, such as latency, 284 congestion, capacity, and particularly unused capacity, would be 285 helpful to get better path selection and utilization rate, but is not 286 normally used in distributed routing algorithms. Additionally, 287 autonomic networks need to be able to manage many more dimensions, 288 such as security settings, power saving, load balancing, etc. Status 289 information and traffic metrics need to be shared between nodes for 290 dynamic adjustment of resources and for monitoring purposes. While 291 this might be achieved by existing protocols when they are available, 292 the new protocol needs to be able to support parameter exchange, 293 including mutual synchronization, even when no negotiation as such is 294 required. In general, these parameters do not apply to all 295 participating nodes, but only to a subset. 297 SN1. A basic requirement for the protocol is therefore the ability 298 to represent, discover, synchronize and negotiate almost any kind of 299 network parameter among arbitrary subsets of participating nodes. 301 SN2. Negotiation is a request/response process that must be 302 guaranteed to terminate (with success or failure) and if necessary it 303 must contain tie-breaking rules for each technical objective that 304 requires them. While these must be defined specifically for each use 305 case, the protocol should have some general mechanisms in support of 306 loop and deadlock prevention, such as hop count limits or timeouts. 308 SN3. Synchronization might concern small groups of nodes or very 309 large groups. Different solutions might be needed at different 310 scales. 312 SN4. To avoid "reinventing the wheel", the protocol should be able 313 to carry the message formats used by existing configuration protocols 314 (such as NETCONF/YANG) in cases where that is convenient. 316 SN5. Human intervention in complex situations is costly and error- 317 prone. Therefore, synchronization or negotiation of parameters 318 without human intervention is desirable whenever the coordination of 319 multiple devices can improve overall network performance. It 320 therefore follows that the protocol, as part of the Autonomic 321 Networking Infrastructure, must be capable of running in any device 322 that would otherwise need human intervention. 324 SN6. Human intervention in large networks is often replaced by use 325 of a top-down network management system (NMS). It therefore follows 326 that the protocol, as part of the Autonomic Networking 327 Infrastructure, must be capable of running in any device that would 328 otherwise be managed by an NMS, and that it can co-exist with an NMS, 329 and with protocols such as SNMP and NETCONF. 331 SN7. Some features are expected to be implemented by individual 332 ASAs, but the protocol must be general enough to allow them: 334 o Dependencies and conflicts: In order to decide a configuration on 335 a given device, the device may need information from neighbors. 336 This can be established through the negotiation procedure, or 337 through synchronization if that is sufficient. However, a given 338 item in a neighbor may depend on other information from its own 339 neighbors, which may need another negotiation or synchronization 340 procedure to obtain or decide. Therefore, there are potential 341 dependencies and conflicts among negotiation or synchronization 342 procedures. Resolving dependencies and conflicts is a matter for 343 the individual ASAs involved. To allow this, there need to be 344 clear boundaries and convergence mechanisms for negotiations. 345 Also some mechanisms are needed to avoid loop dependencies. In 346 such a case, the protocol's role is limited to signaling between 347 ASAs. 349 o Recovery from faults and identification of faulty devices should 350 be as automatic as possible. The protocol's role is limited to 351 the ability to handle discovery, synchronization and negotiation 352 at any time, in case an ASA detects an anomaly such as a 353 negotiation counterpart failing. 355 o Since the goal is to minimize human intervention, it is necessary 356 that the network can in effect "think ahead" before changing its 357 parameters. In other words there must be a possibility of 358 forecasting the effect of a change by a "dry run" mechanism before 359 actually installing the change. This will be an application of 360 the protocol rather than a feature of the protocol itself. 362 o Management logging, monitoring, alerts and tools for intervention 363 are required. However, these can only be features of individual 364 ASAs. Another document [I-D.eckert-anima-stable-connectivity] 365 discusses how such agents may be linked into conventional OAM 366 systems via an Autonomic Control Plane 367 [I-D.ietf-anima-autonomic-control-plane]. 369 SN8. The protocol will be able to deal with a wide variety of 370 technical objectives, covering any type of network parameter. 371 Therefore the protocol will need either an explicit information model 372 describing its messages, or at least a flexible and easily extensible 373 message format. One design consideration is whether to adopt an 374 existing information model or to design a new one. 376 2.3. Specific Technical Requirements 378 T1. It should be convenient for ASA designers to define new 379 technical objectives and for programmers to express them, without 380 excessive impact on run-time efficiency and footprint. The classes 381 of device in which the protocol might run is discussed in 382 [I-D.behringer-anima-reference-model]. 384 T2. The protocol should be easily extensible in case the initially 385 defined discovery, synchronization and negotiation mechanisms prove 386 to be insufficient. 388 T3. To be a generic platform, the protocol payload format should be 389 independent of the transport protocol or IP version. In particular, 390 it should be able to run over IPv6 or IPv4. However, some functions, 391 such as multicasting on a link, might need to be IP version 392 dependent. In case of doubt, IPv6 should be preferred. 394 T4. The protocol must be able to access off-link counterparts via 395 routable addresses, i.e., must not be restricted to link-local 396 operation. 398 T5. It must also be possible for an external discovery mechanism to 399 be used, if appropriate for a given technical objective. In other 400 words, GRASP discovery must not be a prerequisite for GRASP 401 negotiation or synchronization; the prerequisite is discovering a 402 peer's locator by any method. 404 T6. ASAs and the signaling protocol need to run asynchronously when 405 wait states occur. 407 T7. Intent: There must be provision for general Intent rules to be 408 applied by all devices in the network (e.g., security rules, prefix 409 length, resource sharing rules). However, Intent distribution might 410 not use the signaling protocol itself, but its design should not 411 exclude such use. 413 T8. Management monitoring, alerts and intervention: Devices should 414 be able to report to a monitoring system. Some events must be able 415 to generate operator alerts and some provision for emergency 416 intervention must be possible (e.g. to freeze synchronization or 417 negotiation in a mis-behaving device). These features might not use 418 the signaling protocol itself, but its design should not exclude such 419 use. 421 T9. The protocol needs to be fully secured against forged messages 422 and man-in-the middle attacks, and secured as much as reasonably 423 possible against denial of service attacks. It needs to be capable 424 of encryption in order to resist unwanted monitoring. However, it is 425 not required that the protocol itself provides these security 426 features; it may depend on an existing secure environment. 428 3. GRASP Protocol Overview 430 3.1. Terminology 432 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 433 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 434 "OPTIONAL" in this document are to be interpreted as described in 435 [RFC2119] when they appear in ALL CAPS. When these words are not in 436 ALL CAPS (such as "should" or "Should"), they have their usual 437 English meanings, and are not to be interpreted as [RFC2119] key 438 words. 440 This document uses terminology defined in [RFC7575]. 442 The following additional terms are used throughout this document: 444 o Autonomic Device: identical to Autonomic Node. 446 o Discovery: a process by which an ASA discovers peers according to 447 a specific discovery objective. The discovery results may be 448 different according to the different discovery objectives. The 449 discovered peers may later be used as negotiation counterparts or 450 as sources of synchronization data. 452 o Negotiation: a process by which two (or more) ASAs interact 453 iteratively to agree on parameter settings that best satisfy the 454 objectives of one or more ASAs. 456 o State Synchronization: a process by which two (or more) ASAs 457 interact to agree on the current state of parameter values stored 458 in each ASA. This is a special case of negotiation in which 459 information is sent but the ASAs do not request their peers to 460 change parameter settings. All other definitions apply to both 461 negotiation and synchronization. 463 o Technical Objective (usually abbreviated as Objective): A 464 technical objective is a configurable parameter or set of 465 parameters of some kind, which occurs in three contexts: 466 Discovery, Negotiation and Synchronization. In the protocol, an 467 objective is represented by an identifier and if relevant a value. 468 Normally, a given objective will occur during discovery and 469 negotiation, or during discovery and synchronization, but not in 470 all three contexts. 472 * One ASA may support multiple independent objectives. 474 * The parameter described by a given objective is naturally based 475 on a specific service or function or action. It may in 476 principle be anything that can be set to a specific logical, 477 numerical or string value, or a more complex data structure, by 478 a network node. That node is generally expected to contain an 479 ASA which may itself manage other nodes. 481 * Discovery Objective: if a node needs to synchronize or 482 negotiate a specific objective but does not know a peer that 483 supports this objective, it starts a discovery process. The 484 objective is called a Discovery Objective during this process. 486 * Synchronization Objective: an objective whose specific 487 technical content needs to be synchronized among two or more 488 ASAs. 490 * Negotiation Objective: an objective whose specific technical 491 content needs to be decided in coordination with another ASA. 493 o Discovery Initiator: an ASA that spontaneously starts discovery by 494 sending a discovery message referring to a specific discovery 495 objective. 497 o Discovery Responder: a peer ASA which responds to the discovery 498 objective initiated by the discovery initiator. 500 o Synchronization Initiator: an ASA that spontaneously starts 501 synchronization by sending a request message referring to a 502 specific synchronization objective. 504 o Synchronization Responder: a peer ASA which responds with the 505 value of a synchronization objective. 507 o Negotiation Initiator: an ASA that spontaneously starts 508 negotiation by sending a request message referring to a specific 509 negotiation objective. 511 o Negotiation Counterpart: a peer with which the Negotiation 512 Initiator negotiates a specific negotiation objective. 514 3.2. High-Level Design Choices 516 This section describes a behavior model and some considerations for 517 designing a generic signaling protocol initially supporting 518 discovery, synchronization and negotiation, which can act as a 519 platform for different technical objectives. 521 o A generic platform 522 The protocol is designed as a generic platform, which is 523 independent from the synchronization or negotiation contents. It 524 takes care of the general intercommunication between counterparts. 525 The technical contents will vary according to the various 526 technical objectives and the different pairs of counterparts. 528 o The protocol is expected to form part of an Autonomic Networking 529 Infrastructure [I-D.behringer-anima-reference-model]. It will 530 provide services to ASAs via a suitable application programming 531 interface, which will reflect the protocol elements but will not 532 necessarily be in one-to-one correspondence to them. It is 533 expected that a single instance of GRASP will exist in an 534 autonomic node, and that the protocol engine and each ASA will run 535 as independent asynchronous processes. 537 o Security infrastructure and trust relationship 539 Because this negotiation protocol may directly cause changes to 540 device configurations and bring significant impacts to a running 541 network, this protocol is assumed to run within an existing secure 542 environment with strong authentication. 544 On the other hand, a limited negotiation model might be deployed 545 based on a limited trust relationship. For example, between two 546 administrative domains, ASAs might also exchange limited 547 information and negotiate some particular configurations based on 548 a limited conventional or contractual trust relationship. 550 o Discovery, synchronization and negotiation are designed together. 552 The discovery method and the synchronization and negotiation 553 methods are designed in the same way and can be combined when this 554 is useful. These processes can also be performed independently 555 when appropriate. 557 * GRASP discovery is always available for efficient discovery of 558 GRASP peers and allows a rapid mode of operation described in 559 Section 3.3.3. For some objectives, especially those concerned 560 with application layer services, another discovery mechanism 561 such as the future DNS Service Discovery [RFC7558] or Service 562 Location Protocol [RFC2608] MAY be used. The choice is left to 563 the designers of individual ASAs. 565 o A uniform pattern for technical contents 566 The synchronization and negotiation contents are defined according 567 to a uniform pattern. They could be carried either in simple 568 binary format or in payloads described by a flexible language. 569 The basic protocol design uses the Concise Binary Object 570 Representation (CBOR) [RFC7049]. The format is extensible for 571 unknown future requirements. 573 o A flexible model for synchronization 575 GRASP supports bilateral synchronization, which could be used to 576 perform synchronization among a small number of nodes. It also 577 supports an unsolicited flooding mode when large groups of nodes, 578 possibly including all autonomic nodes, need data for the same 579 technical objective. 581 * There may be some network parameters for which a more 582 traditional flooding mechanism such as DNCP 583 [I-D.ietf-homenet-dncp] is considered more appropriate. GRASP 584 can coexist with DNCP. 586 o A simple initiator/responder model for negotiation 588 Multi-party negotiations are too complicated to be modeled and 589 there might be too many dependencies among the parties to converge 590 efficiently. A simple initiator/responder model is more feasible 591 and can complete multi-party negotiations by indirect steps. 593 o Organizing of synchronization or negotiation content 595 Naturally, the technical content will be organized according to 596 the relevant function or service. The content from different 597 functions or services is kept independent from each other. They 598 are not combined into a single option or single session because 599 these contents may be negotiated or synchronized with different 600 counterparts or may be different in response time. 602 o Self-aware network device 604 Every autonomic device will be pre-loaded with various functions 605 and ASAs and will be aware of its own capabilities, typically 606 decided by the hardware, firmware or pre-installed software. Its 607 exact role may depend on Intent and on the surrounding network 608 behaviors, which may include forwarding behaviors, aggregation 609 properties, topology location, bandwidth, tunnel or translation 610 properties, etc. The surrounding topology will depend on the 611 network planning. Following an initial discovery phase, the 612 device properties and those of its neighbors are the foundation of 613 the synchronization or negotiation behavior of a specific device. 614 A device has no pre-configuration for the particular network in 615 which it is installed. 617 o Requests and responses in negotiation procedures 619 The initiator can negotiate with its relevant negotiation 620 counterpart ASAs, which may be different according to the specific 621 negotiation objective. It can request relevant information from 622 the negotiation counterpart so that it can decide its local 623 configuration to give the most coordinated performance. It can 624 request the negotiation counterpart to make a matching 625 configuration in order to set up a successful communication with 626 it. It can request certain simulation or forecast results by 627 sending some dry run conditions. 629 Beyond the traditional yes/no answer, the responder can reply with 630 a suggested alternative if its answer is 'no'. This would start a 631 bi-directional negotiation ending in a compromise between the two 632 ASAs. 634 o Convergence of negotiation procedures 636 To enable convergence, when a responder makes a suggestion of a 637 changed condition in a negative reply, it should be as close as 638 possible to the original request or previous suggestion. The 639 suggested value of the third or later negotiation steps should be 640 chosen between the suggested values from the last two negotiation 641 steps. In any case there must be a mechanism to guarantee 642 convergence (or failure) in a small number of steps, such as a 643 timeout or maximum number of iterations. 645 * End of negotiation 647 A limited number of rounds, for example three, or a timeout, is 648 needed on each ASA for each negotiation objective. It may be 649 an implementation choice, a pre-configurable parameter, or 650 network Intent. These choices might vary between different 651 types of ASA. Therefore, the definition of each negotiation 652 objective MUST clearly specify this, so that the negotiation 653 can always be terminated properly. 655 * Failed negotiation 657 There must be a well-defined procedure for concluding that a 658 negotiation cannot succeed, and if so deciding what happens 659 next (deadlock resolution, tie-breaking, or revert to best- 660 effort service). Again, this MUST be specified for individual 661 negotiation objectives, as an implementation choice, a pre- 662 configurable parameter, or network Intent. 664 3.3. GRASP Protocol Basic Properties and Mechanisms 666 3.3.1. Required External Security Mechanism 668 The protocol SHOULD run within a secure Autonomic Control Plane (ACP) 669 [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to 670 carry all messages securely, including link-local multicast if 671 possible. A GRASP implementation MUST verify whether the ACP is 672 operational. 674 If there is no ACP, the protocol MUST use another form of strong 675 authentication and SHOULD use a form of strong encryption. TLS 676 [RFC5246] is RECOMMENDED for this purpose, based on a local Public 677 Key Infrastructure (PKI) [RFC5280] managed within the autonomic 678 network itself. The details of such a PKI and how its boundary is 679 established are out of scope for this document. DTLS [RFC6347] MAY 680 be used but since GRASP operations usually involve several messages 681 this is not expected to be advantageous. 683 The ACP, or in its absence the local PKI, sets the boundary within 684 which nodes are trusted as GRASP peers. A GRASP implementation MUST 685 refuse to execute any GRASP functions except discovery if there is 686 neither an operational ACP nor an operational TLS environment. 688 As mentioned in Section 3.2, limited GRASP operations might be 689 performed across an administrative domain boundary by mutual 690 agreement. Such operations MUST be authenticated and SHOULD be 691 encrypted. TLS is RECOMMENDED for this purpose. 693 Link-local multicast is used for discovery messages. Responses to 694 discovery messages MUST be secured, with one exception. 696 The exception is that during initialisation, before a node has joined 697 the applicable trust infrastructure, e.g., 698 [I-D.ietf-anima-bootstrapping-keyinfra], or before the ACP is fully 699 established, it might be impossible to secure messages. Indeed, both 700 the security bootstrap process and the ACP creation process might use 701 insecure GRASP discovery and response messages. Such usage MUST be 702 limited to the strictly necessary minimum. A full analysis of the 703 initialisation process is out of scope for the present document. 705 3.3.2. Transport Layer Usage 707 GRASP discovery and flooding messages are designed for use over link- 708 local multicast UDP. They MUST NOT be fragmented, and therefore MUST 709 NOT exceed the link MTU size. Nothing in principle prevents them 710 from working over some other method of sending packets to all on-link 711 neighbors, but this is out of scope for the present specification. 713 All other GRASP messages are unicast and could in principle run over 714 any transport protocol. An implementation MUST support use of TCP. 715 It MAY support use of another transport protocol. However, GRASP 716 itself does not provide for error detection or retransmission. Use 717 of an unreliable transport protocol is therefore NOT RECOMMENDED. 719 When running within a secure ACP on reliable infrastructure, UDP MAY 720 be used for unicast messages not exceeding the minimum IPv6 path MTU; 721 however, TCP MUST be used for longer messages. In other words, IPv6 722 fragmentation is avoided. If a node receives a UDP message but the 723 reply is too long, it MUST open a TCP connection to the peer for the 724 reply. Note that when the network is under heavy load or in a fault 725 condition, UDP might become unreliable. Since this is when autonomic 726 functions are most necessary, automatic fallback to TCP MUST be 727 implemented. The simplest implementation is therefore to use only 728 TCP. 730 When running without an ACP, TLS MUST be supported and used by 731 default, except for link-local multicast messages. DTLS MAY be 732 supported as an alternative but the details are out of scope for this 733 document. 735 For all transport protocols, the GRASP protocol listens to the GRASP 736 Listen Port (Section 3.5). 738 3.3.3. Discovery Mechanism and Procedures 740 o Separated discovery and negotiation mechanisms 742 Although discovery and negotiation or synchronization are 743 defined together in the GRASP, they are separated mechanisms. 744 The discovery process could run independently from the 745 negotiation or synchronization process. Upon receiving a 746 Discovery (Section 3.7.3) message, the recipient ASA should 747 return a response message in which it either indicates itself 748 as a discovery responder or diverts the initiator towards 749 another more suitable ASA. 751 The discovery action will normally be followed by a negotiation 752 or synchronization action. The discovery results could be 753 utilized by the negotiation protocol to decide which ASA the 754 initiator will negotiate with. 756 It is entirely possible to use GRASP discovery without a 757 subsequent negotiation or synchronization action. In this 758 case, the discovered objective is simply used as a name during 759 the discovery process and any subsequent operations between the 760 peers are outside the scope of GRASP. 762 o Discovery Procedures 764 Discovery starts as an on-link operation. The Divert option 765 can tell the discovery initiator to contact an off-link ASA for 766 that discovery objective. Every Discovery message is sent by a 767 discovery initiator via UDP to the ALL_GRASP_NEIGHBOR multicast 768 address (Section 3.5). Every network device that supports the 769 GRASP always listens to a well-known UDP port to capture the 770 discovery messages. 772 If an ASA in the neighbor device supports the requested 773 discovery objective, it MAY respond with a Discovery Response 774 message (Section 3.7.4) with locator option(s). Otherwise, if 775 the neighbor has cached information about an ASA that supports 776 the requested discovery objective (usually because it 777 discovered the same objective before), it SHOULD respond with a 778 Discovery Response message with a Divert option pointing to the 779 appropriate Discovery Responder. 781 If no discovery response is received within a reasonable 782 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), 783 the Discovery message MAY be repeated, with a newly generated 784 Session ID (Section 3.6). An exponential backoff SHOULD be 785 used for subsequent repetitions, in order to mitigate possible 786 denial of service attacks. 788 After a GRASP device successfully discovers a Discovery 789 Responder supporting a specific objective, it MUST cache this 790 information. This cache record MAY be used for future 791 negotiation or synchronization, and SHOULD be passed on when 792 appropriate as a Divert option to another Discovery Initiator. 793 The cache lifetime is an implementation choice that MAY be 794 modified by network Intent. 796 If multiple Discovery Responders are found for the same 797 objective, they SHOULD all be cached, unless this creates a 798 resource shortage. The method of choosing between multiple 799 responders is an implementation choice. This choice MUST be 800 available to each ASA but the GRASP implementation SHOULD 801 provide a default choice. 803 Because Discovery Responders will be cached in a finite cache, 804 they might be deleted at any time. In this case, discovery 805 will need to be repeated. If an ASA exits for any reason, its 806 locator might still be cached for some time, and attempts to 807 connect to it will fail. ASAs need to be robust in these 808 circumstances. 810 A GRASP device with multiple link-layer interfaces (typically a 811 router) MUST support discovery on all interfaces. If it 812 receives a Discovery message on a given interface for a 813 specific objective that it does not support and for which it 814 has not previously cached a Discovery Responder, it MUST relay 815 the query by re-issuing a Discovery message on its other 816 interfaces. The relayed message MUST have a new Session ID. 817 Before this, it MUST decrement the loop count within the 818 objective, and MUST NOT relay the Discovery message if the 819 result is zero. Also, it MUST limit the total rate at which it 820 relays discovery messages to a reasonable value, in order to 821 mitigate possible denial of service attacks. It MUST cache the 822 Session ID value of each relayed discovery message and, to 823 prevent loops, MUST NOT relay a Discovery message which carries 824 such a cached Session ID. These precautions avoid discovery 825 loops and mitigate potential overload. 827 This relayed discovery mechanism, with caching of the results, 828 should be sufficient to support most network bootstrapping 829 scenarios. 831 o A complete discovery process will start with a multicast on the 832 local link. On-link neighbors supporting the discovery objective 833 will respond directly. A neighbor with multiple interfaces will 834 respond with a cached discovery response if any. If not, it will 835 relay the discovery on its other interfaces, for example reaching 836 a higher-level gateway in a hierarchical network. If a node 837 receiving the relayed discovery supports the discovery objective, 838 it will respond to the relayed discovery. If it has a cached 839 response, it will respond with that. If not, it will repeat the 840 discovery process, which thereby becomes recursive. The loop 841 count and timeout will ensure that the process ends. 843 o Rapid Mode (Discovery/Negotiation binding) 845 A Discovery message MAY include a Negotiation Objective option. 846 This allows a rapid mode of negotiation described in 847 Section 3.3.4. A similar mechanism is defined for 848 synchronization in Section 3.3.5. 850 3.3.4. Negotiation Procedures 852 A negotiation initiator sends a negotiation request to a counterpart 853 ASA, including a specific negotiation objective. It may request the 854 negotiation counterpart to make a specific configuration. 855 Alternatively, it may request a certain simulation or forecast result 856 by sending a dry run configuration. The details, including the 857 distinction between dry run and an actual configuration change, will 858 be defined separately for each type of negotiation objective. 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 negotiation request MAY be repeated, with a newly generated Session 863 ID (Section 3.6). An exponential backoff SHOULD be used for 864 subsequent repetitions. 866 If the counterpart can immediately apply the requested configuration, 867 it will give an immediate positive (accept) answer. This will end 868 the negotiation phase immediately. Otherwise, it will negotiate. It 869 will reply with a proposed alternative configuration that it can 870 apply (typically, a configuration that uses fewer resources than 871 requested by the negotiation initiator). This will start a bi- 872 directional negotiation to reach a compromise between the two ASAs. 874 The negotiation procedure is ended when one of the negotiation peers 875 sends a Negotiation Ending message, which contains an accept or 876 decline option and does not need a response from the negotiation 877 peer. Negotiation may also end in failure (equivalent to a decline) 878 if a timeout is exceeded or a loop count is exceeded. 880 A negotiation procedure concerns one objective and one counterpart. 881 Both the initiator and the counterpart may take part in simultaneous 882 negotiations with various other ASAs, or in simultaneous negotiations 883 about different objectives. Thus, GRASP is expected to be used in a 884 multi-threaded mode. Certain negotiation objectives may have 885 restrictions on multi-threading, for example to avoid over-allocating 886 resources. 888 Some configuration actions, for example wavelength switching in 889 optical networks, might take considerable time to execute. The ASA 890 concerned needs to allow for this by design, but GRASP does allow for 891 a peer to insert latency in a negotiation process if necessary 892 (Section 3.7.8). 894 3.3.4.1. Rapid Mode (Discovery/Negotiation Linkage) 896 A Discovery message MAY include a Negotiation Objective option. In 897 this case the Discovery message also acts as a Request Negotiation 898 message to indicate to the Discovery Responder that it could directly 899 reply to the Discovery Initiator with a Negotiation message for rapid 900 processing, if it could act as the corresponding negotiation 901 counterpart. However, the indication is only advisory not 902 prescriptive. 904 This rapid mode could reduce the interactions between nodes so that a 905 higher efficiency could be achieved. This rapid negotiation function 906 SHOULD be configured off by default and MAY be configured on or off 907 by Intent. 909 3.3.5. Synchronization and Flooding Procedure 911 A synchronization initiator sends a synchronization request to a 912 counterpart, including a specific synchronization objective. The 913 counterpart responds with a Synchronization message (Section 3.7.9) 914 containing the current value of the requested synchronization 915 objective. No further messages are needed. 917 If no reply message of any kind is received within a reasonable 918 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 919 synchronization request MAY be repeated, with a newly generated 920 Session ID (Section 3.6). An exponential backoff SHOULD be used for 921 subsequent repetitions. 923 3.3.5.1. Flooding 925 In the case just described, the message exchange is unicast and 926 concerns only one synchronization objective. For large groups of 927 nodes requiring the same data, synchronization flooding is available. 928 For this, a flooding initiator MAY send an unsolicited Flood 929 Synchronization message containing one or more Synchronization 930 Objective option(s), if and only if the specification of those 931 objectives permits it. This is sent as a multicast message to the 932 ALL_GRASP_NEIGHBOR multicast address (Section 3.5). To ensure that 933 flooding does not result in a loop, the originator of the Flood 934 Synchronization message MUST set the loop count in the objectives to 935 a suitable value (the default is GRASP_DEF_LOOPCT). In this case a 936 suitable mechanism is needed to avoid excessive multicast traffic. 937 This mechanism MUST be defined as part of the specification of the 938 synchronization objective(s) concerned. It might be a simple rate 939 limit or a more complex mechanism such as the Trickle algorithm 940 [RFC6206]. 942 A GRASP device with multiple link-layer interfaces (typically a 943 router) MUST support synchronization flooding on all interfaces. If 944 it receives a multicast Flood Synchronization message on a given 945 interface, it MUST relay it by re-issuing a Flood Synchronization 946 message on its other interfaces. The relayed message MUST have a new 947 Session ID. Before this, it MUST decrement the loop count within the 948 objective, and MUST NOT relay the Flood Synchronization message if 949 the result is zero. Also, it MUST limit the total rate at which it 950 relays Flood Synchronization messages to a reasonable value, in order 951 to mitigate possible denial of service attacks. It MUST cache the 952 Session ID value of each relayed Flood Synchronization message and, 953 to prevent loops, MUST NOT relay a Flood Synchronization message 954 which carries such a cached Session ID. These precautions avoid 955 synchronization loops and mitigate potential overload. 957 Note that this mechanism is unreliable in the case of sleeping nodes. 958 Sleeping nodes that require an objective subject to flooding SHOULD 959 periodically request unicast synchronization for that objective. 961 The multicast messages for synchronization flooding are subject to 962 the security rules in Section 3.3.1. In practice this means that 963 they MUST NOT be transmitted and MUST be ignored on receipt unless 964 there is an operational ACP. However, because of the security 965 weakness of link-local multicast (Section 4), synchronization 966 objectives that are flooded SHOULD NOT contain unencrypted sensitive 967 information and SHOULD be validated by the recipient ASA. 969 3.3.5.2. Rapid Mode (Discovery/Synchronization Linkage) 971 A Discovery message MAY include a Synchronization Objective option. 972 In this case the Discovery message also acts as a Request 973 Synchronization message to indicate to the Discovery Responder that 974 it could directly reply to the Discovery Initiator with a 975 Synchronization message Section 3.7.9 with synchronization data for 976 rapid processing, if the discovery target supports the corresponding 977 synchronization objective. However, the indication is only advisory 978 not prescriptive. 980 This rapid mode could reduce the interactions between nodes so that a 981 higher efficiency could be achieved. This rapid synchronization 982 function SHOULD be configured off by default and MAY be configured on 983 or off by Intent. 985 3.4. High Level Deployment Model 987 It is expected that a GRASP implementation will reside in an 988 autonomic node that also contains both the appropriate security 989 environment (preferably the ACP) and one or more Autonomic Service 990 Agents (ASAs). In the minimal case of a single-purpose device, these 991 three components might be fully integrated. A more common model is 992 expected to be a multi-purpose device capable of containing several 993 ASAs. In this case it is expected that the ACP, GRASP and the ASAs 994 will be implemented as separate processes, which are probably multi- 995 threaded to support asynchronous operation. It is expected that 996 GRASP will access the ACP by using a typical socket interface. Well 997 defined Application Programming Interfaces (APIs) will be needed 998 between GRASP and the ASAs. For further details of possible 999 deployment models, see [I-D.behringer-anima-reference-model]. 1001 3.5. GRASP Constants 1003 o ALL_GRASP_NEIGHBOR 1005 A link-local scope multicast address used by a GRASP-enabled 1006 device to discover GRASP-enabled neighbor (i.e., on-link) devices 1007 . All devices that support GRASP are members of this multicast 1008 group. 1010 * IPv6 multicast address: TBD1 1012 * IPv4 multicast address: TBD2 1014 o GRASP_LISTEN_PORT (TBD3) 1016 A UDP and TCP port that every GRASP-enabled network device always 1017 listens to. 1019 o GRASP_DEF_TIMEOUT (60000 milliseconds) 1021 The default timeout used to determine that a discovery etc. has 1022 failed to complete. 1024 o GRASP_DEF_LOOPCT (6) 1026 The default loop count used to determine that a negotiation has 1027 failed to complete, and to avoid looping messages. 1029 3.6. Session Identifier (Session ID) 1031 This is an up to 24-bit opaque value used to distinguish multiple 1032 sessions between the same two devices. A new Session ID MUST be 1033 generated by the initiator for every new Discovery, Flood 1034 Synchronization or Request message. All responses and follow-up 1035 messages in the same discovery, synchronization or negotiation 1036 procedure MUST carry the same Session ID. 1038 The Session ID SHOULD have a very low collision rate locally. It 1039 MUST be generated by a pseudo-random algorithm using a locally 1040 generated seed which is unlikely to be used by any other device in 1041 the same network [RFC4086]. 1043 However, there is a finite probability that two nodes might generate 1044 the same Session ID value. For that reason, when a Session ID is 1045 communicated via GRASP, the receiving node MUST tag it with the 1046 initiator's IP address to allow disambiguation. Multicast GRASP 1047 messages, which may be relayed between links, therefore require a new 1048 Session ID each time they are relayed. 1050 3.7. GRASP Messages 1052 3.7.1. Message Overview 1054 This section defines the GRASP message format and message types. 1055 Message types not listed here are reserved for future use. 1057 The messages currently defined are: 1059 Discovery and Discovery Response. 1061 Request Negotiation, Negotiation, Confirm Waiting and Negotiation 1062 End. 1064 Request Synchronization, Synchronization, and Flood 1065 Synchronization. 1067 No Operation. 1069 3.7.2. GRASP Message Format 1071 GRASP messages share an identical header format and a variable format 1072 area for options. GRASP message headers and options are transmitted 1073 in Concise Binary Object Representation (CBOR) [RFC7049]. In this 1074 specification, they are described using CBOR data definition language 1075 (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is 1076 used to describe each item in this section. A complete and normative 1077 CDDL specification of GRASP is given in Section 5, including 1078 constants such as message types. 1080 Every GRASP message, except the No Operation message, carries a 1081 Session ID (Section 3.6). Options are then presented serially in the 1082 options field. 1084 In fragmentary CDDL, every GRASP message follows the pattern: 1086 grasp-message = (message .within message-structure) / noop-message 1088 message-structure = [MESSAGE_TYPE, session-id, +grasp-option] 1090 MESSAGE_TYPE = 1..255 1091 session-id = 0..16777215 ;up to 24 bits 1092 grasp-option = any 1094 The MESSAGE_TYPE indicates the type of the message and thus defines 1095 the expected options. Any options received that are not consistent 1096 with the MESSAGE_TYPE SHOULD be silently discarded. 1098 The No Operation (noop) message is described in Section 3.7.11. 1100 The various MESSAGE_TYPE values are defined in Section 5. 1102 All other message elements are described below and formally defined 1103 in Section 5. 1105 3.7.3. Discovery Message 1107 In fragmentary CDDL, a Discovery message follows the pattern: 1109 discovery-message = [M_DISCOVERY, session-id, objective] 1111 A discovery initiator sends a Discovery message to initiate a 1112 discovery process for a particular objective option. 1114 The discovery initiator sends the Discovery messages to the link- 1115 local ALL_GRASP_NEIGHBOR multicast address for discovery, and stores 1116 the discovery results (including responding discovery objectives and 1117 corresponding unicast addresses, FQDNs or URIs). 1119 A Discovery message MUST include exactly one of the following: 1121 o a discovery objective option (Section 3.9.1). Its loop count MUST 1122 be set to a suitable value to prevent discovery loops (default 1123 value is GRASP_DEF_LOOPCT). 1125 o a negotiation objective option (Section 3.9.1). This is used both 1126 for the purpose of discovery and to indicate to the discovery 1127 target that it MAY directly reply to the discovery initiatior with 1128 a Negotiation message for rapid processing, if it could act as the 1129 corresponding negotiation counterpart. The sender of such a 1130 Discovery message MUST initialize a negotiation timer and loop 1131 count in the same way as a Request Negotiation message 1132 (Section 3.7.5). 1134 o a synchronization objective option (Section 3.9.1). This is used 1135 both for the purpose of discovery and to indicate to the discovery 1136 target that it MAY directly reply to the discovery initiator with 1137 a Synchronization message for rapid processing, if it could act as 1138 the corresponding synchronization counterpart. Its loop count 1139 MUST be set to a suitable value to prevent discovery loops 1140 (default value is GRASP_DEF_LOOPCT). 1142 3.7.4. Discovery Response Message 1144 In fragmentary CDDL, a Discovery Response message follows the 1145 pattern: 1147 response-message = [M_RESPONSE, session-id, 1148 (+locator-option // divert-option), ?objective)] 1150 A node which receives a Discovery message SHOULD send a Discovery 1151 Response message if and only if it can respond to the discovery. It 1152 MAY include a copy of the discovery objective from the Discovery 1153 message. 1155 If the responding node supports the discovery objective of the 1156 discovery, it MUST include at least one kind of locator option 1157 (Section 3.8.5) to indicate its own location. A sequence of multiple 1158 kinds of locator options (e.g. IP address option and FQDN option) is 1159 also valid. 1161 If the responding node itself does not support the discovery 1162 objective, but it knows the locator of the discovery objective, then 1163 it SHOULD respond to the discovery message with a divert option 1164 (Section 3.8.2) embedding a locator option or a combination of 1165 multiple kinds of locator options which indicate the locator(s) of 1166 the discovery objective. 1168 3.7.5. Request Messages 1170 In fragmentary CDDL, Request Negotiation and Request Synchronization 1171 messages follow the patterns: 1173 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1175 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1177 A negotiation or synchronization requesting node sends the 1178 appropriate Request message to the unicast address (directly stored 1179 or resolved from an FQDN) of the negotiation or synchronization 1180 counterpart (selected from the discovery results). 1182 A Request message MUST include the relevant objective option. In the 1183 case of Request Negotiation, the objective option MUST include the 1184 requested value. 1186 When an initiator sends a Request Negotiation message, it MUST 1187 initialize a negotiation timer for the new negotiation thread with 1188 the value GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is 1189 modified by a Confirm Waiting message (Section 3.7.8), the initiator 1190 will consider that the negotiation has failed when the timer expires. 1192 When an initiator sends a Request message, it MUST initialize the 1193 loop count of the objective option with a value defined in the 1194 specification of the option or, if no such value is specified, with 1195 GRASP_DEF_LOOPCT. 1197 If a node receives a Request message for an objective for which no 1198 ASA is currently listening, it MUST immediately close the relevant 1199 socket to indicate this to the initiator. 1201 3.7.6. Negotiation Message 1203 In fragmentary CDDL, a Negotiation message follows the pattern: 1205 discovery-message = [M_NEGOTIATE, session-id, objective] 1207 A negotiation counterpart sends a Negotiation message in response to 1208 a Request Negotiation message, a Negotiation message, or a Discovery 1209 message in Rapid Mode. A negotiation process MAY include multiple 1210 steps. 1212 The Negotiation message MUST include the relevant Negotiation 1213 Objective option, with its value updated according to progress in the 1214 negotiation. The sender MUST decrement the loop count by 1. If the 1215 loop count becomes zero the message MUST NOT be sent. In this case 1216 the negotiation session has failed and will time out. 1218 3.7.7. Negotiation End Message 1220 In fragmentary CDDL, a Negotiation End message follows the pattern: 1222 end-message = [M_END, session-id, accept-option / decline-option] 1224 A negotiation counterpart sends an Negotiation End message to close 1225 the negotiation. It MUST contain either an accept or a decline 1226 option, defined in Section 3.8.3 and Section 3.8.4. It could be sent 1227 either by the requesting node or the responding node. 1229 3.7.8. Confirm Waiting Message 1231 In fragmentary CDDL, a Confirm Waiting message follows the pattern: 1233 wait-message = [M_WAIT, session-id, waiting-time] 1234 waiting-time = 0..4294967295 ; in milliseconds 1236 A responding node sends a Confirm Waiting message to ask the 1237 requesting node to wait for a further negotiation response. It might 1238 be that the local process needs more time or that the negotiation 1239 depends on another triggered negotiation. This message MUST NOT 1240 include any other options. When received, the waiting time value 1241 overwrites and restarts the current negotiation timer 1242 (Section 3.7.5). 1244 The responding node SHOULD send a Negotiation, Negotiation End or 1245 another Confirm Waiting message before the negotiation timer expires. 1246 If not, the initiator MUST abandon or restart the negotiation 1247 procedure, to avoid an indefinite wait. 1249 3.7.9. Synchronization Message 1251 In fragmentary CDDL, a Synchronization message follows the pattern: 1253 synch-message = [M_SYNCH, session-id, objective] 1255 A node which receives a Request Synchronization, or a Discovery 1256 message in Rapid Mode, sends back a unicast Synchronization message 1257 with the synchronization data, in the form of a GRASP Option for the 1258 specific synchronization objective present in the Request 1259 Synchronization. 1261 3.7.10. Flood Synchronization Message 1263 In fragmentary CDDL, a Flood Synchronization message follows the 1264 pattern: 1266 flood-message = [M_FLOOD, session-id, +objective] 1268 A node MAY initiate flooding by sending an unsolicited Flood 1269 Synchronization Message with synchronization data. This MAY be sent 1270 to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance 1271 with the rules in Section 3.3.5. The synchronization data will be in 1272 the form of GRASP Option(s) for specific synchronization 1273 objective(s). The loop count(s) MUST be set to a suitable value to 1274 prevent flood loops (default value is GRASP_DEF_LOOPCT). 1276 A node that receives a Flood Synchronization message SHOULD cache the 1277 received objectives for use by local ASAs. 1279 3.7.11. No Operation Message 1281 In fragmentary CDDL, a No Operation message follows the pattern: 1283 noop-message = [M_NOOP] 1285 This message MAY be sent by an implementation that for practical 1286 reasons needs to activate a socket. It MUST be silently ignored by a 1287 recipient. 1289 3.8. GRASP Options 1291 This section defines the GRASP options for the negotiation and 1292 synchronization protocol signaling. Additional options may be 1293 defined in the future. 1295 3.8.1. Format of GRASP Options 1297 GRASP options are CBOR objects that MUST start with an unsigned 1298 integer identifying the specific option type carried in this option. 1299 These option types are formally defined in Section 5. Apart from 1300 that the only format requirement is that each option MUST be a well- 1301 formed CBOR object. In general a CBOR array format is RECOMMENDED to 1302 limit overhead. 1304 GRASP options are usually scoped by using encapsulation. However, 1305 this is not a requirement 1307 3.8.2. Divert Option 1309 The Divert option is used to redirect a GRASP request to another 1310 node, which may be more appropriate for the intended negotiation or 1311 synchronization. It may redirect to an entity that is known as a 1312 specific negotiation or synchronization counterpart (on-link or off- 1313 link) or a default gateway. The divert option MUST only be 1314 encapsulated in Discovery Response messages. If found elsewhere, it 1315 SHOULD be silently ignored. 1317 In fragmentary CDDL, the Divert option follows the pattern: 1319 divert-option = [O_DIVERT, +locator-option] 1321 The embedded Locator Option(s) (Section 3.8.5) point to diverted 1322 destination target(s) in response to a Discovery message. 1324 3.8.3. Accept Option 1326 The accept option is used to indicate to the negotiation counterpart 1327 that the proposed negotiation content is accepted. 1329 The accept option MUST only be encapsulated in Negotiation End 1330 messages. If found elsewhere, it SHOULD be silently ignored. 1332 In fragmentary CDDL, the Accept option follows the pattern: 1334 accept-option = [O_ACCEPT] 1336 3.8.4. Decline Option 1338 The decline option is used to indicate to the negotiation counterpart 1339 the proposed negotiation content is declined and end the negotiation 1340 process. 1342 The decline option MUST only be encapsulated in Negotiation End 1343 messages. If found elsewhere, it SHOULD be silently ignored. 1345 In fragmentary CDDL, the Decline option follows the pattern: 1347 decline-option = [O_DECLINE, ?reason] 1348 reason = text ;optional error message 1350 Note: there are scenarios where a negotiation counterpart wants to 1351 decline the proposed negotiation content and continue the negotiation 1352 process. For these scenarios, the negotiation counterpart SHOULD use 1353 a Negotiate message, with either an objective option that contains a 1354 data field set to indicate a meaningless initial value, or a specific 1355 objective option that provides further conditions for convergence. 1357 3.8.5. Locator Options 1359 These locator options are used to present reachability information 1360 for an ASA, a device or an interface. They are Locator IPv4 Address 1361 Option, Locator IPv6 Address Option, Locator FQDN (Fully Qualified 1362 Domain Name) Option and Uniform Resource Identifier Option. 1364 Note: It is assumed that all locators are in scope throughout the 1365 GRASP domain. GRASP is not intended to work across disjoint 1366 addressing or naming realms. 1368 3.8.5.1. Locator IPv4 address option 1370 In fragmentary CDDL, the IPv4 address option follows the pattern: 1372 ipv4-locator-option = bytes .size 4 1374 The content of this option is a binary IPv4 address. 1376 Note: If an operator has internal network address translation for 1377 IPv4, this option MUST NOT be used within the Divert option. 1379 3.8.5.2. Locator IPv6 address option 1381 In fragmentary CDDL, the IPv6 address option follows the pattern: 1383 ipv6-locator-option = bytes .size 16 1385 The content of this option is a binary IPv6 address. 1387 Note 1: The IPv6 address MUST normally have global scope. 1388 Exceptionally, during node bootstrap, a link-local address MAY be 1389 used for specific objectives only. 1391 Note 2: A link-local IPv6 address MUST NOT be used when this option 1392 is included in a Divert option. 1394 3.8.5.3. Locator FQDN option 1396 In fragmentary CDDL, the FQDN option follows the pattern: 1398 fqdn-locator-option = [O_FQDN_LOCATOR, text] 1400 The content of this option is the Fully Qualified Domain Name of the 1401 target. 1403 Note 1: Any FQDN which might not be valid throughout the network in 1404 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1405 when this option is used within the Divert option. 1407 Note 2: Normal GRASP operations are not expected to use this option. 1408 It is intended for special purposes such as discovering external 1409 services. 1411 3.8.5.4. Locator URI option 1413 In fragmentary CDDL, the URI option follows the pattern: 1415 uri-locator-option = [O_URI_LOCATOR, text] 1417 The content of this option is the Uniform Resource Identifier of the 1418 target [RFC3986]. 1420 Note 1: Any URI which might not be valid throughout the network in 1421 question, such as one based on a Multicast DNS name [RFC6762], MUST 1422 NOT be used when this option is used within the Divert option. 1424 Note 2: Normal GRASP operations are not expected to use this option. 1425 It is intended for special purposes such as discovering external 1426 services. 1428 3.9. Objective Options 1430 3.9.1. Format of Objective Options 1432 An objective option is used to identify objectives for the purposes 1433 of discovery, negotiation or synchronization. All objectives MUST be 1434 in the following format, described in fragmentary CDDL: 1436 objective = [objective-name, objective-flags, loop-count, ?any] 1438 objective-name = text 1439 loop-count = 0..255 1441 All objectives are identified by a unique name which is a case- 1442 sensitive UTF-8 string. 1444 The names of generic objectives MUST NOT include a colon (":") and 1445 MUST be registered with IANA (Section 6). 1447 The names of privately defined objectives MUST include at least one 1448 colon (":"). The string preceding the last colon in the name MUST be 1449 globally unique and in some way identify the entity or person 1450 defining the objective. The following three methods MAY be used to 1451 create such a globally unique string: 1453 1. The unique string is a decimal number representing a registered 1454 32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 1455 uniquely identifies the enterprise defining the objective. 1457 2. The unique string is a fully qualified domain name that uniquely 1458 identifies the entity or person defining the objective. 1460 3. The unique string is an email address that uniquely identifies 1461 the entity or person defining the objective. 1463 The GRASP protocol treats the objective name as an opaque string. 1464 For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 1465 and "user@example.org:EX1" would be five different objectives. 1467 The 'objective-flags' field is described below. 1469 The 'loop-count' field is used for terminating negotiation as 1470 described in Section 3.7.6. It is also used for terminating 1471 discovery as described in Section 3.3.3, and for terminating flooding 1472 as described in Section 3.3.5.1. 1474 The 'any' field is to express the actual value of a negotiation or 1475 synchronization objective. Its format is defined in the 1476 specification of the objective and may be a single value or a data 1477 structure of any kind. It is optional because it is optional in a 1478 Discovery or Discovery Response message. 1480 3.9.2. Objective flags 1482 An objective may be relevant for discovery only, for discovery and 1483 negotiation, or for discovery and synchronization. This is expressed 1484 in the objective by logical flags: 1486 objective-flags = uint .bits objective-flag 1487 objective-flag = &( 1488 F_DISC: 0 ; valid for discovery only 1489 F_NEG: 1 ; valid for discovery and negotiation 1490 F_SYNCH: 2 ; valid for discovery and synchronization 1491 ) 1493 3.9.3. General Considerations for Objective Options 1495 As mentioned above, Objective Options MUST be assigned a unique name. 1496 As long as privately defined Objective Options obey the rules above, 1497 this document does not restrict their choice of name, but the entity 1498 or person concerned SHOULD publish the names in use. 1500 All Objective Options MUST respect the CBOR patterns defined above as 1501 "objective" and MUST replace the "any" field with a valid CBOR data 1502 definition for the relevant use case and application. 1504 An Objective Option that contains no additional fields beyond its 1505 "loop-count" can only be a discovery objective and MUST only be used 1506 in Discovery and Discovery Response messages. 1508 The Negotiation Objective Options contain negotiation objectives, 1509 which vary according to different functions/services. They MUST be 1510 carried by Discovery, Request Negotiation or Negotiation messages 1511 only. The negotiation initiator MUST set the initial "loop-count" to 1512 a value specified in the specification of the objective or, if no 1513 such value is specified, to GRASP_DEF_LOOPCT. 1515 For most scenarios, there should be initial values in the negotiation 1516 requests. Consequently, the Negotiation Objective options MUST 1517 always be completely presented in a Request Negotiation message, or 1518 in a Discovery message in rapid mode. If there is no initial value, 1519 the bits in the value field SHOULD all be set to indicate a 1520 meaningless value, unless this is inappropriate for the specific 1521 negotiation objective. 1523 Synchronization Objective Options are similar, but MUST be carried by 1524 Discovery, Discovery Response, Request Synchronization, or Flood 1525 Synchronization messages only. They include value fields only in 1526 Synchronization or Flood Synchronization messages. 1528 3.9.4. Organizing of Objective Options 1530 Generic objective options MUST be specified in documents available to 1531 the public and SHOULD be designed to use either the negotiation or 1532 the synchronization mechanism described above. 1534 As noted earlier, one negotiation objective is handled by each GRASP 1535 negotiation thread. Therefore, a negotiation objective, which is 1536 based on a specific function or action, SHOULD be organized as a 1537 single GRASP option. It is NOT RECOMMENDED to organize multiple 1538 negotiation objectives into a single option, nor to split a single 1539 function or action into multiple negotiation objectives. 1541 It is important to understand that GRASP negotiation does not support 1542 transactional integrity. If transactional integrity is needed for a 1543 specific objective, this must be ensured by the ASA. For example, an 1544 ASA might need to ensure that it only participates in one negotiation 1545 thread at the same time. Such an ASA would need to stop listening 1546 for incoming negotiation requests before generating an outgoing 1547 negotiation request. 1549 A synchronization objective SHOULD be organized as a single GRASP 1550 option. 1552 Some objectives will support more than one operational mode. An 1553 example is a negotiation objective with both a "dry run" mode (where 1554 the negotiation is to find out whether the other end can in fact make 1555 the requested change without problems) and a "live" mode. Such modes 1556 will be defined in the specification of such an objective. These 1557 objectives SHOULD include flags indicating the applicable mode(s). 1559 An objective may have multiple parameters. Parameters can be 1560 categorized into two classes: the obligatory ones presented as fixed 1561 fields; and the optional ones presented in CBOR sub-options or some 1562 other form of data structure embedded in CBOR. The format might be 1563 inherited from an existing management or configuration protocol, the 1564 objective option acting as a carrier for that format. The data 1565 structure might be defined in a formal language, but that is a matter 1566 for the specifications of individual objectives. There are many 1567 candidates, according to the context, such as ABNF, RBNF, XML Schema, 1568 possibly YANG, etc. The GRASP protocol itself is agnostic on these 1569 questions. 1571 It is NOT RECOMMENDED to split parameters in a single objective into 1572 multiple options, unless they have different response periods. An 1573 exception scenario may also be described by split objectives. 1575 All objectives MUST support GRASP discovery. However, as mentioned 1576 in Section 3.2, it is acceptable for an ASA to use an alternative 1577 method of discovery. 1579 Normally, a GRASP objective will refer to specific technical 1580 parameters as explained in Section 3.1. However, it is acceptable to 1581 define an abstract objective for the purpose of managing or 1582 coordinating ASAs. It is also acceptable to define a special-purpose 1583 objective for purposes such as trust bootstrapping or formation of 1584 the ACP. 1586 3.9.5. Experimental and Example Objective Options 1588 The names "EX0" through "EX9" have been reserved for experimental 1589 options. Multiple names have been assigned because a single 1590 experiment may use multiple options simultaneously. These 1591 experimental options are highly likely to have different meanings 1592 when used for different experiments. Therefore, they SHOULD NOT be 1593 used without an explicit human decision and SHOULD NOT be used in 1594 unmanaged networks such as home networks. 1596 These names are also RECOMMENDED for use in documentation examples. 1598 4. Security Considerations 1600 It is obvious that a successful attack on negotiation-enabled nodes 1601 would be extremely harmful, as such nodes might end up with a 1602 completely undesirable configuration that would also adversely affect 1603 their peers. GRASP nodes and messages therefore require full 1604 protection. 1606 - Authentication 1607 A cryptographically authenticated identity for each device is 1608 needed in an autonomic network. It is not safe to assume that a 1609 large network is physically secured against interference or that 1610 all personnel are trustworthy. Each autonomic node MUST be 1611 capable of proving its identity and authenticating its messages. 1612 GRASP relies on a separate external certificate-based security 1613 mechanism to support authentication, data integrity protection, 1614 and anti-replay protection. 1616 Since GRASP is intended to be deployed in a single administrative 1617 domain operating its own trust anchor and CA, there is no need for 1618 a trusted public third party. In a network requiring "air gap" 1619 security, such a dependency would be unacceptable. 1621 If GRASP is used temporarily without an external security 1622 mechanism, for example during system bootstrap (Section 3.3.1), 1623 the Session ID (Section 3.6) will act as a nonce to provide 1624 limited protection against third parties injecting responses. A 1625 full analysis of the secure bootstrap process is out of scope for 1626 the present document. 1628 - Authorization and Roles 1630 The GRASP protocol is agnostic about the role of individual ASAs 1631 and about which objectives a particular ASA is authorized to 1632 support. It SHOULD apply obvious precautions such as allowing 1633 only one ASA in a given node to modify a given objective, but 1634 otherwise authorization is out of scope. 1636 - Privacy and confidentiality 1638 Generally speaking, no personal information is expected to be 1639 involved in the signaling protocol, so there should be no direct 1640 impact on personal privacy. Nevertheless, traffic flow paths, 1641 VPNs, etc. could be negotiated, which could be of interest for 1642 traffic analysis. Also, operators generally want to conceal 1643 details of their network topology and traffic density from 1644 outsiders. Therefore, since insider attacks cannot be excluded in 1645 a large network, the security mechanism for the protocol MUST 1646 provide message confidentiality. This is why Section 3.3.1 1647 requires either an ACP or the use of TLS. 1649 - Link-local multicast security 1651 GRASP has no reasonable alternative to using link-local multicast 1652 for Discovery or Flood Synchronization messages and these messages 1653 are sent in clear and with no authentication. They are therefore 1654 available to on-link eavesdroppers, and could be forged by on-link 1655 attackers. In the case of Discovery, the Discovery Responses are 1656 unicast and will therefore be protected (Section 3.3.1), and an 1657 untrusted forger will not be able to receive responses. In the 1658 case of Flood Synchronization, an on-link eavesdropper will be 1659 able to receive the flooded objectives but there is no response 1660 message to consider. Some precautions for Flood Synchronization 1661 messages are suggested in Section 3.3.5.1. 1663 - DoS Attack Protection 1665 GRASP discovery partly relies on insecure link-local multicast. 1666 Since routers participating in GRASP sometimes relay discovery 1667 messages from one link to another, this could be a vector for 1668 denial of service attacks. Relevant mitigations are specified in 1669 Section 3.3.3. Additionally, it is of great importance that 1670 firewalls prevent any GRASP messages from entering the domain from 1671 an untrusted source. 1673 - Security during bootstrap and discovery 1675 A node cannot authenticate GRASP traffic from other nodes until it 1676 has identified the trust anchor and can validate certificates for 1677 other nodes. Also, until it has succesfully enrolled 1678 [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that 1679 other nodes are able to authenticate its own traffic. Therefore, 1680 GRASP discovery during the bootstrap phase for a new device will 1681 inevitably be insecure and GRASP synchronization and negotiation 1682 will be impossible until enrollment is complete. 1684 - Security of discovered locators 1686 When GRASP discovery returns an IP address, it MUST be that of a 1687 node within the secure environment (Section 3.3.1). If it returns 1688 an FQDN or a URI, the ASA that receives it MUST NOT assume that 1689 the target of the locator is within the secure environment. 1691 5. CDDL Specification of GRASP 1693 1694 grasp-message = (message .within message-structure) / noop-message 1696 message-structure = [MESSAGE_TYPE, session-id, *grasp-option] 1698 MESSAGE_TYPE = 0..255 1699 session-id = 0..16777215 ;up to 24 bits 1700 grasp-option = any 1702 message /= discovery-message 1703 discovery-message = [M_DISCOVERY, session-id, objective] 1705 message /= response-message ;response to Discovery 1706 response-message = [M_RESPONSE, session-id, 1707 (+locator-option // divert-option), ?objective] 1709 message /= synch-message ;response to Synchronization request 1710 synch-message = [M_SYNCH, session-id, objective] 1712 message /= flood-message 1713 flood-message = [M_FLOOD, session-id, +objective] 1715 message /= request-negotiation-message 1716 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1718 message /= request-synchronization-message 1719 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1721 message /= negotiation-message 1722 negotiation-message = [M_NEGOTIATE, session-id, objective] 1724 message /= end-message 1725 end-message = [M_END, session-id, accept-option / decline-option ] 1727 message /= wait-message 1728 wait-message = [M_WAIT, session-id, waiting-time] 1730 noop-message = [M_NOOP] 1732 divert-option = [O_DIVERT, +locator-option] 1734 accept-option = [O_ACCEPT] 1736 decline-option = [O_DECLINE, ?reason] 1737 reason = text ;optional error message 1739 waiting-time = 0..4294967295 ; in milliseconds 1741 locator-option /= ipv4-locator-option 1742 ipv4-locator-option = bytes .size 4 1743 ; this is simpler than [O_IPv4_LOCATOR, bytes .size 4] 1745 locator-option /= ipv6-locator-option 1746 ipv6-locator-option = bytes .size 16 1748 locator-option /= fqdn-locator-option 1749 fqdn-locator-option = [O_FQDN_LOCATOR, text] 1750 locator-option /= uri-locator-option 1751 uri-locator-option = [O_URI_LOCATOR, text] 1753 objective-flags = uint .bits objective-flag 1755 objective-flag = &( 1756 F_DISC: 0 ; valid for discovery only 1757 F_NEG: 1 ; valid for discovery and negotiation 1758 F_SYNCH: 2) ; valid for discovery and synchronization 1760 objective = [objective-name, objective-flags, loop-count, ?any] 1762 objective-name = text ;see specification for uniqueness rules 1764 loop-count = 0..255 1766 ; Constants for message types and option types 1768 M_NOOP = 0 1769 M_DISCOVERY = 1 1770 M_RESPONSE = 2 1771 M_REQ_NEG = 3 1772 M_REQ_SYN = 4 1773 M_NEGOTIATE = 5 1774 M_END = 6 1775 M_WAIT = 7 1776 M_SYNCH = 8 1777 M_FLOOD = 9 1779 O_DIVERT = 100 1780 O_ACCEPT = 101 1781 O_DECLINE = 102 1782 O_FQDN_LOCATOR = 103 1783 O_URI_LOCATOR = 104 1784 1786 6. IANA Considerations 1788 This document defines the General Discovery and Negotiation Protocol 1789 (GRASP). 1791 Section 3.5 explains the following link-local multicast addresses, 1792 which IANA is requested to assign for use by GRASP: 1794 ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in 1795 the IPv6 Link-Local Scope Multicast Addresses registry. 1797 ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in 1798 the IPv4 Multicast Local Network Control Block. 1800 Section 3.5 explains the following UDP and TCP port, which IANA is 1801 requested to assign for use by GRASP: 1803 GRASP_LISTEN_PORT: (TBD3) 1805 The IANA is requested to create a GRASP Parameter Registry including 1806 two registry tables. These are the GRASP Messages and Options 1807 Table and the GRASP Objective Names Table. 1809 GRASP Messages and Options Table. The values in this table are names 1810 paired with decimal integers. Future values MUST be assigned using 1811 the Standards Action policy defined by [RFC5226]. The following 1812 initial values are assigned by this document: 1814 M_NOOP = 0 1815 M_DISCOVERY = 1 1816 M_RESPONSE = 2 1817 M_REQUEST = 3 1818 M_NEGOTIATE = 4 1819 M_END = 5 1820 M_WAIT = 6 1822 O_DIVERT = 100 1823 O_ACCEPT = 101 1824 O_DECLINE = 102 1825 O_FQDN_LOCATOR = 103 1826 O_URI_LOCATOR = 104 1827 O_DEVICE_ID = 105 1829 GRASP Objective Names Table. The values in this table are UTF-8 1830 strings. Future values MUST be assigned using the Specification 1831 Required policy defined by [RFC5226]. The following initial values 1832 are assigned by this document: 1834 EX0 1835 EX1 1836 EX2 1837 EX3 1838 EX4 1839 EX5 1840 EX6 1841 EX7 1842 EX8 1843 EX9 1845 7. Acknowledgements 1847 A major contribution to the original version of this document was 1848 made by Sheng Jiang. 1850 Valuable comments were received from Michael Behringer, Jeferson 1851 Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Halpern, 1852 Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, 1853 Michael Richardson, Markus Stenberg, Rene Struik, Dacheng Zhang, and 1854 other participants in the NMRG research group and the ANIMA working 1855 group. 1857 This document was produced using the xml2rfc tool [RFC2629]. 1859 8. References 1861 8.1. Normative References 1863 [I-D.greevenbosch-appsawg-cbor-cddl] 1864 Vigano, C. and H. Birkholz, "CBOR data definition language 1865 (CDDL): a notational convention to express CBOR data 1866 structures", draft-greevenbosch-appsawg-cbor-cddl-07 (work 1867 in progress), October 2015. 1869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1870 Requirement Levels", BCP 14, RFC 2119, 1871 DOI 10.17487/RFC2119, March 1997, 1872 . 1874 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1875 Resource Identifier (URI): Generic Syntax", STD 66, 1876 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1877 . 1879 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1880 "Randomness Requirements for Security", BCP 106, RFC 4086, 1881 DOI 10.17487/RFC4086, June 2005, 1882 . 1884 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1885 (TLS) Protocol Version 1.2", RFC 5246, 1886 DOI 10.17487/RFC5246, August 2008, 1887 . 1889 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1890 Housley, R., and W. Polk, "Internet X.509 Public Key 1891 Infrastructure Certificate and Certificate Revocation List 1892 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1893 . 1895 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1896 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1897 January 2012, . 1899 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1900 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1901 October 2013, . 1903 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1904 Interface Identifiers with IPv6 Stateless Address 1905 Autoconfiguration (SLAAC)", RFC 7217, 1906 DOI 10.17487/RFC7217, April 2014, 1907 . 1909 8.2. Informative References 1911 [I-D.behringer-anima-reference-model] 1912 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 1913 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 1914 for Autonomic Networking", draft-behringer-anima- 1915 reference-model-04 (work in progress), October 2015. 1917 [I-D.chaparadza-intarea-igcp] 1918 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 1919 Mahkonen, "IP based Generic Control Protocol (IGCP)", 1920 draft-chaparadza-intarea-igcp-00 (work in progress), July 1921 2011. 1923 [I-D.eckert-anima-stable-connectivity] 1924 Eckert, T. and M. Behringer, "Using Autonomic Control 1925 Plane for Stable Connectivity of Network OAM", draft- 1926 eckert-anima-stable-connectivity-02 (work in progress), 1927 October 2015. 1929 [I-D.ietf-anima-autonomic-control-plane] 1930 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 1931 Autonomic Control Plane", draft-ietf-anima-autonomic- 1932 control-plane-01 (work in progress), October 2015. 1934 [I-D.ietf-anima-bootstrapping-keyinfra] 1935 Pritikin, M., Richardson, M., Behringer, M., and S. 1936 Bjarnason, "Bootstrapping Key Infrastructures", draft- 1937 ietf-anima-bootstrapping-keyinfra-01 (work in progress), 1938 October 2015. 1940 [I-D.ietf-homenet-dncp] 1941 Stenberg, M. and S. Barth, "Distributed Node Consensus 1942 Protocol", draft-ietf-homenet-dncp-12 (work in progress), 1943 November 2015. 1945 [I-D.ietf-homenet-hncp] 1946 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1947 Control Protocol", draft-ietf-homenet-hncp-10 (work in 1948 progress), November 2015. 1950 [I-D.ietf-netconf-restconf] 1951 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1952 Protocol", draft-ietf-netconf-restconf-09 (work in 1953 progress), December 2015. 1955 [I-D.liang-iana-pen] 1956 Liang, P., Melnikov, A., and D. Conrad, "Private 1957 Enterprise Number (PEN) practices and Internet Assigned 1958 Numbers Authority (IANA) registration considerations", 1959 draft-liang-iana-pen-06 (work in progress), July 2015. 1961 [I-D.stenberg-anima-adncp] 1962 Stenberg, M., "Autonomic Distributed Node Consensus 1963 Protocol", draft-stenberg-anima-adncp-00 (work in 1964 progress), March 2015. 1966 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1967 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1968 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1969 September 1997, . 1971 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 1972 "Service Location Protocol, Version 2", RFC 2608, 1973 DOI 10.17487/RFC2608, June 1999, 1974 . 1976 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1977 DOI 10.17487/RFC2629, June 1999, 1978 . 1980 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1981 "Remote Authentication Dial In User Service (RADIUS)", 1982 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1983 . 1985 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1986 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1987 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1988 . 1990 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1991 C., and M. Carney, "Dynamic Host Configuration Protocol 1992 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1993 2003, . 1995 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 1996 for the Simple Network Management Protocol (SNMP)", 1997 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 1998 . 2000 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2001 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2002 DOI 10.17487/RFC4861, September 2007, 2003 . 2005 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2006 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2007 DOI 10.17487/RFC5226, May 2008, 2008 . 2010 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2011 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2012 October 2010, . 2014 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 2015 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 2016 March 2011, . 2018 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2019 and A. Bierman, Ed., "Network Configuration Protocol 2020 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2021 . 2023 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2024 Ed., "Diameter Base Protocol", RFC 6733, 2025 DOI 10.17487/RFC6733, October 2012, 2026 . 2028 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2029 DOI 10.17487/RFC6762, February 2013, 2030 . 2032 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2033 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2034 . 2036 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2037 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2038 DOI 10.17487/RFC6887, April 2013, 2039 . 2041 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2042 Constrained-Node Networks", RFC 7228, 2043 DOI 10.17487/RFC7228, May 2014, 2044 . 2046 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 2047 "Requirements for Scalable DNS-Based Service Discovery 2048 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 2049 DOI 10.17487/RFC7558, July 2015, 2050 . 2052 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2053 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2054 Networking: Definitions and Design Goals", RFC 7575, 2055 DOI 10.17487/RFC7575, June 2015, 2056 . 2058 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 2059 Analysis for Autonomic Networking", RFC 7576, 2060 DOI 10.17487/RFC7576, June 2015, 2061 . 2063 Appendix A. Open Issues 2065 o 7. Cross-check against other ANIMA WG documents for consistency 2066 and gaps. 2068 o 43. Rapid mode synchronization and negotiation is currently 2069 limited to a single objective for simplicity of design and 2070 implementation. A future consideration is to allow multiple 2071 objectives in rapid mode for greater efficiency. 2073 o 48. Should the Appendix "Capability Analysis of Current 2074 Protocols" be deleted before RFC publication? 2076 Appendix B. Closed Issues [RFC Editor: Please remove] 2078 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 2079 as message transport mechanisms. This is not clarified yet. UDP 2080 is good for short conversations, is necessary for multicast 2081 discovery, and generally fits the discovery and divert scenarios 2082 well. However, it will cause problems with large messages. TCP 2083 is good for stable and long sessions, with a little bit of time 2084 consumption during the session establishment stage. If messages 2085 exceed a reasonable MTU, a TCP mode will be required in any case. 2086 This question may be affected by the security discussion. 2088 RESOLVED by specifying UDP for short message and TCP for longer 2089 one. 2091 o 2. DTLS or TLS vs built-in security mechanism. For now, this 2092 specification has chosen a PKI based built-in security mechanism 2093 based on asymmetric cryptography. However, (D)TLS might be chosen 2094 as security solution to avoid duplication of effort. It also 2095 allows essentially similar security for short messages over UDP 2096 and longer ones over TCP. The implementation trade-offs are 2097 different. The current approach requires expensive asymmetric 2098 cryptographic calculations for every message. (D)TLS has startup 2099 overheads but cheaper crypto per message. DTLS is less mature 2100 than TLS. 2102 RESOLVED by specifying external security (ACP or (D)TLS). 2104 o The following open issues applied only if the original security 2105 model was retained: 2107 * 2.1. For replay protection, GRASP currently requires every 2108 participant to have an NTP-synchronized clock. Is this OK for 2109 low-end devices, and how does it work during device 2110 bootstrapping? We could take the Timestamp out of signature 2111 option, to become an independent and OPTIONAL (or RECOMMENDED) 2112 option. 2114 * 2.2. The Signature Option states that this option could be any 2115 place in a message. Wouldn't it be better to specify a 2116 position (such as the end)? That would be much simpler to 2117 implement. 2119 RESOLVED by changing security model. 2121 o 3. DoS Attack Protection needs work. 2123 RESOLVED by adding text. 2125 o 4. Should we consider preferring a text-based approach to 2126 discovery (after the initial discovery needed for bootstrapping)? 2127 This could be a complementary mechanism for multicast based 2128 discovery, especially for a very large autonomic network. 2129 Centralized registration could be automatically deployed 2130 incrementally. At the very first stage, the repository could be 2131 empty; then it could be filled in by the objectives discovered by 2132 different devices (for example using Dynamic DNS Update). The 2133 more records are stored in the repository, the less the multicast- 2134 based discovery is needed. However, if we adopt such a mechanism, 2135 there would be challenges: stateful solution, and security. 2137 RESOLVED for now by adding optional use of DNS-SD by ASAs. 2138 Subsequently removed by editors as irrelevant to GRASP istelf. 2140 o 5. Need to expand description of the minimum requirements for the 2141 specification of an individual discovery, synchronization or 2142 negotiation objective. 2144 RESOLVED for now by extra wording. 2146 o 6. Use case and protocol walkthrough. A description of how a 2147 node starts up, performs discovery, and conducts negotiation and 2148 synchronisation for a sample use case would help readers to 2149 understand the applicability of this specification. Maybe it 2150 should be an artificial use case or maybe a simple real one, based 2151 on a conceptual API. However, the authors have not yet decided 2152 whether to have a separate document or have it in the protocol 2153 document. 2155 RESOLVED: recommend a separate document. 2157 o 8. Consideration of ADNCP proposal. 2159 RESOLVED by adding optional use of DNCP for flooding-type 2160 synchronization. 2162 o 9. Clarify how a GDNP instance knows whether it is running inside 2163 the ACP. (Sheng) 2165 RESOLVED by improved text. 2167 o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. 2168 (Sheng) 2170 RESOLVED by improved text and declaring DTLS out of scope for this 2171 draft. 2173 o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - 2174 Brian] 2176 RESOLVED by improved text. 2178 o 12. Justify that IP address within ACP or (D)TLS environment is 2179 sufficient to prove AN identity; or explain how Device Identity 2180 Option is used. (Sheng) 2182 RESOLVED for now: we assume that all ASAs in a device are trusted 2183 as soon as the device is trusted, so they share credentials. In 2184 that case the Device Identity Option is useless. This needs to be 2185 reviewed later. 2187 o 13. Emphasise that negotiation/synchronization are independent 2188 from discovery, although the rapid discovery mode includes the 2189 first step of a negotiation/synchronization. (Sheng) 2191 RESOLVED by improved text. 2193 o 14. Do we need an unsolicited flooding mechanism for discovery 2194 (for discovery results that everyone needs), to reduce scaling 2195 impact of flooding discovery messages? (Toerless) 2197 RESOLVED: Yes, added to requirements and solution. 2199 o 15. Do we need flag bits in Objective Options to distinguish 2200 distinguish Synchronization and Negotiation "Request" or rapid 2201 mode "Discovery" messages? (Bing) 2203 RESOLVED: yes, work on the API showed that these flags are 2204 essential. 2206 o 16. (Related to issue 14). Should we revive the "unsolicited 2207 Response" for flooding synchronisation data? This has to be done 2208 carefully due to the well-known issues with flooding, but it could 2209 be useful, e.g. for Intent distribution, where DNCP doesn't seem 2210 applicable. 2212 RESOLVED: Yes, see #14. 2214 o 17. Ensure that the discovery mechanism is completely proof 2215 against loops and protected against duplicate responses. 2217 RESOLVED: Added loop count mechanism. 2219 o 18. Discuss the handling of multiple valid discovery responses. 2221 RESOLVED: Stated that the choice must be available to the ASA but 2222 GRASP implementation should pick a default. 2224 o 19. Should we use a text-oriented format such as JSON/CBOR 2225 instead of native binary TLV format? 2227 RESOLVED: Yes, changed to CBOR. 2229 o 20. Is the Divert option needed? If a discovery response 2230 provides a valid IP address or FQDN, the recipient doesn't gain 2231 any extra knowledge from the Divert. On the other hand, the 2232 presence of Divert informs the receiver that the target is off- 2233 link, which might be useful sometimes. 2235 RESOLVED: Decided to keep Divert option. 2237 o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling 2238 Protocol)? 2240 RESOLVED: Yes, name changed. 2242 o 22. Does discovery mechanism scale robustly as needed? Need hop 2243 limit on relaying? 2245 RESOLVED: Added hop limit. 2247 o 23. Need more details on TTL for caching discovery responses. 2249 RESOLVED: Done. 2251 o 24. Do we need "fast withdrawal" of discovery responses? 2253 RESOLVED: This doesn't seem necessary. If an ASA exits or stops 2254 supporting a given objective, peers will fail to start future 2255 sessions and will simply repeat discovery. 2257 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? 2259 RESOLVED: Decided not to consider this further as a GRASP protocol 2260 issue. GRASP objectives could embed DNS-SD formats if needed. 2262 o 26. Add a URL type to the locator options (for security bootstrap 2263 etc.) 2265 RESOLVED: Done, later renamed as URI. 2267 o 27. Security of Flood multicasts (Section 3.3.5.1). 2269 RESOLVED: added text. 2271 o 28. Does ACP support secure link-local multicast? 2273 RESOLVED by new text in the Security Considerations. 2275 o 29. PEN is used to distinguish vendor options. Would it be 2276 better to use a domain name? Anything unique will do. 2278 RESOLVED: Simplified this by removing PEN field and changing 2279 naming rules for objectives. 2281 o 30. Does response to discovery require randomized delays to 2282 mitigate amplification attacks? 2284 RESOLVED: WG feedback is that it's unnecessary. 2286 o 31. We have specified repeats for failed discovery etc. Is that 2287 sufficient to deal with sleeping nodes? 2289 RESOLVED: WG feedback is that it's unnecessary to say more. 2291 o 32. We have one-to-one synchronization and flooding 2292 synchronization. Do we also need selective flooding to a subset 2293 of nodes? 2295 RESOLVED: This will be discussed as a protocol extension in a 2296 separate draft (draft-liu-anima-grasp-distribution). 2298 o 33. Clarify if/when discovery needs to be repeated. 2300 RESOLVED: Done. 2302 o 34. Clarify what is mandatory for running in ACP, expand 2303 discussion of security boundary when running with no ACP - might 2304 rely on the local PKI infrastructure. 2306 RESOLVED: Done. 2308 o 35. State that role-based authorization of ASAs is out of scope 2309 for GRASP. GRASP doesn't recognize/handle any "roles". 2311 RESOLVED: Done. 2313 o 36. Reconsider CBOR definition for PEN syntax. ( objective-name 2314 = text / [pen, text] ; pen = uint ) 2316 RESOLVED: See issue 29. 2318 o 37. Are URI locators really needed? 2320 RESOLVED: Yes, e.g. for security bootstrap discovery, but added 2321 note that addresses are the normal case (same for FQDN locators). 2323 o 38. Is Session ID sufficient to identify relayed responses? 2324 Isn't the originator's address needed too? 2326 RESOLVED: Yes, this is needed for multicast messages and their 2327 responses. 2329 o 39. Clarify that a node will contain one GRASP instance 2330 supporting multiple ASAs. 2332 RESOLVED: Done. 2334 o 40. Add a "reason" code to the DECLINE option? 2336 RESOLVED: Done. 2338 o 41. What happens if an ASA cannot conveniently use one of the 2339 GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) 2340 simply pass the discovery results to the ASA so that it can open 2341 its own socket? 2343 RESOLVED: Both would be possible, but (b) is preferred. 2345 o 42. Do we need a feature whereby an ASA can bypass the ACP and 2346 use the data plane for efficiency/throughput? This would require 2347 discovery to return non-ACP addresses and would evade ACP 2348 security. 2350 RESOLVED: This is considered out of scope for GRASP, but a comment 2351 has been added in security considerations. 2353 o 44. In requirement T9, the words that encryption "may not be 2354 required in all deployments" were removed. Is that OK?. 2356 RESOLVED: No objections. 2358 o 45. Device Identity Option is unused. Can we remove it 2359 completely?. 2361 RESOLVED: No objections. Done. 2363 o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD 2364 messages is intended to assist in loop prevention. However, we 2365 also have the loop count for that. Also, if we create a new 2366 Session ID each time a DISCOVER or FLOOD is relayed, that ID can 2367 be disambiguated by recipients. It would be simpler to remove the 2368 initiator from the messages, making parsing more uniform. Is that 2369 OK? 2371 RESOLVED: Yes. Done. 2373 o 47. REQUEST is a dual purpose message (request negotiation or 2374 request synchronization). Would it be better to split this into 2375 two different messages (and adjust various message names 2376 accordingly)? 2378 RESOLVED: Yes. Done. 2380 Appendix C. Change log [RFC Editor: Please remove] 2382 draft-ietf-anima-grasp-03, 2016-02-24: 2384 Protocol change: Removed initiator field from certain messages and 2385 adjusted relaying requirement to simplify loop detection. Also 2386 clarified narrative explanation of discovery relaying. 2388 Protocol change: Split Request message into two (Request Negotiation 2389 and Request Synchronization) and updated other message names for 2390 clarity. 2392 Protocol change: Dropped unused Device ID option. 2394 Further clarified text on transport layer usage. 2396 New text about multicast insecurity in Security Considerations. 2398 Various other clarifications and editorial fixes, including moving 2399 some material to Appendix. 2401 draft-ietf-anima-grasp-02, 2016-01-13: 2403 Resolved numerous issues according to WG discussions. 2405 Renumbered requirements, added D9. 2407 Protocol change: only allow one objective in rapid mode. 2409 Protocol change: added optional error string to DECLINE option. 2411 Protocol change: removed statement that seemed to say that a Request 2412 not preceded by a Discovery should cause a Discovery response. That 2413 made no sense, because there is no way the initiator would know where 2414 to send the Request. 2416 Protocol change: Removed PEN option from vendor objectives, changed 2417 naming rule accordingly. 2419 Protocol change: Added FLOOD message to simplify coding. 2421 Protocol change: Added SYNCH message to simplify coding. 2423 Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD 2424 messages. But also allowed the relay process for DISCOVER and FLOOD 2425 to regenerate a Session ID. 2427 Protocol change: Require that discovered addresses must be global 2428 (except during bootstrap). 2430 Protocol change: Receiver of REQUEST message must close socket if no 2431 ASA is listening for the objective. 2433 Protocol change: Simplified Waiting message. 2435 Protocol change: Added No Operation message. 2437 Renamed URL locator type as URI locator type. 2439 Updated CDDL definition. 2441 Various other clarifications and editorial fixes. 2443 draft-ietf-anima-grasp-01, 2015-10-09: 2445 Updated requirements after list discussion. 2447 Changed from TLV to CBOR format - many detailed changes, added co- 2448 author. 2450 Tightened up loop count and timeouts for various cases. 2452 Noted that GRASP does not provide transactional integrity. 2454 Various other clarifications and editorial fixes. 2456 draft-ietf-anima-grasp-00, 2015-08-14: 2458 File name and protocol name changed following WG adoption. 2460 Added URL locator type. 2462 draft-carpenter-anima-gdn-protocol-04, 2015-06-21: 2464 Tuned wording around hierarchical structure. 2466 Changed "device" to "ASA" in many places. 2468 Reformulated requirements to be clear that the ASA is the main 2469 customer for signaling. 2471 Added requirement for flooding unsolicited synch, and added it to 2472 protocol spec. Recognized DNCP as alternative for flooding synch 2473 data. 2475 Requirements clarified, expanded and rearranged following design team 2476 discussion. 2478 Clarified that GDNP discovery must not be a prerequisite for GDNP 2479 negotiation or synchronization (resolved issue 13). 2481 Specified flag bits for objective options (resolved issue 15). 2483 Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 2484 9,10,11). 2486 Updated DNCP description from latest DNCP draft. 2488 Editorial improvements. 2490 draft-carpenter-anima-gdn-protocol-03, 2015-04-20: 2492 Removed intrinsic security, required external security 2494 Format changes to allow DNCP co-existence 2496 Recognized DNS-SD as alternative discovery method. 2498 Editorial improvements 2500 draft-carpenter-anima-gdn-protocol-02, 2015-02-19: 2502 Tuned requirements to clarify scope, 2504 Clarified relationship between types of objective, 2506 Clarified that objectives may be simple values or complex data 2507 structures, 2509 Improved description of objective options, 2510 Added loop-avoidance mechanisms (loop count and default timeout, 2511 limitations on discovery relaying and on unsolicited responses), 2513 Allow multiple discovery objectives in one response, 2515 Provided for missing or multiple discovery responses, 2517 Indicated how modes such as "dry run" should be supported, 2519 Minor editorial and technical corrections and clarifications, 2521 Reorganized future work list. 2523 draft-carpenter-anima-gdn-protocol-01, restructured the logical flow 2524 of the document, updated to describe synchronization completely, add 2525 unsolicited responses, numerous corrections and clarifications, 2526 expanded future work list, 2015-01-06. 2528 draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- 2529 config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 2530 02, 2014-10-08. 2532 Appendix D. Capability Analysis of Current Protocols 2534 This appendix discusses various existing protocols with properties 2535 related to the above negotiation and synchronisation requirements. 2536 The purpose is to evaluate whether any existing protocol, or a simple 2537 combination of existing protocols, can meet those requirements. 2539 Numerous protocols include some form of discovery, but these all 2540 appear to be very specific in their applicability. Service Location 2541 Protocol (SLP) [RFC2608] provides service discovery for managed 2542 networks, but requires configuration of its own servers. DNS-SD 2543 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 2544 small networks with a single link layer. [RFC7558] aims to extend 2545 this to larger autonomous networks but this is not yet standardized. 2546 However, both SLP and DNS-SD appear to target primarily application 2547 layer services, not the layer 2 and 3 objectives relevant to basic 2548 network configuration. Both SLP and DNS-SD are text-based protocols. 2550 Routing protocols are mainly one-way information announcements. The 2551 receiver makes independent decisions based on the received 2552 information and there is no direct feedback information to the 2553 announcing peer. This remains true even though the protocol is used 2554 in both directions between peer routers; there is state 2555 synchronization, but no negotiation, and each peer runs its route 2556 calculations independently. 2558 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 2559 response model not well suited for peer negotiation. Network 2560 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 2561 does allow positive or negative responses from the target system, but 2562 this is still not adequate for negotiation. 2564 There are various existing protocols that have elementary negotiation 2565 abilities, such as Dynamic Host Configuration Protocol for IPv6 2566 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 2567 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 2568 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 2569 configuration or management protocols. However, they either provide 2570 only a simple request/response model in a master/slave context or 2571 very limited negotiation abilities. 2573 There are some signaling protocols with an element of negotiation. 2574 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 2575 designed for negotiating quality of service parameters along the path 2576 of a unicast or multicast flow. RSVP is a very specialised protocol 2577 aimed at end-to-end flows. However, it has some flexibility, having 2578 been extended for MPLS label distribution [RFC3209]. A more generic 2579 design is General Internet Signalling Transport (GIST) [RFC5971], but 2580 it is complex, tries to solve many problems, and is also aimed at 2581 per-flow signaling across many hops rather than at device-to-device 2582 signaling. However, we cannot completely exclude extended RSVP or 2583 GIST as a synchronization and negotiation protocol. They do not 2584 appear to be directly useable for peer discovery. 2586 We now consider two protocols that are works in progress at the time 2587 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 2588 protocol intended to convey NETCONF information expressed in the YANG 2589 language via HTTP, including the ability to transit HTML 2590 intermediaries. While this is a powerful approach in the context of 2591 centralised configuration of a complex network, it is not well 2592 adapted to efficient interactive negotiation between peer devices, 2593 especially simple ones that are unlikely to include YANG processing 2594 already. 2596 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 2597 [I-D.ietf-homenet-dncp]. This is defined as a generic form of state 2598 synchronization protocol, with a proposed usage profile being the 2599 Home Networking Control Protocol (HNCP) [I-D.ietf-homenet-hncp] for 2600 configuring Homenet routers. A specific application of DNCP for 2601 autonomic networking was proposed in [I-D.stenberg-anima-adncp]. 2603 DNCP "is designed to provide a way for each participating node to 2604 publish a set of TLV (Type-Length-Value) tuples, and to provide a 2605 shared and common view about the data published... DNCP is most 2606 suitable for data that changes only infrequently... If constant rapid 2607 state changes are needed, the preferable choice is to use an 2608 additional point-to-point channel..." 2610 Specific features of DNCP include: 2612 o Every participating node has a unique node identifier. 2614 o DNCP messages are encoded as a sequence of TLV objects, sent over 2615 unicast UDP or TCP, with or without (D)TLS security. 2617 o Multicast is used only for discovery of DNCP neighbors when lower 2618 security is acceptable. 2620 o Synchronization of state is maintained by a flooding process using 2621 the Trickle algorithm. There is no bilateral synchronization or 2622 negotiation capability. 2624 o The HNCP profile of DNCP is designed to operate between directly 2625 connected neighbors on a shared link using UDP and link-local IPv6 2626 addresses. 2628 DNCP does not meet the needs of a general negotiation protocol, 2629 because it is designed specifically for flooding synchronization. 2630 Also, in its HNCP profile it is limited to link-local messages and to 2631 IPv6. However, at the minimum it is a very interesting test case for 2632 this style of interaction between devices without needing a central 2633 authority, and it is a proven method of network-wide state 2634 synchronization by flooding. 2636 A proposal was made some years ago for an IP based Generic Control 2637 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 2638 information exchange and negotiation but not directly at peer 2639 discovery. However, it has many points in common with the present 2640 work. 2642 None of the above solutions appears to completely meet the needs of 2643 generic discovery, state synchronization and negotiation in a single 2644 solution. Many of the protocols assume that they are working in a 2645 traditional top-down or north-south scenario, rather than a fluid 2646 peer-to-peer scenario. Most of them are specialized in one way or 2647 another. As a result, we have not identified a combination of 2648 existing protocols that meets the requirements in Section 2. Also, 2649 we have not identified a path by which one of the existing protocols 2650 could be extended to meet the requirements. 2652 Authors' Addresses 2654 Carsten Bormann 2655 Universitaet Bremen TZI 2656 Postfach 330440 2657 D-28359 Bremen 2658 Germany 2660 Email: cabo@tzi.org 2662 Brian Carpenter (editor) 2663 Department of Computer Science 2664 University of Auckland 2665 PB 92019 2666 Auckland 1142 2667 New Zealand 2669 Email: brian.e.carpenter@gmail.com 2671 Bing Liu (editor) 2672 Huawei Technologies Co., Ltd 2673 Q14, Huawei Campus 2674 No.156 Beiqing Road 2675 Hai-Dian District, Beijing 100095 2676 P.R. China 2678 Email: leo.liubing@huawei.com