idnits 2.17.1 draft-ietf-anima-grasp-07.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 (September 13, 2016) is 2753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-08 ** 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-03 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-03 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-02 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-01 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-16 -- 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 (~~), 7 warnings (==), 3 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: March 17, 2017 Univ. of Auckland 6 B. Liu, Ed. 7 Huawei Technologies Co., Ltd 8 September 13, 2016 10 A Generic Autonomic Signaling Protocol (GRASP) 11 draft-ietf-anima-grasp-07 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 March 17, 2017. 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 . . . . . . . . . . . . . . . 5 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. Limited Security Instances . . . . . . . . . . . . . 15 71 3.3.3. Transport Layer Usage . . . . . . . . . . . . . . . . 17 72 3.3.4. Discovery Mechanism and Procedures . . . . . . . . . 18 73 3.3.5. Negotiation Procedures . . . . . . . . . . . . . . . 21 74 3.3.6. Synchronization and Flooding Procedure . . . . . . . 22 75 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 24 76 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 25 77 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 26 78 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 26 79 3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 26 80 3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 27 81 3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 27 82 3.7.4. Discovery Response Message . . . . . . . . . . . . . 28 83 3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 29 84 3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 30 85 3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 30 86 3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 31 87 3.7.9. Synchronization Message . . . . . . . . . . . . . . . 31 88 3.7.10. Flood Synchronization Message . . . . . . . . . . . . 31 89 3.7.11. No Operation Message . . . . . . . . . . . . . . . . 32 90 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 33 91 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 33 92 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 33 93 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 33 94 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 34 95 3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 34 96 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 36 97 3.9.1. Format of Objective Options . . . . . . . . . . . . . 36 98 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 37 99 3.9.3. General Considerations for Objective Options . . . . 37 100 3.9.4. Organizing of Objective Options . . . . . . . . . . . 38 101 3.9.5. Experimental and Example Objective Options . . . . . 39 102 4. Implementation Status [RFC Editor: please remove] . . . . . . 40 103 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 40 104 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 40 105 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 106 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 43 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 108 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 109 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 110 9.1. Normative References . . . . . . . . . . . . . . . . . . 47 111 9.2. Informative References . . . . . . . . . . . . . . . . . 48 112 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 51 113 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 52 114 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 59 115 Appendix D. Capability Analysis of Current Protocols . . . . . . 63 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 118 1. Introduction 120 The success of the Internet has made IP-based networks bigger and 121 more complicated. Large-scale ISP and enterprise networks have 122 become more and more problematic for human based management. Also, 123 operational costs are growing quickly. Consequently, there are 124 increased requirements for autonomic behavior in the networks. 125 General aspects of autonomic networks are discussed in [RFC7575] and 126 [RFC7576]. 128 One approach is to largely decentralize the logic of network 129 management by migrating it into network elements. A reference model 130 for autonomic networking on this basis is given in 131 [I-D.ietf-anima-reference-model]. The reader should consult this 132 document to understand how various autonomic components fit together. 133 In order to fulfil autonomy, devices that embody Autonomic Service 134 Agents (ASAs, [RFC7575]) have specific signaling requirements. In 135 particular they need to discover each other, to synchronize state 136 with each other, and to negotiate parameters and resources directly 137 with each other. There is no limitation on the types of parameters 138 and resources concerned, which can include very basic information 139 needed for addressing and routing, as well as anything else that 140 might be configured in a conventional non-autonomic network. The 141 atomic unit of discovery, synchronization or negotiation is referred 142 to as a technical objective, i.e, a configurable parameter or set of 143 parameters (defined more precisely in Section 3.1). 145 Following this Introduction, Section 2 describes the requirements for 146 discovery, synchronization and negotiation. Negotiation is an 147 iterative process, requiring multiple message exchanges forming a 148 closed loop between the negotiating entities. In fact, these 149 entities are ASAs, normally but not necessarily in different network 150 devices. State synchronization, when needed, can be regarded as a 151 special case of negotiation, without iteration. Section 3.2 152 describes a behavior model for a protocol intended to support 153 discovery, synchronization and negotiation. The design of GeneRic 154 Autonomic Signaling Protocol (GRASP) in Section 3 of this document is 155 mainly based on this behavior model. The relevant capabilities of 156 various existing protocols are reviewed in Appendix D. 158 The proposed discovery mechanism is oriented towards synchronization 159 and negotiation objectives. It is based on a neighbor discovery 160 process, but also supports diversion to off-link peers. There is no 161 assumption of any particular form of network topology. When a device 162 starts up with no pre-configuration, it has no knowledge of the 163 topology. The protocol itself is capable of being used in a small 164 and/or flat network structure such as a small office or home network 165 as well as a professionally managed network. Therefore, the 166 discovery mechanism needs to be able to allow a device to bootstrap 167 itself without making any prior assumptions about network structure. 169 Because GRASP can be used to perform a decision process among 170 distributed devices or between networks, it must run in a secure and 171 strongly authenticated environment. 173 It is understood that in realistic deployments, not all devices will 174 support GRASP. It is expected that some autonomic service agents 175 will directly manage a group of non-autonomic nodes, and that other 176 non-autonomic nodes will be managed traditionally. Such mixed 177 scenarios are not discussed in this specification. 179 2. Requirement Analysis of Discovery, Synchronization and Negotiation 181 This section discusses the requirements for discovery, negotiation 182 and synchronization capabilities. The primary user of the protocol 183 is an autonomic service agent (ASA), so the requirements are mainly 184 expressed as the features needed by an ASA. A single physical device 185 might contain several ASAs, and a single ASA might manage several 186 technical objectives. If a technical objective is managed by several 187 ASAs, any necessary coordination is outside the scope of the 188 signaling protocol itself. 190 Note that requirements for ASAs themselves, such as the processing of 191 Intent [RFC7575] or interfaces for coordination between ASAs are out 192 of scope for the present document. 194 2.1. Requirements for Discovery 196 D1. ASAs may be designed to manage anything, as required in 197 Section 2.2. A basic requirement is therefore that the protocol can 198 represent and discover any kind of technical objective among 199 arbitrary subsets of participating nodes. 201 In an autonomic network we must assume that when a device starts up 202 it has no information about any peer devices, the network structure, 203 or what specific role it must play. The ASA(s) inside the device are 204 in the same situation. In some cases, when a new application session 205 starts up within a device, the device or ASA may again lack 206 information about relevant peers. For example, it might be necessary 207 to set up resources on multiple other devices, coordinated and 208 matched to each other so that there is no wasted resource. Security 209 settings might also need updating to allow for the new device or 210 user. The relevant peers may be different for different technical 211 objectives. Therefore discovery needs to be repeated as often as 212 necessary to find peers capable of acting as counterparts for each 213 objective that a discovery initiator needs to handle. From this 214 background we derive the next three requirements: 216 D2. When an ASA first starts up, it has no knowledge of the specific 217 network to which it is attached. Therefore the discovery process 218 must be able to support any network scenario, assuming only that the 219 device concerned is bootstrapped from factory condition. 221 D3. When an ASA starts up, it must require no configured location 222 information about any peers in order to discover them. 224 D4. If an ASA supports multiple technical objectives, relevant peers 225 may be different for different discovery objectives, so discovery 226 needs to be performed separately to find counterparts for each 227 objective. Thus, there must be a mechanism by which an ASA can 228 separately discover peer ASAs for each of the technical objectives 229 that it needs to manage, whenever necessary. 231 D5. Following discovery, an ASA will normally perform negotiation or 232 synchronization for the corresponding objectives. The design should 233 allow for this by conveniently linking discovery to negotiation and 234 synchronization. It may provide an optional mechanism to combine 235 discovery and negotiation/synchronization in a single call. 237 D6. Some objectives may only be significant on the local link, but 238 others may be significant across the routed network and require off- 239 link operations. Thus, the relevant peers might be immediate 240 neighbors on the same layer 2 link, or they might be more distant and 241 only accessible via layer 3. The mechanism must therefore provide 242 both on-link and off-link discovery of ASAs supporting specific 243 technical objectives. 245 D7. The discovery process should be flexible enough to allow for 246 special cases, such as the following: 248 o During initialisation, a device must be able to establish mutual 249 trust with the rest of the network and join an authentication 250 mechanism. Although this will inevitably start with a discovery 251 action, it is a special case precisely because trust is not yet 252 established. This topic is the subject of 253 [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once 254 trust has been established for a device, all ASAs within the 255 device inherit the device's credentials and are also trusted. 257 o Depending on the type of network involved, discovery of other 258 central functions might be needed, such as the Network Operations 259 Center (NOC) [I-D.ietf-anima-stable-connectivity]. The protocol 260 must be capable of supporting such discovery during 261 initialisation, as well as discovery during ongoing operation. 263 D8. The discovery process must not generate excessive traffic and 264 must take account of sleeping nodes in the case of a constrained-node 265 network [RFC7228]. 267 D9. There must be a mechanism for handling stale discovery results. 269 2.2. Requirements for Synchronization and Negotiation Capability 271 As background, consider the example of routing protocols, the closest 272 approximation to autonomic networking already in widespread use. 273 Routing protocols use a largely autonomic model based on distributed 274 devices that communicate repeatedly with each other. The focus is 275 reachability, so current routing protocols mainly consider simple 276 link status, i.e., up or down, and an underlying assumption is that 277 all nodes need a consistent view of the network topology in order for 278 the routing algorithm to converge. Thus, routing is mainly based on 279 information synchronization between peers, rather than on bi- 280 directional negotiation. Other information, such as latency, 281 congestion, capacity, and particularly unused capacity, would be 282 helpful to get better path selection and utilization rate, but is not 283 normally used in distributed routing algorithms. Additionally, 284 autonomic networks need to be able to manage many more dimensions, 285 such as security settings, power saving, load balancing, etc. Status 286 information and traffic metrics need to be shared between nodes for 287 dynamic adjustment of resources and for monitoring purposes. While 288 this might be achieved by existing protocols when they are available, 289 the new protocol needs to be able to support parameter exchange, 290 including mutual synchronization, even when no negotiation as such is 291 required. In general, these parameters do not apply to all 292 participating nodes, but only to a subset. 294 SN1. A basic requirement for the protocol is therefore the ability 295 to represent, discover, synchronize and negotiate almost any kind of 296 network parameter among selected subsets of participating nodes. 298 SN2. Negotiation is a request/response process that must be 299 guaranteed to terminate (with success or failure) and if necessary it 300 must contain tie-breaking rules for each technical objective that 301 requires them. While these must be defined specifically for each use 302 case, the protocol should have some general mechanisms in support of 303 loop and deadlock prevention, such as hop count limits or timeouts. 305 SN3. Synchronization might concern small groups of nodes or very 306 large groups. Different solutions might be needed at different 307 scales. 309 SN4. To avoid "reinventing the wheel", the protocol should be able 310 to encapsulate the data formats used by existing configuration 311 protocols (such as NETCONF/YANG) in cases where that is convenient. 313 SN5. Human intervention in complex situations is costly and error- 314 prone. Therefore, synchronization or negotiation of parameters 315 without human intervention is desirable whenever the coordination of 316 multiple devices can improve overall network performance. It 317 therefore follows that the protocol, as part of the Autonomic 318 Networking Infrastructure, should be capable of running in any device 319 that would otherwise need human intervention. The issue of running 320 in constrained nodes is discussed in 321 [I-D.ietf-anima-reference-model]. 323 SN6. Human intervention in large networks is often replaced by use 324 of a top-down network management system (NMS). It therefore follows 325 that the protocol, as part of the Autonomic Networking 326 Infrastructure, should be capable of running in any device that would 327 otherwise be managed by an NMS, and that it can co-exist with an NMS, 328 and with protocols such as SNMP and NETCONF. 330 SN7. Some features are expected to be implemented by individual 331 ASAs, but the protocol must be general enough to allow them: 333 o Dependencies and conflicts: In order to decide a configuration on 334 a given device, the device may need information from neighbors. 335 This can be established through the negotiation procedure, or 336 through synchronization if that is sufficient. However, a given 337 item in a neighbor may depend on other information from its own 338 neighbors, which may need another negotiation or synchronization 339 procedure to obtain or decide. Therefore, there are potential 340 dependencies and conflicts among negotiation or synchronization 341 procedures. Resolving dependencies and conflicts is a matter for 342 the individual ASAs involved. To allow this, there need to be 343 clear boundaries and convergence mechanisms for negotiations. 344 Also some mechanisms are needed to avoid loop dependencies. In 345 such a case, the protocol's role is limited to bilateral signaling 346 between ASAs. 348 o Recovery from faults and identification of faulty devices should 349 be as automatic as possible. The protocol's role is limited to 350 the ability to handle discovery, synchronization and negotiation 351 at any time, in case an ASA detects an anomaly such as a 352 negotiation counterpart failing. 354 o Since the goal is to minimize human intervention, it is necessary 355 that the network can in effect "think ahead" before changing its 356 parameters. One aspect of this is an ASA that relies on a 357 knowledge base to predict network behavior. This is out of scope 358 for the signaling protocol. However, another aspect is 359 forecasting the effect of a change by a "dry run" negotiation 360 before actually installing the change. This will be an 361 application of the protocol rather than a feature of the protocol 362 itself. 364 o Management logging, monitoring, alerts and tools for intervention 365 are required. However, these can only be features of individual 366 ASAs. Another document [I-D.ietf-anima-stable-connectivity] 367 discusses how such agents may be linked into conventional OAM 368 systems via an Autonomic Control Plane 369 [I-D.ietf-anima-autonomic-control-plane]. 371 SN8. The protocol will be able to deal with a wide variety of 372 technical objectives, covering any type of network parameter. 373 Therefore the protocol will need a flexible and easily extensible 374 format for describing objectives. At a later stage it may be 375 desirable to adopt an explicit information model. One consideration 376 is whether to adopt an existing information model or to design a new 377 one. 379 2.3. Specific Technical Requirements 381 T1. It should be convenient for ASA designers to define new 382 technical objectives and for programmers to express them, without 383 excessive impact on run-time efficiency and footprint. In 384 particular, it should be possible for ASAs to be implemented 385 independently of each other as user space programs rather than as 386 kernel code. The classes of device in which the protocol might run 387 is discussed in [I-D.ietf-anima-reference-model]. 389 T2. The protocol should be easily extensible in case the initially 390 defined discovery, synchronization and negotiation mechanisms prove 391 to be insufficient. 393 T3. To be a generic platform, the protocol payload format should be 394 independent of the transport protocol or IP version. In particular, 395 it should be able to run over IPv6 or IPv4. However, some functions, 396 such as multicasting on a link, might need to be IP version 397 dependent. In case of doubt, IPv6 should be preferred. 399 T4. The protocol must be able to access off-link counterparts via 400 routable addresses, i.e., must not be restricted to link-local 401 operation. 403 T5. It must also be possible for an external discovery mechanism to 404 be used, if appropriate for a given technical objective. In other 405 words, GRASP discovery must not be a prerequisite for GRASP 406 negotiation or synchronization. 408 T6. The protocol must be capable of supporting multiple simultaneous 409 operations, especially when wait states occur. 411 T7. Intent: There must be provision for general Intent rules to be 412 applied by all devices in the network (e.g., security rules, prefix 413 length, resource sharing rules). However, Intent distribution might 414 not use the signaling protocol itself, but its design should not 415 exclude such use. 417 T8. Management monitoring, alerts and intervention: Devices should 418 be able to report to a monitoring system. Some events must be able 419 to generate operator alerts and some provision for emergency 420 intervention must be possible (e.g. to freeze synchronization or 421 negotiation in a mis-behaving device). These features might not use 422 the signaling protocol itself, but its design should not exclude such 423 use. 425 T9. The protocol needs to be fully secured against forged messages 426 and man-in-the middle attacks, and secured as much as reasonably 427 possible against denial of service attacks. It needs to be capable 428 of encryption in order to resist unwanted monitoring. However, it is 429 not required that the protocol itself provides these security 430 features; it may depend on an existing secure environment. 432 3. GRASP Protocol Overview 434 3.1. Terminology 436 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 437 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 438 "OPTIONAL" in this document are to be interpreted as described in 439 [RFC2119] when they appear in ALL CAPS. When these words are not in 440 ALL CAPS (such as "should" or "Should"), they have their usual 441 English meanings, and are not to be interpreted as [RFC2119] key 442 words. 444 This document uses terminology defined in [RFC7575]. 446 The following additional terms are used throughout this document: 448 o Autonomic Device: identical to Autonomic Node. 450 o Discovery: a process by which an ASA discovers peers according to 451 a specific discovery objective. The discovery results may be 452 different according to the different discovery objectives. The 453 discovered peers may later be used as negotiation counterparts or 454 as sources of synchronization data. 456 o Negotiation: a process by which two ASAs interact iteratively to 457 agree on parameter settings that best satisfy the objectives of 458 both ASAs. 460 o State Synchronization: a process by which ASAs interact to receive 461 the current state of parameter values stored in other ASAs. This 462 is a special case of negotiation in which information is sent but 463 the ASAs do not request their peers to change parameter settings. 464 All other definitions apply to both negotiation and 465 synchronization. 467 o Technical Objective (usually abbreviated as Objective): A 468 technical objective is a configurable parameter or set of 469 parameters of some kind, which occurs in three contexts: 470 Discovery, Negotiation and Synchronization. In the protocol, an 471 objective is represented by an identifier and if relevant a value. 472 Normally, a given objective will not occur in negotiation and 473 synchronization contexts simultaneously. 475 * One ASA may support multiple independent objectives. 477 * The parameter described by a given objective is naturally based 478 on a specific service or function or action. It may in 479 principle be anything that can be set to a specific logical, 480 numerical or string value, or a more complex data structure, by 481 a network node. That node is generally expected to contain an 482 ASA which may itself manage subsidiary non-autonomic nodes. 484 * Discovery Objective: if a node needs to synchronize or 485 negotiate a specific objective but does not know a peer that 486 supports this objective, it starts a discovery process. The 487 objective is called a Discovery Objective during this process. 489 * Synchronization Objective: an objective whose specific 490 technical content needs to be synchronized among two or more 491 ASAs. 493 * Negotiation Objective: an objective whose specific technical 494 content needs to be decided in coordination with another ASA. 496 o Discovery Initiator: an ASA that spontaneously starts discovery by 497 sending a discovery message referring to a specific discovery 498 objective. 500 o Discovery Responder: a peer that either contains an ASA supporting 501 the discovery objective indicated by the discovery initiator, or 502 caches the locator(s) of the ASA(s) supporting the objective. The 503 locator(s) are indicated in a Discovery Response, which is 504 normally sent by the protocol kernel, as described later. 506 o Synchronization Initiator: an ASA that spontaneously starts 507 synchronization by sending a request message referring to a 508 specific synchronization objective. 510 o Synchronization Responder: a peer ASA which responds with the 511 value of a synchronization objective. 513 o Negotiation Initiator: an ASA that spontaneously starts 514 negotiation by sending a request message referring to a specific 515 negotiation objective. 517 o Negotiation Counterpart: a peer with which the Negotiation 518 Initiator negotiates a specific negotiation objective. 520 3.2. High-Level Design Choices 522 This section describes a behavior model and some considerations for 523 designing a generic signaling protocol initially supporting 524 discovery, synchronization and negotiation, which can act as a 525 platform for different technical objectives. 527 o A generic platform 528 The protocol is designed as a generic platform, which is 529 independent from the synchronization or negotiation contents. It 530 takes care of the general intercommunication between counterparts. 531 The technical contents will vary according to the various 532 technical objectives and the different pairs of counterparts. 534 o The protocol is expected to form part of an Autonomic Networking 535 Infrastructure [I-D.ietf-anima-reference-model]. It will provide 536 services to ASAs via a suitable application programming interface 537 (API), which will reflect the protocol elements but will not 538 necessarily be in one-to-one correspondence to them. This API is 539 out of scope for the present document. 541 o It is normally expected that a single main instance of GRASP will 542 exist in an autonomic node, and that the protocol engine and each 543 ASA will run as independent asynchronous processes. However, 544 separate GRASP instances may exist for security reasons 545 (Section 3.3.2). 547 o Security infrastructure and trust relationship 549 Because this negotiation protocol may directly cause changes to 550 device configurations and bring significant impacts to a running 551 network, this protocol is assumed to run within an existing secure 552 environment with strong authentication. As a design choice, the 553 protocol itself is not provided with built-in security 554 functionality. 556 On the other hand, a limited negotiation model might be deployed 557 based on a limited trust relationship. For example, between two 558 administrative domains, ASAs might also exchange limited 559 information and negotiate some particular configurations based on 560 a limited conventional or contractual trust relationship. 562 o Discovery, synchronization and negotiation are designed together. 564 The discovery method and the synchronization and negotiation 565 methods are designed in the same way and can be combined when this 566 is useful. These processes can also be performed independently 567 when appropriate. 569 * GRASP discovery is always available for efficient discovery of 570 GRASP peers and allows a rapid mode of operation described in 571 Section 3.3.4. For some objectives, especially those concerned 572 with application layer services, another discovery mechanism 573 such as the future DNS Service Discovery [RFC7558] or Service 574 Location Protocol [RFC2608] MAY be used. The choice is left to 575 the designers of individual ASAs. 577 o A uniform pattern for technical contents 579 The synchronization and negotiation contents are defined according 580 to a uniform pattern. They could be carried either in simple 581 binary format or in payloads described by a flexible language. 582 The basic protocol design uses the Concise Binary Object 583 Representation (CBOR) [RFC7049]. The format is extensible for 584 unknown future requirements. 586 o A flexible model for synchronization 588 GRASP supports bilateral synchronization, which could be used to 589 perform synchronization among a small number of nodes. It also 590 supports an unsolicited flooding mode when large groups of nodes, 591 possibly including all autonomic nodes, need data for the same 592 technical objective. 594 * There may be some network parameters for which a more 595 traditional flooding mechanism such as DNCP [RFC7787] is 596 considered more appropriate. GRASP can coexist with DNCP. 598 o A simple initiator/responder model for negotiation 600 Multi-party negotiations are too complicated to be modeled and 601 there might be too many dependencies among the parties to converge 602 efficiently. A simple initiator/responder model is more feasible 603 and can complete multi-party negotiations by indirect steps. 605 o Organizing of synchronization or negotiation content 607 Naturally, the technical content will be organized according to 608 the relevant function or service. The content from different 609 functions or services is kept independent from each other. They 610 are not combined into a single option or single session because 611 these contents may be negotiated or synchronized with different 612 counterparts or may be different in response time. Thus a normal 613 arrangement would be a single ASA managing a small set of closely 614 related objectives, with a version of that ASA in each relevant 615 autonomic node. Further discussion of this aspect is out of scope 616 for the current document. 618 o Requests and responses in negotiation procedures 620 The initiator can negotiate with its relevant negotiation 621 counterpart ASAs, which may be different according to the specific 622 negotiation objective. It can request relevant information from 623 the negotiation counterpart so that it can decide its local 624 configuration to give the most coordinated performance. It can 625 request the negotiation counterpart to make a matching 626 configuration in order to set up a successful communication with 627 it. It can request certain simulation or forecast results by 628 sending some dry run conditions. 630 Beyond the traditional yes/no answer, the responder can reply with 631 a suggested alternative value for the objective concerned. This 632 would start a bi-directional negotiation ending in a compromise 633 between the two ASAs. 635 o Convergence of negotiation procedures 637 To enable convergence, when a responder makes a suggestion of a 638 changed condition in a negative reply, it should be as close as 639 possible to the original request or previous suggestion. The 640 suggested value of the third or later negotiation steps should be 641 chosen between the suggested values from the last two negotiation 642 steps. In any case there must be a mechanism to guarantee 643 convergence (or failure) in a small number of steps, such as a 644 timeout or maximum number of iterations. 646 * End of negotiation 648 A limited number of rounds, for example three, or a timeout, is 649 needed on each ASA for each negotiation objective. It may be 650 an implementation choice, a pre-configurable parameter, or 651 network Intent. These choices might vary between different 652 types of ASA. Therefore, the definition of each negotiation 653 objective MUST clearly specify this, so that the negotiation 654 can always be terminated properly. 656 * 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 GRASP synchronization and negotiation functions if 686 there is neither an operational ACP nor an operational TLS or DTLS 687 environment. 689 Link-local multicast is used for discovery messages. Responses to 690 discovery messages MUST be secured, with one exception mentioned in 691 the next section. 693 3.3.2. Limited Security Instances 695 This section describes three cases where additional instances of 696 GRASP are appropriate. 698 1) As mentioned in Section 3.2, some GRASP operations might be 699 performed across an administrative domain boundary by mutual 700 agreement. Such operations MUST be confined to a separate instance 701 of GRASP with its own copy of all GRASP data structures. Messages 702 MUST be authenticated and SHOULD be encrypted. TLS is RECOMMENDED 703 for this purpose. 705 2) During initialisation, before a node has joined the applicable 706 trust infrastructure, [I-D.ietf-anima-bootstrapping-keyinfra], it is 707 impossible to secure messages. Thus, the security bootstrap process 708 needs to use insecure GRASP discovery, response and flood messages. 709 Such usage MUST be limited to link-local operations and MUST be 710 confined to a separate insecure instance of GRASP with its own copy 711 of all GRASP data structures. This instance is nicknamed DULL - 712 Discovery Unsolicited Link Local. 714 The detailed rules for the DULL instance of GRASP are as follows: 716 o An initiator MUST only send Discovery or Flood Synchronization 717 link-local multicast messages with a loop count of 1. A responder 718 MAY send a Discovery Response message. Other GRASP message types 719 MUST NOT be sent. 721 o A responder MUST silently discard any message whose loop count is 722 not 1. 724 o A responder MUST silently discard any message referring to a GRASP 725 Objective that is not directly part of the bootstrap creation 726 process. 728 o A responder MUST NOT relay any multicast messages. 730 o A Discovery Response MUST indicate a link-local address. 732 o A Discovery Response MUST NOT include a Divert option. 734 o A node MUST silently discard any message whose source address is 735 not link-local. 737 3) During ACP formation [I-D.ietf-anima-autonomic-control-plane], a 738 separate instance of GRASP is used, with unicast messages secured by 739 TLS, and with its own copy of all GRASP data structures. This 740 instance is nicknamed SONN - Secure Only Neighbor Negotiation. 742 The detailed rules for the SONN instance of GRASP are as follows: 744 o Any type of GRASP message MAY be sent. 746 o An initiator MUST send any Discovery or Flood Synchronization 747 link-local multicast messages with a loop count of 1. 749 o A responder MUST silently discard any Discovery or Flood 750 Synchronization message whose loop count is not 1. 752 o A responder MUST silently discard any message referring to a GRASP 753 Objective that is not directly part of the ACP creation process. 755 o A responder MUST NOT relay any multicast messages. 757 o A Discovery Response MUST indicate a link-local address. 759 o A Discovery Response MUST NOT include a Divert option. 761 o A node MUST silently discard any message whose source address is 762 not link-local. 764 3.3.3. Transport Layer Usage 766 GRASP discovery and flooding messages are designed for use over link- 767 local multicast UDP. They MUST NOT be fragmented, and therefore MUST 768 NOT exceed the link MTU size. Nothing in principle prevents them 769 from working over some other method of sending packets to all on-link 770 neighbors, but this is out of scope for the present specification. 772 All other GRASP messages are unicast and could in principle run over 773 any transport protocol. An implementation MUST support use of TCP. 774 It MAY support use of another transport protocol. However, GRASP 775 itself does not provide for error detection or retransmission. Use 776 of an unreliable transport protocol is therefore NOT RECOMMENDED. 778 Nevertheless, when running within a secure ACP on reliable 779 infrastructure, UDP MAY be used for unicast messages not exceeding 780 the minimum IPv6 path MTU; however, TCP MUST be used for longer 781 messages. In other words, IPv6 fragmentation is avoided. If a node 782 receives a UDP message but the reply is too long, it MUST open a TCP 783 connection to the peer for the reply. Note that when the network is 784 under heavy load or in a fault condition, UDP might become 785 unreliable. Since this is when autonomic functions are most 786 necessary, automatic fallback to TCP MUST be implemented. The 787 simplest implementation is therefore to use only TCP. In particular, 788 to guarantee interoperability during bootstrap and startup, using TCP 789 for discovery responses is strongly advised. 791 When running without an ACP, TLS MUST be supported and used by 792 default, except for link-local multicast messages. DTLS MAY be 793 supported as an alternative but the details are out of scope for this 794 document. Transport protocols other than TCP and UDP are also out of 795 scope for this document. 797 For link-local multicast, the GRASP protocol listens to the well- 798 known GRASP Listen Port (Section 3.5). For unicast transport 799 sessions used for discovery responses, synchronization and 800 negotiation, the ASA concerned normally listens on its own 801 dynamically assigned ports, which are communicated to its peers 802 during discovery. However, a minimal implementation MAY use the 803 GRASP Listen Port for this purpose. 805 3.3.4. Discovery Mechanism and Procedures 807 o Separated discovery and negotiation mechanisms 809 Although discovery and negotiation or synchronization are 810 defined together in the GRASP, they are separated mechanisms. 811 The discovery process could run independently from the 812 negotiation or synchronization process. Upon receiving a 813 Discovery (Section 3.7.3) message, the recipient node should 814 return a response message in which it either indicates itself 815 as a discovery responder or diverts the initiator towards 816 another more suitable ASA. 818 The discovery action will normally be followed by a negotiation 819 or synchronization action. The discovery results could be 820 utilized by the negotiation protocol to decide which ASA the 821 initiator will negotiate with. 823 The initiator of a discovery action for a given objective need 824 not be capable of responding to that objective as a Negotiation 825 Counterpart, as a Synchronization Responder or as source for 826 flooding. For example, an ASA might perform discovery even if 827 it only wishes to act a Synchronization Initiator or 828 Negotiation Initiator. Such an ASA does not itself need to 829 respond to discovery messages. 831 It is also entirely possible to use GRASP discovery without any 832 subsequent negotiation or synchronization action. In this 833 case, the discovered objective is simply used as a name during 834 the discovery process and any subsequent operations between the 835 peers are outside the scope of GRASP. 837 o Discovery Procedures 839 Discovery starts as an on-link operation. The Divert option 840 can tell the discovery initiator to contact an off-link ASA for 841 that discovery objective. Every Discovery message is sent by a 842 discovery initiator via UDP to the ALL_GRASP_NEIGHBOR link- 843 local multicast address (Section 3.5). Every network device 844 that supports GRASP always listens to a well-known UDP port to 845 capture the discovery messages. Because this port is unique in 846 a device, this is a function of the GRASP kernel and not of an 847 individual ASA. As a result, each ASA will need to register 848 the objectives that it supports with the GRASP kernel. 850 If an ASA in a neighbor device supports the requested discovery 851 objective, the device SHOULD respond to the link-local 852 multicast with a unicast Discovery Response message 853 (Section 3.7.4) with locator option(s), unless it is 854 temporarily unavailable. Otherwise, if the neighbor has cached 855 information about an ASA that supports the requested discovery 856 objective (usually because it discovered the same objective 857 before), it SHOULD respond with a Discovery Response message 858 with a Divert option pointing to the appropriate Discovery 859 Responder. 861 If a device has no information about the requested discovery 862 objective, and is not acting as a discovery relay (see below) 863 it MUST silently discard the Discovery message. 865 If no discovery response is received within a reasonable 866 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), 867 the Discovery message MAY be repeated, with a newly generated 868 Session ID (Section 3.6). An exponential backoff SHOULD be 869 used for subsequent repetitions, in order to mitigate possible 870 denial of service attacks. 872 After a GRASP device successfully discovers a locator for a 873 Discovery Responder supporting a specific objective, it MUST 874 cache this information, including the interface identifier via 875 which it was discovered. This cache record MAY be used for 876 future negotiation or synchronization, and the locator SHOULD 877 be passed on when appropriate as a Divert option to another 878 Discovery Initiator. 880 The cache mechanism MUST include a lifetime for each entry. 881 The lifetime is derived from a time-to-live (ttl) parameter in 882 each Discovery Response message. Cached entries MUST be 883 ignored or deleted after their lifetime expires. In some 884 environments, unplanned address renumbering might occur. In 885 such cases, the lifetime SHOULD be short compared to the 886 typical address lifetime and a mechanism to flush the discovery 887 cache SHOULD be implemented. The discovery mechanism needs to 888 track the node's current address to ensure that Discovery 889 Responses always indicate the correct address. 891 If multiple Discovery Responders are found for the same 892 objective, they SHOULD all be cached, unless this creates a 893 resource shortage. The method of choosing between multiple 894 responders is an implementation choice. This choice MUST be 895 available to each ASA but the GRASP implementation SHOULD 896 provide a default choice. 898 Because Discovery Responders will be cached in a finite cache, 899 they might be deleted at any time. In this case, discovery 900 will need to be repeated. If an ASA exits for any reason, its 901 locator might still be cached for some time, and attempts to 902 connect to it will fail. ASAs need to be robust in these 903 circumstances. 905 A GRASP device with multiple link-layer interfaces (typically a 906 router) MUST support discovery on all interfaces. If it 907 receives a Discovery message on a given interface for a 908 specific objective that it does not support and for which it 909 has not previously cached a Discovery Responder, it MUST relay 910 the query by re-issuing a Discovery message as a link-local 911 multicast on its other interfaces. The relayed discovery 912 message MUST have the same Session ID as the incoming discovery 913 message and MUST be tagged with the IP address of its original 914 initiator. Since the relay device is unaware of the timeout 915 set by the original initiator it SHOULD set a timeout at least 916 equal to GRASP_DEF_TIMEOUT milliseconds. 918 The relaying device MUST decrement the loop count within the 919 objective, and MUST NOT relay the Discovery message if the 920 result is zero. Also, it MUST limit the total rate at which it 921 relays discovery messages to a reasonable value, in order to 922 mitigate possible denial of service attacks. It MUST cache the 923 Session ID value and initiator address of each relayed 924 Discovery message until any Discovery Responses have arrived or 925 the discovery process has timed out. To prevent loops, it MUST 926 NOT relay a Discovery message which carries a given cached 927 Session ID and initiator address more than once. These 928 precautions avoid discovery loops and mitigate potential 929 overload. 931 The discovery results received by the relaying device MUST in 932 turn be sent as a Discovery Response message to the Discovery 933 message that caused the relay action. 935 This relayed discovery mechanism, with caching of the results, 936 should be sufficient to support most network bootstrapping 937 scenarios. 939 o A complete discovery process will start with a multicast on the 940 local link. On-link neighbors supporting the discovery objective 941 will respond directly. A neighbor with multiple interfaces will 942 respond with a cached discovery response if any. If not, it will 943 relay the discovery on its other interfaces, for example reaching 944 a higher-level gateway in a hierarchical network. If a node 945 receiving the relayed discovery supports the discovery objective, 946 it will respond to the relayed discovery. If it has a cached 947 response, it will respond with that. If not, it will repeat the 948 discovery process, which thereby becomes recursive. The loop 949 count and timeout will ensure that the process ends. 951 o Rapid Mode (Discovery/Negotiation binding) 953 A Discovery message MAY include a Negotiation Objective option. 954 This allows a rapid mode of negotiation described in 955 Section 3.3.5. A similar mechanism is defined for 956 synchronization in Section 3.3.6. 958 Note that rapid mode is currently limited to a single objective 959 for simplicity of design and implementation. A possible future 960 extension is to allow multiple objectives in rapid mode for 961 greater efficiency. 963 3.3.5. Negotiation Procedures 965 A negotiation initiator sends a negotiation request to a counterpart 966 ASA, including a specific negotiation objective. It may request the 967 negotiation counterpart to make a specific configuration. 968 Alternatively, it may request a certain simulation or forecast result 969 by sending a dry run configuration. The details, including the 970 distinction between dry run and an actual configuration change, will 971 be defined separately for each type of negotiation objective. 973 If no reply message of any kind is received within a reasonable 974 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 975 negotiation request MAY be repeated, with a newly generated Session 976 ID (Section 3.6). An exponential backoff SHOULD be used for 977 subsequent repetitions. 979 If the counterpart can immediately apply the requested configuration, 980 it will give an immediate positive (accept) answer. This will end 981 the negotiation phase immediately. Otherwise, it will negotiate. It 982 will reply with a proposed alternative configuration that it can 983 apply (typically, a configuration that uses fewer resources than 984 requested by the negotiation initiator). This will start a bi- 985 directional negotiation to reach a compromise between the two ASAs. 987 The negotiation procedure is ended when one of the negotiation peers 988 sends a Negotiation Ending message, which contains an accept or 989 decline option and does not need a response from the negotiation 990 peer. Negotiation may also end in failure (equivalent to a decline) 991 if a timeout is exceeded or a loop count is exceeded. 993 A negotiation procedure concerns one objective and one counterpart. 994 Both the initiator and the counterpart may take part in simultaneous 995 negotiations with various other ASAs, or in simultaneous negotiations 996 about different objectives. Thus, GRASP is expected to be used in a 997 multi-threaded mode. Certain negotiation objectives may have 998 restrictions on multi-threading, for example to avoid over-allocating 999 resources. 1001 Some configuration actions, for example wavelength switching in 1002 optical networks, might take considerable time to execute. The ASA 1003 concerned needs to allow for this by design, but GRASP does allow for 1004 a peer to insert latency in a negotiation process if necessary 1005 (Section 3.7.8). 1007 3.3.5.1. Rapid Mode (Discovery/Negotiation Linkage) 1009 A Discovery message MAY include a Negotiation Objective option. In 1010 this case the Discovery message also acts as a Request Negotiation 1011 message to indicate to the Discovery Responder that it could directly 1012 reply to the Discovery Initiator with a Negotiation message for rapid 1013 processing, if it could act as the corresponding negotiation 1014 counterpart. However, the indication is only advisory not 1015 prescriptive. 1017 It is possible that a Discovery Response will arrive from a responder 1018 that does not support rapid mode, before such a Negotiation message 1019 arrives. In this case, rapid mode will not occur. 1021 This rapid mode could reduce the interactions between nodes so that a 1022 higher efficiency could be achieved. However, a network in which 1023 some nodes support rapid mode and others do not will have complex 1024 timing-dependent behaviors. Therefore, the rapid negotiation 1025 function SHOULD be configured off by default and MAY be configured on 1026 or off by Intent. 1028 3.3.6. Synchronization and Flooding Procedure 1030 A synchronization initiator sends a synchronization request to a 1031 counterpart, including a specific synchronization objective. The 1032 counterpart responds with a Synchronization message (Section 3.7.9) 1033 containing the current value of the requested synchronization 1034 objective. No further messages are needed. 1036 If no reply message of any kind is received within a reasonable 1037 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 1038 synchronization request MAY be repeated, with a newly generated 1039 Session ID (Section 3.6). An exponential backoff SHOULD be used for 1040 subsequent repetitions. 1042 3.3.6.1. Flooding 1044 In the case just described, the message exchange is unicast and 1045 concerns only one synchronization objective. For large groups of 1046 nodes requiring the same data, synchronization flooding is available. 1047 For this, a flooding initiator MAY send an unsolicited Flood 1048 Synchronization message containing one or more Synchronization 1049 Objective option(s), if and only if the specification of those 1050 objectives permits it. This is sent as a multicast message to the 1051 ALL_GRASP_NEIGHBOR multicast address (Section 3.5). 1053 Every network device that supports GRASP always listens to a well- 1054 known UDP port to capture flooding messages. Because this port is 1055 unique in a device, this is a function of the GRASP kernel. 1057 To ensure that flooding does not result in a loop, the originator of 1058 the Flood Synchronization message MUST set the loop count in the 1059 objectives to a suitable value (the default is GRASP_DEF_LOOPCT). 1060 Also, a suitable mechanism is needed to avoid excessive multicast 1061 traffic. This mechanism MUST be defined as part of the specification 1062 of the synchronization objective(s) concerned. It might be a simple 1063 rate limit or a more complex mechanism such as the Trickle algorithm 1064 [RFC6206]. 1066 A GRASP device with multiple link-layer interfaces (typically a 1067 router) MUST support synchronization flooding on all interfaces. If 1068 it receives a multicast Flood Synchronization message on a given 1069 interface, it MUST relay it by re-issuing a Flood Synchronization 1070 message on its other interfaces. The relayed message MUST have the 1071 same Session ID as the incoming message and MUST be tagged with the 1072 IP address of its original initiator. 1074 The relaying device MUST decrement the loop count within the first 1075 objective, and MUST NOT relay the Flood Synchronization message if 1076 the result is zero. Also, it MUST limit the total rate at which it 1077 relays Flood Synchronization messages to a reasonable value, in order 1078 to mitigate possible denial of service attacks. It MUST cache the 1079 Session ID value and initiator address of each relayed Flood 1080 Synchronization message for a finite time not less than twice 1081 GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay 1082 a Flood Synchronization message which carries a given cached Session 1083 ID and initiator address more than once. These precautions avoid 1084 synchronization loops and mitigate potential overload. 1086 Note that this mechanism is unreliable in the case of sleeping nodes, 1087 or new nodes that join the network, or nodes that rejoin the network 1088 after a fault. An ASA that initiates a flood SHOULD repeat the flood 1089 at a suitable frequency and SHOULD also act as a synchronization 1090 responder for the objective(s) concerned. Thus nodes that require an 1091 objective subject to flooding can either wait for the next flood or 1092 request unicast synchronization for that objective. 1094 The multicast messages for synchronization flooding are subject to 1095 the security rules in Section 3.3.1. In practice this means that 1096 they MUST NOT be transmitted and MUST be ignored on receipt unless 1097 there is an operational ACP or equivalent strong security in place. 1098 However, because of the security weakness of link-local multicast 1099 (Section 5), synchronization objectives that are flooded SHOULD NOT 1100 contain unencrypted private information and SHOULD be validated by 1101 the recipient ASA. 1103 3.3.6.2. Rapid Mode (Discovery/Synchronization Linkage) 1105 A Discovery message MAY include a Synchronization Objective option. 1106 In this case the Discovery message also acts as a Request 1107 Synchronization message to indicate to the Discovery Responder that 1108 it could directly reply to the Discovery Initiator with a 1109 Synchronization message Section 3.7.9 with synchronization data for 1110 rapid processing, if the discovery target supports the corresponding 1111 synchronization objective. However, the indication is only advisory 1112 not prescriptive. 1114 It is possible that a Discovery Response will arrive from a responder 1115 that does not support rapid mode, before such a Synchronization 1116 message arrives. In this case, rapid mode will not occur. 1118 This rapid mode could reduce the interactions between nodes so that a 1119 higher efficiency could be achieved. However, a network in which 1120 some nodes support rapid mode and others do not will have complex 1121 timing-dependent behaviors. Therefore, the rapid synchronization 1122 function SHOULD be configured off by default and MAY be configured on 1123 or off by Intent. 1125 3.4. High Level Deployment Model 1127 It is expected that a GRASP implementation will reside in an 1128 autonomic node that also contains both the appropriate security 1129 environment (preferably the ACP) and one or more Autonomic Service 1130 Agents (ASAs). In the minimal case of a single-purpose device, these 1131 three components might be fully integrated. A more common model is 1132 expected to be a multi-purpose device capable of containing several 1133 ASAs. In this case it is expected that the ACP, GRASP and the ASAs 1134 will be implemented as separate processes, which are probably multi- 1135 threaded to support asynchronous and simultaneous operations. It is 1136 expected that GRASP will access the ACP by using a typical socket 1137 interface. A well defined Application Programming Interface (API) 1138 will be needed between GRASP and the ASAs. In some implementations, 1139 ASAs would run in user space with a GRASP library providing the API, 1140 and this library would in turn communicate via system calls with core 1141 GRASP functions running in kernel mode. For further details of 1142 possible deployment models, see [I-D.ietf-anima-reference-model]. 1144 Because GRASP needs to work whatever happens, especially during 1145 bootstrapping and during fault conditions, it is essential that every 1146 implementation is as robust as possible. For example, discovery 1147 failures, or any kind of socket error at any time, must not cause 1148 irrecoverable failures in GRASP itself, and must return suitable 1149 error codes through the API so that ASAs can also recover. 1151 GRASP must always start up correctly after a system restart. All run 1152 time error conditions, and events such as address renumbering, 1153 network interface failures, and CPU sleep/wake cycles, must be 1154 handled in such a way that GRASP will still operate correctly and 1155 securely (Section 3.3.1) afterwards. 1157 An autonomic node will normally run a single instance of GRASP, used 1158 by multiple ASAs. However, scenarios where multiple instances of 1159 GRASP run in a single node, perhaps with different security 1160 properties, are not excluded. In this case, each instance MUST 1161 listen independently for GRASP link-local muticasts in order for 1162 discovery and flooding to work correctly. 1164 3.5. GRASP Constants 1166 o ALL_GRASP_NEIGHBOR 1168 A link-local scope multicast address used by a GRASP-enabled 1169 device to discover GRASP-enabled neighbor (i.e., on-link) devices 1170 . All devices that support GRASP are members of this multicast 1171 group. 1173 * IPv6 multicast address: TBD1 1175 * IPv4 multicast address: TBD2 1177 o GRASP_LISTEN_PORT (TBD3) 1179 A well-known UDP user port that every GRASP-enabled network device 1180 MUST always listen to for link-local multicasts. Additionally, 1181 this user port MAY be used to listen for TCP or UDP unicast 1182 messages in a simple implementation of GRASP (Section 3.3.3). 1184 o GRASP_DEF_TIMEOUT (60000 milliseconds) 1186 The default timeout used to determine that a discovery etc. has 1187 failed to complete. 1189 o GRASP_DEF_LOOPCT (6) 1191 The default loop count used to determine that a negotiation has 1192 failed to complete, and to avoid looping messages. 1194 3.6. Session Identifier (Session ID) 1196 This is an up to 24-bit opaque value used to distinguish multiple 1197 sessions between the same two devices. A new Session ID MUST be 1198 generated by the initiator for every new Discovery, Flood 1199 Synchronization or Request message. All responses and follow-up 1200 messages in the same discovery, synchronization or negotiation 1201 procedure MUST carry the same Session ID. 1203 The Session ID SHOULD have a very low collision rate locally. It 1204 MUST be generated by a pseudo-random algorithm using a locally 1205 generated seed which is unlikely to be used by any other device in 1206 the same network [RFC4086]. 1208 However, there is a finite probability that two nodes might generate 1209 the same Session ID value. For that reason, when a Session ID is 1210 communicated via GRASP, the receiving node MUST tag it with the 1211 initiator's IP address to allow disambiguation. Multicast GRASP 1212 messages and their responses, which may be relayed between links, 1213 therefore include a field that carries the initiator's global IP 1214 address. 1216 3.7. GRASP Messages 1218 3.7.1. Message Overview 1220 This section defines the GRASP message format and message types. 1221 Message types not listed here are reserved for future use. 1223 The messages currently defined are: 1225 Discovery and Discovery Response. 1227 Request Negotiation, Negotiation, Confirm Waiting and Negotiation 1228 End. 1230 Request Synchronization, Synchronization, and Flood 1231 Synchronization. 1233 No Operation. 1235 3.7.2. GRASP Message Format 1237 GRASP messages share an identical header format and a variable format 1238 area for options. GRASP message headers and options are transmitted 1239 in Concise Binary Object Representation (CBOR) [RFC7049]. In this 1240 specification, they are described using CBOR data definition language 1241 (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is 1242 used to describe each item in this section. A complete and normative 1243 CDDL specification of GRASP is given in Section 6, including 1244 constants such as message types. 1246 Every GRASP message, except the No Operation message, carries a 1247 Session ID (Section 3.6). Options are then presented serially in the 1248 options field. 1250 In fragmentary CDDL, every GRASP message follows the pattern: 1252 grasp-message = (message .within message-structure) / noop-message 1254 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 1255 *grasp-option] 1257 MESSAGE_TYPE = 1..255 1258 session-id = 0..16777215 ;up to 24 bits 1259 grasp-option = any 1261 The MESSAGE_TYPE indicates the type of the message and thus defines 1262 the expected options. Any options received that are not consistent 1263 with the MESSAGE_TYPE SHOULD be silently discarded. 1265 The No Operation (noop) message is described in Section 3.7.11. 1267 The various MESSAGE_TYPE values are defined in Section 6. 1269 All other message elements are described below and formally defined 1270 in Section 6. 1272 3.7.3. Discovery Message 1274 In fragmentary CDDL, a Discovery message follows the pattern: 1276 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1278 A discovery initiator sends a Discovery message to initiate a 1279 discovery process for a particular objective option. 1281 The discovery initiator sends the Discovery messages via UDP to port 1282 GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast 1283 address. It then listens for unicast TCP responses on the same port, 1284 and stores the discovery results (including responding discovery 1285 objectives and corresponding unicast locators). 1287 The 'initiator' field in the message is a globally unique IP address 1288 of the initiator, for the sole purpose of disambiguating the Session 1289 ID in other nodes. If for some reason the initiator does not have a 1290 globally unique IP address, it MUST use a link-local address for this 1291 purpose that is highly likely to be unique, for example using 1292 [RFC7217]. 1294 A Discovery message MUST include exactly one of the following: 1296 o a discovery objective option (Section 3.9.1). Its loop count MUST 1297 be set to a suitable value to prevent discovery loops (default 1298 value is GRASP_DEF_LOOPCT). If the discovery initiator requires 1299 only on-link responses, the loop count MUST be set to 1. 1301 o a negotiation objective option (Section 3.9.1). This is used both 1302 for the purpose of discovery and to indicate to the discovery 1303 target that it MAY directly reply to the discovery initiatior with 1304 a Negotiation message for rapid processing, if it could act as the 1305 corresponding negotiation counterpart. The sender of such a 1306 Discovery message MUST initialize a negotiation timer and loop 1307 count in the same way as a Request Negotiation message 1308 (Section 3.7.5). 1310 o a synchronization objective option (Section 3.9.1). This is used 1311 both for the purpose of discovery and to indicate to the discovery 1312 target that it MAY directly reply to the discovery initiator with 1313 a Synchronization message for rapid processing, if it could act as 1314 the corresponding synchronization counterpart. Its loop count 1315 MUST be set to a suitable value to prevent discovery loops 1316 (default value is GRASP_DEF_LOOPCT). 1318 3.7.4. Discovery Response Message 1320 In fragmentary CDDL, a Discovery Response message follows the 1321 pattern: 1323 response-message = [M_RESPONSE, session-id, initiator, ttl, 1324 (+locator-option // divert-option), ?objective)] 1326 ttl = 0..4294967295 ; in milliseconds 1328 A node which receives a Discovery message SHOULD send a Discovery 1329 Response message if and only if it can respond to the discovery. 1331 It MUST contain the same Session ID and initiator as the Discovery 1332 message. 1334 It MUST contain a time-to-live (ttl) for the validity of the 1335 response, given as a positive integer value in milliseconds. Zero 1336 is treated as the default value GRASP_DEF_TIMEOUT (Section 3.5). 1338 It MAY include a copy of the discovery objective from the 1339 Discovery message. 1341 It is sent to the sender of the Discovery message via TCP at the port 1342 used to send the Discovery message. 1344 If the responding node supports the discovery objective of the 1345 discovery, it MUST include at least one kind of locator option 1346 (Section 3.8.5) to indicate its own location. A sequence of multiple 1347 kinds of locator options (e.g. IP address option and FQDN option) is 1348 also valid. 1350 If the responding node itself does not support the discovery 1351 objective, but it knows the locator of the discovery objective, then 1352 it SHOULD respond to the discovery message with a divert option 1353 (Section 3.8.2) embedding a locator option or a combination of 1354 multiple kinds of locator options which indicate the locator(s) of 1355 the discovery objective. 1357 More details on the processing of Discovery Responses are given in 1358 Section 3.3.4. 1360 3.7.5. Request Messages 1362 In fragmentary CDDL, Request Negotiation and Request Synchronization 1363 messages follow the patterns: 1365 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1367 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1368 A negotiation or synchronization requesting node sends the 1369 appropriate Request message to the unicast address (directly stored 1370 or resolved from an FQDN or URI) of the negotiation or 1371 synchronization counterpart, using the appropriate protocol and port 1372 numbers (selected from the discovery results). 1374 A Request message MUST include the relevant objective option. In the 1375 case of Request Negotiation, the objective option MUST include the 1376 requested value. 1378 When an initiator sends a Request Negotiation message, it MUST 1379 initialize a negotiation timer for the new negotiation thread with 1380 the value GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is 1381 modified by a Confirm Waiting message (Section 3.7.8), the initiator 1382 will consider that the negotiation has failed when the timer expires. 1384 When an initiator sends a Request message, it MUST initialize the 1385 loop count of the objective option with a value defined in the 1386 specification of the option or, if no such value is specified, with 1387 GRASP_DEF_LOOPCT. 1389 If a node receives a Request message for an objective for which no 1390 ASA is currently listening, it MUST immediately close the relevant 1391 socket to indicate this to the initiator. 1393 3.7.6. Negotiation Message 1395 In fragmentary CDDL, a Negotiation message follows the pattern: 1397 discovery-message = [M_NEGOTIATE, session-id, objective] 1399 A negotiation counterpart sends a Negotiation message in response to 1400 a Request Negotiation message, a Negotiation message, or a Discovery 1401 message in Rapid Mode. A negotiation process MAY include multiple 1402 steps. 1404 The Negotiation message MUST include the relevant Negotiation 1405 Objective option, with its value updated according to progress in the 1406 negotiation. The sender MUST decrement the loop count by 1. If the 1407 loop count becomes zero the message MUST NOT be sent. In this case 1408 the negotiation session has failed and will time out. 1410 3.7.7. Negotiation End Message 1412 In fragmentary CDDL, a Negotiation End message follows the pattern: 1414 end-message = [M_END, session-id, accept-option / decline-option] 1416 A negotiation counterpart sends an Negotiation End message to close 1417 the negotiation. It MUST contain either an accept or a decline 1418 option, defined in Section 3.8.3 and Section 3.8.4. It could be sent 1419 either by the requesting node or the responding node. 1421 3.7.8. Confirm Waiting Message 1423 In fragmentary CDDL, a Confirm Waiting message follows the pattern: 1425 wait-message = [M_WAIT, session-id, waiting-time] 1426 waiting-time = 0..4294967295 ; in milliseconds 1428 A responding node sends a Confirm Waiting message to ask the 1429 requesting node to wait for a further negotiation response. It might 1430 be that the local process needs more time or that the negotiation 1431 depends on another triggered negotiation. This message MUST NOT 1432 include any other options. When received, the waiting time value 1433 overwrites and restarts the current negotiation timer 1434 (Section 3.7.5). 1436 The responding node SHOULD send a Negotiation, Negotiation End or 1437 another Confirm Waiting message before the negotiation timer expires. 1438 If not, the initiator MUST abandon or restart the negotiation 1439 procedure, to avoid an indefinite wait. 1441 3.7.9. Synchronization Message 1443 In fragmentary CDDL, a Synchronization message follows the pattern: 1445 synch-message = [M_SYNCH, session-id, objective] 1447 A node which receives a Request Synchronization, or a Discovery 1448 message in Rapid Mode, sends back a unicast Synchronization message 1449 with the synchronization data, in the form of a GRASP Option for the 1450 specific synchronization objective present in the Request 1451 Synchronization. 1453 3.7.10. Flood Synchronization Message 1455 In fragmentary CDDL, a Flood Synchronization message follows the 1456 pattern: 1458 flood-message = [M_FLOOD, session-id, initiator, ttl, 1459 (locator-option / []), +objective] 1461 ttl = 0..4294967295 ; in milliseconds 1463 A node MAY initiate flooding by sending an unsolicited Flood 1464 Synchronization Message with synchronization data. This MAY be sent 1465 to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance 1466 with the rules in Section 3.3.6. 1468 The initiator address is provided as described for Discovery 1469 messages. 1471 The message MUST contain a time-to-live (ttl) for the validity of 1472 the response, given as a positive integer value in milliseconds. 1473 There is no default; zero indicates an indefinite lifetime. 1475 The message MAY contain a locator option indicating the ASA that 1476 initiated the flooded data. In its absence, an empty option MUST 1477 be included. 1479 The synchronization data are in the form of GRASP Option(s) for 1480 specific synchronization objective(s). The loop count(s) MUST be 1481 set to a suitable value to prevent flood loops (default value is 1482 GRASP_DEF_LOOPCT). 1484 A node that receives a Flood Synchronization message MUST cache the 1485 received objectives for use by local ASAs. Each cached objective 1486 MUST be tagged with the locator option sent with it, or with a null 1487 tag if an empty locator option was sent. If a subsequent Flood 1488 Synchronization message carrying the same objective arrives with the 1489 same tag, the corresponding cached copy of the objective MUST be 1490 overwritten. If a subsequent Flood Synchronization message carrying 1491 the same objective arrives with a different tag, a new cached entry 1492 MUST be created. 1494 Note: the purpose of this mechanism is to allow the recipient of 1495 flooded values to distinguish between different senders of the same 1496 objective, and if necessary communicate with them using the locator, 1497 protocol and port included in the locator option. Many objectives 1498 will not need this mechanism, so they will be flooded with a null 1499 locator. 1501 Cached entries MUST be ignored or deleted after their lifetime 1502 expires. 1504 3.7.11. No Operation Message 1506 In fragmentary CDDL, a No Operation message follows the pattern: 1508 noop-message = [M_NOOP] 1510 This message MAY be sent by an implementation that for practical 1511 reasons needs to activate a socket. It MUST be silently ignored by a 1512 recipient. 1514 3.8. GRASP Options 1516 This section defines the GRASP options for the negotiation and 1517 synchronization protocol signaling. Additional options may be 1518 defined in the future. 1520 3.8.1. Format of GRASP Options 1522 GRASP options are CBOR objects that MUST start with an unsigned 1523 integer identifying the specific option type carried in this option. 1524 These option types are formally defined in Section 6. Apart from 1525 that the only format requirement is that each option MUST be a well- 1526 formed CBOR object. In general a CBOR array format is RECOMMENDED to 1527 limit overhead. 1529 GRASP options are usually scoped by using encapsulation. However, 1530 this is not a requirement 1532 3.8.2. Divert Option 1534 The Divert option is used to redirect a GRASP request to another 1535 node, which may be more appropriate for the intended negotiation or 1536 synchronization. It may redirect to an entity that is known as a 1537 specific negotiation or synchronization counterpart (on-link or off- 1538 link) or a default gateway. The divert option MUST only be 1539 encapsulated in Discovery Response messages. If found elsewhere, it 1540 SHOULD be silently ignored. 1542 A discovery initiator MAY ignore a Divert option if it only requires 1543 direct discovery responses. 1545 In fragmentary CDDL, the Divert option follows the pattern: 1547 divert-option = [O_DIVERT, +locator-option] 1549 The embedded Locator Option(s) (Section 3.8.5) point to diverted 1550 destination target(s) in response to a Discovery message. 1552 3.8.3. Accept Option 1554 The accept option is used to indicate to the negotiation counterpart 1555 that the proposed negotiation content is accepted. 1557 The accept option MUST only be encapsulated in Negotiation End 1558 messages. If found elsewhere, it SHOULD be silently ignored. 1560 In fragmentary CDDL, the Accept option follows the pattern: 1562 accept-option = [O_ACCEPT] 1564 3.8.4. Decline Option 1566 The decline option is used to indicate to the negotiation counterpart 1567 the proposed negotiation content is declined and end the negotiation 1568 process. 1570 The decline option MUST only be encapsulated in Negotiation End 1571 messages. If found elsewhere, it SHOULD be silently ignored. 1573 In fragmentary CDDL, the Decline option follows the pattern: 1575 decline-option = [O_DECLINE, ?reason] 1576 reason = text ;optional error message 1578 Note: there are scenarios where a negotiation counterpart wants to 1579 decline the proposed negotiation content and continue the negotiation 1580 process. For these scenarios, the negotiation counterpart SHOULD use 1581 a Negotiate message, with either an objective option that contains a 1582 data field set to indicate a meaningless initial value, or a specific 1583 objective option that provides further conditions for convergence. 1585 3.8.5. Locator Options 1587 These locator options are used to present reachability information 1588 for an ASA, a device or an interface. They are Locator IPv6 Address 1589 Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified 1590 Domain Name) Option and URI (Uniform Resource Identifier) Option. 1592 Since ASAs will normally run as independent user programs, locator 1593 options need to indicate the network layer locator plus the transport 1594 protocol and port number for reaching the target. For this reason, 1595 the Locator Options for IP addresses and FQDNs include this 1596 information explicitly. In the case of the URI Option, this 1597 information can be encoded in the URI itself. 1599 Note: It is assumed that all locators are in scope throughout the 1600 GRASP domain. GRASP is not intended to work across disjoint 1601 addressing or naming realms. 1603 3.8.5.1. Locator IPv6 address option 1605 In fragmentary CDDL, the IPv6 address option follows the pattern: 1607 ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address, 1608 transport-proto, port-number] 1609 ipv6-address = bytes .size 16 1611 transport-proto = IPPROTO_TCP / IPPROTO_UDP 1612 IPPROTO_TCP = 6 1613 IPPROTO_UDP = 17 1614 port-number = 0..65535 1616 The content of this option is a binary IPv6 address followed by the 1617 protocol number and port number to be used. 1619 Note 1: The IPv6 address MUST normally have global scope. 1620 Exceptionally, during node bootstrap, a link-local address MAY be 1621 used for specific objectives only. 1623 Note 2: A link-local IPv6 address MUST NOT be used when this option 1624 is included in a Divert option. 1626 3.8.5.2. Locator IPv4 address option 1628 In fragmentary CDDL, the IPv4 address option follows the pattern: 1630 ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address, 1631 transport-proto, port-number] 1632 ipv4-address = bytes .size 4 1634 The content of this option is a binary IPv4 address followed by the 1635 protocol number and port number to be used. 1637 Note: If an operator has internal network address translation for 1638 IPv4, this option MUST NOT be used within the Divert option. 1640 3.8.5.3. Locator FQDN option 1642 In fragmentary CDDL, the FQDN option follows the pattern: 1644 fqdn-locator-option = [O_FQDN_LOCATOR, text, 1645 transport-proto, port-number] 1647 The content of this option is the Fully Qualified Domain Name of the 1648 target followed by the protocol number and port number to be used. 1650 Note 1: Any FQDN which might not be valid throughout the network in 1651 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1652 when this option is used within the Divert option. 1654 Note 2: Normal GRASP operations are not expected to use this option. 1655 It is intended for special purposes such as discovering external 1656 services. 1658 3.8.5.4. Locator URI option 1660 In fragmentary CDDL, the URI option follows the pattern: 1662 uri-locator = [O_URI_LOCATOR, text] 1664 The content of this option is the Uniform Resource Identifier of the 1665 target [RFC3986]. 1667 Note 1: Any URI which might not be valid throughout the network in 1668 question, such as one based on a Multicast DNS name [RFC6762], MUST 1669 NOT be used when this option is used within the Divert option. 1671 Note 2: Normal GRASP operations are not expected to use this option. 1672 It is intended for special purposes such as discovering external 1673 services. 1675 3.9. Objective Options 1677 3.9.1. Format of Objective Options 1679 An objective option is used to identify objectives for the purposes 1680 of discovery, negotiation or synchronization. All objectives MUST be 1681 in the following format, described in fragmentary CDDL: 1683 objective = [objective-name, objective-flags, loop-count, ?any] 1685 objective-name = text 1686 loop-count = 0..255 1688 All objectives are identified by a unique name which is a case- 1689 sensitive UTF-8 string. 1691 The names of generic objectives MUST NOT include a colon (":") and 1692 MUST be registered with IANA (Section 7). 1694 The names of privately defined objectives MUST include at least one 1695 colon (":"). The string preceding the last colon in the name MUST be 1696 globally unique and in some way identify the entity or person 1697 defining the objective. The following three methods MAY be used to 1698 create such a globally unique string: 1700 1. The unique string is a decimal number representing a registered 1701 32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 1702 uniquely identifies the enterprise defining the objective. 1704 2. The unique string is a fully qualified domain name that uniquely 1705 identifies the entity or person defining the objective. 1707 3. The unique string is an email address that uniquely identifies 1708 the entity or person defining the objective. 1710 The GRASP protocol treats the objective name as an opaque string. 1711 For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 1712 and "user@example.org:EX1" would be five different objectives. 1714 The 'objective-flags' field is described below. 1716 The 'loop-count' field is used for terminating negotiation as 1717 described in Section 3.7.6. It is also used for terminating 1718 discovery as described in Section 3.3.4, and for terminating flooding 1719 as described in Section 3.3.6.1. 1721 The 'any' field is to express the actual value of a negotiation or 1722 synchronization objective. Its format is defined in the 1723 specification of the objective and may be a single value or a data 1724 structure of any kind. It is optional because it is optional in a 1725 Discovery or Discovery Response message. 1727 3.9.2. Objective flags 1729 An objective may be relevant for discovery only, for discovery and 1730 negotiation, or for discovery and synchronization. This is expressed 1731 in the objective by logical flags: 1733 objective-flags = uint .bits objective-flag 1734 objective-flag = &( 1735 F_DISC: 0 ; valid for discovery only 1736 F_NEG: 1 ; valid for discovery and negotiation 1737 F_SYNCH: 2 ; valid for discovery and synchronization 1738 ) 1740 3.9.3. General Considerations for Objective Options 1742 As mentioned above, Objective Options MUST be assigned a unique name. 1743 As long as privately defined Objective Options obey the rules above, 1744 this document does not restrict their choice of name, but the entity 1745 or person concerned SHOULD publish the names in use. 1747 All Objective Options MUST respect the CBOR patterns defined above as 1748 "objective" and MUST replace the "any" field with a valid CBOR data 1749 definition for the relevant use case and application. 1751 An Objective Option that contains no additional fields beyond its 1752 "loop-count" can only be a discovery objective and MUST only be used 1753 in Discovery and Discovery Response messages. 1755 The Negotiation Objective Options contain negotiation objectives, 1756 which vary according to different functions/services. They MUST be 1757 carried by Discovery, Request Negotiation or Negotiation messages 1758 only. The negotiation initiator MUST set the initial "loop-count" to 1759 a value specified in the specification of the objective or, if no 1760 such value is specified, to GRASP_DEF_LOOPCT. 1762 For most scenarios, there should be initial values in the negotiation 1763 requests. Consequently, the Negotiation Objective options MUST 1764 always be completely presented in a Request Negotiation message, or 1765 in a Discovery message in rapid mode. If there is no initial value, 1766 the bits in the value field SHOULD all be set to indicate a 1767 meaningless value, unless this is inappropriate for the specific 1768 negotiation objective. 1770 Synchronization Objective Options are similar, but MUST be carried by 1771 Discovery, Discovery Response, Request Synchronization, or Flood 1772 Synchronization messages only. They include value fields only in 1773 Synchronization or Flood Synchronization messages. 1775 3.9.4. Organizing of Objective Options 1777 Generic objective options MUST be specified in documents available to 1778 the public and SHOULD be designed to use either the negotiation or 1779 the synchronization mechanism described above. 1781 As noted earlier, one negotiation objective is handled by each GRASP 1782 negotiation thread. Therefore, a negotiation objective, which is 1783 based on a specific function or action, SHOULD be organized as a 1784 single GRASP option. It is NOT RECOMMENDED to organize multiple 1785 negotiation objectives into a single option, nor to split a single 1786 function or action into multiple negotiation objectives. 1788 It is important to understand that GRASP negotiation does not support 1789 transactional integrity. If transactional integrity is needed for a 1790 specific objective, this must be ensured by the ASA. For example, an 1791 ASA might need to ensure that it only participates in one negotiation 1792 thread at the same time. Such an ASA would need to stop listening 1793 for incoming negotiation requests before generating an outgoing 1794 negotiation request. 1796 A synchronization objective SHOULD be organized as a single GRASP 1797 option. 1799 Some objectives will support more than one operational mode. An 1800 example is a negotiation objective with both a "dry run" mode (where 1801 the negotiation is to find out whether the other end can in fact make 1802 the requested change without problems) and a "live" mode. Such modes 1803 will be defined in the specification of such an objective. These 1804 objectives SHOULD include flags indicating the applicable mode(s). 1806 An objective may have multiple parameters. Parameters can be 1807 categorized into two classes: the obligatory ones presented as fixed 1808 fields; and the optional ones presented in CBOR sub-options or some 1809 other form of data structure embedded in CBOR. The format might be 1810 inherited from an existing management or configuration protocol, the 1811 objective option acting as a carrier for that format. The data 1812 structure might be defined in a formal language, but that is a matter 1813 for the specifications of individual objectives. There are many 1814 candidates, according to the context, such as ABNF, RBNF, XML Schema, 1815 possibly YANG, etc. The GRASP protocol itself is agnostic on these 1816 questions. 1818 It is NOT RECOMMENDED to split parameters in a single objective into 1819 multiple options, unless they have different response periods. An 1820 exception scenario may also be described by split objectives. 1822 All objectives MUST support GRASP discovery. However, as mentioned 1823 in Section 3.2, it is acceptable for an ASA to use an alternative 1824 method of discovery. 1826 Normally, a GRASP objective will refer to specific technical 1827 parameters as explained in Section 3.1. However, it is acceptable to 1828 define an abstract objective for the purpose of managing or 1829 coordinating ASAs. It is also acceptable to define a special-purpose 1830 objective for purposes such as trust bootstrapping or formation of 1831 the ACP. 1833 3.9.5. Experimental and Example Objective Options 1835 The names "EX0" through "EX9" have been reserved for experimental 1836 options. Multiple names have been assigned because a single 1837 experiment may use multiple options simultaneously. These 1838 experimental options are highly likely to have different meanings 1839 when used for different experiments. Therefore, they SHOULD NOT be 1840 used without an explicit human decision and SHOULD NOT be used in 1841 unmanaged networks such as home networks. 1843 These names are also RECOMMENDED for use in documentation examples. 1845 4. Implementation Status [RFC Editor: please remove] 1847 Two prototype implementations of GRASP have been made. 1849 4.1. BUPT C++ Implementation 1851 o Name: BaseNegotiator.cpp, msg.cpp, Client.cpp, Server.cpp 1853 o Description: C++ implementation of GRASP kernel and API 1855 o Maturity: Prototype code, interoperable between Ubuntu. 1857 o Coverage: Corresponds to draft-carpenter-anima-gdn-protocol-03. 1858 Since it was implemented based on the old version draft, the most 1859 significant limitations comparing to current protocol design 1860 include: 1862 * Not support CBOR 1864 * Not support Flooding 1866 * Not support loop avoidance 1868 * only coded for IPv6, any IPv4 is accidental 1870 o Licensing: Huawei License. 1872 o Experience: https://github.com/liubingpang/IETF-Anima-Signaling- 1873 Protocol/blob/master/README.md 1875 o Contact: https://github.com/liubingpang/IETF-Anima-Signaling- 1876 Protocol 1878 4.2. Python Implementation 1880 o Name: graspy 1882 o Description: Python 3 implementation of GRASP kernel and API. 1884 o Maturity: Prototype code, interoperable between Windows 7 and 1885 Debian. 1887 o Coverage: Corresponds to draft-ietf-anima-grasp-07. Limitations 1888 include: 1890 * insecure: uses a dummy ACP module and does not implement TLS 1892 * only coded for IPv6, any IPv4 is accidental 1894 * FQDN and URI locators incompletely supported 1896 * no code for rapid mode 1898 * relay code is lazy (no rate control) 1900 * all unicast transactions use TCP (no unicast UDP). 1901 Experimental code for unicast UDP proved to be complex and 1902 brittle. 1904 * optional Objective option in Response messages not implemented 1906 * workarounds for defects in Python socket module and Windows 1907 socket peculiarities 1909 o Licensing: Simplified BSD 1911 o Experience: https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf 1913 o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ 1915 5. Security Considerations 1917 It is obvious that a successful attack on negotiation-enabled nodes 1918 would be extremely harmful, as such nodes might end up with a 1919 completely undesirable configuration that would also adversely affect 1920 their peers. GRASP nodes and messages therefore require full 1921 protection. 1923 - Authentication 1925 A cryptographically authenticated identity for each device is 1926 needed in an autonomic network. It is not safe to assume that a 1927 large network is physically secured against interference or that 1928 all personnel are trustworthy. Each autonomic node MUST be 1929 capable of proving its identity and authenticating its messages. 1930 GRASP relies on a separate external certificate-based security 1931 mechanism to support authentication, data integrity protection, 1932 and anti-replay protection. 1934 Since GRASP is intended to be deployed in a single administrative 1935 domain operating its own trust anchor and CA, there is no need for 1936 a trusted public third party. In a network requiring "air gap" 1937 security, such a dependency would be unacceptable. 1939 If GRASP is used temporarily without an external security 1940 mechanism, for example during system bootstrap (Section 3.3.1), 1941 the Session ID (Section 3.6) will act as a nonce to provide 1942 limited protection against third parties injecting responses. A 1943 full analysis of the secure bootstrap process is out of scope for 1944 the present document. 1946 - Authorization and Roles 1948 The GRASP protocol is agnostic about the role of individual ASAs 1949 and about which objectives a particular ASA is authorized to 1950 support. An implementation might support precautions such as 1951 allowing only one ASA in a given node to modify a given objective, 1952 but this may not be appropriate in all cases. For example, it 1953 might be operationally useful to allow an old and a new version of 1954 the same ASA to run simultaneously during an overlap period. 1955 These questions are out of scope for the present specification. 1957 - Privacy and confidentiality 1959 Generally speaking, no personal information is expected to be 1960 involved in the signaling protocol, so there should be no direct 1961 impact on personal privacy. Nevertheless, traffic flow paths, 1962 VPNs, etc. could be negotiated, which could be of interest for 1963 traffic analysis. Also, operators generally want to conceal 1964 details of their network topology and traffic density from 1965 outsiders. Therefore, since insider attacks cannot be excluded in 1966 a large network, the security mechanism for the protocol MUST 1967 provide message confidentiality. This is why Section 3.3.1 1968 requires either an ACP or the use of TLS. 1970 - Link-local multicast security 1972 GRASP has no reasonable alternative to using link-local multicast 1973 for Discovery or Flood Synchronization messages and these messages 1974 are sent in clear and with no authentication. They are therefore 1975 available to on-link eavesdroppers, and could be forged by on-link 1976 attackers. In the case of Discovery, the Discovery Responses are 1977 unicast and will therefore be protected (Section 3.3.1), and an 1978 untrusted forger will not be able to receive responses. In the 1979 case of Flood Synchronization, an on-link eavesdropper will be 1980 able to receive the flooded objectives but there is no response 1981 message to consider. Some precautions for Flood Synchronization 1982 messages are suggested in Section 3.3.6.1. 1984 - DoS Attack Protection 1986 GRASP discovery partly relies on insecure link-local multicast. 1987 Since routers participating in GRASP sometimes relay discovery 1988 messages from one link to another, this could be a vector for 1989 denial of service attacks. Relevant mitigations are specified in 1990 Section 3.3.4. Additionally, it is of great importance that 1991 firewalls prevent any GRASP messages from entering the domain from 1992 an untrusted source. 1994 - Security during bootstrap and discovery 1996 A node cannot authenticate GRASP traffic from other nodes until it 1997 has identified the trust anchor and can validate certificates for 1998 other nodes. Also, until it has succesfully enrolled 1999 [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that 2000 other nodes are able to authenticate its own traffic. Therefore, 2001 GRASP discovery during the bootstrap phase for a new device will 2002 inevitably be insecure and GRASP synchronization and negotiation 2003 will be impossible until enrollment is complete. Further details 2004 are given in Section 3.3.2. 2006 - Security of discovered locators 2008 When GRASP discovery returns an IP address, it MUST be that of a 2009 node within the secure environment (Section 3.3.1). If it returns 2010 an FQDN or a URI, the ASA that receives it MUST NOT assume that 2011 the target of the locator is within the secure environment. 2013 6. CDDL Specification of GRASP 2015 2016 grasp-message = (message .within message-structure) / noop-message 2018 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 2019 *grasp-option] 2021 MESSAGE_TYPE = 0..255 2022 session-id = 0..16777215 ;up to 24 bits 2023 grasp-option = any 2025 message /= discovery-message 2026 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 2028 message /= response-message ;response to Discovery 2029 response-message = [M_RESPONSE, session-id, initiator, ttl, 2030 (+locator-option // divert-option), ?objective] 2032 message /= synch-message ;response to Synchronization request 2033 synch-message = [M_SYNCH, session-id, objective] 2035 message /= flood-message 2036 flood-message = [M_FLOOD, session-id, initiator, ttl, 2037 (locator-option / []), +objective] 2039 message /= request-negotiation-message 2040 request-negotiation-message = [M_REQ_NEG, session-id, objective] 2042 message /= request-synchronization-message 2043 request-synchronization-message = [M_REQ_SYN, session-id, objective] 2045 message /= negotiation-message 2046 negotiation-message = [M_NEGOTIATE, session-id, objective] 2048 message /= end-message 2049 end-message = [M_END, session-id, accept-option / decline-option ] 2051 message /= wait-message 2052 wait-message = [M_WAIT, session-id, waiting-time] 2054 noop-message = [M_NOOP] 2056 divert-option = [O_DIVERT, +locator-option] 2058 accept-option = [O_ACCEPT] 2060 decline-option = [O_DECLINE, ?reason] 2061 reason = text ;optional error message 2063 waiting-time = 0..4294967295 ; in milliseconds 2064 ttl = 0..4294967295 ; in milliseconds 2066 locator-option /= [O_IPv4_LOCATOR, ipv4-address, 2067 transport-proto, port-number] 2068 ipv4-address = bytes .size 4 2070 locator-option /= [O_IPv6_LOCATOR, ipv6-address, 2071 transport-proto, port-number] 2072 ipv6-address = bytes .size 16 2074 locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number] 2076 transport-proto = IPPROTO_TCP / IPPROTO_UDP 2077 IPPROTO_TCP = 6 2078 IPPROTO_UDP = 17 2079 port-number = 0..65535 2081 locator-option /= [O_URI_LOCATOR, text] 2083 initiator = ipv4-address / ipv6-address 2085 objective-flags = uint .bits objective-flag 2087 objective-flag = &( 2088 F_DISC: 0 ; valid for discovery only 2089 F_NEG: 1 ; valid for discovery and negotiation 2090 F_SYNCH: 2) ; valid for discovery and synchronization 2092 objective = [objective-name, objective-flags, loop-count, ?any] 2094 objective-name = text ;see specification for uniqueness rules 2096 loop-count = 0..255 2098 ; Constants for message types and option types 2100 M_NOOP = 0 2101 M_DISCOVERY = 1 2102 M_RESPONSE = 2 2103 M_REQ_NEG = 3 2104 M_REQ_SYN = 4 2105 M_NEGOTIATE = 5 2106 M_END = 6 2107 M_WAIT = 7 2108 M_SYNCH = 8 2109 M_FLOOD = 9 2111 O_DIVERT = 100 2112 O_ACCEPT = 101 2113 O_DECLINE = 102 2114 O_IPv6_LOCATOR = 103 2115 O_IPv4_LOCATOR = 104 2116 O_FQDN_LOCATOR = 105 2117 O_URI_LOCATOR = 106 2118 2120 7. IANA Considerations 2122 This document defines the Generic Autonomic Signaling Protocol 2123 (GRASP). 2125 Section 3.5 explains the following link-local multicast addresses, 2126 which IANA is requested to assign for use by GRASP: 2128 ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in 2129 the IPv6 Link-Local Scope Multicast Addresses registry. 2131 ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in 2132 the IPv4 Multicast Local Network Control Block. 2134 Section 3.5 explains the following User Port, which IANA is requested 2135 to assign for use by GRASP for both UDP and TCP: 2137 GRASP_LISTEN_PORT: (TBD3) 2138 Service Name: Generic Autonomic Signaling Protocol (GRASP) 2139 Transport Protocols: UDP, TCP 2140 Assignee: iesg@ietf.org 2141 Contact: chair@ietf.org 2142 Description: See Section 3.5 2143 Reference: RFC XXXX (this document) 2145 The IANA is requested to create a GRASP Parameter Registry including 2146 two registry tables. These are the GRASP Messages and Options 2147 Table and the GRASP Objective Names Table. 2149 GRASP Messages and Options Table. The values in this table are names 2150 paired with decimal integers. Future values MUST be assigned using 2151 the Standards Action policy defined by [RFC5226]. The following 2152 initial values are assigned by this document: 2154 M_NOOP = 0 2155 M_DISCOVERY = 1 2156 M_RESPONSE = 2 2157 M_REQ_NEG = 3 2158 M_REQ_SYN = 4 2159 M_NEGOTIATE = 5 2160 M_END = 6 2161 M_WAIT = 7 2162 M_SYNCH = 8 2163 M_FLOOD = 9 2165 O_DIVERT = 100 2166 O_ACCEPT = 101 2167 O_DECLINE = 102 2168 O_IPv6_LOCATOR = 103 2169 O_IPv4_LOCATOR = 104 2170 O_FQDN_LOCATOR = 105 2171 O_URI_LOCATOR = 106 2172 GRASP Objective Names Table. The values in this table are UTF-8 2173 strings. Future values MUST be assigned using the Specification 2174 Required policy defined by [RFC5226]. The following initial values 2175 are assigned by this document: 2177 EX0 2178 EX1 2179 EX2 2180 EX3 2181 EX4 2182 EX5 2183 EX6 2184 EX7 2185 EX8 2186 EX9 2188 8. Acknowledgements 2190 A major contribution to the original version of this document was 2191 made by Sheng Jiang. 2193 Valuable comments were received from Michael Behringer, Jeferson 2194 Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Toerless Eckert, Yu Fu, 2195 Joel Halpern, Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, 2196 Reshad Rahman, Michael Richardson, Markus Stenberg, Rene Struik, 2197 Dacheng Zhang, and other participants in the NMRG research group and 2198 the ANIMA working group. 2200 9. References 2202 9.1. Normative References 2204 [I-D.greevenbosch-appsawg-cbor-cddl] 2205 Vigano, C. and H. Birkholz, "CBOR data definition language 2206 (CDDL): a notational convention to express CBOR data 2207 structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work 2208 in progress), March 2016. 2210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2211 Requirement Levels", BCP 14, RFC 2119, 2212 DOI 10.17487/RFC2119, March 1997, 2213 . 2215 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2216 Resource Identifier (URI): Generic Syntax", STD 66, 2217 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2218 . 2220 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2221 "Randomness Requirements for Security", BCP 106, RFC 4086, 2222 DOI 10.17487/RFC4086, June 2005, 2223 . 2225 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2226 (TLS) Protocol Version 1.2", RFC 5246, 2227 DOI 10.17487/RFC5246, August 2008, 2228 . 2230 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2231 Housley, R., and W. Polk, "Internet X.509 Public Key 2232 Infrastructure Certificate and Certificate Revocation List 2233 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2234 . 2236 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2237 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2238 January 2012, . 2240 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2241 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2242 October 2013, . 2244 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2245 Interface Identifiers with IPv6 Stateless Address 2246 Autoconfiguration (SLAAC)", RFC 7217, 2247 DOI 10.17487/RFC7217, April 2014, 2248 . 2250 9.2. Informative References 2252 [I-D.chaparadza-intarea-igcp] 2253 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 2254 Mahkonen, "IP based Generic Control Protocol (IGCP)", 2255 draft-chaparadza-intarea-igcp-00 (work in progress), July 2256 2011. 2258 [I-D.ietf-anima-autonomic-control-plane] 2259 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 2260 Control Plane", draft-ietf-anima-autonomic-control- 2261 plane-03 (work in progress), July 2016. 2263 [I-D.ietf-anima-bootstrapping-keyinfra] 2264 Pritikin, M., Richardson, M., Behringer, M., and S. 2265 Bjarnason, "Bootstrapping Remote Secure Key 2266 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2267 keyinfra-03 (work in progress), June 2016. 2269 [I-D.ietf-anima-reference-model] 2270 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 2271 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 2272 Reference Model for Autonomic Networking", draft-ietf- 2273 anima-reference-model-02 (work in progress), July 2016. 2275 [I-D.ietf-anima-stable-connectivity] 2276 Eckert, T. and M. Behringer, "Using Autonomic Control 2277 Plane for Stable Connectivity of Network OAM", draft-ietf- 2278 anima-stable-connectivity-01 (work in progress), July 2279 2016. 2281 [I-D.ietf-netconf-restconf] 2282 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2283 Protocol", draft-ietf-netconf-restconf-16 (work in 2284 progress), August 2016. 2286 [I-D.liang-iana-pen] 2287 Liang, P., Melnikov, A., and D. Conrad, "Private 2288 Enterprise Number (PEN) practices and Internet Assigned 2289 Numbers Authority (IANA) registration considerations", 2290 draft-liang-iana-pen-06 (work in progress), July 2015. 2292 [I-D.stenberg-anima-adncp] 2293 Stenberg, M., "Autonomic Distributed Node Consensus 2294 Protocol", draft-stenberg-anima-adncp-00 (work in 2295 progress), March 2015. 2297 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2298 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2299 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2300 September 1997, . 2302 [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, 2303 "Server Cache Synchronization Protocol (SCSP)", RFC 2334, 2304 DOI 10.17487/RFC2334, April 1998, 2305 . 2307 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 2308 "Service Location Protocol, Version 2", RFC 2608, 2309 DOI 10.17487/RFC2608, June 1999, 2310 . 2312 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2313 "Remote Authentication Dial In User Service (RADIUS)", 2314 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2315 . 2317 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2318 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2319 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2320 . 2322 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2323 C., and M. Carney, "Dynamic Host Configuration Protocol 2324 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2325 2003, . 2327 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 2328 for the Simple Network Management Protocol (SNMP)", 2329 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 2330 . 2332 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2333 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2334 DOI 10.17487/RFC4861, September 2007, 2335 . 2337 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2338 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2339 DOI 10.17487/RFC5226, May 2008, 2340 . 2342 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2343 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2344 October 2010, . 2346 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 2347 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 2348 March 2011, . 2350 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2351 and A. Bierman, Ed., "Network Configuration Protocol 2352 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2353 . 2355 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2356 Ed., "Diameter Base Protocol", RFC 6733, 2357 DOI 10.17487/RFC6733, October 2012, 2358 . 2360 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2361 DOI 10.17487/RFC6762, February 2013, 2362 . 2364 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2365 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2366 . 2368 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2369 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2370 DOI 10.17487/RFC6887, April 2013, 2371 . 2373 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2374 Constrained-Node Networks", RFC 7228, 2375 DOI 10.17487/RFC7228, May 2014, 2376 . 2378 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 2379 "Requirements for Scalable DNS-Based Service Discovery 2380 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 2381 DOI 10.17487/RFC7558, July 2015, 2382 . 2384 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2385 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2386 Networking: Definitions and Design Goals", RFC 7575, 2387 DOI 10.17487/RFC7575, June 2015, 2388 . 2390 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 2391 Analysis for Autonomic Networking", RFC 7576, 2392 DOI 10.17487/RFC7576, June 2015, 2393 . 2395 [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus 2396 Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, 2397 . 2399 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2400 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2401 2016, . 2403 Appendix A. Open Issues 2405 o 7. Cross-check against other ANIMA WG documents for consistency 2406 and gaps. 2408 Appendix B. Closed Issues [RFC Editor: Please remove] 2410 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 2411 as message transport mechanisms. This is not clarified yet. UDP 2412 is good for short conversations, is necessary for multicast 2413 discovery, and generally fits the discovery and divert scenarios 2414 well. However, it will cause problems with large messages. TCP 2415 is good for stable and long sessions, with a little bit of time 2416 consumption during the session establishment stage. If messages 2417 exceed a reasonable MTU, a TCP mode will be required in any case. 2418 This question may be affected by the security discussion. 2420 RESOLVED by specifying UDP for short message and TCP for longer 2421 one. 2423 o 2. DTLS or TLS vs built-in security mechanism. For now, this 2424 specification has chosen a PKI based built-in security mechanism 2425 based on asymmetric cryptography. However, (D)TLS might be chosen 2426 as security solution to avoid duplication of effort. It also 2427 allows essentially similar security for short messages over UDP 2428 and longer ones over TCP. The implementation trade-offs are 2429 different. The current approach requires expensive asymmetric 2430 cryptographic calculations for every message. (D)TLS has startup 2431 overheads but cheaper crypto per message. DTLS is less mature 2432 than TLS. 2434 RESOLVED by specifying external security (ACP or (D)TLS). 2436 o The following open issues applied only if the original security 2437 model was retained: 2439 * 2.1. For replay protection, GRASP currently requires every 2440 participant to have an NTP-synchronized clock. Is this OK for 2441 low-end devices, and how does it work during device 2442 bootstrapping? We could take the Timestamp out of signature 2443 option, to become an independent and OPTIONAL (or RECOMMENDED) 2444 option. 2446 * 2.2. The Signature Option states that this option could be any 2447 place in a message. Wouldn't it be better to specify a 2448 position (such as the end)? That would be much simpler to 2449 implement. 2451 RESOLVED by changing security model. 2453 o 3. DoS Attack Protection needs work. 2455 RESOLVED by adding text. 2457 o 4. Should we consider preferring a text-based approach to 2458 discovery (after the initial discovery needed for bootstrapping)? 2459 This could be a complementary mechanism for multicast based 2460 discovery, especially for a very large autonomic network. 2461 Centralized registration could be automatically deployed 2462 incrementally. At the very first stage, the repository could be 2463 empty; then it could be filled in by the objectives discovered by 2464 different devices (for example using Dynamic DNS Update). The 2465 more records are stored in the repository, the less the multicast- 2466 based discovery is needed. However, if we adopt such a mechanism, 2467 there would be challenges: stateful solution, and security. 2469 RESOLVED for now by adding optional use of DNS-SD by ASAs. 2470 Subsequently removed by editors as irrelevant to GRASP istelf. 2472 o 5. Need to expand description of the minimum requirements for the 2473 specification of an individual discovery, synchronization or 2474 negotiation objective. 2476 RESOLVED for now by extra wording. 2478 o 6. Use case and protocol walkthrough. A description of how a 2479 node starts up, performs discovery, and conducts negotiation and 2480 synchronisation for a sample use case would help readers to 2481 understand the applicability of this specification. Maybe it 2482 should be an artificial use case or maybe a simple real one, based 2483 on a conceptual API. However, the authors have not yet decided 2484 whether to have a separate document or have it in the protocol 2485 document. 2487 RESOLVED: recommend a separate document. 2489 o 8. Consideration of ADNCP proposal. 2491 RESOLVED by adding optional use of DNCP for flooding-type 2492 synchronization. 2494 o 9. Clarify how a GDNP instance knows whether it is running inside 2495 the ACP. (Sheng) 2497 RESOLVED by improved text. 2499 o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. 2500 (Sheng) 2502 RESOLVED by improved text and declaring DTLS out of scope for this 2503 draft. 2505 o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - 2506 Brian] 2508 RESOLVED by improved text. 2510 o 12. Justify that IP address within ACP or (D)TLS environment is 2511 sufficient to prove AN identity; or explain how Device Identity 2512 Option is used. (Sheng) 2514 RESOLVED for now: we assume that all ASAs in a device are trusted 2515 as soon as the device is trusted, so they share credentials. In 2516 that case the Device Identity Option is useless. This needs to be 2517 reviewed later. 2519 o 13. Emphasise that negotiation/synchronization are independent 2520 from discovery, although the rapid discovery mode includes the 2521 first step of a negotiation/synchronization. (Sheng) 2523 RESOLVED by improved text. 2525 o 14. Do we need an unsolicited flooding mechanism for discovery 2526 (for discovery results that everyone needs), to reduce scaling 2527 impact of flooding discovery messages? (Toerless) 2529 RESOLVED: Yes, added to requirements and solution. 2531 o 15. Do we need flag bits in Objective Options to distinguish 2532 distinguish Synchronization and Negotiation "Request" or rapid 2533 mode "Discovery" messages? (Bing) 2535 RESOLVED: yes, work on the API showed that these flags are 2536 essential. 2538 o 16. (Related to issue 14). Should we revive the "unsolicited 2539 Response" for flooding synchronisation data? This has to be done 2540 carefully due to the well-known issues with flooding, but it could 2541 be useful, e.g. for Intent distribution, where DNCP doesn't seem 2542 applicable. 2544 RESOLVED: Yes, see #14. 2546 o 17. Ensure that the discovery mechanism is completely proof 2547 against loops and protected against duplicate responses. 2549 RESOLVED: Added loop count mechanism. 2551 o 18. Discuss the handling of multiple valid discovery responses. 2553 RESOLVED: Stated that the choice must be available to the ASA but 2554 GRASP implementation should pick a default. 2556 o 19. Should we use a text-oriented format such as JSON/CBOR 2557 instead of native binary TLV format? 2559 RESOLVED: Yes, changed to CBOR. 2561 o 20. Is the Divert option needed? If a discovery response 2562 provides a valid IP address or FQDN, the recipient doesn't gain 2563 any extra knowledge from the Divert. On the other hand, the 2564 presence of Divert informs the receiver that the target is off- 2565 link, which might be useful sometimes. 2567 RESOLVED: Decided to keep Divert option. 2569 o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling 2570 Protocol)? 2572 RESOLVED: Yes, name changed. 2574 o 22. Does discovery mechanism scale robustly as needed? Need hop 2575 limit on relaying? 2577 RESOLVED: Added hop limit. 2579 o 23. Need more details on TTL for caching discovery responses. 2581 RESOLVED: Done. 2583 o 24. Do we need "fast withdrawal" of discovery responses? 2585 RESOLVED: This doesn't seem necessary. If an ASA exits or stops 2586 supporting a given objective, peers will fail to start future 2587 sessions and will simply repeat discovery. 2589 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? 2591 RESOLVED: Decided not to consider this further as a GRASP protocol 2592 issue. GRASP objectives could embed DNS-SD formats if needed. 2594 o 26. Add a URL type to the locator options (for security bootstrap 2595 etc.) 2597 RESOLVED: Done, later renamed as URI. 2599 o 27. Security of Flood multicasts (Section 3.3.6.1). 2601 RESOLVED: added text. 2603 o 28. Does ACP support secure link-local multicast? 2605 RESOLVED by new text in the Security Considerations. 2607 o 29. PEN is used to distinguish vendor options. Would it be 2608 better to use a domain name? Anything unique will do. 2610 RESOLVED: Simplified this by removing PEN field and changing 2611 naming rules for objectives. 2613 o 30. Does response to discovery require randomized delays to 2614 mitigate amplification attacks? 2616 RESOLVED: WG feedback is that it's unnecessary. 2618 o 31. We have specified repeats for failed discovery etc. Is that 2619 sufficient to deal with sleeping nodes? 2621 RESOLVED: WG feedback is that it's unnecessary to say more. 2623 o 32. We have one-to-one synchronization and flooding 2624 synchronization. Do we also need selective flooding to a subset 2625 of nodes? 2627 RESOLVED: This will be discussed as a protocol extension in a 2628 separate draft (draft-liu-anima-grasp-distribution). 2630 o 33. Clarify if/when discovery needs to be repeated. 2632 RESOLVED: Done. 2634 o 34. Clarify what is mandatory for running in ACP, expand 2635 discussion of security boundary when running with no ACP - might 2636 rely on the local PKI infrastructure. 2638 RESOLVED: Done. 2640 o 35. State that role-based authorization of ASAs is out of scope 2641 for GRASP. GRASP doesn't recognize/handle any "roles". 2643 RESOLVED: Done. 2645 o 36. Reconsider CBOR definition for PEN syntax. ( objective-name 2646 = text / [pen, text] ; pen = uint ) 2648 RESOLVED: See issue 29. 2650 o 37. Are URI locators really needed? 2652 RESOLVED: Yes, e.g. for security bootstrap discovery, but added 2653 note that addresses are the normal case (same for FQDN locators). 2655 o 38. Is Session ID sufficient to identify relayed responses? 2656 Isn't the originator's address needed too? 2658 RESOLVED: Yes, this is needed for multicast messages and their 2659 responses. 2661 o 39. Clarify that a node will contain one GRASP instance 2662 supporting multiple ASAs. 2664 RESOLVED: Done. 2666 o 40. Add a "reason" code to the DECLINE option? 2668 RESOLVED: Done. 2670 o 41. What happens if an ASA cannot conveniently use one of the 2671 GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) 2672 simply pass the discovery results to the ASA so that it can open 2673 its own socket? 2675 RESOLVED: Both would be possible, but (b) is preferred. 2677 o 42. Do we need a feature whereby an ASA can bypass the ACP and 2678 use the data plane for efficiency/throughput? This would require 2679 discovery to return non-ACP addresses and would evade ACP 2680 security. 2682 RESOLVED: This is considered out of scope for GRASP, but a comment 2683 has been added in security considerations. 2685 o 43. Rapid mode synchronization and negotiation is currently 2686 limited to a single objective for simplicity of design and 2687 implementation. A future consideration is to allow multiple 2688 objectives in rapid mode for greater efficiency. 2690 RESOLVED: This is considered out of scope for this version. 2692 o 44. In requirement T9, the words that encryption "may not be 2693 required in all deployments" were removed. Is that OK?. 2695 RESOLVED: No objections. 2697 o 45. Device Identity Option is unused. Can we remove it 2698 completely?. 2700 RESOLVED: No objections. Done. 2702 o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD 2703 messages is intended to assist in loop prevention. However, we 2704 also have the loop count for that. Also, if we create a new 2705 Session ID each time a DISCOVER or FLOOD is relayed, that ID can 2706 be disambiguated by recipients. It would be simpler to remove the 2707 initiator from the messages, making parsing more uniform. Is that 2708 OK? 2710 RESOLVED: Yes. Done. 2712 o 47. REQUEST is a dual purpose message (request negotiation or 2713 request synchronization). Would it be better to split this into 2714 two different messages (and adjust various message names 2715 accordingly)? 2717 RESOLVED: Yes. Done. 2719 o 48. Should the Appendix "Capability Analysis of Current 2720 Protocols" be deleted before RFC publication? 2722 RESOLVED: No (per WG meeting at IETF 96). 2724 o 49. Section 3.3.1 Should say more about signaling between two 2725 autonomic networks/domains. 2727 RESOLVED: Description of separate GRASP instance added. 2729 o 50. Is Rapid mode limited to on-link only? What happens if first 2730 discovery responder does not support Rapid Mode? Section 3.3.5, 2731 Section 3.3.6) 2733 RESOLVED: Not limited to on-link. First responder wins. 2735 o 51. Should flooded objectives have a time-to-live before they are 2736 deleted from the flood cache? And should they be tagged in the 2737 cache with their source locator? 2739 RESOLVED: TTL added to Flood (and Discovery Response) messages. 2740 Cached flooded objectives must be tagged with their originating 2741 ASA locator, and multiple copies must be kept if necessary. 2743 o 52. Describe in detail what is allowed and disallowed in an 2744 insecure instance of GRASP. 2746 RESOLVED: Done. 2748 o 53. Tune IANA Considerations to support early assignment request. 2750 RESOLVED: Done. 2752 Appendix C. Change log [RFC Editor: Please remove] 2754 draft-ietf-anima-grasp-07, 2016-09-13: 2756 Protocol change: Added TTL field to Flood message (issue 51). 2758 Protocol change: Added Locator option to Flood message (issue 51). 2760 Protocol change: Added TTL field to Discovery Response message 2761 (corrollary to issue 51). 2763 Clarified details of rapid mode (issues 43 and 50). 2765 Description of inter-domain GRASP instance added (issue 49). 2767 Description of limited security GRASP instances added (issue 52). 2769 Strengthened advice to use TCP rather than UDP. 2771 Updated IANA considerations and text about well-known port usage 2772 (issue 53). 2774 Amended text about ASA authorization and roles to allow for 2775 overlapping ASAs. 2777 Added text recommending that Flood should be repeated periodically. 2779 Editorial fixes. 2781 draft-ietf-anima-grasp-06, 2016-06-27: 2783 Added text on discovery cache timeouts. 2785 Noted that ASAs that are only initiators do not need to respond to 2786 discovery message. 2788 Added text on unexpected address changes. 2790 Added text on robust implementation. 2792 Clarifications and editorial fixes for numerous review comments 2793 Added open issues for some review comments. 2795 draft-ietf-anima-grasp-05, 2016-05-13: 2797 Noted in requirement T1 that it should be possible to implement ASAs 2798 independently as user space programs. 2800 Protocol change: Added protocol number and port to discovery 2801 response. Updated protocol description, CDDL and IANA considerations 2802 accordingly. 2804 Clarified that discovery and flood multicasts are handled by the 2805 GRASP kernel, not directly by ASAs. 2807 Clarified that a node may discover an objective without supporting it 2808 for synchronization or negotiation. 2810 Added Implementation Status section. 2812 Added reference to SCSP. 2814 Editorial fixes. 2816 draft-ietf-anima-grasp-04, 2016-03-11: 2818 Protocol change: Restored initiator field in certain messages and 2819 adjusted relaying rules to provide complete loop detection. 2821 Updated IANA Considerations. 2823 draft-ietf-anima-grasp-03, 2016-02-24: 2825 Protocol change: Removed initiator field from certain messages and 2826 adjusted relaying requirement to simplify loop detection. Also 2827 clarified narrative explanation of discovery relaying. 2829 Protocol change: Split Request message into two (Request Negotiation 2830 and Request Synchronization) and updated other message names for 2831 clarity. 2833 Protocol change: Dropped unused Device ID option. 2835 Further clarified text on transport layer usage. 2837 New text about multicast insecurity in Security Considerations. 2839 Various other clarifications and editorial fixes, including moving 2840 some material to Appendix. 2842 draft-ietf-anima-grasp-02, 2016-01-13: 2844 Resolved numerous issues according to WG discussions. 2846 Renumbered requirements, added D9. 2848 Protocol change: only allow one objective in rapid mode. 2850 Protocol change: added optional error string to DECLINE option. 2852 Protocol change: removed statement that seemed to say that a Request 2853 not preceded by a Discovery should cause a Discovery response. That 2854 made no sense, because there is no way the initiator would know where 2855 to send the Request. 2857 Protocol change: Removed PEN option from vendor objectives, changed 2858 naming rule accordingly. 2860 Protocol change: Added FLOOD message to simplify coding. 2862 Protocol change: Added SYNCH message to simplify coding. 2864 Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD 2865 messages. But also allowed the relay process for DISCOVER and FLOOD 2866 to regenerate a Session ID. 2868 Protocol change: Require that discovered addresses must be global 2869 (except during bootstrap). 2871 Protocol change: Receiver of REQUEST message must close socket if no 2872 ASA is listening for the objective. 2874 Protocol change: Simplified Waiting message. 2876 Protocol change: Added No Operation message. 2878 Renamed URL locator type as URI locator type. 2880 Updated CDDL definition. 2882 Various other clarifications and editorial fixes. 2884 draft-ietf-anima-grasp-01, 2015-10-09: 2886 Updated requirements after list discussion. 2888 Changed from TLV to CBOR format - many detailed changes, added co- 2889 author. 2891 Tightened up loop count and timeouts for various cases. 2893 Noted that GRASP does not provide transactional integrity. 2895 Various other clarifications and editorial fixes. 2897 draft-ietf-anima-grasp-00, 2015-08-14: 2899 File name and protocol name changed following WG adoption. 2901 Added URL locator type. 2903 draft-carpenter-anima-gdn-protocol-04, 2015-06-21: 2905 Tuned wording around hierarchical structure. 2907 Changed "device" to "ASA" in many places. 2909 Reformulated requirements to be clear that the ASA is the main 2910 customer for signaling. 2912 Added requirement for flooding unsolicited synch, and added it to 2913 protocol spec. Recognized DNCP as alternative for flooding synch 2914 data. 2916 Requirements clarified, expanded and rearranged following design team 2917 discussion. 2919 Clarified that GDNP discovery must not be a prerequisite for GDNP 2920 negotiation or synchronization (resolved issue 13). 2922 Specified flag bits for objective options (resolved issue 15). 2924 Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 2925 9,10,11). 2927 Updated DNCP description from latest DNCP draft. 2929 Editorial improvements. 2931 draft-carpenter-anima-gdn-protocol-03, 2015-04-20: 2933 Removed intrinsic security, required external security 2935 Format changes to allow DNCP co-existence 2937 Recognized DNS-SD as alternative discovery method. 2939 Editorial improvements 2941 draft-carpenter-anima-gdn-protocol-02, 2015-02-19: 2943 Tuned requirements to clarify scope, 2945 Clarified relationship between types of objective, 2947 Clarified that objectives may be simple values or complex data 2948 structures, 2950 Improved description of objective options, 2952 Added loop-avoidance mechanisms (loop count and default timeout, 2953 limitations on discovery relaying and on unsolicited responses), 2955 Allow multiple discovery objectives in one response, 2957 Provided for missing or multiple discovery responses, 2959 Indicated how modes such as "dry run" should be supported, 2961 Minor editorial and technical corrections and clarifications, 2963 Reorganized future work list. 2965 draft-carpenter-anima-gdn-protocol-01, restructured the logical flow 2966 of the document, updated to describe synchronization completely, add 2967 unsolicited responses, numerous corrections and clarifications, 2968 expanded future work list, 2015-01-06. 2970 draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- 2971 config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 2972 02, 2014-10-08. 2974 Appendix D. Capability Analysis of Current Protocols 2976 This appendix discusses various existing protocols with properties 2977 related to the requirements described in Section 2. The purpose is 2978 to evaluate whether any existing protocol, or a simple combination of 2979 existing protocols, can meet those requirements. 2981 Numerous protocols include some form of discovery, but these all 2982 appear to be very specific in their applicability. Service Location 2983 Protocol (SLP) [RFC2608] provides service discovery for managed 2984 networks, but requires configuration of its own servers. DNS-SD 2985 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 2986 small networks with a single link layer. [RFC7558] aims to extend 2987 this to larger autonomous networks but this is not yet standardized. 2988 However, both SLP and DNS-SD appear to target primarily application 2989 layer services, not the layer 2 and 3 objectives relevant to basic 2990 network configuration. Both SLP and DNS-SD are text-based protocols. 2992 Routing protocols are mainly one-way information announcements. The 2993 receiver makes independent decisions based on the received 2994 information and there is no direct feedback information to the 2995 announcing peer. This remains true even though the protocol is used 2996 in both directions between peer routers; there is state 2997 synchronization, but no negotiation, and each peer runs its route 2998 calculations independently. 3000 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 3001 response model not well suited for peer negotiation. Network 3002 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 3003 does allow positive or negative responses from the target system, but 3004 this is still not adequate for negotiation. 3006 There are various existing protocols that have elementary negotiation 3007 abilities, such as Dynamic Host Configuration Protocol for IPv6 3008 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 3009 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 3010 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 3011 configuration or management protocols. However, they either provide 3012 only a simple request/response model in a master/slave context or 3013 very limited negotiation abilities. 3015 There are some signaling protocols with an element of negotiation. 3016 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 3017 designed for negotiating quality of service parameters along the path 3018 of a unicast or multicast flow. RSVP is a very specialised protocol 3019 aimed at end-to-end flows. However, it has some flexibility, having 3020 been extended for MPLS label distribution [RFC3209]. A more generic 3021 design is General Internet Signalling Transport (GIST) [RFC5971], but 3022 it is complex, tries to solve many problems, and is also aimed at 3023 per-flow signaling across many hops rather than at device-to-device 3024 signaling. However, we cannot completely exclude extended RSVP or 3025 GIST as a synchronization and negotiation protocol. They do not 3026 appear to be directly useable for peer discovery. 3028 We now consider two protocols that are works in progress at the time 3029 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 3030 protocol intended to convey NETCONF information expressed in the YANG 3031 language via HTTP, including the ability to transit HTML 3032 intermediaries. While this is a powerful approach in the context of 3033 centralised configuration of a complex network, it is not well 3034 adapted to efficient interactive negotiation between peer devices, 3035 especially simple ones that might not include YANG processing 3036 already. 3038 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 3039 [RFC7787]. This is defined as a generic form of state 3040 synchronization protocol, with a proposed usage profile being the 3041 Home Networking Control Protocol (HNCP) [RFC7788] for configuring 3042 Homenet routers. A specific application of DNCP for autonomic 3043 networking was proposed in [I-D.stenberg-anima-adncp]. 3045 DNCP "is designed to provide a way for each participating node to 3046 publish a set of TLV (Type-Length-Value) tuples, and to provide a 3047 shared and common view about the data published... DNCP is most 3048 suitable for data that changes only infrequently... If constant rapid 3049 state changes are needed, the preferable choice is to use an 3050 additional point-to-point channel..." 3052 Specific features of DNCP include: 3054 o Every participating node has a unique node identifier. 3056 o DNCP messages are encoded as a sequence of TLV objects, sent over 3057 unicast UDP or TCP, with or without (D)TLS security. 3059 o Multicast is used only for discovery of DNCP neighbors when lower 3060 security is acceptable. 3062 o Synchronization of state is maintained by a flooding process using 3063 the Trickle algorithm. There is no bilateral synchronization or 3064 negotiation capability. 3066 o The HNCP profile of DNCP is designed to operate between directly 3067 connected neighbors on a shared link using UDP and link-local IPv6 3068 addresses. 3070 DNCP does not meet the needs of a general negotiation protocol, 3071 because it is designed specifically for flooding synchronization. 3072 Also, in its HNCP profile it is limited to link-local messages and to 3073 IPv6. However, at the minimum it is a very interesting test case for 3074 this style of interaction between devices without needing a central 3075 authority, and it is a proven method of network-wide state 3076 synchronization by flooding. 3078 The Server Cache Synchronization Protocol (SCSP) [RFC2334] also 3079 describes a method for cache synchronization and cache replication 3080 among a group of nodes. 3082 A proposal was made some years ago for an IP based Generic Control 3083 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 3084 information exchange and negotiation but not directly at peer 3085 discovery. However, it has many points in common with the present 3086 work. 3088 None of the above solutions appears to completely meet the needs of 3089 generic discovery, state synchronization and negotiation in a single 3090 solution. Many of the protocols assume that they are working in a 3091 traditional top-down or north-south scenario, rather than a fluid 3092 peer-to-peer scenario. Most of them are specialized in one way or 3093 another. As a result, we have not identified a combination of 3094 existing protocols that meets the requirements in Section 2. Also, 3095 we have not identified a path by which one of the existing protocols 3096 could be extended to meet the requirements. 3098 Authors' Addresses 3100 Carsten Bormann 3101 Universitaet Bremen TZI 3102 Postfach 330440 3103 D-28359 Bremen 3104 Germany 3106 Email: cabo@tzi.org 3108 Brian Carpenter (editor) 3109 Department of Computer Science 3110 University of Auckland 3111 PB 92019 3112 Auckland 1142 3113 New Zealand 3115 Email: brian.e.carpenter@gmail.com 3117 Bing Liu (editor) 3118 Huawei Technologies Co., Ltd 3119 Q14, Huawei Campus 3120 No.156 Beiqing Road 3121 Hai-Dian District, Beijing 100095 3122 P.R. China 3124 Email: leo.liubing@huawei.com