idnits 2.17.1 draft-ietf-anima-grasp-02.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 (January 13, 2016) is 2997 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-07 ** Downref: Normative reference to an Informational draft: draft-greevenbosch-appsawg-cbor-cddl (ref. 'I-D.greevenbosch-appsawg-cbor-cddl') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-01 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-09 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track B. Carpenter, Ed. 5 Expires: July 16, 2016 Univ. of Auckland 6 B. Liu, Ed. 7 Huawei Technologies Co., Ltd 8 January 13, 2016 10 A Generic Autonomic Signaling Protocol (GRASP) 11 draft-ietf-anima-grasp-02 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 July 16, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirement Analysis of Discovery, Synchronization and 60 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Requirements for Discovery . . . . . . . . . . . . . . . 4 62 2.2. Requirements for Synchronization and Negotiation 63 Capability . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Specific Technical Requirements . . . . . . . . . . . . . 8 65 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10 66 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 11 68 3.3. GRASP Protocol Basic Properties and Mechanisms . . . . . 15 69 3.3.1. Required External Security Mechanism . . . . . . . . 15 70 3.3.2. Transport Layer Usage . . . . . . . . . . . . . . . . 16 71 3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16 72 3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 18 73 3.3.5. Synchronization and Flooding Procedure . . . . . . . 20 74 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 21 75 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 21 76 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 22 77 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 22 78 3.7.1. GRASP Message Format . . . . . . . . . . . . . . . . 23 79 3.7.2. Discovery Message . . . . . . . . . . . . . . . . . . 23 80 3.7.3. Response Message . . . . . . . . . . . . . . . . . . 24 81 3.7.4. Request Message . . . . . . . . . . . . . . . . . . . 25 82 3.7.5. Negotiation Message . . . . . . . . . . . . . . . . . 25 83 3.7.6. Negotiation-ending Message . . . . . . . . . . . . . 26 84 3.7.7. Confirm-waiting Message . . . . . . . . . . . . . . . 26 85 3.7.8. Synchronization Message . . . . . . . . . . . . . . . 26 86 3.7.9. Flood Message . . . . . . . . . . . . . . . . . . . . 27 87 3.7.10. No Operation Message . . . . . . . . . . . . . . . . 27 88 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 27 89 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 27 90 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 28 91 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 28 92 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 28 93 3.8.5. Device Identity Option . . . . . . . . . . . . . . . 29 94 3.8.6. Locator Options . . . . . . . . . . . . . . . . . . . 29 95 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 30 96 3.9.1. Format of Objective Options . . . . . . . . . . . . . 30 97 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 32 98 3.9.3. General Considerations for Objective Options . . . . 32 99 3.9.4. Organizing of Objective Options . . . . . . . . . . . 33 100 3.9.5. Experimental and Example Objective Options . . . . . 34 101 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 34 102 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 103 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 42 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 105 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 106 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 46 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 48 109 10.2. Informative References . . . . . . . . . . . . . . . . . 49 110 Appendix A. Capability Analysis of Current Protocols . . . . . . 53 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 113 1. Introduction 115 The success of the Internet has made IP-based networks bigger and 116 more complicated. Large-scale ISP and enterprise networks have 117 become more and more problematic for human based management. Also, 118 operational costs are growing quickly. Consequently, there are 119 increased requirements for autonomic behavior in the networks. 120 General aspects of autonomic networks are discussed in [RFC7575] and 121 [RFC7576]. 123 One approach is to largely decentralize the logic of network 124 management by migrating it into network elements. A reference model 125 for autonomic networking on this basis is given in 126 [I-D.behringer-anima-reference-model]. In order to fulfil autonomy, 127 devices that embody autonomic service agents have specific signaling 128 requirements. In particular they need to discover each other, to 129 synchronize state with each other, and to negotiate parameters and 130 resources directly with each other. There is no restriction on the 131 type of parameters and resources concerned, which include very basic 132 information needed for addressing and routing, as well as anything 133 else that might be configured in a conventional non-autonomic 134 network. The atomic unit of synchronization or negotiation is 135 referred to as a technical objective, i.e, a configurable parameter 136 or set of parameters (defined more precisely in Section 3.1). 138 Following this Introduction, Section 2 describes the requirements for 139 discovery, synchronization and negotiation. Negotiation is an 140 iterative process, requiring multiple message exchanges forming a 141 closed loop between the negotiating devices. State synchronization, 142 when needed, can be regarded as a special case of negotiation, 143 without iteration. Section 3.2 describes a behavior model for a 144 protocol intended to support discovery, synchronization and 145 negotiation. The design of GeneRic Autonomic Signaling Protocol 146 (GRASP) in Section 3 of this document is mainly based on this 147 behavior model. The relevant capabilities of various existing 148 protocols are reviewed in Appendix A. 150 The proposed discovery mechanism is oriented towards synchronization 151 and negotiation objectives. It is based on a neighbor discovery 152 process, but also supports diversion to off-link peers. Although 153 many negotiations will occur between horizontally distributed peers, 154 many target scenarios are hierarchical networks, which is the 155 predominant structure of current large-scale managed networks. 156 However, when a device starts up with no pre-configuration, it has no 157 knowledge of the topology. The protocol itself is capable of being 158 used in a small and/or flat network structure such as a small office 159 or home network as well as a professionally managed network. 160 Therefore, the discovery mechanism needs to be able to allow a device 161 to bootstrap itself without making any prior assumptions about 162 network structure. 164 Because GRASP can be used to perform a decision process among 165 distributed devices or between networks, it must run in a secure and 166 strongly authenticated environment. 168 It is understood that in realistic deployments, not all devices will 169 support GRASP. It is expected that some autonomic service agents 170 will directly manage a group of non-autonomic nodes, and that other 171 non-autonomic nodes will be managed traditionally. Such mixed 172 scenarios are not discussed in this specification. 174 2. Requirement Analysis of Discovery, Synchronization and Negotiation 176 This section discusses the requirements for discovery, negotiation 177 and synchronization capabilities. The primary user of the protocol 178 is an autonomic service agent (ASA), so the requirements are mainly 179 expressed as the features needed by an ASA. A single physical device 180 might contain several ASAs, and a single ASA might manage several 181 technical objectives. 183 Note that requirements for ASAs themselves, such as the processing of 184 Intent [RFC7575] or interfaces for coordination between ASAs are out 185 of scope for the present document. 187 2.1. Requirements for Discovery 189 D1. ASAs may be designed to manage anything, as required in 190 Section 2.2. A basic requirement is therefore that the protocol can 191 represent and discover any kind of technical objective among 192 arbitrary subsets of participating nodes. 194 In an autonomic network we must assume that when a device starts up 195 it has no information about any peer devices, the network structure, 196 or what specific role it must play. The ASA(s) inside the device are 197 in the same situation. In some cases, when a new application session 198 starts up within a device, the device or ASA may again lack 199 information about relevant peers. It might be necessary to set up 200 resources on multiple other devices, coordinated and matched to each 201 other so that there is no wasted resource. Security settings might 202 also need updating to allow for the new device or user. The relevant 203 peers may be different for different technical objectives. Therefore 204 discovery needs to be repeated as often as necessary to find peers 205 capable of acting as counterparts for each objective that a discovery 206 initiator needs to handle. From this background we derive the next 207 three requirements: 209 D2. When an ASA first starts up, it has no knowledge of the specific 210 network to which it is attached. Therefore the discovery process 211 must be able to support any network scenario, assuming only that the 212 device concerned is bootstrapped from factory condition. 214 D3. When an ASA starts up, it must require no information about any 215 peers in order to discover them. 217 D4. If an ASA supports multiple technical objectives, relevant peers 218 may be different for different discovery objectives, so discovery 219 needs to be repeated to find counterparts for each objective. Thus, 220 there must be a mechanism by which an ASA can separately discover 221 peer ASAs for each of the technical objectives that it needs to 222 manage, whenever necessary. 224 D5. Following discovery, an ASA will normally perform negotiation or 225 synchronization for the corresponding objectives. The design should 226 allow for this by associating discovery, negotiation and 227 synchronization objectives. It may provide an optional mechanism to 228 combine discovery and negotiation/synchronization in a single call. 230 D6. Some objectives may only be significant on the local link, but 231 others may be significant across the routed network and require off- 232 link operations. Thus, the relevant peers might be immediate 233 neighbors on the same layer 2 link, or they might be more distant and 234 only accessible via layer 3. The mechanism must therefore provide 235 both on-link and off-link discovery of ASAs supporting specific 236 technical objectives. 238 D7. The discovery process should be flexible enough to allow for 239 special cases, such as the following: 241 o In some networks, as mentioned above, there will be some 242 hierarchical structure, at least for certain synchronization or 243 negotiation objectives, but this is unknown in advance. The 244 discovery protocol must therefore operate regardless of 245 hierarchical structure, which is an attribute of individual 246 technical objectives and not of the autonomic network as a whole. 247 This is part of the more general requirement to discover off-link 248 peers. 250 o During initialisation, a device must be able to establish mutual 251 trust with the rest of the network and join an authentication 252 mechanism. Although this will inevitably start with a discovery 253 action, it is a special case precisely because trust is not yet 254 established. This topic is the subject of 255 [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once 256 trust has been established for a device, all ASAs within the 257 device inherit the device's credentials and are also trusted. 259 o Depending on the type of network involved, discovery of other 260 central functions might be needed, such as the Network Operations 261 Center (NOC) [I-D.eckert-anima-stable-connectivity]. The protocol 262 must be capable of supporting such discovery during 263 initialisation, as well as discovery during ongoing operation. 265 D8. The discovery process must not generate excessive traffic and 266 must take account of sleeping nodes in the case of a constrained-node 267 network [RFC7228]. 269 D9. There must be a mechanism for handling stale discovery results. 271 2.2. Requirements for Synchronization and Negotiation Capability 273 As background, consider the example of routing protocols, the closest 274 approximation to autonomic networking already in widespread use. 275 Routing protocols use a largely autonomic model based on distributed 276 devices that communicate repeatedly with each other. The focus is 277 reachability, so current routing protocols mainly consider simple 278 link status, i.e., up or down, and an underlying assumption is that 279 all nodes need a consistent view of the network topology in order for 280 the routing algorithm to converge. Thus, routing is mainly based on 281 information synchronization between peers, rather than on bi- 282 directional negotiation. Other information, such as latency, 283 congestion, capacity, and particularly unused capacity, would be 284 helpful to get better path selection and utilization rate, but is not 285 normally used in distributed routing algorithms. Additionally, 286 autonomic networks need to be able to manage many more dimensions, 287 such as security settings, power saving, load balancing, etc. Status 288 information and traffic metrics need to be shared between nodes for 289 dynamic adjustment of resources and for monitoring purposes. While 290 this might be achieved by existing protocols when they are available, 291 the new protocol needs to be able to support parameter exchange, 292 including mutual synchronization, even when no negotiation as such is 293 required. In general, these parameters do not apply to all 294 participating nodes, but only to a subset. 296 SN1. A basic requirement for the protocol is therefore the ability 297 to represent, discover, synchronize and negotiate almost any kind of 298 network parameter among arbitrary subsets of participating nodes. 300 SN2. Negotiation is a request/response process that must be 301 guaranteed to terminate (with success or failure) and if necessary it 302 must contain tie-breaking rules for each technical objective that 303 requires them. While these must be defined specifically for each use 304 case, the protocol should have some general mechanisms in support of 305 loop and deadlock prevention, such as hop count limits or timeouts. 307 SN3. Synchronization might concern small groups of nodes or very 308 large groups. Different solutions might be needed at different 309 scales. 311 SN4. To avoid "reinventing the wheel", the protocol should be able 312 to carry the message formats used by existing configuration protocols 313 (such as NETCONF/YANG) in cases where that is convenient. 315 SN5. Human intervention in complex situations is costly and error- 316 prone. Therefore, synchronization or negotiation of parameters 317 without human intervention is desirable whenever the coordination of 318 multiple devices can improve overall network performance. It 319 therefore follows that the protocol, as part of the Autonomic 320 Networking Infrastructure, must be capable of running in any device 321 that would otherwise need human intervention. 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, must 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 signaling between 346 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. In other words there must be a possibility of 357 forecasting the effect of a change by a "dry run" mechanism before 358 actually installing the change. This will be an application of 359 the protocol rather than a feature of the protocol itself. 361 o Management logging, monitoring, alerts and tools for intervention 362 are required. However, these can only be features of individual 363 ASAs. Another document [I-D.eckert-anima-stable-connectivity] 364 discusses how such agents may be linked into conventional OAM 365 systems via an Autonomic Control Plane 366 [I-D.ietf-anima-autonomic-control-plane]. 368 SN8. The protocol will be able to deal with a wide variety of 369 technical objectives, covering any type of network parameter. 370 Therefore the protocol will need either an explicit information model 371 describing its messages, or at least a flexible and easily extensible 372 message format. One design consideration is whether to adopt an 373 existing information model or to design a new one. 375 2.3. Specific Technical Requirements 377 T1. It should be convenient for ASA designers to define new 378 technical objectives and for programmers to express them, without 379 excessive impact on run-time efficiency and footprint. The classes 380 of device in which the protocol might run is discussed in 381 [I-D.behringer-anima-reference-model]. 383 T2. The protocol should be easily extensible in case the initially 384 defined discovery, synchronization and negotiation mechanisms prove 385 to be insufficient. 387 T3. To be a generic platform, the protocol payload format should be 388 independent of the transport protocol or IP version. In particular, 389 it should be able to run over IPv6 or IPv4. However, some functions, 390 such as multicasting on a link, might need to be IP version 391 dependent. In case of doubt, IPv6 should be preferred. 393 T4. The protocol must be able to access off-link counterparts via 394 routable addresses, i.e., must not be restricted to link-local 395 operation. 397 T5. It must also be possible for an external discovery mechanism to 398 be used, if appropriate for a given technical objective. In other 399 words, GRASP discovery must not be a prerequisite for GRASP 400 negotiation or synchronization; the prerequisite is discovering a 401 peer's locator by any method. 403 T6. ASAs and the signaling protocol need to run asynchronously when 404 wait states occur. 406 T7. Intent: There must be provision for general Intent rules to be 407 applied by all devices in the network (e.g., security rules, prefix 408 length, resource sharing rules). However, Intent distribution might 409 not use the signaling protocol itself, but its design should not 410 exclude such use. 412 T8. Management monitoring, alerts and intervention: Devices should 413 be able to report to a monitoring system. Some events must be able 414 to generate operator alerts and some provision for emergency 415 intervention must be possible (e.g. to freeze synchronization or 416 negotiation in a mis-behaving device). These features might not use 417 the signaling protocol itself, but its design should not exclude such 418 use. 420 T9. The protocol needs to be fully secured against forged messages 421 and man-in-the middle attacks, and secured as much as reasonably 422 possible against denial of service attacks. It needs to be capable 423 of encryption in order to resist unwanted monitoring. However, it is 424 not required that the protocol itself provides these security 425 features; it may depend on an existing secure environment. 427 3. GRASP Protocol Overview 429 3.1. Terminology 431 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 432 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 433 "OPTIONAL" in this document are to be interpreted as described in 434 [RFC2119] when they appear in ALL CAPS. When these words are not in 435 ALL CAPS (such as "should" or "Should"), they have their usual 436 English meanings, and are not to be interpreted as [RFC2119] key 437 words. 439 This document uses terminology defined in [RFC7575]. 441 The following additional terms are used throughout this document: 443 o Autonomic Device: identical to Autonomic Node. 445 o Discovery: a process by which an ASA discovers peers according to 446 a specific discovery objective. The discovery results may be 447 different according to the different discovery objectives. The 448 discovered peers may later be used as negotiation counterparts or 449 as sources of synchronization data. 451 o Negotiation: a process by which two (or more) ASAs interact 452 iteratively to agree on parameter settings that best satisfy the 453 objectives of one or more ASAs. 455 o State Synchronization: a process by which two (or more) ASAs 456 interact to agree on the current state of parameter values stored 457 in each ASA. This is a special case of negotiation in which 458 information is sent but the ASAs do not request their peers to 459 change parameter settings. All other definitions apply to both 460 negotiation and synchronization. 462 o Technical Objective (usually abbreviated as Objective): A 463 technical objective is a configurable parameter or set of 464 parameters of some kind, which occurs in three contexts: 465 Discovery, Negotiation and Synchronization. In the protocol, an 466 objective is represented by an identifier and if relevant a value. 467 Normally, a given objective will occur during discovery and 468 negotiation, or during discovery and synchronization, but not in 469 all three contexts. 471 * One ASA may support multiple independent objectives. 473 * The parameter described by a given objective is naturally based 474 on a specific service or function or action. It may in 475 principle be anything that can be set to a specific logical, 476 numerical or string value, or a more complex data structure, by 477 a network node. That node is generally expected to contain an 478 ASA which may itself manage other nodes. 480 * Discovery Objective: if a node needs to synchronize or 481 negotiate a specific objective but does not know a peer that 482 supports this objective, it starts a discovery process. The 483 objective is called a Discovery Objective during this process. 485 * Synchronization Objective: an objective whose specific 486 technical content needs to be synchronized among two or more 487 ASAs. 489 * Negotiation Objective: an objective whose specific technical 490 content needs to be decided in coordination with another ASA. 492 o Discovery Initiator: an ASA that spontaneously starts discovery by 493 sending a discovery message referring to a specific discovery 494 objective. 496 o Discovery Responder: a peer ASA which responds to the discovery 497 objective initiated by the discovery initiator. 499 o Synchronization Initiator: an ASA that spontaneously starts 500 synchronization by sending a request message referring to a 501 specific synchronization objective. 503 o Synchronization Responder: a peer ASA which responds with the 504 value of a synchronization objective. 506 o Negotiation Initiator: an ASA that spontaneously starts 507 negotiation by sending a request message referring to a specific 508 negotiation objective. 510 o Negotiation Counterpart: a peer with which the Negotiation 511 Initiator negotiates a specific negotiation objective. 513 3.2. High-Level Design Choices 515 This section describes a behavior model and some considerations for 516 designing a generic signaling protocol initially supporting 517 discovery, synchronization and negotiation, which can act as a 518 platform for different technical objectives. 520 o A generic platform 521 The protocol is designed as a generic platform, which is 522 independent from the synchronization or negotiation contents. It 523 takes care of the general intercommunication between counterparts. 524 The technical contents will vary according to the various 525 technical objectives and the different pairs of counterparts. 527 o The protocol is expected to form part of an Autonomic Networking 528 Infrastructure [I-D.behringer-anima-reference-model]. It will 529 provide services to ASAs via a suitable application programming 530 interface, which will reflect the protocol elements but will not 531 necessarily be in one-to-one correspondence to them. It is 532 expected that a single instance of GRASP will exist in an 533 autonomic node, and that the protocol engine and each ASA will run 534 as independent asynchronous processes. 536 o Security infrastructure and trust relationship 538 Because this negotiation protocol may directly cause changes to 539 device configurations and bring significant impacts to a running 540 network, this protocol is assumed to run within an existing secure 541 environment with strong authentication. 543 On the other hand, a limited negotiation model might be deployed 544 based on a limited trust relationship. For example, between two 545 administrative domains, ASAs might also exchange limited 546 information and negotiate some particular configurations based on 547 a limited conventional or contractual trust relationship. 549 o Discovery, synchronization and negotiation are designed together. 551 The discovery method and the synchronization and negotiation 552 methods are designed in the same way and can be combined when this 553 is useful. These processes can also be performed independently 554 when appropriate. 556 * GRASP discovery is always available for efficient discovery of 557 GRASP peers and allows a rapid mode of operation described in 558 Section 3.3.3. For some objectives, especially those concerned 559 with application layer services, another discovery mechanism 560 such as the future DNS Service Discovery [RFC7558] or Service 561 Location Protocol [RFC2608] MAY be used. The choice is left to 562 the designers of individual ASAs. 564 o A uniform pattern for technical contents 565 The synchronization and negotiation contents are defined according 566 to a uniform pattern. They could be carried either in simple 567 binary format or in payloads described by a flexible language. 568 The basic protocol design uses the Concise Binary Object 569 Representation (CBOR) [RFC7049]. The format is extensible for 570 unknown future requirements. 572 o A flexible model for synchronization 574 GRASP supports bilateral synchronization, which could be used to 575 perform synchronization among a small number of nodes. It also 576 supports an unsolicited flooding mode when large groups of nodes, 577 possibly including all autonomic nodes, need data for the same 578 technical objective. 580 * There may be some network parameters for which a more 581 traditional flooding mechanism such as DNCP 582 [I-D.ietf-homenet-dncp] is considered more appropriate. GRASP 583 can coexist with DNCP. 585 o A simple initiator/responder model for negotiation 587 Multi-party negotiations are too complicated to be modeled and 588 there might be too many dependencies among the parties to converge 589 efficiently. A simple initiator/responder model is more feasible 590 and can complete multi-party negotiations by indirect steps. 592 o Organizing of synchronization or negotiation content 594 Naturally, the technical content will be organized according to 595 the relevant function or service. The content from different 596 functions or services is kept independent from each other. They 597 are not combined into a single option or single session because 598 these contents may be negotiated or synchronized with different 599 counterparts or may be different in response time. 601 o Self-aware network device 603 Every autonomic device will be pre-loaded with various functions 604 and ASAs and will be aware of its own capabilities, typically 605 decided by the hardware, firmware or pre-installed software. Its 606 exact role may depend on Intent and on the surrounding network 607 behaviors, which may include forwarding behaviors, aggregation 608 properties, topology location, bandwidth, tunnel or translation 609 properties, etc. The surrounding topology will depend on the 610 network planning. Following an initial discovery phase, the 611 device properties and those of its neighbors are the foundation of 612 the synchronization or negotiation behavior of a specific device. 613 A device has no pre-configuration for the particular network in 614 which it is installed. 616 o Requests and responses in negotiation procedures 618 The initiator can negotiate with its relevant negotiation 619 counterpart ASAs, which may be different according to the specific 620 negotiation objective. It can request relevant information from 621 the negotiation counterpart so that it can decide its local 622 configuration to give the most coordinated performance. It can 623 request the negotiation counterpart to make a matching 624 configuration in order to set up a successful communication with 625 it. It can request certain simulation or forecast results by 626 sending some dry run conditions. 628 Beyond the traditional yes/no answer, the responder can reply with 629 a suggested alternative if its answer is 'no'. This would start a 630 bi-directional negotiation ending in a compromise between the two 631 ASAs. 633 o Convergence of negotiation procedures 635 To enable convergence, when a responder makes a suggestion of a 636 changed condition in a negative reply, it should be as close as 637 possible to the original request or previous suggestion. The 638 suggested value of the third or later negotiation steps should be 639 chosen between the suggested values from the last two negotiation 640 steps. In any case there must be a mechanism to guarantee 641 convergence (or failure) in a small number of steps, such as a 642 timeout or maximum number of iterations. 644 * End of negotiation 646 A limited number of rounds, for example three, or a timeout, is 647 needed on each ASA for each negotiation objective. It may be 648 an implementation choice, a pre-configurable parameter, or 649 network Intent. These choices might vary between different 650 types of ASA. Therefore, the definition of each negotiation 651 objective MUST clearly specify this, so that the negotiation 652 can always be terminated properly. 654 * Failed negotiation 656 There must be a well-defined procedure for concluding that a 657 negotiation cannot succeed, and if so deciding what happens 658 next (deadlock resolution, tie-breaking, or revert to best- 659 effort service). Again, this MUST be specified for individual 660 negotiation objectives, as an implementation choice, a pre- 661 configurable parameter, or network Intent. 663 3.3. GRASP Protocol Basic Properties and Mechanisms 665 3.3.1. Required External Security Mechanism 667 The protocol SHOULD run within a secure Autonomic Control Plane (ACP) 668 [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to 669 carry all messages securely, including link-local multicast if 670 possible. A GRASP implementation MUST verify whether the ACP is 671 operational. 673 If there is no ACP, the protocol MUST use another form of strong 674 authentication and SHOULD use a form of strong encryption. TLS 675 [RFC5246] is RECOMMENDED for this purpose, based on a local Public 676 Key Infrastructure (PKI) [RFC5280] managed within the autonomic 677 network itself. The details of such a PKI and how its boundary is 678 established are out of scope for this document. DTLS [RFC6347] MAY 679 be used but since GRASP operations usually involve several messages 680 this is not expected to be advantageous. 682 The ACP, or in its absence the local PKI, sets the boundary within 683 which nodes are trusted as GRASP peers. A GRASP implementation MUST 684 refuse to execute any GRASP functions except discovery if there is 685 neither an operational ACP nor an operational (D)TLS environment. 687 As mentioned in Section 3.2, limited GRASP operations might be 688 performed across an administrative domain boundary by mutual 689 agreement. Such operations MUST be authenticated and SHOULD be 690 encrypted. TLS is RECOMMENDED for this purpose. 692 Link-local multicast is used for discovery messages. Responses to 693 discovery messages MUST be secured, with one exception. 695 The exception is that during initialisation, before a node has joined 696 the applicable trust infrastructure, e.g., 697 [I-D.ietf-anima-bootstrapping-keyinfra], or before the ACP is fully 698 established, it might be impossible to secure messages. Indeed, both 699 the security bootstrap process and the ACP creation process might use 700 insecure GRASP discovery and response messages. Such usage MUST be 701 limited to the strictly necessary minimum. A full analysis of the 702 initialisation process is out of scope for the present document. 704 3.3.2. Transport Layer Usage 706 The protocol is capable of running over UDP or TCP, except for link- 707 local multicast discovery messages, which can only run over UDP and 708 MUST NOT be fragmented, and therefore cannot exceed the link MTU 709 size. 711 When running within a secure ACP, UDP SHOULD be used for messages not 712 exceeding the minimum IPv6 path MTU, and TCP MUST be used for longer 713 messages. In other words, IPv6 fragmentation is avoided. If a node 714 receives a UDP message but the reply is too long, it MUST open a TCP 715 connection to the peer for the reply. 717 When running without an ACP, TLS SHOULD be supported and used by 718 default, except for multicast discovery messages. DTLS MAY be 719 supported as an alternative but the details are out of scope for this 720 document. 722 For all transport protocols, the GRASP protocol listens to the GRASP 723 Listen Port (Section 3.5). 725 3.3.3. Discovery Mechanism and Procedures 727 o Separated discovery and negotiation mechanisms 729 Although discovery and negotiation or synchronization are 730 defined together in the GRASP, they are separated mechanisms. 731 The discovery process could run independently from the 732 negotiation or synchronization process. Upon receiving a 733 discovery (Section 3.7.2) message, the recipient ASA should 734 return a message in which it either indicates itself as a 735 discovery responder or diverts the initiator towards another 736 more suitable ASA. 738 The discovery action will normally be followed by a negotiation 739 or synchronization action. The discovery results could be 740 utilized by the negotiation protocol to decide which ASA the 741 initiator will negotiate with. 743 It is entirely possible to use GRASP discovery without a 744 subsequent negotiation or synchronization action. In this 745 case, the discovered objective is simply used as a name during 746 the discovery process and any subsequent operations between the 747 peers are outside the scope of GRASP. 749 o Discovery Procedures 751 Discovery starts as an on-link operation. The Divert option 752 can tell the discovery initiator to contact an off-link ASA for 753 that discovery objective. Every Discovery message is sent by a 754 discovery initiator via UDP to the ALL_GRASP_NEIGHBOR multicast 755 address (Section 3.5). Every network device that supports the 756 GRASP always listens to a well-known UDP port to capture the 757 discovery messages. 759 If an ASA in the neighbor device supports the requested 760 discovery objective, it MAY respond with a Response message 761 (Section 3.7.3) with locator option(s). Otherwise, if the 762 neighbor has cached information about an ASA that supports the 763 requested discovery objective (usually because it discovered 764 the same objective before), it SHOULD respond with a Response 765 message with a Divert option pointing to the appropriate 766 Discovery Responder. 768 If no discovery response is received within a reasonable 769 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), 770 the Discovery message MAY be repeated, with a newly generated 771 Session ID (Section 3.6). An exponential backoff SHOULD be 772 used for subsequent repetitions, in order to mitigate possible 773 denial of service attacks. 775 After a GRASP device successfully discovers a Discovery 776 Responder supporting a specific objective, it MUST cache this 777 information. This cache record MAY be used for future 778 negotiation or synchronization, and SHOULD be passed on when 779 appropriate as a Divert option to another Discovery Initiator. 780 The cache lifetime is an implementation choice that MAY be 781 modified by network Intent. 783 If multiple Discovery Responders are found for the same 784 objective, they SHOULD all be cached, unless this creates a 785 resource shortage. The method of choosing between multiple 786 responders is an implementation choice. This choice MUST be 787 available to each ASA but the GRASP implementation SHOULD 788 provide a default choice. 790 Because Discovery Responders will be cached in a finite cache, 791 they might be deleted at any time. In this case, discovery 792 will need to be repeated. If an ASA exits for any reason, its 793 locator might still be cached for some time, and attempts to 794 connect to it will fail. ASAs need to be robust in these 795 circumstances. 797 A GRASP device with multiple link-layer interfaces (typically a 798 router) MUST support discovery on all interfaces. If it 799 receives a Discovery message on a given interface for a 800 specific objective that it does not support and for which it 801 has not previously discovered a Discovery Responder, it MUST 802 relay the query by re-issuing a Discovery message on its other 803 interfaces. The relayed message MAY have a different Session 804 ID. Before this, it MUST decrement the loop count within the 805 objective, and MUST NOT relay the Discovery message if the 806 result is zero. Also, it MUST limit the total rate at which it 807 relays discovery messages to a reasonable value, in order to 808 mitigate possible denial of service attacks. It MUST cache the 809 Session ID value of each relayed discovery message and, to 810 prevent loops, MUST NOT relay a Discovery message which carries 811 such a cached Session ID. These precautions avoid discovery 812 loops and mitigate potential overload. 814 This relayed discovery mechanism, with caching of the results, 815 should be sufficient to support most network bootstrapping 816 scenarios. 818 o A complete discovery process will start with multicast on the 819 local link; a neighbor might divert it to an off-link destination, 820 which could be a default higher-level gateway in a hierarchical 821 network. Then discovery would continue with a unicast to that 822 gateway; if that gateway is still not the right counterpart, it 823 should divert to another gateway, which is in principle closer to 824 the right counterpart. Finally the right counterpart responds to 825 start the negotiation or synchronization process. 827 o Rapid Mode (Discovery/Negotiation binding) 829 A Discovery message MAY include a Negotiation Objective option. 830 This allows a rapid mode of negotiation described in 831 Section 3.3.4. A similar mechanism is defined for 832 synchronization in Section 3.3.5. 834 3.3.4. Negotiation Procedures 836 A negotiation initiator sends a negotiation request to a counterpart 837 ASA, including a specific negotiation objective. It may request the 838 negotiation counterpart to make a specific configuration. 839 Alternatively, it may request a certain simulation or forecast result 840 by sending a dry run configuration. The details, including the 841 distinction between dry run and an actual configuration change, will 842 be defined separately for each type of negotiation objective. 844 If no reply message of any kind is received within a reasonable 845 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 846 negotiation request MAY be repeated, with a newly generated Session 847 ID (Section 3.6). An exponential backoff SHOULD be used for 848 subsequent repetitions. 850 If the counterpart can immediately apply the requested configuration, 851 it will give an immediate positive (accept) answer. This will end 852 the negotiation phase immediately. Otherwise, it will negotiate. It 853 will reply with a proposed alternative configuration that it can 854 apply (typically, a configuration that uses fewer resources than 855 requested by the negotiation initiator). This will start a bi- 856 directional negotiation to reach a compromise between the two ASAs. 858 The negotiation procedure is ended when one of the negotiation peers 859 sends a Negotiation Ending message, which contains an accept or 860 decline option and does not need a response from the negotiation 861 peer. Negotiation may also end in failure (equivalent to a decline) 862 if a timeout is exceeded or a loop count is exceeded. 864 A negotiation procedure concerns one objective and one counterpart. 865 Both the initiator and the counterpart may take part in simultaneous 866 negotiations with various other ASAs, or in simultaneous negotiations 867 about different objectives. Thus, GRASP is expected to be used in a 868 multi-threaded mode. Certain negotiation objectives may have 869 restrictions on multi-threading, for example to avoid over-allocating 870 resources. 872 Some configuration actions, for example wavelength switching in 873 optical networks, might take considerable time to execute. The ASA 874 concerned needs to allow for this by design, but GRASP does allow for 875 a peer to insert latency in a negotiation process if necessary 876 (Section 3.7.7). 878 3.3.4.1. Rapid Mode (Discovery/Negotiation Linkage) 880 A Discovery message MAY include a Negotiation Objective option. In 881 this case the Discovery message also acts as a Request message to 882 indicate to the Discovery Responder that it could directly reply to 883 the Discovery Initiator with a Negotiation message for rapid 884 processing, if it could act as the corresponding negotiation 885 counterpart. However, the indication is only advisory not 886 prescriptive. 888 This rapid mode could reduce the interactions between nodes so that a 889 higher efficiency could be achieved. This rapid negotiation function 890 SHOULD be configured off by default and MAY be configured on or off 891 by Intent. 893 3.3.5. Synchronization and Flooding Procedure 895 A synchronization initiator sends a synchronization request to a 896 counterpart, including a specific synchronization objective. The 897 counterpart responds with a Synchronization message (Section 3.7.8) 898 containing the current value of the requested synchronization 899 objective. No further messages are needed. 901 If no reply message of any kind is received within a reasonable 902 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 903 synchronization request MAY be repeated, with a newly generated 904 Session ID (Section 3.6). An exponential backoff SHOULD be used for 905 subsequent repetitions. 907 3.3.5.1. Flooding 909 In the case just described, the message exchange is unicast and 910 concerns only one synchronization objective. For large groups of 911 nodes requiring the same data, synchronization flooding is available. 912 For this, a flooding initiator MAY send an unsolicited Flood message 913 containing one or more Synchronization Objective option(s), if and 914 only if the specification of those objectives permits it. This is 915 sent as a multicast message to the ALL_GRASP_NEIGHBOR multicast 916 address (Section 3.5). To ensure that flooding does not result in a 917 loop, the originator of the Flood message MUST set the loop count in 918 the objectives to a suitable value (the default is GRASP_DEF_LOOPCT). 919 In this case a suitable mechanism is needed to avoid excessive 920 multicast traffic. This mechanism MUST be defined as part of the 921 specification of the synchronization objective(s) concerned. It 922 might be a simple rate limit or a more complex mechanism such as the 923 Trickle algorithm [RFC6206]. 925 A GRASP device with multiple link-layer interfaces (typically a 926 router) MUST support synchronization flooding on all interfaces. If 927 it receives a multicast Flood message on a given interface, it MUST 928 relay it by re-issuing a Flood message on its other interfaces. The 929 relayed message MAY have a different Session ID. Before this, it 930 MUST decrement the loop count within the objective, and MUST NOT 931 relay the Flood message if the result is zero. Also, it MUST limit 932 the total rate at which it relays Flood messages to a reasonable 933 value, in order to mitigate possible denial of service attacks. It 934 MUST cache the Session ID value of each relayed Flood message and, to 935 prevent loops, MUST NOT relay a Flood message which carries such a 936 cached Session ID. These precautions avoid synchronization loops and 937 mitigate potential overload. 939 Note that this mechanism is unreliable in the case of sleeping nodes. 940 Sleeping nodes that require an objective subject to flooding SHOULD 941 periodically request unicast synchronization for that objective. 943 The multicast messages for synchronization flooding are subject to 944 the security rules in Section 3.3.1. In practice this means that 945 they MUST NOT be transmitted and MUST be ignored on receipt unless 946 there is an operational ACP. 948 3.3.5.2. Rapid Mode (Discovery/Synchronization Linkage) 950 A Discovery message MAY include a Synchronization Objective option. 951 In this case the Discovery message also acts as a Request message to 952 indicate to the Discovery Responder that it could directly reply to 953 the Discovery Initiator with a Synchronization message Section 3.7.8 954 with synchronization data for rapid processing, if the discovery 955 target supports the corresponding synchronization objective. 956 However, the indication is only advisory not prescriptive. 958 This rapid mode could reduce the interactions between nodes so that a 959 higher efficiency could be achieved. This rapid synchronization 960 function SHOULD be configured off by default and MAY be configured on 961 or off by Intent. 963 3.4. High Level Deployment Model 965 It is expected that a GRASP implementation will reside in an 966 autonomic node that also contains both the appropriate security 967 environment (preferably the ACP) and one or more Autonomic Service 968 Agents (ASAs). In the minimal case of a single-purpose device, these 969 three components might be fully integrated. A more common model is 970 expected to be a multi-purpose device capable of containing several 971 ASAs. In this case it is expected that the ACP, GRASP and the ASAs 972 will be implemented as separate processes, which are probably multi- 973 threaded to support asynchronous operation. It is expected that 974 GRASP will access the ACP by using a typical socket interface. Well 975 defined Application Programming Interfaces (APIs) will be needed 976 between GRASP and the ASAs. For further details of possible 977 deployment models, see [I-D.behringer-anima-reference-model]. 979 3.5. GRASP Constants 981 o ALL_GRASP_NEIGHBOR 983 A link-local scope multicast address used by a GRASP-enabled 984 device to discover GRASP-enabled neighbor (i.e., on-link) devices 985 . All devices that support GRASP are members of this multicast 986 group. 988 * IPv6 multicast address: TBD1 990 * IPv4 multicast address: TBD2 992 o GRASP_LISTEN_PORT (TBD3) 994 A UDP and TCP port that every GRASP-enabled network device always 995 listens to. 997 o GRASP_DEF_TIMEOUT (60000 milliseconds) 999 The default timeout used to determine that a discovery etc. has 1000 failed to complete. 1002 o GRASP_DEF_LOOPCT (6) 1004 The default loop count used to determine that a negotiation has 1005 failed to complete, and to avoid looping messages. 1007 3.6. Session Identifier (Session ID) 1009 This is an up to 24-bit opaque value used to distinguish multiple 1010 sessions between the same two devices. A new Session ID MUST be 1011 generated by the initiator for every new Discovery, Flood or Request 1012 message. All responses and follow-up messages in the same discovery, 1013 synchronization or negotiation procedure MUST carry the same Session 1014 ID. 1016 The Session ID SHOULD have a very low collision rate locally. It 1017 MUST be generated by a pseudo-random algorithm using a locally 1018 generated seed which is unlikely to be used by any other device in 1019 the same network [RFC4086]. 1021 However, there is a finite probability that two nodes might generate 1022 the same Session ID value. For that reason, when a Session ID is 1023 communicated via GRASP, the receiving node MUST tag it with the 1024 initiator's IP address to allow disambiguation. Multicast GRASP 1025 messages and their responses, which may be relayed between links, 1026 therefore include a field that carries the initiator's global IP 1027 address. 1029 3.7. GRASP Messages 1031 This section defines the GRASP message format and message types. 1032 Message types not listed here are reserved for future use. 1034 3.7.1. GRASP Message Format 1036 GRASP messages share an identical header format and a variable format 1037 area for options. GRASP message headers and options are transmitted 1038 in Concise Binary Object Representation (CBOR) [RFC7049]. In this 1039 specification, they are described using CBOR data definition language 1040 (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is 1041 used to describe each item in this section. A complete and normative 1042 CDDL specification of GRASP is given in Section 6, including 1043 constants such as message types. 1045 Every GRASP message, except the No Operation message, carries a 1046 Session ID (Section 3.6). Options are then presented serially in the 1047 options field. 1049 In fragmentary CDDL, every GRASP message follows the pattern: 1051 grasp-message = (message .within message-structure) / noop-message 1053 message-structure = [MESSAGE_TYPE, session-id, +grasp-option] 1055 MESSAGE_TYPE = 1..255 1056 session-id = 0..16777215 ;up to 24 bits 1057 grasp-option = any 1059 The MESSAGE_TYPE indicates the type of the message and thus defines 1060 the expected options. Any options received that are not consistent 1061 with the MESSAGE_TYPE SHOULD be silently discarded. 1063 The No Operation (noop) message is described in Section 3.7.10. 1065 The various MESSAGE_TYPE values are defined in Section 6. 1067 All other message elements are described below and formally defined 1068 in Section 6. 1070 3.7.2. Discovery Message 1072 In fragmentary CDDL, a Discovery message follows the pattern: 1074 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1076 A discovery initiator sends a Discovery message to initiate a 1077 discovery process for a particular objective option. 1079 The discovery initiator sends the Discovery messages to the link- 1080 local ALL_GRASP_NEIGHBOR multicast address for discovery, and stores 1081 the discovery results (including responding discovery objectives and 1082 corresponding unicast addresses, FQDNs or URIs). 1084 The 'initiator' field in the message is a globally unique IP address 1085 of the initiator, for the sole purpose of disambiguating the Session 1086 ID in other nodes. If for some reason the initiator does not have a 1087 globally unique IP address, it MUST use a link-local address for this 1088 purpose that is highly likely to be unique, for example using 1089 [RFC7217]. 1091 A Discovery message MUST include exactly one of the following: 1093 o a discovery objective option (Section 3.9.1). Its loop count MUST 1094 be set to a suitable value to prevent discovery loops (default 1095 value is GRASP_DEF_LOOPCT). 1097 o a negotiation objective option (Section 3.9.1). This is used both 1098 for the purpose of discovery and to indicate to the discovery 1099 target that it MAY directly reply to the discovery initiatior with 1100 a Negotiation message for rapid processing, if it could act as the 1101 corresponding negotiation counterpart. The sender of such a 1102 Discovery message MUST initialize a negotiation timer and loop 1103 count in the same way as a Request message (Section 3.7.4). 1105 o a synchronization objective option (Section 3.9.1). This is used 1106 both for the purpose of discovery and to indicate to the discovery 1107 target that it MAY directly reply to the discovery initiator with 1108 a Synchronization message for rapid processing, if it could act as 1109 the corresponding synchronization counterpart. Its loop count 1110 MUST be set to a suitable value to prevent discovery loops 1111 (default value is GRASP_DEF_LOOPCT). 1113 3.7.3. Response Message 1115 In fragmentary CDDL, a Response message follows the pattern: 1117 response-message = [M_RESPONSE, session-id, initiator, 1118 (+locator-option // divert-option), ?objective)] 1120 A node which receives a Discovery message SHOULD send a Response 1121 message if and only if it can respond to the discovery. It MUST 1122 contain the same Session ID and initiator as the Discovery message. 1123 It MAY include a copy of the discovery objective from the Discovery 1124 message. 1126 If the responding node supports the discovery objective of the 1127 discovery, it MUST include at least one kind of locator option 1128 (Section 3.8.6) to indicate its own location. A sequence of multiple 1129 kinds of locator options (e.g. IP address option + FQDN option) is 1130 also valid. 1132 If the responding node itself does not support the discovery 1133 objective, but it knows the locator of the discovery objective, then 1134 it SHOULD respond to the discovery message with a divert option 1135 (Section 3.8.2) embedding a locator option or a combination of 1136 multiple kinds of locator options which indicate the locator(s) of 1137 the discovery objective. 1139 3.7.4. Request Message 1141 In fragmentary CDDL, a Request message follows the pattern: 1143 request-message = [M_REQUEST, session-id, objective] 1145 A negotiation or synchronization requesting node sends the Request 1146 message to the unicast address (directly stored or resolved from an 1147 FQDN) of the negotiation or synchronization counterpart (selected 1148 from the discovery results). 1150 A request message MUST include the relevant objective option, with 1151 the requested value in the case of negotiation. 1153 When an initiator sends a Request message, it MUST initialize a 1154 negotiation timer for the new negotiation thread with the value 1155 GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is modified by a 1156 Confirm-waiting message (Section 3.7.7), the initiator will consider 1157 that the negotiation has failed when the timer expires. 1159 When an initiator sends a Request message, it MUST initialize the 1160 loop count of the objective option with a value defined in the 1161 specification of the option or, if no such value is specified, with 1162 GRASP_DEF_LOOPCT. 1164 If a node receives a Request message for an objective for which no 1165 ASA is currently listening, it MUST immediately close the relevant 1166 socket to indicate this to the initiator. 1168 3.7.5. Negotiation Message 1170 In fragmentary CDDL, a Negotiation message follows the pattern: 1172 discovery-message = [M_NEGOTIATE, session-id, objective] 1174 A negotiation counterpart sends a Negotiation message in response to 1175 a Request message, a Negotiation message, or a Discovery message in 1176 Rapid Mode. A negotiation process MAY include multiple steps. 1178 The Negotiation message MUST include the relevant Negotiation 1179 Objective option, with its value updated according to progress in the 1180 negotiation. The sender MUST decrement the loop count by 1. If the 1181 loop count becomes zero the message MUST NOT be sent. In this case 1182 the negotiation session has failed and will time out. 1184 3.7.6. Negotiation-ending Message 1186 In fragmentary CDDL, a Negotiation-ending message follows the 1187 pattern: 1189 end-message = [M_END, session-id, accept-option / decline-option] 1191 A negotiation counterpart sends an Negotiation-ending message to 1192 close the negotiation. It MUST contain either an accept or a decline 1193 option, defined in Section 3.8.3 and Section 3.8.4. It could be sent 1194 either by the requesting node or the responding node. 1196 3.7.7. Confirm-waiting Message 1198 In fragmentary CDDL, a Confirm-waiting message follows the pattern: 1200 wait-message = [M_WAIT, session-id, waiting-time] 1201 waiting-time = 0..4294967295 ; in milliseconds 1203 A responding node sends a Confirm-waiting message to ask the 1204 requesting node to wait for a further negotiation response. It might 1205 be that the local process needs more time or that the negotiation 1206 depends on another triggered negotiation. This message MUST NOT 1207 include any other options. When received, the waiting time value 1208 overwrites and restarts the current negotiation timer 1209 (Section 3.7.4). 1211 The responding node SHOULD send a Negotiation, Negotiation-Ending or 1212 another Confirm-waiting message before the negotiation timer expires. 1213 If not, the initiator MUST abandon or restart the negotiation 1214 procedure, to avoid an indefinite wait. 1216 3.7.8. Synchronization Message 1218 In fragmentary CDDL, a Synchronization message follows the pattern: 1220 synch-message = [M_SYNCH, session-id, objective] 1222 A node which receives a synchronization Request, or a Discovery 1223 message in Rapid Mode, sends back a unicast Synchronization message 1224 with the synchronization data, in the form of a GRASP Option for the 1225 specific synchronization objective present in the Request. 1227 3.7.9. Flood Message 1229 In fragmentary CDDL, a Flood message follows the pattern: 1231 flood-message = [M_FLOOD, session-id, initiator, +objective] 1233 A node MAY initiate flooding by sending an unsolicited Flood Message 1234 with synchronization data. This MAY be sent to the link-local 1235 ALL_GRASP_NEIGHBOR multicast address, in accordance with the rules in 1236 Section 3.3.5. The initiator address is provided as described for 1237 Discovery messages. The synchronization data will be in the form of 1238 GRASP Option(s) for specific synchronization objective(s). The loop 1239 count(s) MUST be set to a suitable value to prevent flood loops 1240 (default value is GRASP_DEF_LOOPCT). 1242 A node that receives a Flood message SHOULD cache the received 1243 objectives for use by local ASAs. 1245 3.7.10. No Operation Message 1247 In fragmentary CDDL, a No Operation message follows the pattern: 1249 noop-message = [M_NOOP] 1251 This message MAY be sent by an implementation that for practical 1252 reasons needs to activate a socket. It MUST be silently ignored by a 1253 recipient. 1255 3.8. GRASP Options 1257 This section defines the GRASP options for the negotiation and 1258 synchronization protocol signaling. Additional options may be 1259 defined in the future. 1261 3.8.1. Format of GRASP Options 1263 GRASP options are CBOR objects that MUST start with an unsigned 1264 integer identifying the specific option type carried in this option. 1265 These option types are formally defined in Section 6. Apart from 1266 that the only format requirement is that each option MUST be a well- 1267 formed CBOR object. In general a CBOR array format is RECOMMENDED to 1268 limit overhead. 1270 GRASP options are usually scoped by using encapsulation. However, 1271 this is not a requirement 1273 3.8.2. Divert Option 1275 The Divert option is used to redirect a GRASP request to another 1276 node, which may be more appropriate for the intended negotiation or 1277 synchronization. It may redirect to an entity that is known as a 1278 specific negotiation or synchronization counterpart (on-link or off- 1279 link) or a default gateway. The divert option MUST only be 1280 encapsulated in Response messages. If found elsewhere, it SHOULD be 1281 silently ignored. 1283 In fragmentary CDDL, the Divert option follows the pattern: 1285 divert-option = [O_DIVERT, +locator-option] 1287 The embedded Locator Option(s) (Section 3.8.6) point to diverted 1288 destination target(s) in response to a Discovery message. 1290 3.8.3. Accept Option 1292 The accept option is used to indicate to the negotiation counterpart 1293 that the proposed negotiation content is accepted. 1295 The accept option MUST only be encapsulated in Negotiation-ending 1296 messages. If found elsewhere, it SHOULD be silently ignored. 1298 In fragmentary CDDL, the Accept option follows the pattern: 1300 accept-option = [O_ACCEPT] 1302 3.8.4. Decline Option 1304 The decline option is used to indicate to the negotiation counterpart 1305 the proposed negotiation content is declined and end the negotiation 1306 process. 1308 The decline option MUST only be encapsulated in Negotiation-ending 1309 messages. If found elsewhere, it SHOULD be silently ignored. 1311 In fragmentary CDDL, the Decline option follows the pattern: 1313 decline-option = [O_DECLINE, ?reason] 1314 reason = text ;optional error message 1316 Note: there are scenarios where a negotiation counterpart wants to 1317 decline the proposed negotiation content and continue the negotiation 1318 process. For these scenarios, the negotiation counterpart SHOULD use 1319 a Negotiate message, with either an objective option that contains a 1320 data field set to indicate a meaningless initial value, or a specific 1321 objective option that provides further conditions for convergence. 1323 3.8.5. Device Identity Option 1325 The Device Identity option carries the identities of the sender and 1326 of the domain(s) that it belongs to. 1328 In fragmentary CDDL, the Device Identity option follows the pattern: 1330 option-device-id = [O_DEVICE_ID, bytes] 1332 The option contains a variable-length field containing the device 1333 identity and one or more domain identities. The format is not yet 1334 defined. 1336 Note: Currently this option is an unused placeholder. It might be 1337 removed or modified. 1339 3.8.6. Locator Options 1341 These locator options are used to present reachability information 1342 for an ASA, a device or an interface. They are Locator IPv4 Address 1343 Option, Locator IPv6 Address Option, Locator FQDN (Fully Qualified 1344 Domain Name) Option and Uniform Resource Identifier Option. 1346 Note: It is assumed that all locators are in scope throughout the 1347 GRASP domain. GRASP is not intended to work across disjoint 1348 addressing or naming realms. 1350 3.8.6.1. Locator IPv4 address option 1352 In fragmentary CDDL, the IPv4 address option follows the pattern: 1354 ipv4-locator-option = bytes .size 4 1356 The content of this option is a binary IPv4 address. 1358 Note: If an operator has internal network address translation for 1359 IPv4, this option MUST NOT be used within the Divert option. 1361 3.8.6.2. Locator IPv6 address option 1363 In fragmentary CDDL, the IPv6 address option follows the pattern: 1365 ipv6-locator-option = bytes .size 16 1367 The content of this option is a binary IPv6 address. 1369 Note 1: The IPv6 address MUST normally have global scope. 1370 Exceptionally, during node bootstrap, a link-local address MAY be 1371 used for specific objectives only. 1373 Note 2: A link-local IPv6 address MUST NOT be used when this option 1374 is included in a Divert option. 1376 3.8.6.3. Locator FQDN option 1378 In fragmentary CDDL, the FQDN option follows the pattern: 1380 fqdn-locator-option = [O_FQDN_LOCATOR, text] 1382 The content of this option is the Fully Qualified Domain Name of the 1383 target. 1385 Note 1: Any FQDN which might not be valid throughout the network in 1386 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1387 when this option is used within the Divert option. 1389 Note 2: Normal GRASP operations are not expected to use this option. 1390 It is intended for special purposes such as discovering external 1391 services. 1393 3.8.6.4. Locator URI option 1395 In fragmentary CDDL, the URI option follows the pattern: 1397 uri-locator-option = [O_URI_LOCATOR, text] 1399 The content of this option is the Uniform Resource Identifier of the 1400 target [RFC3986]. 1402 Note 1: Any URI which might not be valid throughout the network in 1403 question, such as one based on a Multicast DNS name [RFC6762], MUST 1404 NOT be used when this option is used within the Divert option. 1406 Note 2: Normal GRASP operations are not expected to use this option. 1407 It is intended for special purposes such as discovering external 1408 services. 1410 3.9. Objective Options 1412 3.9.1. Format of Objective Options 1414 An objective option is used to identify objectives for the purposes 1415 of discovery, negotiation or synchronization. All objectives MUST be 1416 in the following format, described in fragmentary CDDL: 1418 objective = [objective-name, objective-flags, loop-count, ?any] 1420 objective-name = text 1421 loop-count = 0..255 1423 All objectives are identified by a unique name which is a case- 1424 sensitive UTF-8 string. 1426 The names of generic objectives MUST NOT include a colon (":") and 1427 MUST be registered with IANA (Section 7). 1429 The names of privately defined objectives MUST include at least one 1430 colon (":"). The string preceding the last colon in the name MUST be 1431 globally unique and in some way identify the entity or person 1432 defining the objective. The following three methods MAY be used to 1433 create such a globally unique string: 1435 1. The unique string is a decimal number representing a registered 1436 32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 1437 uniquely identifies the enterprise defining the objective. 1439 2. The unique string is a fully qualified domain name that uniquely 1440 identifies the entity or person defining the objective. 1442 3. The unique string is an email address that uniquely identifies 1443 the entity or person defining the objective. 1445 The GRASP protocol treats the objective name as an opaque string. 1446 For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 1447 and "user@example.org:EX1" would be five different objectives. 1449 The 'objective-flags' field is described below. 1451 The 'loop-count' field is used for terminating negotiation as 1452 described in Section 3.7.5. It is also used for terminating 1453 discovery as described in Section 3.3.3, and for terminating flooding 1454 as described in Section 3.3.5.1. 1456 The 'any' field is to express the actual value of a negotiation or 1457 synchronization objective. Its format is defined in the 1458 specification of the objective and may be a single value or a data 1459 structure of any kind. It is optional because it is optional in a 1460 Discovery or Response message. 1462 3.9.2. Objective flags 1464 An objective may be relevant for discovery only, for discovery and 1465 negotiation, or for discovery and synchronization. This is expressed 1466 in the objective by logical flags: 1468 objective-flags = uint .bits objective-flag 1469 objective-flag = &( 1470 F_DISC: 0 ; valid for discovery only 1471 F_NEG: 1 ; valid for discovery and negotiation 1472 F_SYNCH: 2 ; valid for discovery and synchronization 1473 ) 1475 3.9.3. General Considerations for Objective Options 1477 As mentioned above, Objective Options MUST be assigned a unique name. 1478 As long as privately defined Objective Options obey the rules above, 1479 this document does not restrict their choice of name, but the entity 1480 or person concerned SHOULD publish the names in use. 1482 All Objective Options MUST respect the CBOR patterns defined above as 1483 "objective" and MUST replace the "any" field with a valid CBOR data 1484 definition for the relevant use case and application. 1486 An Objective Option that contains no additional fields beyond its 1487 "loop-count" can only be a discovery objective and MUST only be used 1488 in Discovery and Response messages. 1490 The Negotiation Objective Options contain negotiation objectives, 1491 which vary according to different functions/services. They MUST be 1492 carried by Discovery, Request or Negotiation Messages only. The 1493 negotiation initiator MUST set the initial "loop-count" to a value 1494 specified in the specification of the objective or, if no such value 1495 is specified, to GRASP_DEF_LOOPCT. 1497 For most scenarios, there should be initial values in the negotiation 1498 requests. Consequently, the Negotiation Objective options MUST 1499 always be completely presented in a Request message, or in a 1500 Discovery message in rapid mode. If there is no initial value, the 1501 bits in the value field SHOULD all be set to indicate a meaningless 1502 value, unless this is inappropriate for the specific negotiation 1503 objective. 1505 Synchronization Objective Options are similar, but MUST be carried by 1506 Discovery, Request, Response or Flood messages only. They include 1507 value fields only in Response or Flood messages. 1509 3.9.4. Organizing of Objective Options 1511 Generic objective options MUST be specified in documents available to 1512 the public and SHOULD be designed to use either the negotiation or 1513 the synchronization mechanism described above. 1515 As noted earlier, one negotiation objective is handled by each GRASP 1516 negotiation thread. Therefore, a negotiation objective, which is 1517 based on a specific function or action, SHOULD be organized as a 1518 single GRASP option. It is NOT RECOMMENDED to organize multiple 1519 negotiation objectives into a single option, nor to split a single 1520 function or action into multiple negotiation objectives. 1522 It is important to understand that GRASP negotiation does not support 1523 transactional integrity. If transactional integrity is needed for a 1524 specific objective, this must be ensured by the ASA. For example, an 1525 ASA might need to ensure that it only participates in one negotiation 1526 thread at the same time. Such an ASA would need to stop listening 1527 for incoming negotiation requests before generating an outgoing 1528 negotiation request. 1530 A synchronization objective SHOULD be organized as a single GRASP 1531 option. 1533 Some objectives will support more than one operational mode. An 1534 example is a negotiation objective with both a "dry run" mode (where 1535 the negotiation is to find out whether the other end can in fact make 1536 the requested change without problems) and a "live" mode. Such modes 1537 will be defined in the specification of such an objective. These 1538 objectives SHOULD include flags indicating the applicable mode(s). 1540 An objective may have multiple parameters. Parameters can be 1541 categorized into two classes: the obligatory ones presented as fixed 1542 fields; and the optional ones presented in CBOR sub-options or some 1543 other form of data structure embedded in CBOR. The format might be 1544 inherited from an existing management or configuration protocol, the 1545 objective option acting as a carrier for that format. The data 1546 structure might be defined in a formal language, but that is a matter 1547 for the specifications of individual objectives. There are many 1548 candidates, according to the context, such as ABNF, RBNF, XML Schema, 1549 possibly YANG, etc. The GRASP protocol itself is agnostic on these 1550 questions. 1552 It is NOT RECOMMENDED to split parameters in a single objective into 1553 multiple options, unless they have different response periods. An 1554 exception scenario may also be described by split objectives. 1556 All objectives MUST support GRASP discovery. However, as mentioned 1557 in Section 3.2, it is acceptable for an ASA to use an alternative 1558 method of discovery. 1560 Normally, a GRASP objective will refer to specific technical 1561 parameters as explained in Section 3.1. However, it is acceptable to 1562 define an abstract objective for the purpose of managing or 1563 coordinating ASAs. It is also acceptable to define a special-purpose 1564 objective for purposes such as trust bootstrapping or formation of 1565 the ACP. 1567 3.9.5. Experimental and Example Objective Options 1569 The names "EX0" through "EX9" have been reserved for experimental 1570 options. Multiple names have been assigned because a single 1571 experiment may use multiple options simultaneously. These 1572 experimental options are highly likely to have different meanings 1573 when used for different experiments. Therefore, they SHOULD NOT be 1574 used without an explicit human decision and SHOULD NOT be used in 1575 unmanaged networks such as home networks. 1577 These names are also RECOMMENDED for use in documentation examples. 1579 4. Open Issues 1581 RFC Editor: This section should be deleted except for any items not 1582 marked as resolved, which should be retained and renumbered. 1584 There are various unresolved design questions that are worthy of more 1585 work in the near future, as listed below (statically numbered in 1586 historical order for reference purposes, with the resolved issues 1587 retained for reference): 1589 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 1590 as message transport mechanisms. This is not clarified yet. UDP 1591 is good for short conversations, is necessary for multicast 1592 discovery, and generally fits the discovery and divert scenarios 1593 well. However, it will cause problems with large messages. TCP 1594 is good for stable and long sessions, with a little bit of time 1595 consumption during the session establishment stage. If messages 1596 exceed a reasonable MTU, a TCP mode will be required in any case. 1597 This question may be affected by the security discussion. 1599 RESOLVED by specifying UDP for short message and TCP for longer 1600 one. 1602 o 2. DTLS or TLS vs built-in security mechanism. For now, this 1603 specification has chosen a PKI based built-in security mechanism 1604 based on asymmetric cryptography. However, (D)TLS might be chosen 1605 as security solution to avoid duplication of effort. It also 1606 allows essentially similar security for short messages over UDP 1607 and longer ones over TCP. The implementation trade-offs are 1608 different. The current approach requires expensive asymmetric 1609 cryptographic calculations for every message. (D)TLS has startup 1610 overheads but cheaper crypto per message. DTLS is less mature 1611 than TLS. 1613 RESOLVED by specifying external security (ACP or (D)TLS). 1615 o The following open issues applied only if the original security 1616 model was retained: 1618 * 2.1. For replay protection, GRASP currently requires every 1619 participant to have an NTP-synchronized clock. Is this OK for 1620 low-end devices, and how does it work during device 1621 bootstrapping? We could take the Timestamp out of signature 1622 option, to become an independent and OPTIONAL (or RECOMMENDED) 1623 option. 1625 * 2.2. The Signature Option states that this option could be any 1626 place in a message. Wouldn't it be better to specify a 1627 position (such as the end)? That would be much simpler to 1628 implement. 1630 RESOLVED by changing security model. 1632 o 3. DoS Attack Protection needs work. 1634 RESOLVED by adding text. 1636 o 4. Should we consider preferring a text-based approach to 1637 discovery (after the initial discovery needed for bootstrapping)? 1638 This could be a complementary mechanism for multicast based 1639 discovery, especially for a very large autonomic network. 1640 Centralized registration could be automatically deployed 1641 incrementally. At the very first stage, the repository could be 1642 empty; then it could be filled in by the objectives discovered by 1643 different devices (for example using Dynamic DNS Update). The 1644 more records are stored in the repository, the less the multicast- 1645 based discovery is needed. However, if we adopt such a mechanism, 1646 there would be challenges: stateful solution, and security. 1648 RESOLVED for now by adding optional use of DNS-SD by ASAs. 1649 Subsequently removed by editors as irrelevant to GRASP istelf. 1651 o 5. Need to expand description of the minimum requirements for the 1652 specification of an individual discovery, synchronization or 1653 negotiation objective. 1655 RESOLVED for now by extra wording. 1657 o 6. Use case and protocol walkthrough. A description of how a 1658 node starts up, performs discovery, and conducts negotiation and 1659 synchronisation for a sample use case would help readers to 1660 understand the applicability of this specification. Maybe it 1661 should be an artificial use case or maybe a simple real one, based 1662 on a conceptual API. However, the authors have not yet decided 1663 whether to have a separate document or have it in the protocol 1664 document. 1666 RESOLVED: recommend a separate document. 1668 o 7. Cross-check against other ANIMA WG documents for consistency 1669 and gaps. 1671 o 8. Consideration of ADNCP proposal. 1673 RESOLVED by adding optional use of DNCP for flooding-type 1674 synchronization. 1676 o 9. Clarify how a GDNP instance knows whether it is running inside 1677 the ACP. (Sheng) 1679 RESOLVED by improved text. 1681 o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. 1682 (Sheng) 1684 RESOLVED by improved text and declaring DTLS out of scope for this 1685 draft. 1687 o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - 1688 Brian] 1690 RESOLVED by improved text. 1692 o 12. Justify that IP address within ACP or (D)TLS environment is 1693 sufficient to prove AN identity; or explain how Device Identity 1694 Option is used. (Sheng) 1696 RESOLVED for now: we assume that all ASAs in a device are trusted 1697 as soon as the device is trusted, so they share credentials. In 1698 that case the Device Identity Option is useless. This needs to be 1699 reviewed later. 1701 o 13. Emphasise that negotiation/synchronization are independent 1702 from discovery, although the rapid discovery mode includes the 1703 first step of a negotiation/synchronization. (Sheng) 1705 RESOLVED by improved text. 1707 o 14. Do we need an unsolicited flooding mechanism for discovery 1708 (for discovery results that everyone needs), to reduce scaling 1709 impact of flooding discovery messages? (Toerless) 1711 RESOLVED: Yes, added to requirements and solution. 1713 o 15. Do we need flag bits in Objective Options to distinguish 1714 distinguish Synchronization and Negotiation "Request" or rapid 1715 mode "Discovery" messages? (Bing) 1717 RESOLVED: yes, work on the API showed that these flags are 1718 essential. 1720 o 16. (Related to issue 14). Should we revive the "unsolicited 1721 Response" for flooding synchronisation data? This has to be done 1722 carefully due to the well-known issues with flooding, but it could 1723 be useful, e.g. for Intent distribution, where DNCP doesn't seem 1724 applicable. 1726 RESOLVED: Yes, see #14. 1728 o 17. Ensure that the discovery mechanism is completely proof 1729 against loops and protected against duplicate responses. 1731 RESOLVED: Added loop count mechanism. 1733 o 18. Discuss the handling of multiple valid discovery responses. 1735 RESOLVED: Stated that the choice must be available to the ASA but 1736 GRASP implementation should pick a default. 1738 o 19. Should we use a text-oriented format such as JSON/CBOR 1739 instead of native binary TLV format? 1741 RESOLVED: Yes, changed to CBOR. 1743 o 20. Is the Divert option needed? If a discovery response 1744 provides a valid IP address or FQDN, the recipient doesn't gain 1745 any extra knowledge from the Divert. On the other hand, the 1746 presence of Divert informs the receiver that the target is off- 1747 link, which might be useful sometimes. 1749 RESOLVED: Decided to keep Divert option. 1751 o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling 1752 Protocol)? 1754 RESOLVED: Yes, name changed. 1756 o 22. Does discovery mechanism scale robustly as needed? Need hop 1757 limit on relaying? 1759 RESOLVED: Added hop limit. 1761 o 23. Need more details on TTL for caching discovery responses. 1763 RESOLVED: Done. 1765 o 24. Do we need "fast withdrawal" of discovery responses? 1767 RESOLVED: This doesn't seem necessary. If an ASA exits or stops 1768 supporting a given objective, peers will fail to start future 1769 sessions and will simply repeat discovery. 1771 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? 1773 RESOLVED: Decided not to consider this further as a GRASP protocol 1774 issue. GRASP objectives could embed DNS-SD formats if needed. 1776 o 26. Add a URL type to the locator options (for security bootstrap 1777 etc.) 1779 RESOLVED: Done, later renamed as URI. 1781 o 27. Security of Flood multicasts (Section 3.3.5.1). 1783 RESOLVED: added text. 1785 o 28. Does ACP support secure link-local multicast? 1787 o 29. PEN is used to distinguish vendor options. Would it be 1788 better to use a domain name? Anything unique will do. 1790 RESOLVED: Simplified this by removing PEN field and changing 1791 naming rules for objectives. 1793 o 30. Does response to discovery require randomized delays to 1794 mitigate amplification attacks? 1796 RESOLVED: WG feedback is that it's unnecessary. 1798 o 31. We have specified repeats for failed discovery etc. Is that 1799 sufficient to deal with sleeping nodes? 1801 RESOLVED: WG feedback is that it's unnecessary to say more. 1803 o 32. We have one-to-one synchronization and flooding 1804 synchronization. Do we also need selective flooding to a subset 1805 of nodes? 1807 RESOLVED: This will be discussed as a protocol extension in a 1808 separate draft (draft-liu-anima-grasp-distribution). 1810 o 33. Clarify if/when discovery needs to be repeated. 1812 RESOLVED: Done. 1814 o 34. Clarify what is mandatory for running in ACP, expand 1815 discussion of security boundary when running with no ACP - might 1816 rely on the local PKI infrastructure. 1818 RESOLVED: Done. 1820 o 35. State that role-based authorization of ASAs is out of scope 1821 for GRASP. GRASP doesn't recognize/handle any "roles". 1823 RESOLVED: Done. 1825 o 36. Reconsider CBOR definition for PEN syntax. ( objective-name 1826 = text / [pen, text] ; pen = uint ) 1828 RESOLVED: See issue 29. 1830 o 37. Are URI locators really needed? 1832 RESOLVED: Yes, e.g. for security bootstrap discovery, but added 1833 note that addresses are the normal case (same for FQDN locators). 1835 o 38. Is Session ID sufficient to identify relayed responses? 1836 Isn't the originator's address needed too? 1838 RESOLVED: Yes, this is needed for multicast messages and their 1839 responses. 1841 o 39. Clarify that a node will contain one GRASP instance 1842 supporting multiple ASAs. 1844 RESOLVED: Done. 1846 o 40. Add a "reason" code to the DECLINE option? 1848 RESOLVED: Done. 1850 o 41. What happens if an ASA cannot conveniently use one of the 1851 GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) 1852 simply pass the discovery results to the ASA so that it can open 1853 its own socket? 1855 RESOLVED: Both would be possible, but (b) is preferred. 1857 o 42. Do we need a feature whereby an ASA can bypass the ACP and 1858 use the data plane for efficiency/throughput? This would require 1859 discovery to return non-ACP addresses and would evade ACP 1860 security. 1862 o 43. Rapid mode synchronization and negotiation is currently 1863 limited to a single objective for simplicity of design and 1864 implementation. A future consideration is to allow multiple 1865 objectives in rapid mode for greater efficiency. 1867 o 44. In requirement T9, the words that encryption "may not be 1868 required in all deployments" were removed. Is that OK?. 1870 o 45. Device Identity Option is unused. Can we remove it 1871 completely?. 1873 o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD 1874 messages is intended to assist in loop prevention. However, we 1875 also have the loop count for that. It would be simpler to remove 1876 the initiator, making message parsing more uniform. Is that OK? 1878 o 47. REQUEST is a dual purpose message (request negotiation or 1879 request synchronization). Would it be better to split this into 1880 two different messages (and adjust various message names 1881 accordingly)? 1883 5. Security Considerations 1885 It is obvious that a successful attack on negotiation-enabled nodes 1886 would be extremely harmful, as such nodes might end up with a 1887 completely undesirable configuration that would also adversely affect 1888 their peers. GRASP nodes and messages therefore require full 1889 protection. 1891 - Authentication 1893 A cryptographically authenticated identity for each device is 1894 needed in an autonomic network. It is not safe to assume that a 1895 large network is physically secured against interference or that 1896 all personnel are trustworthy. Each autonomic node MUST be 1897 capable of proving its identity and authenticating its messages. 1898 GRASP relies on a separate external certificate-based security 1899 mechanism to support authentication, data integrity protection, 1900 and anti-replay protection. 1902 Since GRASP is intended to be deployed in a single administrative 1903 domain operating its own trust anchor and CA, there is no need for 1904 a trusted public third party. In a network requiring "air gap" 1905 security, such a dependency would be unacceptable. 1907 If GRASP is used temporarily without an external security 1908 mechanism, for example during system bootstrap (Section 3.3.1), 1909 the Session ID (Section 3.6) will act as a nonce to provide 1910 limited protection against third parties injecting responses. A 1911 full analysis of the secure bootstrap process is out of scope for 1912 the present document. 1914 - Authorization and Roles 1916 The GRASP protocol is agnostic about the role of individual ASAs 1917 and about which objectives a particular ASA is authorized to 1918 support. It SHOULD apply obvious precautions such as allowing 1919 only one ASA in a given node to modify a given objective, but 1920 otherwise authorization is out of scope. 1922 - Privacy and confidentiality 1924 Generally speaking, no personal information is expected to be 1925 involved in the signaling protocol, so there should be no direct 1926 impact on personal privacy. Nevertheless, traffic flow paths, 1927 VPNs, etc. could be negotiated, which could be of interest for 1928 traffic analysis. Also, operators generally want to conceal 1929 details of their network topology and traffic density from 1930 outsiders. Therefore, since insider attacks cannot be excluded in 1931 a large network, the security mechanism for the protocol MUST 1932 provide message confidentiality. 1934 - DoS Attack Protection 1935 GRASP discovery partly relies on insecure link-local multicast. 1936 Since routers participating in GRASP sometimes relay discovery 1937 messages from one link to another, this could be a vector for 1938 denial of service attacks. Relevant mitigations are specified in 1939 Section 3.3.3. Additionally, it is of great importance that 1940 firewalls prevent any GRASP messages from entering the domain from 1941 an untrusted source. 1943 - Security during bootstrap and discovery 1945 A node cannot authenticate GRASP traffic from other nodes until it 1946 has identified the trust anchor and can validate certificates for 1947 other nodes. Also, until it has succesfully enrolled 1948 [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that 1949 other nodes are able to authenticate its own traffic. Therefore, 1950 GRASP discovery during the bootstrap phase for a new device will 1951 inevitably be insecure and GRASP synchronization and negotiation 1952 will be impossible until enrollment is complete. 1954 6. CDDL Specification of GRASP 1956 1958 grasp-message = (message .within message-structure) / noop-message 1960 message-structure = [MESSAGE_TYPE, session-id, +grasp-option] 1962 MESSAGE_TYPE = 0..255 1963 session-id = 0..16777215 ;up to 24 bits 1964 grasp-option = any 1966 message /= discovery-message 1967 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1969 message /= response-message ;response to Discovery 1970 response-message = [M_RESPONSE, session-id, initiator, 1971 (+locator-option // divert-option), ?objective] 1973 message /= synch-message ;response to Synchronization request 1974 synch-message = [M_SYNCH, session-id, objective] 1976 message /= flood-message 1977 flood-message = [M_FLOOD, session-id, initiator, +objective] 1979 message /= request-message 1980 request-message = [M_REQUEST, session-id, objective] 1982 message /= negotiation-message 1983 negotiation-message = [M_NEGOTIATE, session-id, objective] 1985 message /= end-message 1986 end-message = [M_END, session-id, accept-option / decline-option ] 1988 message /= wait-message 1989 wait-message = [M_WAIT, session-id, waiting-time] 1991 noop-message = [M_NOOP] 1993 divert-option = [O_DIVERT, +locator-option] 1995 accept-option = [O_ACCEPT] 1997 decline-option = [O_DECLINE, ?reason] 1998 reason = text ;optional error message 2000 waiting-time = 0..4294967295 ; in milliseconds 2002 option-device-id = [O_DEVICE_ID, bytes] 2004 locator-option /= ipv4-locator-option 2005 ipv4-locator-option = bytes .size 4 2006 ; this is simpler than [O_IPv4_LOCATOR, bytes .size 4] 2008 locator-option /= ipv6-locator-option 2009 ipv6-locator-option = bytes .size 16 2011 locator-option /= fqdn-locator-option 2012 fqdn-locator-option = [O_FQDN_LOCATOR, text] 2014 locator-option /= uri-locator-option 2015 uri-locator-option = [O_URI_LOCATOR, text] 2017 initiator = ipv4-locator-option / ipv6-locator-option 2019 objective-flags = uint .bits objective-flag 2021 objective-flag = &( 2022 F_DISC: 0 ; valid for discovery only 2023 F_NEG: 1 ; valid for discovery and negotiation 2024 F_SYNCH: 2 ; valid for discovery and synchronization 2025 ) 2027 objective = [objective-name, objective-flags, loop-count, ?any] 2029 objective-name = text ;see specification for uniqueness rules 2030 loop-count = 0..255 2032 ; Constants for message types and option types 2034 M_NOOP = 0 2035 M_DISCOVERY = 1 2036 M_RESPONSE = 2 2037 M_REQUEST = 3 2038 M_NEGOTIATE = 4 2039 M_END = 5 2040 M_WAIT = 6 2041 M_SYNCH = 7 2042 M_FLOOD = 8 2044 O_DIVERT = 100 2045 O_ACCEPT = 101 2046 O_DECLINE = 102 2047 O_FQDN_LOCATOR = 103 2048 O_URI_LOCATOR = 104 2049 O_DEVICE_ID = 105 2051 2053 7. IANA Considerations 2055 This document defines the General Discovery and Negotiation Protocol 2056 (GRASP). 2058 Section 3.5 explains the following link-local multicast addresses, 2059 which IANA is requested to assign for use by GRASP: 2061 ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in 2062 the IPv6 Link-Local Scope Multicast Addresses registry. 2064 ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in 2065 the IPv4 Multicast Local Network Control Block. 2067 Section 3.5 explains the following UDP and TCP port, which IANA is 2068 requested to assign for use by GRASP: 2070 GRASP_LISTEN_PORT: (TBD3) 2072 The IANA is requested to create a GRASP Parameter Registry including 2073 two registry tables. These are the GRASP Messages and Options 2074 Table and the GRASP Objective Names Table. 2076 GRASP Messages and Options Table. The values in this table are names 2077 paired with decimal integers. Future values MUST be assigned using 2078 the Standards Action policy defined by [RFC5226]. The following 2079 initial values are assigned by this document: 2081 M_NOOP = 0 2082 M_DISCOVERY = 1 2083 M_RESPONSE = 2 2084 M_REQUEST = 3 2085 M_NEGOTIATE = 4 2086 M_END = 5 2087 M_WAIT = 6 2089 O_DIVERT = 100 2090 O_ACCEPT = 101 2091 O_DECLINE = 102 2092 O_FQDN_LOCATOR = 103 2093 O_URI_LOCATOR = 104 2094 O_DEVICE_ID = 105 2096 GRASP Objective Names Table. The values in this table are UTF-8 2097 strings. Future values MUST be assigned using the Specification 2098 Required policy defined by [RFC5226]. The following initial values 2099 are assigned by this document: 2101 EX0 2102 EX1 2103 EX2 2104 EX3 2105 EX4 2106 EX5 2107 EX6 2108 EX7 2109 EX8 2110 EX9 2112 8. Acknowledgements 2114 A major contribution to the original version of this document was 2115 made by Sheng Jiang. 2117 Valuable comments were received from Michael Behringer, Jeferson 2118 Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Halpern, 2119 Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, 2120 Michael Richardson, Markus Stenberg, Rene Struik, Dacheng Zhang, and 2121 other participants in the NMRG research group and the ANIMA working 2122 group. 2124 This document was produced using the xml2rfc tool [RFC2629]. 2126 9. Change log [RFC Editor: Please remove] 2128 draft-ietf-anima-grasp-02, 2016-01-13: 2130 Resolved numerous issues according to WG discussions. 2132 Renumbered requirements, added D9. 2134 Protocol change: only allow one objective in rapid mode. 2136 Protocol change: added optional error string to DECLINE option. 2138 Protocol change: removed statement that seemed to say that a Request 2139 not preceded by a Discovery should cause a Discovery response. That 2140 made no sense, because there is no way the initiator would know where 2141 to send the Request. 2143 Protocol change: Removed PEN option from vendor objectives, changed 2144 naming rule accordingly. 2146 Protocol change: Added FLOOD message to simplify coding. 2148 Protocol change: Added SYNCH message to simplify coding. 2150 Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD 2151 messages. But also allowed the relay process for DISCOVER and FLOOD 2152 to regenerate a Session ID. 2154 Protocol change: Require that discovered addresses must be global 2155 (except during bootstrap). 2157 Protocol change: Receiver of REQUEST message must close socket if no 2158 ASA is listening for the objective. 2160 Protocol change: Simplified Waiting message. 2162 Protocol change: Added No Operation message. 2164 Renamed URL locator type as URI locator type. 2166 Updated CDDL definition. 2168 Various other clarifications and editorial fixes. 2170 draft-ietf-anima-grasp-01, 2015-10-09: 2172 Updated requirements after list discussion. 2174 Changed from TLV to CBOR format - many detailed changes, added co- 2175 author. 2177 Tightened up loop count and timeouts for various cases. 2179 Noted that GRASP does not provide transactional integrity. 2181 Various other clarifications and editorial fixes. 2183 draft-ietf-anima-grasp-00, 2015-08-14: 2185 File name and protocol name changed following WG adoption. 2187 Added URL locator type. 2189 draft-carpenter-anima-gdn-protocol-04, 2015-06-21: 2191 Tuned wording around hierarchical structure. 2193 Changed "device" to "ASA" in many places. 2195 Reformulated requirements to be clear that the ASA is the main 2196 customer for signaling. 2198 Added requirement for flooding unsolicited synch, and added it to 2199 protocol spec. Recognized DNCP as alternative for flooding synch 2200 data. 2202 Requirements clarified, expanded and rearranged following design team 2203 discussion. 2205 Clarified that GDNP discovery must not be a prerequisite for GDNP 2206 negotiation or synchronization (resolved issue 13). 2208 Specified flag bits for objective options (resolved issue 15). 2210 Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 2211 9,10,11). 2213 Updated DNCP description from latest DNCP draft. 2215 Editorial improvements. 2217 draft-carpenter-anima-gdn-protocol-03, 2015-04-20: 2219 Removed intrinsic security, required external security 2220 Format changes to allow DNCP co-existence 2222 Recognized DNS-SD as alternative discovery method. 2224 Editorial improvements 2226 draft-carpenter-anima-gdn-protocol-02, 2015-02-19: 2228 Tuned requirements to clarify scope, 2230 Clarified relationship between types of objective, 2232 Clarified that objectives may be simple values or complex data 2233 structures, 2235 Improved description of objective options, 2237 Added loop-avoidance mechanisms (loop count and default timeout, 2238 limitations on discovery relaying and on unsolicited responses), 2240 Allow multiple discovery objectives in one response, 2242 Provided for missing or multiple discovery responses, 2244 Indicated how modes such as "dry run" should be supported, 2246 Minor editorial and technical corrections and clarifications, 2248 Reorganized future work list. 2250 draft-carpenter-anima-gdn-protocol-01, restructured the logical flow 2251 of the document, updated to describe synchronization completely, add 2252 unsolicited responses, numerous corrections and clarifications, 2253 expanded future work list, 2015-01-06. 2255 draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- 2256 config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 2257 02, 2014-10-08. 2259 10. References 2261 10.1. Normative References 2263 [I-D.greevenbosch-appsawg-cbor-cddl] 2264 Vigano, C. and H. Birkholz, "CBOR data definition language 2265 (CDDL): a notational convention to express CBOR data 2266 structures", draft-greevenbosch-appsawg-cbor-cddl-07 (work 2267 in progress), October 2015. 2269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2270 Requirement Levels", BCP 14, RFC 2119, 2271 DOI 10.17487/RFC2119, March 1997, 2272 . 2274 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2275 Resource Identifier (URI): Generic Syntax", STD 66, 2276 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2277 . 2279 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2280 "Randomness Requirements for Security", BCP 106, RFC 4086, 2281 DOI 10.17487/RFC4086, June 2005, 2282 . 2284 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2285 (TLS) Protocol Version 1.2", RFC 5246, 2286 DOI 10.17487/RFC5246, August 2008, 2287 . 2289 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2290 Housley, R., and W. Polk, "Internet X.509 Public Key 2291 Infrastructure Certificate and Certificate Revocation List 2292 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2293 . 2295 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2296 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2297 January 2012, . 2299 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2300 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2301 October 2013, . 2303 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2304 Interface Identifiers with IPv6 Stateless Address 2305 Autoconfiguration (SLAAC)", RFC 7217, 2306 DOI 10.17487/RFC7217, April 2014, 2307 . 2309 10.2. Informative References 2311 [I-D.behringer-anima-reference-model] 2312 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 2313 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 2314 for Autonomic Networking", draft-behringer-anima- 2315 reference-model-04 (work in progress), October 2015. 2317 [I-D.chaparadza-intarea-igcp] 2318 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 2319 Mahkonen, "IP based Generic Control Protocol (IGCP)", 2320 draft-chaparadza-intarea-igcp-00 (work in progress), July 2321 2011. 2323 [I-D.eckert-anima-stable-connectivity] 2324 Eckert, T. and M. Behringer, "Using Autonomic Control 2325 Plane for Stable Connectivity of Network OAM", draft- 2326 eckert-anima-stable-connectivity-02 (work in progress), 2327 October 2015. 2329 [I-D.ietf-anima-autonomic-control-plane] 2330 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 2331 Autonomic Control Plane", draft-ietf-anima-autonomic- 2332 control-plane-01 (work in progress), October 2015. 2334 [I-D.ietf-anima-bootstrapping-keyinfra] 2335 Pritikin, M., Richardson, M., Behringer, M., and S. 2336 Bjarnason, "Bootstrapping Key Infrastructures", draft- 2337 ietf-anima-bootstrapping-keyinfra-01 (work in progress), 2338 October 2015. 2340 [I-D.ietf-homenet-dncp] 2341 Stenberg, M. and S. Barth, "Distributed Node Consensus 2342 Protocol", draft-ietf-homenet-dncp-12 (work in progress), 2343 November 2015. 2345 [I-D.ietf-homenet-hncp] 2346 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2347 Control Protocol", draft-ietf-homenet-hncp-10 (work in 2348 progress), November 2015. 2350 [I-D.ietf-netconf-restconf] 2351 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2352 Protocol", draft-ietf-netconf-restconf-09 (work in 2353 progress), December 2015. 2355 [I-D.liang-iana-pen] 2356 Liang, P., Melnikov, A., and D. Conrad, "Private 2357 Enterprise Number (PEN) practices and Internet Assigned 2358 Numbers Authority (IANA) registration considerations", 2359 draft-liang-iana-pen-06 (work in progress), July 2015. 2361 [I-D.stenberg-anima-adncp] 2362 Stenberg, M., "Autonomic Distributed Node Consensus 2363 Protocol", draft-stenberg-anima-adncp-00 (work in 2364 progress), March 2015. 2366 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2367 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2368 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2369 September 1997, . 2371 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 2372 "Service Location Protocol, Version 2", RFC 2608, 2373 DOI 10.17487/RFC2608, June 1999, 2374 . 2376 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2377 DOI 10.17487/RFC2629, June 1999, 2378 . 2380 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2381 "Remote Authentication Dial In User Service (RADIUS)", 2382 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2383 . 2385 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2386 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2387 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2388 . 2390 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2391 C., and M. Carney, "Dynamic Host Configuration Protocol 2392 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2393 2003, . 2395 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 2396 for the Simple Network Management Protocol (SNMP)", 2397 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 2398 . 2400 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2401 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2402 DOI 10.17487/RFC4861, September 2007, 2403 . 2405 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2406 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2407 DOI 10.17487/RFC5226, May 2008, 2408 . 2410 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2411 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2412 October 2010, . 2414 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 2415 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 2416 March 2011, . 2418 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2419 and A. Bierman, Ed., "Network Configuration Protocol 2420 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2421 . 2423 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2424 Ed., "Diameter Base Protocol", RFC 6733, 2425 DOI 10.17487/RFC6733, October 2012, 2426 . 2428 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2429 DOI 10.17487/RFC6762, February 2013, 2430 . 2432 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2433 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2434 . 2436 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2437 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2438 DOI 10.17487/RFC6887, April 2013, 2439 . 2441 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2442 Constrained-Node Networks", RFC 7228, 2443 DOI 10.17487/RFC7228, May 2014, 2444 . 2446 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 2447 "Requirements for Scalable DNS-Based Service Discovery 2448 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 2449 DOI 10.17487/RFC7558, July 2015, 2450 . 2452 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2453 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2454 Networking: Definitions and Design Goals", RFC 7575, 2455 DOI 10.17487/RFC7575, June 2015, 2456 . 2458 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 2459 Analysis for Autonomic Networking", RFC 7576, 2460 DOI 10.17487/RFC7576, June 2015, 2461 . 2463 Appendix A. Capability Analysis of Current Protocols 2465 This appendix discusses various existing protocols with properties 2466 related to the above negotiation and synchronisation requirements. 2467 The purpose is to evaluate whether any existing protocol, or a simple 2468 combination of existing protocols, can meet those requirements. 2470 Numerous protocols include some form of discovery, but these all 2471 appear to be very specific in their applicability. Service Location 2472 Protocol (SLP) [RFC2608] provides service discovery for managed 2473 networks, but requires configuration of its own servers. DNS-SD 2474 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 2475 small networks with a single link layer. [RFC7558] aims to extend 2476 this to larger autonomous networks but this is not yet standardized. 2477 However, both SLP and DNS-SD appear to target primarily application 2478 layer services, not the layer 2 and 3 objectives relevant to basic 2479 network configuration. Both SLP and DNS-SD are text-based protocols. 2481 Routing protocols are mainly one-way information announcements. The 2482 receiver makes independent decisions based on the received 2483 information and there is no direct feedback information to the 2484 announcing peer. This remains true even though the protocol is used 2485 in both directions between peer routers; there is state 2486 synchronization, but no negotiation, and each peer runs its route 2487 calculations independently. 2489 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 2490 response model not well suited for peer negotiation. Network 2491 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 2492 does allow positive or negative responses from the target system, but 2493 this is still not adequate for negotiation. 2495 There are various existing protocols that have elementary negotiation 2496 abilities, such as Dynamic Host Configuration Protocol for IPv6 2497 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 2498 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 2499 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 2500 configuration or management protocols. However, they either provide 2501 only a simple request/response model in a master/slave context or 2502 very limited negotiation abilities. 2504 There are some signaling protocols with an element of negotiation. 2505 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 2506 designed for negotiating quality of service parameters along the path 2507 of a unicast or multicast flow. RSVP is a very specialised protocol 2508 aimed at end-to-end flows. However, it has some flexibility, having 2509 been extended for MPLS label distribution [RFC3209]. A more generic 2510 design is General Internet Signalling Transport (GIST) [RFC5971], but 2511 it is complex, tries to solve many problems, and is also aimed at 2512 per-flow signaling across many hops rather than at device-to-device 2513 signaling. However, we cannot completely exclude extended RSVP or 2514 GIST as a synchronization and negotiation protocol. They do not 2515 appear to be directly useable for peer discovery. 2517 We now consider two protocols that are works in progress at the time 2518 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 2519 protocol intended to convey NETCONF information expressed in the YANG 2520 language via HTTP, including the ability to transit HTML 2521 intermediaries. While this is a powerful approach in the context of 2522 centralised configuration of a complex network, it is not well 2523 adapted to efficient interactive negotiation between peer devices, 2524 especially simple ones that are unlikely to include YANG processing 2525 already. 2527 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 2528 [I-D.ietf-homenet-dncp]. This is defined as a generic form of state 2529 synchronization protocol, with a proposed usage profile being the 2530 Home Networking Control Protocol (HNCP) [I-D.ietf-homenet-hncp] for 2531 configuring Homenet routers. A specific application of DNCP for 2532 autonomic networking was proposed in [I-D.stenberg-anima-adncp]. 2534 DNCP "is designed to provide a way for each participating node to 2535 publish a set of TLV (Type-Length-Value) tuples, and to provide a 2536 shared and common view about the data published... DNCP is most 2537 suitable for data that changes only infrequently... If constant rapid 2538 state changes are needed, the preferable choice is to use an 2539 additional point-to-point channel..." 2541 Specific features of DNCP include: 2543 o Every participating node has a unique node identifier. 2545 o DNCP messages are encoded as a sequence of TLV objects, sent over 2546 unicast UDP or TCP, with or without (D)TLS security. 2548 o Multicast is used only for discovery of DNCP neighbors when lower 2549 security is acceptable. 2551 o Synchronization of state is maintained by a flooding process using 2552 the Trickle algorithm. There is no bilateral synchronization or 2553 negotiation capability. 2555 o The HNCP profile of DNCP is designed to operate between directly 2556 connected neighbors on a shared link using UDP and link-local IPv6 2557 addresses. 2559 DNCP does not meet the needs of a general negotiation protocol, 2560 because it is designed specifically for flooding synchronization. 2561 Also, in its HNCP profile it is limited to link-local messages and to 2562 IPv6. However, at the minimum it is a very interesting test case for 2563 this style of interaction between devices without needing a central 2564 authority, and it is a proven method of network-wide state 2565 synchronization by flooding. 2567 A proposal was made some years ago for an IP based Generic Control 2568 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 2569 information exchange and negotiation but not directly at peer 2570 discovery. However, it has many points in common with the present 2571 work. 2573 None of the above solutions appears to completely meet the needs of 2574 generic discovery, state synchronization and negotiation in a single 2575 solution. Many of the protocols assume that they are working in a 2576 traditional top-down or north-south scenario, rather than a fluid 2577 peer-to-peer scenario. Most of them are specialized in one way or 2578 another. As a result, we have not identified a combination of 2579 existing protocols that meets the requirements in Section 2. Also, 2580 we have not identified a path by which one of the existing protocols 2581 could be extended to meet the requirements. 2583 Authors' Addresses 2585 Carsten Bormann 2586 Universitaet Bremen TZI 2587 Postfach 330440 2588 D-28359 Bremen 2589 Germany 2591 Email: cabo@tzi.org 2593 Brian Carpenter (editor) 2594 Department of Computer Science 2595 University of Auckland 2596 PB 92019 2597 Auckland 1142 2598 New Zealand 2600 Email: brian.e.carpenter@gmail.com 2601 Bing Liu (editor) 2602 Huawei Technologies Co., Ltd 2603 Q14, Huawei Campus 2604 No.156 Beiqing Road 2605 Hai-Dian District, Beijing 100095 2606 P.R. China 2608 Email: leo.liubing@huawei.com