idnits 2.17.1 draft-ietf-anima-grasp-05.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 (May 13, 2016) is 2903 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-08 ** Downref: Normative reference to an Informational draft: draft-greevenbosch-appsawg-cbor-cddl (ref. 'I-D.greevenbosch-appsawg-cbor-cddl') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-02 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-02 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-01 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-00 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-13 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track B. Carpenter, Ed. 5 Expires: November 14, 2016 Univ. of Auckland 6 B. Liu, Ed. 7 Huawei Technologies Co., Ltd 8 May 13, 2016 10 A Generic Autonomic Signaling Protocol (GRASP) 11 draft-ietf-anima-grasp-05 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 November 14, 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 . . . . . . . . . . . . . . . 5 62 2.2. Requirements for Synchronization and Negotiation 63 Capability . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Specific Technical Requirements . . . . . . . . . . . . . 9 65 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10 66 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . 17 72 3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 19 73 3.3.5. Synchronization and Flooding Procedure . . . . . . . 21 74 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 22 75 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 23 76 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 23 77 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 24 78 3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 24 79 3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 24 80 3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 25 81 3.7.4. Discovery Response Message . . . . . . . . . . . . . 26 82 3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 27 83 3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 27 84 3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 28 85 3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 28 86 3.7.9. Synchronization Message . . . . . . . . . . . . . . . 28 87 3.7.10. Flood Synchronization Message . . . . . . . . . . . . 29 88 3.7.11. No Operation Message . . . . . . . . . . . . . . . . 29 89 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 29 90 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 29 91 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 30 92 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 30 93 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 30 94 3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 31 95 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 33 96 3.9.1. Format of Objective Options . . . . . . . . . . . . . 33 97 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 34 98 3.9.3. General Considerations for Objective Options . . . . 34 99 3.9.4. Organizing of Objective Options . . . . . . . . . . . 35 100 3.9.5. Experimental and Example Objective Options . . . . . 36 101 4. Implementation Status [RFC Editor: please remove] . . . . . . 36 102 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 36 103 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 37 104 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 105 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 40 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 109 9.1. Normative References . . . . . . . . . . . . . . . . . . 44 110 9.2. Informative References . . . . . . . . . . . . . . . . . 45 111 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 48 112 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 48 113 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 55 114 Appendix D. Capability Analysis of Current Protocols . . . . . . 58 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 117 1. Introduction 119 The success of the Internet has made IP-based networks bigger and 120 more complicated. Large-scale ISP and enterprise networks have 121 become more and more problematic for human based management. Also, 122 operational costs are growing quickly. Consequently, there are 123 increased requirements for autonomic behavior in the networks. 124 General aspects of autonomic networks are discussed in [RFC7575] and 125 [RFC7576]. 127 One approach is to largely decentralize the logic of network 128 management by migrating it into network elements. A reference model 129 for autonomic networking on this basis is given in 130 [I-D.ietf-anima-reference-model]. In order to fulfil autonomy, 131 devices that embody autonomic service agents have specific signaling 132 requirements. In particular they need to discover each other, to 133 synchronize state with each other, and to negotiate parameters and 134 resources directly with each other. There is no restriction on the 135 type of parameters and resources concerned, which include very basic 136 information needed for addressing and routing, as well as anything 137 else that might be configured in a conventional non-autonomic 138 network. The atomic unit of synchronization or negotiation is 139 referred to as a technical objective, i.e, a configurable parameter 140 or set of parameters (defined more precisely in Section 3.1). 142 Following this Introduction, Section 2 describes the requirements for 143 discovery, synchronization and negotiation. Negotiation is an 144 iterative process, requiring multiple message exchanges forming a 145 closed loop between the negotiating devices. State synchronization, 146 when needed, can be regarded as a special case of negotiation, 147 without iteration. Section 3.2 describes a behavior model for a 148 protocol intended to support discovery, synchronization and 149 negotiation. The design of GeneRic Autonomic Signaling Protocol 150 (GRASP) in Section 3 of this document is mainly based on this 151 behavior model. The relevant capabilities of various existing 152 protocols are reviewed in Appendix D. 154 The proposed discovery mechanism is oriented towards synchronization 155 and negotiation objectives. It is based on a neighbor discovery 156 process, but also supports diversion to off-link peers. Although 157 many negotiations will occur between horizontally distributed peers, 158 many target scenarios are hierarchical networks, which is the 159 predominant structure of current large-scale managed networks. 160 However, when a device starts up with no pre-configuration, it has no 161 knowledge of the topology. The protocol itself is capable of being 162 used in a small and/or flat network structure such as a small office 163 or home network as well as a professionally managed network. 164 Therefore, the discovery mechanism needs to be able to allow a device 165 to bootstrap itself without making any prior assumptions about 166 network structure. 168 Because GRASP can be used to perform a decision process among 169 distributed devices or between networks, it must run in a secure and 170 strongly authenticated environment. 172 It is understood that in realistic deployments, not all devices will 173 support GRASP. It is expected that some autonomic service agents 174 will directly manage a group of non-autonomic nodes, and that other 175 non-autonomic nodes will be managed traditionally. Such mixed 176 scenarios are not discussed in this specification. 178 2. Requirement Analysis of Discovery, Synchronization and Negotiation 180 This section discusses the requirements for discovery, negotiation 181 and synchronization capabilities. The primary user of the protocol 182 is an autonomic service agent (ASA), so the requirements are mainly 183 expressed as the features needed by an ASA. A single physical device 184 might contain several ASAs, and a single ASA might manage several 185 technical objectives. 187 Note that requirements for ASAs themselves, such as the processing of 188 Intent [RFC7575] or interfaces for coordination between ASAs are out 189 of scope for the present document. 191 2.1. Requirements for Discovery 193 D1. ASAs may be designed to manage anything, as required in 194 Section 2.2. A basic requirement is therefore that the protocol can 195 represent and discover any kind of technical objective among 196 arbitrary subsets of participating nodes. 198 In an autonomic network we must assume that when a device starts up 199 it has no information about any peer devices, the network structure, 200 or what specific role it must play. The ASA(s) inside the device are 201 in the same situation. In some cases, when a new application session 202 starts up within a device, the device or ASA may again lack 203 information about relevant peers. It might be necessary to set up 204 resources on multiple other devices, coordinated and matched to each 205 other so that there is no wasted resource. Security settings might 206 also need updating to allow for the new device or user. The relevant 207 peers may be different for different technical objectives. Therefore 208 discovery needs to be repeated as often as necessary to find peers 209 capable of acting as counterparts for each objective that a discovery 210 initiator needs to handle. From this background we derive the next 211 three requirements: 213 D2. When an ASA first starts up, it has no knowledge of the specific 214 network to which it is attached. Therefore the discovery process 215 must be able to support any network scenario, assuming only that the 216 device concerned is bootstrapped from factory condition. 218 D3. When an ASA starts up, it must require no information about any 219 peers in order to discover them. 221 D4. If an ASA supports multiple technical objectives, relevant peers 222 may be different for different discovery objectives, so discovery 223 needs to be repeated to find counterparts for each objective. Thus, 224 there must be a mechanism by which an ASA can separately discover 225 peer ASAs for each of the technical objectives that it needs to 226 manage, whenever necessary. 228 D5. Following discovery, an ASA will normally perform negotiation or 229 synchronization for the corresponding objectives. The design should 230 allow for this by associating discovery, negotiation and 231 synchronization objectives. It may provide an optional mechanism to 232 combine discovery and negotiation/synchronization in a single call. 234 D6. Some objectives may only be significant on the local link, but 235 others may be significant across the routed network and require off- 236 link operations. Thus, the relevant peers might be immediate 237 neighbors on the same layer 2 link, or they might be more distant and 238 only accessible via layer 3. The mechanism must therefore provide 239 both on-link and off-link discovery of ASAs supporting specific 240 technical objectives. 242 D7. The discovery process should be flexible enough to allow for 243 special cases, such as the following: 245 o In some networks, as mentioned above, there will be some 246 hierarchical structure, at least for certain synchronization or 247 negotiation objectives, but this is unknown in advance. The 248 discovery protocol must therefore operate regardless of 249 hierarchical structure, which is an attribute of individual 250 technical objectives and not of the autonomic network as a whole. 251 This is part of the more general requirement to discover off-link 252 peers. 254 o During initialisation, a device must be able to establish mutual 255 trust with the rest of the network and join an authentication 256 mechanism. Although this will inevitably start with a discovery 257 action, it is a special case precisely because trust is not yet 258 established. This topic is the subject of 259 [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once 260 trust has been established for a device, all ASAs within the 261 device inherit the device's credentials and are also trusted. 263 o Depending on the type of network involved, discovery of other 264 central functions might be needed, such as the Network Operations 265 Center (NOC) [I-D.ietf-anima-stable-connectivity]. The protocol 266 must be capable of supporting such discovery during 267 initialisation, as well as discovery during ongoing operation. 269 D8. The discovery process must not generate excessive traffic and 270 must take account of sleeping nodes in the case of a constrained-node 271 network [RFC7228]. 273 D9. There must be a mechanism for handling stale discovery results. 275 2.2. Requirements for Synchronization and Negotiation Capability 277 As background, consider the example of routing protocols, the closest 278 approximation to autonomic networking already in widespread use. 279 Routing protocols use a largely autonomic model based on distributed 280 devices that communicate repeatedly with each other. The focus is 281 reachability, so current routing protocols mainly consider simple 282 link status, i.e., up or down, and an underlying assumption is that 283 all nodes need a consistent view of the network topology in order for 284 the routing algorithm to converge. Thus, routing is mainly based on 285 information synchronization between peers, rather than on bi- 286 directional negotiation. Other information, such as latency, 287 congestion, capacity, and particularly unused capacity, would be 288 helpful to get better path selection and utilization rate, but is not 289 normally used in distributed routing algorithms. Additionally, 290 autonomic networks need to be able to manage many more dimensions, 291 such as security settings, power saving, load balancing, etc. Status 292 information and traffic metrics need to be shared between nodes for 293 dynamic adjustment of resources and for monitoring purposes. While 294 this might be achieved by existing protocols when they are available, 295 the new protocol needs to be able to support parameter exchange, 296 including mutual synchronization, even when no negotiation as such is 297 required. In general, these parameters do not apply to all 298 participating nodes, but only to a subset. 300 SN1. A basic requirement for the protocol is therefore the ability 301 to represent, discover, synchronize and negotiate almost any kind of 302 network parameter among arbitrary subsets of participating nodes. 304 SN2. Negotiation is a request/response process that must be 305 guaranteed to terminate (with success or failure) and if necessary it 306 must contain tie-breaking rules for each technical objective that 307 requires them. While these must be defined specifically for each use 308 case, the protocol should have some general mechanisms in support of 309 loop and deadlock prevention, such as hop count limits or timeouts. 311 SN3. Synchronization might concern small groups of nodes or very 312 large groups. Different solutions might be needed at different 313 scales. 315 SN4. To avoid "reinventing the wheel", the protocol should be able 316 to carry the message formats used by existing configuration protocols 317 (such as NETCONF/YANG) in cases where that is convenient. 319 SN5. Human intervention in complex situations is costly and error- 320 prone. Therefore, synchronization or negotiation of parameters 321 without human intervention is desirable whenever the coordination of 322 multiple devices can improve overall network performance. It 323 therefore follows that the protocol, as part of the Autonomic 324 Networking Infrastructure, must be capable of running in any device 325 that would otherwise need human intervention. 327 SN6. Human intervention in large networks is often replaced by use 328 of a top-down network management system (NMS). It therefore follows 329 that the protocol, as part of the Autonomic Networking 330 Infrastructure, must be capable of running in any device that would 331 otherwise be managed by an NMS, and that it can co-exist with an NMS, 332 and with protocols such as SNMP and NETCONF. 334 SN7. Some features are expected to be implemented by individual 335 ASAs, but the protocol must be general enough to allow them: 337 o Dependencies and conflicts: In order to decide a configuration on 338 a given device, the device may need information from neighbors. 339 This can be established through the negotiation procedure, or 340 through synchronization if that is sufficient. However, a given 341 item in a neighbor may depend on other information from its own 342 neighbors, which may need another negotiation or synchronization 343 procedure to obtain or decide. Therefore, there are potential 344 dependencies and conflicts among negotiation or synchronization 345 procedures. Resolving dependencies and conflicts is a matter for 346 the individual ASAs involved. To allow this, there need to be 347 clear boundaries and convergence mechanisms for negotiations. 348 Also some mechanisms are needed to avoid loop dependencies. In 349 such a case, the protocol's role is limited to signaling between 350 ASAs. 352 o Recovery from faults and identification of faulty devices should 353 be as automatic as possible. The protocol's role is limited to 354 the ability to handle discovery, synchronization and negotiation 355 at any time, in case an ASA detects an anomaly such as a 356 negotiation counterpart failing. 358 o Since the goal is to minimize human intervention, it is necessary 359 that the network can in effect "think ahead" before changing its 360 parameters. In other words there must be a possibility of 361 forecasting the effect of a change by a "dry run" mechanism before 362 actually installing the change. This will be an application of 363 the protocol rather than a feature of the protocol itself. 365 o Management logging, monitoring, alerts and tools for intervention 366 are required. However, these can only be features of individual 367 ASAs. Another document [I-D.ietf-anima-stable-connectivity] 368 discusses how such agents may be linked into conventional OAM 369 systems via an Autonomic Control Plane 370 [I-D.ietf-anima-autonomic-control-plane]. 372 SN8. The protocol will be able to deal with a wide variety of 373 technical objectives, covering any type of network parameter. 374 Therefore the protocol will need either an explicit information model 375 describing its messages, or at least a flexible and easily extensible 376 message format. One design consideration is whether to adopt an 377 existing information model or to design a new one. 379 2.3. Specific Technical Requirements 381 T1. It should be convenient for ASA designers to define new 382 technical objectives and for programmers to express them, without 383 excessive impact on run-time efficiency and footprint. In 384 particular, it should be possible for ASAs to be implemented 385 independently of each other as user space programs rather than as 386 kernel code. The classes of device in which the protocol might run 387 is discussed in [I-D.ietf-anima-reference-model]. 389 T2. The protocol should be easily extensible in case the initially 390 defined discovery, synchronization and negotiation mechanisms prove 391 to be insufficient. 393 T3. To be a generic platform, the protocol payload format should be 394 independent of the transport protocol or IP version. In particular, 395 it should be able to run over IPv6 or IPv4. However, some functions, 396 such as multicasting on a link, might need to be IP version 397 dependent. In case of doubt, IPv6 should be preferred. 399 T4. The protocol must be able to access off-link counterparts via 400 routable addresses, i.e., must not be restricted to link-local 401 operation. 403 T5. It must also be possible for an external discovery mechanism to 404 be used, if appropriate for a given technical objective. In other 405 words, GRASP discovery must not be a prerequisite for GRASP 406 negotiation or synchronization; the prerequisite is discovering a 407 peer's locator by any method. 409 T6. ASAs and the signaling protocol need to run asynchronously when 410 wait states occur. 412 T7. Intent: There must be provision for general Intent rules to be 413 applied by all devices in the network (e.g., security rules, prefix 414 length, resource sharing rules). However, Intent distribution might 415 not use the signaling protocol itself, but its design should not 416 exclude such use. 418 T8. Management monitoring, alerts and intervention: Devices should 419 be able to report to a monitoring system. Some events must be able 420 to generate operator alerts and some provision for emergency 421 intervention must be possible (e.g. to freeze synchronization or 422 negotiation in a mis-behaving device). These features might not use 423 the signaling protocol itself, but its design should not exclude such 424 use. 426 T9. The protocol needs to be fully secured against forged messages 427 and man-in-the middle attacks, and secured as much as reasonably 428 possible against denial of service attacks. It needs to be capable 429 of encryption in order to resist unwanted monitoring. However, it is 430 not required that the protocol itself provides these security 431 features; it may depend on an existing secure environment. 433 3. GRASP Protocol Overview 435 3.1. Terminology 437 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 438 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 439 "OPTIONAL" in this document are to be interpreted as described in 440 [RFC2119] when they appear in ALL CAPS. When these words are not in 441 ALL CAPS (such as "should" or "Should"), they have their usual 442 English meanings, and are not to be interpreted as [RFC2119] key 443 words. 445 This document uses terminology defined in [RFC7575]. 447 The following additional terms are used throughout this document: 449 o Autonomic Device: identical to Autonomic Node. 451 o Discovery: a process by which an ASA discovers peers according to 452 a specific discovery objective. The discovery results may be 453 different according to the different discovery objectives. The 454 discovered peers may later be used as negotiation counterparts or 455 as sources of synchronization data. 457 o Negotiation: a process by which two (or more) ASAs interact 458 iteratively to agree on parameter settings that best satisfy the 459 objectives of one or more ASAs. 461 o State Synchronization: a process by which two (or more) ASAs 462 interact to agree on the current state of parameter values stored 463 in each ASA. This is a special case of negotiation in which 464 information is sent but the ASAs do not request their peers to 465 change parameter settings. All other definitions apply to both 466 negotiation and synchronization. 468 o Technical Objective (usually abbreviated as Objective): A 469 technical objective is a configurable parameter or set of 470 parameters of some kind, which occurs in three contexts: 471 Discovery, Negotiation and Synchronization. In the protocol, an 472 objective is represented by an identifier and if relevant a value. 473 Normally, a given objective will occur during discovery and 474 negotiation, or during discovery and synchronization, but not in 475 all three contexts. 477 * One ASA may support multiple independent objectives. 479 * The parameter described by a given objective is naturally based 480 on a specific service or function or action. It may in 481 principle be anything that can be set to a specific logical, 482 numerical or string value, or a more complex data structure, by 483 a network node. That node is generally expected to contain an 484 ASA which may itself manage other nodes. 486 * Discovery Objective: if a node needs to synchronize or 487 negotiate a specific objective but does not know a peer that 488 supports this objective, it starts a discovery process. The 489 objective is called a Discovery Objective during this process. 491 * Synchronization Objective: an objective whose specific 492 technical content needs to be synchronized among two or more 493 ASAs. 495 * Negotiation Objective: an objective whose specific technical 496 content needs to be decided in coordination with another ASA. 498 o Discovery Initiator: an ASA that spontaneously starts discovery by 499 sending a discovery message referring to a specific discovery 500 objective. 502 o Discovery Responder: a peer that either contains an ASA supporting 503 the discovery objective indicated by the discovery initiator, or 504 caches the locator(s) of the ASA(s) supporting the objective. The 505 locator(s) are indicated in a Discovery Response, which is 506 normally sent by the protocol kernel, as described later. 508 o Synchronization Initiator: an ASA that spontaneously starts 509 synchronization by sending a request message referring to a 510 specific synchronization objective. 512 o Synchronization Responder: a peer ASA which responds with the 513 value of a synchronization objective. 515 o Negotiation Initiator: an ASA that spontaneously starts 516 negotiation by sending a request message referring to a specific 517 negotiation objective. 519 o Negotiation Counterpart: a peer with which the Negotiation 520 Initiator negotiates a specific negotiation objective. 522 3.2. High-Level Design Choices 524 This section describes a behavior model and some considerations for 525 designing a generic signaling protocol initially supporting 526 discovery, synchronization and negotiation, which can act as a 527 platform for different technical objectives. 529 o A generic platform 531 The protocol is designed as a generic platform, which is 532 independent from the synchronization or negotiation contents. It 533 takes care of the general intercommunication between counterparts. 534 The technical contents will vary according to the various 535 technical objectives and the different pairs of counterparts. 537 o The protocol is expected to form part of an Autonomic Networking 538 Infrastructure [I-D.ietf-anima-reference-model]. It will provide 539 services to ASAs via a suitable application programming interface, 540 which will reflect the protocol elements but will not necessarily 541 be in one-to-one correspondence to them. It is expected that a 542 single instance of GRASP will exist in an autonomic node, and that 543 the protocol engine and each ASA will run as independent 544 asynchronous processes. 546 o Security infrastructure and trust relationship 548 Because this negotiation protocol may directly cause changes to 549 device configurations and bring significant impacts to a running 550 network, this protocol is assumed to run within an existing secure 551 environment with strong authentication. 553 On the other hand, a limited negotiation model might be deployed 554 based on a limited trust relationship. For example, between two 555 administrative domains, ASAs might also exchange limited 556 information and negotiate some particular configurations based on 557 a limited conventional or contractual trust relationship. 559 o Discovery, synchronization and negotiation are designed together. 561 The discovery method and the synchronization and negotiation 562 methods are designed in the same way and can be combined when this 563 is useful. These processes can also be performed independently 564 when appropriate. 566 * GRASP discovery is always available for efficient discovery of 567 GRASP peers and allows a rapid mode of operation described in 568 Section 3.3.3. For some objectives, especially those concerned 569 with application layer services, another discovery mechanism 570 such as the future DNS Service Discovery [RFC7558] or Service 571 Location Protocol [RFC2608] MAY be used. The choice is left to 572 the designers of individual ASAs. 574 o A uniform pattern for technical contents 576 The synchronization and negotiation contents are defined according 577 to a uniform pattern. They could be carried either in simple 578 binary format or in payloads described by a flexible language. 579 The basic protocol design uses the Concise Binary Object 580 Representation (CBOR) [RFC7049]. The format is extensible for 581 unknown future requirements. 583 o A flexible model for synchronization 585 GRASP supports bilateral synchronization, which could be used to 586 perform synchronization among a small number of nodes. It also 587 supports an unsolicited flooding mode when large groups of nodes, 588 possibly including all autonomic nodes, need data for the same 589 technical objective. 591 * There may be some network parameters for which a more 592 traditional flooding mechanism such as DNCP [RFC7787] is 593 considered more appropriate. GRASP can coexist with DNCP. 595 o A simple initiator/responder model for negotiation 597 Multi-party negotiations are too complicated to be modeled and 598 there might be too many dependencies among the parties to converge 599 efficiently. A simple initiator/responder model is more feasible 600 and can complete multi-party negotiations by indirect steps. 602 o Organizing of synchronization or negotiation content 604 Naturally, the technical content will be organized according to 605 the relevant function or service. The content from different 606 functions or services is kept independent from each other. They 607 are not combined into a single option or single session because 608 these contents may be negotiated or synchronized with different 609 counterparts or may be different in response time. 611 o Self-aware network device 613 Every autonomic device will be pre-loaded with various functions 614 and ASAs and will be aware of its own capabilities, typically 615 decided by the hardware, firmware or pre-installed software. Its 616 exact role may depend on Intent and on the surrounding network 617 behaviors, which may include forwarding behaviors, aggregation 618 properties, topology location, bandwidth, tunnel or translation 619 properties, etc. The surrounding topology will depend on the 620 network planning. Following an initial discovery phase, the 621 device properties and those of its neighbors are the foundation of 622 the synchronization or negotiation behavior of a specific device. 623 A device has no pre-configuration for the particular network in 624 which it is installed. 626 o Requests and responses in negotiation procedures 628 The initiator can negotiate with its relevant negotiation 629 counterpart ASAs, which may be different according to the specific 630 negotiation objective. It can request relevant information from 631 the negotiation counterpart so that it can decide its local 632 configuration to give the most coordinated performance. It can 633 request the negotiation counterpart to make a matching 634 configuration in order to set up a successful communication with 635 it. It can request certain simulation or forecast results by 636 sending some dry run conditions. 638 Beyond the traditional yes/no answer, the responder can reply with 639 a suggested alternative if its answer is 'no'. This would start a 640 bi-directional negotiation ending in a compromise between the two 641 ASAs. 643 o Convergence of negotiation procedures 645 To enable convergence, when a responder makes a suggestion of a 646 changed condition in a negative reply, it should be as close as 647 possible to the original request or previous suggestion. The 648 suggested value of the third or later negotiation steps should be 649 chosen between the suggested values from the last two negotiation 650 steps. In any case there must be a mechanism to guarantee 651 convergence (or failure) in a small number of steps, such as a 652 timeout or maximum number of iterations. 654 * End of negotiation 655 A limited number of rounds, for example three, or a timeout, is 656 needed on each ASA for each negotiation objective. It may be 657 an implementation choice, a pre-configurable parameter, or 658 network Intent. These choices might vary between different 659 types of ASA. Therefore, the definition of each negotiation 660 objective MUST clearly specify this, so that the negotiation 661 can always be terminated properly. 663 * Failed negotiation 665 There must be a well-defined procedure for concluding that a 666 negotiation cannot succeed, and if so deciding what happens 667 next (deadlock resolution, tie-breaking, or revert to best- 668 effort service). Again, this MUST be specified for individual 669 negotiation objectives, as an implementation choice, a pre- 670 configurable parameter, or network Intent. 672 3.3. GRASP Protocol Basic Properties and Mechanisms 674 3.3.1. Required External Security Mechanism 676 The protocol SHOULD run within a secure Autonomic Control Plane (ACP) 677 [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to 678 carry all messages securely, including link-local multicast if 679 possible. A GRASP implementation MUST verify whether the ACP is 680 operational. 682 If there is no ACP, the protocol MUST use another form of strong 683 authentication and SHOULD use a form of strong encryption. TLS 684 [RFC5246] is RECOMMENDED for this purpose, based on a local Public 685 Key Infrastructure (PKI) [RFC5280] managed within the autonomic 686 network itself. The details of such a PKI and how its boundary is 687 established are out of scope for this document. DTLS [RFC6347] MAY 688 be used but since GRASP operations usually involve several messages 689 this is not expected to be advantageous. 691 The ACP, or in its absence the local PKI, sets the boundary within 692 which nodes are trusted as GRASP peers. A GRASP implementation MUST 693 refuse to execute any GRASP functions except discovery if there is 694 neither an operational ACP nor an operational TLS environment. 696 As mentioned in Section 3.2, limited GRASP operations might be 697 performed across an administrative domain boundary by mutual 698 agreement. Such operations MUST be authenticated and SHOULD be 699 encrypted. TLS is RECOMMENDED for this purpose. 701 Link-local multicast is used for discovery messages. Responses to 702 discovery messages MUST be secured, with one exception. 704 The exception is that during initialisation, before a node has joined 705 the applicable trust infrastructure, e.g., 706 [I-D.ietf-anima-bootstrapping-keyinfra], or before the ACP is fully 707 established, it might be impossible to secure messages. Indeed, both 708 the security bootstrap process and the ACP creation process might use 709 insecure GRASP discovery and response messages. Such usage MUST be 710 limited to the strictly necessary minimum. A full analysis of the 711 initialisation process is out of scope for the present document. 713 3.3.2. Transport Layer Usage 715 GRASP discovery and flooding messages are designed for use over link- 716 local multicast UDP. They MUST NOT be fragmented, and therefore MUST 717 NOT exceed the link MTU size. Nothing in principle prevents them 718 from working over some other method of sending packets to all on-link 719 neighbors, but this is out of scope for the present specification. 721 All other GRASP messages are unicast and could in principle run over 722 any transport protocol. An implementation MUST support use of TCP. 723 It MAY support use of another transport protocol. However, GRASP 724 itself does not provide for error detection or retransmission. Use 725 of an unreliable transport protocol is therefore NOT RECOMMENDED. 727 When running within a secure ACP on reliable infrastructure, UDP MAY 728 be used for unicast messages not exceeding the minimum IPv6 path MTU; 729 however, TCP MUST be used for longer messages. In other words, IPv6 730 fragmentation is avoided. If a node receives a UDP message but the 731 reply is too long, it MUST open a TCP connection to the peer for the 732 reply. Note that when the network is under heavy load or in a fault 733 condition, UDP might become unreliable. Since this is when autonomic 734 functions are most necessary, automatic fallback to TCP MUST be 735 implemented. The simplest implementation is therefore to use only 736 TCP. 738 When running without an ACP, TLS MUST be supported and used by 739 default, except for link-local multicast messages. DTLS MAY be 740 supported as an alternative but the details are out of scope for this 741 document. 743 For link-local multicast, the GRASP protocol listens to the GRASP 744 Listen Port (Section 3.5). This port is also used to listen for 745 unicast discovery responses. For unicast transport sessions used for 746 synchronization and negotiation, the ASA concerned listens on its own 747 dynamically assigned port, which is communicated to its peers during 748 discovery. 750 3.3.3. Discovery Mechanism and Procedures 752 o Separated discovery and negotiation mechanisms 754 Although discovery and negotiation or synchronization are 755 defined together in the GRASP, they are separated mechanisms. 756 The discovery process could run independently from the 757 negotiation or synchronization process. Upon receiving a 758 Discovery (Section 3.7.3) message, the recipient node should 759 return a response message in which it either indicates itself 760 as a discovery responder or diverts the initiator towards 761 another more suitable ASA. 763 The discovery action will normally be followed by a negotiation 764 or synchronization action. The discovery results could be 765 utilized by the negotiation protocol to decide which ASA the 766 initiator will negotiate with. 768 The initiator of a discovery action for a given objective need 769 not be capable of supporting that objective for negotiation or 770 as a source for synchronization or flooding. In other words an 771 ASA might perform discovery because it only wishes to receive 772 synchronization data. 774 It is entirely possible to use GRASP discovery without any 775 subsequent negotiation or synchronization action. In this 776 case, the discovered objective is simply used as a name during 777 the discovery process and any subsequent operations between the 778 peers are outside the scope of GRASP. 780 o Discovery Procedures 782 Discovery starts as an on-link operation. The Divert option 783 can tell the discovery initiator to contact an off-link ASA for 784 that discovery objective. Every Discovery message is sent by a 785 discovery initiator via UDP to the ALL_GRASP_NEIGHBOR link- 786 local multicast address (Section 3.5). Every network device 787 that supports GRASP always listens to a well-known UDP port to 788 capture the discovery messages. Because this port is unique in 789 a device, this is a function of the GRASP kernel and not of an 790 individual ASA. As a result, each ASA will need to register 791 the objectives that it supports with the GRASP kernel. 793 If an ASA in a neighbor device supports the requested discovery 794 objective, the device MAY respond to the link-local multicast 795 with a unicast Discovery Response message (Section 3.7.4) with 796 locator option(s). Otherwise, if the neighbor has cached 797 information about an ASA that supports the requested discovery 798 objective (usually because it discovered the same objective 799 before), it SHOULD respond with a Discovery Response message 800 with a Divert option pointing to the appropriate Discovery 801 Responder. 803 If no discovery response is received within a reasonable 804 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), 805 the Discovery message MAY be repeated, with a newly generated 806 Session ID (Section 3.6). An exponential backoff SHOULD be 807 used for subsequent repetitions, in order to mitigate possible 808 denial of service attacks. 810 After a GRASP device successfully discovers a Discovery 811 Responder supporting a specific objective, it MUST cache this 812 information. This cache record MAY be used for future 813 negotiation or synchronization, and SHOULD be passed on when 814 appropriate as a Divert option to another Discovery Initiator. 815 The cache lifetime is an implementation choice that MAY be 816 modified by network Intent. 818 If multiple Discovery Responders are found for the same 819 objective, they SHOULD all be cached, unless this creates a 820 resource shortage. The method of choosing between multiple 821 responders is an implementation choice. This choice MUST be 822 available to each ASA but the GRASP implementation SHOULD 823 provide a default choice. 825 Because Discovery Responders will be cached in a finite cache, 826 they might be deleted at any time. In this case, discovery 827 will need to be repeated. If an ASA exits for any reason, its 828 locator might still be cached for some time, and attempts to 829 connect to it will fail. ASAs need to be robust in these 830 circumstances. 832 A GRASP device with multiple link-layer interfaces (typically a 833 router) MUST support discovery on all interfaces. If it 834 receives a Discovery message on a given interface for a 835 specific objective that it does not support and for which it 836 has not previously cached a Discovery Responder, it MUST relay 837 the query by re-issuing a Discovery message as a link-local 838 multicast on its other interfaces. The relayed discovery 839 message MUST have the same Session ID as the incoming discovery 840 message and MUST be tagged with the IP address of its original 841 initiator. Since the relay device is unaware of the timeout 842 set by the original initiator it SHOULD set a timeout at least 843 equal to GRASP_DEF_TIMEOUT milliseconds. 845 The relaying device MUST decrement the loop count within the 846 objective, and MUST NOT relay the Discovery message if the 847 result is zero. Also, it MUST limit the total rate at which it 848 relays discovery messages to a reasonable value, in order to 849 mitigate possible denial of service attacks. It MUST cache the 850 Session ID value and initiator address of each relayed 851 Discovery message until any Discovery Responses have arrived or 852 the discovery process has timed out. To prevent loops, it MUST 853 NOT relay a Discovery message which carries a given cached 854 Session ID and initiator address more than once. These 855 precautions avoid discovery loops and mitigate potential 856 overload. 858 The discovery results received by the relaying device MUST in 859 turn be sent as a Discovery Response message to the Discovery 860 message that caused the relay action. 862 This relayed discovery mechanism, with caching of the results, 863 should be sufficient to support most network bootstrapping 864 scenarios. 866 o A complete discovery process will start with a multicast on the 867 local link. On-link neighbors supporting the discovery objective 868 will respond directly. A neighbor with multiple interfaces will 869 respond with a cached discovery response if any. If not, it will 870 relay the discovery on its other interfaces, for example reaching 871 a higher-level gateway in a hierarchical network. If a node 872 receiving the relayed discovery supports the discovery objective, 873 it will respond to the relayed discovery. If it has a cached 874 response, it will respond with that. If not, it will repeat the 875 discovery process, which thereby becomes recursive. The loop 876 count and timeout will ensure that the process ends. 878 o Rapid Mode (Discovery/Negotiation binding) 880 A Discovery message MAY include a Negotiation Objective option. 881 This allows a rapid mode of negotiation described in 882 Section 3.3.4. A similar mechanism is defined for 883 synchronization in Section 3.3.5. 885 3.3.4. Negotiation Procedures 887 A negotiation initiator sends a negotiation request to a counterpart 888 ASA, including a specific negotiation objective. It may request the 889 negotiation counterpart to make a specific configuration. 890 Alternatively, it may request a certain simulation or forecast result 891 by sending a dry run configuration. The details, including the 892 distinction between dry run and an actual configuration change, will 893 be defined separately for each type of negotiation objective. 895 If no reply message of any kind is received within a reasonable 896 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 897 negotiation request MAY be repeated, with a newly generated Session 898 ID (Section 3.6). An exponential backoff SHOULD be used for 899 subsequent repetitions. 901 If the counterpart can immediately apply the requested configuration, 902 it will give an immediate positive (accept) answer. This will end 903 the negotiation phase immediately. Otherwise, it will negotiate. It 904 will reply with a proposed alternative configuration that it can 905 apply (typically, a configuration that uses fewer resources than 906 requested by the negotiation initiator). This will start a bi- 907 directional negotiation to reach a compromise between the two ASAs. 909 The negotiation procedure is ended when one of the negotiation peers 910 sends a Negotiation Ending message, which contains an accept or 911 decline option and does not need a response from the negotiation 912 peer. Negotiation may also end in failure (equivalent to a decline) 913 if a timeout is exceeded or a loop count is exceeded. 915 A negotiation procedure concerns one objective and one counterpart. 916 Both the initiator and the counterpart may take part in simultaneous 917 negotiations with various other ASAs, or in simultaneous negotiations 918 about different objectives. Thus, GRASP is expected to be used in a 919 multi-threaded mode. Certain negotiation objectives may have 920 restrictions on multi-threading, for example to avoid over-allocating 921 resources. 923 Some configuration actions, for example wavelength switching in 924 optical networks, might take considerable time to execute. The ASA 925 concerned needs to allow for this by design, but GRASP does allow for 926 a peer to insert latency in a negotiation process if necessary 927 (Section 3.7.8). 929 3.3.4.1. Rapid Mode (Discovery/Negotiation Linkage) 931 A Discovery message MAY include a Negotiation Objective option. In 932 this case the Discovery message also acts as a Request Negotiation 933 message to indicate to the Discovery Responder that it could directly 934 reply to the Discovery Initiator with a Negotiation message for rapid 935 processing, if it could act as the corresponding negotiation 936 counterpart. However, the indication is only advisory not 937 prescriptive. 939 This rapid mode could reduce the interactions between nodes so that a 940 higher efficiency could be achieved. This rapid negotiation function 941 SHOULD be configured off by default and MAY be configured on or off 942 by Intent. 944 3.3.5. Synchronization and Flooding Procedure 946 A synchronization initiator sends a synchronization request to a 947 counterpart, including a specific synchronization objective. The 948 counterpart responds with a Synchronization message (Section 3.7.9) 949 containing the current value of the requested synchronization 950 objective. No further messages are needed. 952 If no reply message of any kind is received within a reasonable 953 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 954 synchronization request MAY be repeated, with a newly generated 955 Session ID (Section 3.6). An exponential backoff SHOULD be used for 956 subsequent repetitions. 958 3.3.5.1. Flooding 960 In the case just described, the message exchange is unicast and 961 concerns only one synchronization objective. For large groups of 962 nodes requiring the same data, synchronization flooding is available. 963 For this, a flooding initiator MAY send an unsolicited Flood 964 Synchronization message containing one or more Synchronization 965 Objective option(s), if and only if the specification of those 966 objectives permits it. This is sent as a multicast message to the 967 ALL_GRASP_NEIGHBOR multicast address (Section 3.5). 969 Every network device that supports GRASP always listens to a well- 970 known UDP port to capture flooding messages. Because this port is 971 unique in a device, this is a function of the GRASP kernel. 973 To ensure that flooding does not result in a loop, the originator of 974 the Flood Synchronization message MUST set the loop count in the 975 objectives to a suitable value (the default is GRASP_DEF_LOOPCT). 976 Also, a suitable mechanism is needed to avoid excessive multicast 977 traffic. This mechanism MUST be defined as part of the specification 978 of the synchronization objective(s) concerned. It might be a simple 979 rate limit or a more complex mechanism such as the Trickle algorithm 980 [RFC6206]. 982 A GRASP device with multiple link-layer interfaces (typically a 983 router) MUST support synchronization flooding on all interfaces. If 984 it receives a multicast Flood Synchronization message on a given 985 interface, it MUST relay it by re-issuing a Flood Synchronization 986 message on its other interfaces. The relayed message MUST have the 987 same Session ID as the incoming message and MUST be tagged with the 988 IP address of its original initiator. 990 The relaying device MUST decrement the loop count within the first 991 objective, and MUST NOT relay the Flood Synchronization message if 992 the result is zero. Also, it MUST limit the total rate at which it 993 relays Flood Synchronization messages to a reasonable value, in order 994 to mitigate possible denial of service attacks. It MUST cache the 995 Session ID value and initiator address of each relayed Flood 996 Synchronization message for a finite time not less than twice 997 GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay 998 a Flood Synchronization message which carries a given cached Session 999 ID and initiator address more than once. These precautions avoid 1000 synchronization loops and mitigate potential overload. 1002 Note that this mechanism is unreliable in the case of sleeping nodes. 1003 Sleeping nodes that require an objective subject to flooding SHOULD 1004 periodically request unicast synchronization for that objective. 1006 The multicast messages for synchronization flooding are subject to 1007 the security rules in Section 3.3.1. In practice this means that 1008 they MUST NOT be transmitted and MUST be ignored on receipt unless 1009 there is an operational ACP. However, because of the security 1010 weakness of link-local multicast (Section 5), synchronization 1011 objectives that are flooded SHOULD NOT contain unencrypted sensitive 1012 information and SHOULD be validated by the recipient ASA. 1014 3.3.5.2. Rapid Mode (Discovery/Synchronization Linkage) 1016 A Discovery message MAY include a Synchronization Objective option. 1017 In this case the Discovery message also acts as a Request 1018 Synchronization message to indicate to the Discovery Responder that 1019 it could directly reply to the Discovery Initiator with a 1020 Synchronization message Section 3.7.9 with synchronization data for 1021 rapid processing, if the discovery target supports the corresponding 1022 synchronization objective. However, the indication is only advisory 1023 not prescriptive. 1025 This rapid mode could reduce the interactions between nodes so that a 1026 higher efficiency could be achieved. This rapid synchronization 1027 function SHOULD be configured off by default and MAY be configured on 1028 or off by Intent. 1030 3.4. High Level Deployment Model 1032 It is expected that a GRASP implementation will reside in an 1033 autonomic node that also contains both the appropriate security 1034 environment (preferably the ACP) and one or more Autonomic Service 1035 Agents (ASAs). In the minimal case of a single-purpose device, these 1036 three components might be fully integrated. A more common model is 1037 expected to be a multi-purpose device capable of containing several 1038 ASAs. In this case it is expected that the ACP, GRASP and the ASAs 1039 will be implemented as separate processes, which are probably multi- 1040 threaded to support asynchronous operation. It is expected that 1041 GRASP will access the ACP by using a typical socket interface. A 1042 well defined Application Programming Interface (API) will be needed 1043 between GRASP and the ASAs. In some implementations, ASAs would run 1044 in user space with a GRASP library providing the API, and this 1045 library would in turn communicate via system calls with core GRASP 1046 functions running in kernel mode. For further details of possible 1047 deployment models, see [I-D.ietf-anima-reference-model]. 1049 3.5. GRASP Constants 1051 o ALL_GRASP_NEIGHBOR 1053 A link-local scope multicast address used by a GRASP-enabled 1054 device to discover GRASP-enabled neighbor (i.e., on-link) devices 1055 . All devices that support GRASP are members of this multicast 1056 group. 1058 * IPv6 multicast address: TBD1 1060 * IPv4 multicast address: TBD2 1062 o GRASP_LISTEN_PORT (TBD3) 1064 A UDP and TCP port that every GRASP-enabled network device always 1065 listens to. 1067 o GRASP_DEF_TIMEOUT (60000 milliseconds) 1069 The default timeout used to determine that a discovery etc. has 1070 failed to complete. 1072 o GRASP_DEF_LOOPCT (6) 1074 The default loop count used to determine that a negotiation has 1075 failed to complete, and to avoid looping messages. 1077 3.6. Session Identifier (Session ID) 1079 This is an up to 24-bit opaque value used to distinguish multiple 1080 sessions between the same two devices. A new Session ID MUST be 1081 generated by the initiator for every new Discovery, Flood 1082 Synchronization or Request message. All responses and follow-up 1083 messages in the same discovery, synchronization or negotiation 1084 procedure MUST carry the same Session ID. 1086 The Session ID SHOULD have a very low collision rate locally. It 1087 MUST be generated by a pseudo-random algorithm using a locally 1088 generated seed which is unlikely to be used by any other device in 1089 the same network [RFC4086]. 1091 However, there is a finite probability that two nodes might generate 1092 the same Session ID value. For that reason, when a Session ID is 1093 communicated via GRASP, the receiving node MUST tag it with the 1094 initiator's IP address to allow disambiguation. Multicast GRASP 1095 messages and their responses, which may be relayed between links, 1096 therefore include a field that carries the initiator's global IP 1097 address. 1099 3.7. GRASP Messages 1101 3.7.1. Message Overview 1103 This section defines the GRASP message format and message types. 1104 Message types not listed here are reserved for future use. 1106 The messages currently defined are: 1108 Discovery and Discovery Response. 1110 Request Negotiation, Negotiation, Confirm Waiting and Negotiation 1111 End. 1113 Request Synchronization, Synchronization, and Flood 1114 Synchronization. 1116 No Operation. 1118 3.7.2. GRASP Message Format 1120 GRASP messages share an identical header format and a variable format 1121 area for options. GRASP message headers and options are transmitted 1122 in Concise Binary Object Representation (CBOR) [RFC7049]. In this 1123 specification, they are described using CBOR data definition language 1124 (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is 1125 used to describe each item in this section. A complete and normative 1126 CDDL specification of GRASP is given in Section 6, including 1127 constants such as message types. 1129 Every GRASP message, except the No Operation message, carries a 1130 Session ID (Section 3.6). Options are then presented serially in the 1131 options field. 1133 In fragmentary CDDL, every GRASP message follows the pattern: 1135 grasp-message = (message .within message-structure) / noop-message 1137 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 1138 *grasp-option] 1140 MESSAGE_TYPE = 1..255 1141 session-id = 0..16777215 ;up to 24 bits 1142 grasp-option = any 1144 The MESSAGE_TYPE indicates the type of the message and thus defines 1145 the expected options. Any options received that are not consistent 1146 with the MESSAGE_TYPE SHOULD be silently discarded. 1148 The No Operation (noop) message is described in Section 3.7.11. 1150 The various MESSAGE_TYPE values are defined in Section 6. 1152 All other message elements are described below and formally defined 1153 in Section 6. 1155 3.7.3. Discovery Message 1157 In fragmentary CDDL, a Discovery message follows the pattern: 1159 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1161 A discovery initiator sends a Discovery message to initiate a 1162 discovery process for a particular objective option. 1164 The discovery initiator sends the Discovery messages via UDP to port 1165 GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast 1166 address. It then listens for unicast TCP responses on the same port, 1167 and stores the discovery results (including responding discovery 1168 objectives and corresponding unicast locators). 1170 The 'initiator' field in the message is a globally unique IP address 1171 of the initiator, for the sole purpose of disambiguating the Session 1172 ID in other nodes. If for some reason the initiator does not have a 1173 globally unique IP address, it MUST use a link-local address for this 1174 purpose that is highly likely to be unique, for example using 1175 [RFC7217]. 1177 A Discovery message MUST include exactly one of the following: 1179 o a discovery objective option (Section 3.9.1). Its loop count MUST 1180 be set to a suitable value to prevent discovery loops (default 1181 value is GRASP_DEF_LOOPCT). 1183 o a negotiation objective option (Section 3.9.1). This is used both 1184 for the purpose of discovery and to indicate to the discovery 1185 target that it MAY directly reply to the discovery initiatior with 1186 a Negotiation message for rapid processing, if it could act as the 1187 corresponding negotiation counterpart. The sender of such a 1188 Discovery message MUST initialize a negotiation timer and loop 1189 count in the same way as a Request Negotiation message 1190 (Section 3.7.5). 1192 o a synchronization objective option (Section 3.9.1). This is used 1193 both for the purpose of discovery and to indicate to the discovery 1194 target that it MAY directly reply to the discovery initiator with 1195 a Synchronization message for rapid processing, if it could act as 1196 the corresponding synchronization counterpart. Its loop count 1197 MUST be set to a suitable value to prevent discovery loops 1198 (default value is GRASP_DEF_LOOPCT). 1200 3.7.4. Discovery Response Message 1202 In fragmentary CDDL, a Discovery Response message follows the 1203 pattern: 1205 response-message = [M_RESPONSE, session-id, initiator, 1206 (+locator-option // divert-option), ?objective)] 1208 A node which receives a Discovery message SHOULD send a Discovery 1209 Response message if and only if it can respond to the discovery. It 1210 MUST contain the same Session ID and initiator as the Discovery 1211 message. It MAY include a copy of the discovery objective from the 1212 Discovery message. It is sent to the sender of the Discovery message 1213 via TCP at the port GRASP_LISTEN_PORT. 1215 If the responding node supports the discovery objective of the 1216 discovery, it MUST include at least one kind of locator option 1217 (Section 3.8.5) to indicate its own location. A sequence of multiple 1218 kinds of locator options (e.g. IP address option and FQDN option) is 1219 also valid. 1221 If the responding node itself does not support the discovery 1222 objective, but it knows the locator of the discovery objective, then 1223 it SHOULD respond to the discovery message with a divert option 1224 (Section 3.8.2) embedding a locator option or a combination of 1225 multiple kinds of locator options which indicate the locator(s) of 1226 the discovery objective. 1228 3.7.5. Request Messages 1230 In fragmentary CDDL, Request Negotiation and Request Synchronization 1231 messages follow the patterns: 1233 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1235 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1237 A negotiation or synchronization requesting node sends the 1238 appropriate Request message to the unicast address (directly stored 1239 or resolved from an FQDN or URI) of the negotiation or 1240 synchronization counterpart, using the appropriate protocol and port 1241 numbers (selected from the discovery results). 1243 A Request message MUST include the relevant objective option. In the 1244 case of Request Negotiation, the objective option MUST include the 1245 requested value. 1247 When an initiator sends a Request Negotiation message, it MUST 1248 initialize a negotiation timer for the new negotiation thread with 1249 the value GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is 1250 modified by a Confirm Waiting message (Section 3.7.8), the initiator 1251 will consider that the negotiation has failed when the timer expires. 1253 When an initiator sends a Request message, it MUST initialize the 1254 loop count of the objective option with a value defined in the 1255 specification of the option or, if no such value is specified, with 1256 GRASP_DEF_LOOPCT. 1258 If a node receives a Request message for an objective for which no 1259 ASA is currently listening, it MUST immediately close the relevant 1260 socket to indicate this to the initiator. 1262 3.7.6. Negotiation Message 1264 In fragmentary CDDL, a Negotiation message follows the pattern: 1266 discovery-message = [M_NEGOTIATE, session-id, objective] 1268 A negotiation counterpart sends a Negotiation message in response to 1269 a Request Negotiation message, a Negotiation message, or a Discovery 1270 message in Rapid Mode. A negotiation process MAY include multiple 1271 steps. 1273 The Negotiation message MUST include the relevant Negotiation 1274 Objective option, with its value updated according to progress in the 1275 negotiation. The sender MUST decrement the loop count by 1. If the 1276 loop count becomes zero the message MUST NOT be sent. In this case 1277 the negotiation session has failed and will time out. 1279 3.7.7. Negotiation End Message 1281 In fragmentary CDDL, a Negotiation End message follows the pattern: 1283 end-message = [M_END, session-id, accept-option / decline-option] 1285 A negotiation counterpart sends an Negotiation End message to close 1286 the negotiation. It MUST contain either an accept or a decline 1287 option, defined in Section 3.8.3 and Section 3.8.4. It could be sent 1288 either by the requesting node or the responding node. 1290 3.7.8. Confirm Waiting Message 1292 In fragmentary CDDL, a Confirm Waiting message follows the pattern: 1294 wait-message = [M_WAIT, session-id, waiting-time] 1295 waiting-time = 0..4294967295 ; in milliseconds 1297 A responding node sends a Confirm Waiting message to ask the 1298 requesting node to wait for a further negotiation response. It might 1299 be that the local process needs more time or that the negotiation 1300 depends on another triggered negotiation. This message MUST NOT 1301 include any other options. When received, the waiting time value 1302 overwrites and restarts the current negotiation timer 1303 (Section 3.7.5). 1305 The responding node SHOULD send a Negotiation, Negotiation End or 1306 another Confirm Waiting message before the negotiation timer expires. 1307 If not, the initiator MUST abandon or restart the negotiation 1308 procedure, to avoid an indefinite wait. 1310 3.7.9. Synchronization Message 1312 In fragmentary CDDL, a Synchronization message follows the pattern: 1314 synch-message = [M_SYNCH, session-id, objective] 1316 A node which receives a Request Synchronization, or a Discovery 1317 message in Rapid Mode, sends back a unicast Synchronization message 1318 with the synchronization data, in the form of a GRASP Option for the 1319 specific synchronization objective present in the Request 1320 Synchronization. 1322 3.7.10. Flood Synchronization Message 1324 In fragmentary CDDL, a Flood Synchronization message follows the 1325 pattern: 1327 flood-message = [M_FLOOD, session-id, initiator, +objective] 1329 A node MAY initiate flooding by sending an unsolicited Flood 1330 Synchronization Message with synchronization data. This MAY be sent 1331 to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance 1332 with the rules in Section 3.3.5. The initiator address is provided 1333 as described for Discovery messages. The synchronization data will 1334 be in the form of GRASP Option(s) for specific synchronization 1335 objective(s). The loop count(s) MUST be set to a suitable value to 1336 prevent flood loops (default value is GRASP_DEF_LOOPCT). 1338 A node that receives a Flood Synchronization message SHOULD cache the 1339 received objectives for use by local ASAs. 1341 3.7.11. No Operation Message 1343 In fragmentary CDDL, a No Operation message follows the pattern: 1345 noop-message = [M_NOOP] 1347 This message MAY be sent by an implementation that for practical 1348 reasons needs to activate a socket. It MUST be silently ignored by a 1349 recipient. 1351 3.8. GRASP Options 1353 This section defines the GRASP options for the negotiation and 1354 synchronization protocol signaling. Additional options may be 1355 defined in the future. 1357 3.8.1. Format of GRASP Options 1359 GRASP options are CBOR objects that MUST start with an unsigned 1360 integer identifying the specific option type carried in this option. 1361 These option types are formally defined in Section 6. Apart from 1362 that the only format requirement is that each option MUST be a well- 1363 formed CBOR object. In general a CBOR array format is RECOMMENDED to 1364 limit overhead. 1366 GRASP options are usually scoped by using encapsulation. However, 1367 this is not a requirement 1369 3.8.2. Divert Option 1371 The Divert option is used to redirect a GRASP request to another 1372 node, which may be more appropriate for the intended negotiation or 1373 synchronization. It may redirect to an entity that is known as a 1374 specific negotiation or synchronization counterpart (on-link or off- 1375 link) or a default gateway. The divert option MUST only be 1376 encapsulated in Discovery Response messages. If found elsewhere, it 1377 SHOULD be silently ignored. 1379 In fragmentary CDDL, the Divert option follows the pattern: 1381 divert-option = [O_DIVERT, +locator-option] 1383 The embedded Locator Option(s) (Section 3.8.5) point to diverted 1384 destination target(s) in response to a Discovery message. 1386 3.8.3. Accept Option 1388 The accept option is used to indicate to the negotiation counterpart 1389 that the proposed negotiation content is accepted. 1391 The accept option MUST only be encapsulated in Negotiation End 1392 messages. If found elsewhere, it SHOULD be silently ignored. 1394 In fragmentary CDDL, the Accept option follows the pattern: 1396 accept-option = [O_ACCEPT] 1398 3.8.4. Decline Option 1400 The decline option is used to indicate to the negotiation counterpart 1401 the proposed negotiation content is declined and end the negotiation 1402 process. 1404 The decline option MUST only be encapsulated in Negotiation End 1405 messages. If found elsewhere, it SHOULD be silently ignored. 1407 In fragmentary CDDL, the Decline option follows the pattern: 1409 decline-option = [O_DECLINE, ?reason] 1410 reason = text ;optional error message 1412 Note: there are scenarios where a negotiation counterpart wants to 1413 decline the proposed negotiation content and continue the negotiation 1414 process. For these scenarios, the negotiation counterpart SHOULD use 1415 a Negotiate message, with either an objective option that contains a 1416 data field set to indicate a meaningless initial value, or a specific 1417 objective option that provides further conditions for convergence. 1419 3.8.5. Locator Options 1421 These locator options are used to present reachability information 1422 for an ASA, a device or an interface. They are Locator IPv6 Address 1423 Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified 1424 Domain Name) Option and URI (Uniform Resource Identifier) Option. 1426 Since ASAs will normally run as independent user programs, locator 1427 options need to indicate the network layer locator plus the transport 1428 protocol and port number for reaching the target. For this reason, 1429 the Locator Options for IP addresses and FQDNs include this 1430 information explicitly. In the case of the URI Option, this 1431 information can be encoded in the URI itself. 1433 Note: It is assumed that all locators are in scope throughout the 1434 GRASP domain. GRASP is not intended to work across disjoint 1435 addressing or naming realms. 1437 3.8.5.1. Locator IPv6 address option 1439 In fragmentary CDDL, the IPv6 address option follows the pattern: 1441 ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address, 1442 transport-proto, port-number] 1443 ipv6-address = bytes .size 16 1445 transport-proto = IPPROTO_TCP / IPPROTO_UDP 1446 IPPROTO_TCP = 6 1447 IPPROTO_UDP = 17 1448 port-number = 0..65535 1450 The content of this option is a binary IPv6 address followed by the 1451 protocol number and port number to be used. 1453 Note 1: The IPv6 address MUST normally have global scope. 1454 Exceptionally, during node bootstrap, a link-local address MAY be 1455 used for specific objectives only. 1457 Note 2: A link-local IPv6 address MUST NOT be used when this option 1458 is included in a Divert option. 1460 3.8.5.2. Locator IPv4 address option 1462 In fragmentary CDDL, the IPv4 address option follows the pattern: 1464 ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address, 1465 transport-proto, port-number] 1466 ipv4-address = bytes .size 4 1468 The content of this option is a binary IPv4 address followed by the 1469 protocol number and port number to be used. 1471 Note: If an operator has internal network address translation for 1472 IPv4, this option MUST NOT be used within the Divert option. 1474 3.8.5.3. Locator FQDN option 1476 In fragmentary CDDL, the FQDN option follows the pattern: 1478 fqdn-locator-option = [O_FQDN_LOCATOR, text, 1479 transport-proto, port-number] 1481 The content of this option is the Fully Qualified Domain Name of the 1482 target followed by the protocol number and port number to be used. 1484 Note 1: Any FQDN which might not be valid throughout the network in 1485 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1486 when this option is used within the Divert option. 1488 Note 2: Normal GRASP operations are not expected to use this option. 1489 It is intended for special purposes such as discovering external 1490 services. 1492 3.8.5.4. Locator URI option 1494 In fragmentary CDDL, the URI option follows the pattern: 1496 uri-locator = [O_URI_LOCATOR, text] 1498 The content of this option is the Uniform Resource Identifier of the 1499 target [RFC3986]. 1501 Note 1: Any URI which might not be valid throughout the network in 1502 question, such as one based on a Multicast DNS name [RFC6762], MUST 1503 NOT be used when this option is used within the Divert option. 1505 Note 2: Normal GRASP operations are not expected to use this option. 1506 It is intended for special purposes such as discovering external 1507 services. 1509 3.9. Objective Options 1511 3.9.1. Format of Objective Options 1513 An objective option is used to identify objectives for the purposes 1514 of discovery, negotiation or synchronization. All objectives MUST be 1515 in the following format, described in fragmentary CDDL: 1517 objective = [objective-name, objective-flags, loop-count, ?any] 1519 objective-name = text 1520 loop-count = 0..255 1522 All objectives are identified by a unique name which is a case- 1523 sensitive UTF-8 string. 1525 The names of generic objectives MUST NOT include a colon (":") and 1526 MUST be registered with IANA (Section 7). 1528 The names of privately defined objectives MUST include at least one 1529 colon (":"). The string preceding the last colon in the name MUST be 1530 globally unique and in some way identify the entity or person 1531 defining the objective. The following three methods MAY be used to 1532 create such a globally unique string: 1534 1. The unique string is a decimal number representing a registered 1535 32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 1536 uniquely identifies the enterprise defining the objective. 1538 2. The unique string is a fully qualified domain name that uniquely 1539 identifies the entity or person defining the objective. 1541 3. The unique string is an email address that uniquely identifies 1542 the entity or person defining the objective. 1544 The GRASP protocol treats the objective name as an opaque string. 1545 For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 1546 and "user@example.org:EX1" would be five different objectives. 1548 The 'objective-flags' field is described below. 1550 The 'loop-count' field is used for terminating negotiation as 1551 described in Section 3.7.6. It is also used for terminating 1552 discovery as described in Section 3.3.3, and for terminating flooding 1553 as described in Section 3.3.5.1. 1555 The 'any' field is to express the actual value of a negotiation or 1556 synchronization objective. Its format is defined in the 1557 specification of the objective and may be a single value or a data 1558 structure of any kind. It is optional because it is optional in a 1559 Discovery or Discovery Response message. 1561 3.9.2. Objective flags 1563 An objective may be relevant for discovery only, for discovery and 1564 negotiation, or for discovery and synchronization. This is expressed 1565 in the objective by logical flags: 1567 objective-flags = uint .bits objective-flag 1568 objective-flag = &( 1569 F_DISC: 0 ; valid for discovery only 1570 F_NEG: 1 ; valid for discovery and negotiation 1571 F_SYNCH: 2 ; valid for discovery and synchronization 1572 ) 1574 3.9.3. General Considerations for Objective Options 1576 As mentioned above, Objective Options MUST be assigned a unique name. 1577 As long as privately defined Objective Options obey the rules above, 1578 this document does not restrict their choice of name, but the entity 1579 or person concerned SHOULD publish the names in use. 1581 All Objective Options MUST respect the CBOR patterns defined above as 1582 "objective" and MUST replace the "any" field with a valid CBOR data 1583 definition for the relevant use case and application. 1585 An Objective Option that contains no additional fields beyond its 1586 "loop-count" can only be a discovery objective and MUST only be used 1587 in Discovery and Discovery Response messages. 1589 The Negotiation Objective Options contain negotiation objectives, 1590 which vary according to different functions/services. They MUST be 1591 carried by Discovery, Request Negotiation or Negotiation messages 1592 only. The negotiation initiator MUST set the initial "loop-count" to 1593 a value specified in the specification of the objective or, if no 1594 such value is specified, to GRASP_DEF_LOOPCT. 1596 For most scenarios, there should be initial values in the negotiation 1597 requests. Consequently, the Negotiation Objective options MUST 1598 always be completely presented in a Request Negotiation message, or 1599 in a Discovery message in rapid mode. If there is no initial value, 1600 the bits in the value field SHOULD all be set to indicate a 1601 meaningless value, unless this is inappropriate for the specific 1602 negotiation objective. 1604 Synchronization Objective Options are similar, but MUST be carried by 1605 Discovery, Discovery Response, Request Synchronization, or Flood 1606 Synchronization messages only. They include value fields only in 1607 Synchronization or Flood Synchronization messages. 1609 3.9.4. Organizing of Objective Options 1611 Generic objective options MUST be specified in documents available to 1612 the public and SHOULD be designed to use either the negotiation or 1613 the synchronization mechanism described above. 1615 As noted earlier, one negotiation objective is handled by each GRASP 1616 negotiation thread. Therefore, a negotiation objective, which is 1617 based on a specific function or action, SHOULD be organized as a 1618 single GRASP option. It is NOT RECOMMENDED to organize multiple 1619 negotiation objectives into a single option, nor to split a single 1620 function or action into multiple negotiation objectives. 1622 It is important to understand that GRASP negotiation does not support 1623 transactional integrity. If transactional integrity is needed for a 1624 specific objective, this must be ensured by the ASA. For example, an 1625 ASA might need to ensure that it only participates in one negotiation 1626 thread at the same time. Such an ASA would need to stop listening 1627 for incoming negotiation requests before generating an outgoing 1628 negotiation request. 1630 A synchronization objective SHOULD be organized as a single GRASP 1631 option. 1633 Some objectives will support more than one operational mode. An 1634 example is a negotiation objective with both a "dry run" mode (where 1635 the negotiation is to find out whether the other end can in fact make 1636 the requested change without problems) and a "live" mode. Such modes 1637 will be defined in the specification of such an objective. These 1638 objectives SHOULD include flags indicating the applicable mode(s). 1640 An objective may have multiple parameters. Parameters can be 1641 categorized into two classes: the obligatory ones presented as fixed 1642 fields; and the optional ones presented in CBOR sub-options or some 1643 other form of data structure embedded in CBOR. The format might be 1644 inherited from an existing management or configuration protocol, the 1645 objective option acting as a carrier for that format. The data 1646 structure might be defined in a formal language, but that is a matter 1647 for the specifications of individual objectives. There are many 1648 candidates, according to the context, such as ABNF, RBNF, XML Schema, 1649 possibly YANG, etc. The GRASP protocol itself is agnostic on these 1650 questions. 1652 It is NOT RECOMMENDED to split parameters in a single objective into 1653 multiple options, unless they have different response periods. An 1654 exception scenario may also be described by split objectives. 1656 All objectives MUST support GRASP discovery. However, as mentioned 1657 in Section 3.2, it is acceptable for an ASA to use an alternative 1658 method of discovery. 1660 Normally, a GRASP objective will refer to specific technical 1661 parameters as explained in Section 3.1. However, it is acceptable to 1662 define an abstract objective for the purpose of managing or 1663 coordinating ASAs. It is also acceptable to define a special-purpose 1664 objective for purposes such as trust bootstrapping or formation of 1665 the ACP. 1667 3.9.5. Experimental and Example Objective Options 1669 The names "EX0" through "EX9" have been reserved for experimental 1670 options. Multiple names have been assigned because a single 1671 experiment may use multiple options simultaneously. These 1672 experimental options are highly likely to have different meanings 1673 when used for different experiments. Therefore, they SHOULD NOT be 1674 used without an explicit human decision and SHOULD NOT be used in 1675 unmanaged networks such as home networks. 1677 These names are also RECOMMENDED for use in documentation examples. 1679 4. Implementation Status [RFC Editor: please remove] 1681 Two prototype implementations of GRASP have been made. 1683 4.1. BUPT C++ Implementation 1685 o Name: BaseNegotiator.cpp, msg.cpp, Client.cpp, Server.cpp 1687 o Description: C++ implementation of GRASP kernel and API 1689 o Maturity: Prototype code, interoperable between Ubuntu. 1691 o Coverage: Corresponds to draft-carpenter-anima-gdn-protocol-03. 1692 Since it was implemented based on the old version draft, the most 1693 significant limitations comparing to current protocol design 1694 include: 1696 * Not support CBOR 1698 * Not support Flooding 1699 * Not support loop avoidance 1701 * only coded for IPv6, any IPv4 is accidental 1703 o Licensing: Huawei License. 1705 o Experience: https://github.com/liubingpang/IETF-Anima-Signaling- 1706 Protocol/blob/master/README.md 1708 o Contact: https://github.com/liubingpang/IETF-Anima-Signaling- 1709 Protocol 1711 4.2. Python Implementation 1713 o Name: graspy 1715 o Description: Python 3 implementation of GRASP kernel and API. 1717 o Maturity: Prototype code, interoperable between Windows 7 and 1718 Debian. 1720 o Coverage: Corresponds to draft-ietf-anima-grasp-05. Limitations 1721 include: 1723 * insecure: uses a dummy ACP module and does not implement TLS 1725 * only coded for IPv6, any IPv4 is accidental 1727 * FQDN and URI locators incompletely supported 1729 * no code for rapid mode 1731 * relay code is lazy (no rate control) 1733 * all unicast transactions use TCP (no unicast UDP) 1735 * optional Objective option in Response messages not implemented 1737 * workarounds for defects in Python socket module and Windows 1738 socket peculiarities 1740 o Licensing: Simplified BSD 1742 o Experience: https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf 1744 o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ 1746 5. Security Considerations 1748 It is obvious that a successful attack on negotiation-enabled nodes 1749 would be extremely harmful, as such nodes might end up with a 1750 completely undesirable configuration that would also adversely affect 1751 their peers. GRASP nodes and messages therefore require full 1752 protection. 1754 - Authentication 1756 A cryptographically authenticated identity for each device is 1757 needed in an autonomic network. It is not safe to assume that a 1758 large network is physically secured against interference or that 1759 all personnel are trustworthy. Each autonomic node MUST be 1760 capable of proving its identity and authenticating its messages. 1761 GRASP relies on a separate external certificate-based security 1762 mechanism to support authentication, data integrity protection, 1763 and anti-replay protection. 1765 Since GRASP is intended to be deployed in a single administrative 1766 domain operating its own trust anchor and CA, there is no need for 1767 a trusted public third party. In a network requiring "air gap" 1768 security, such a dependency would be unacceptable. 1770 If GRASP is used temporarily without an external security 1771 mechanism, for example during system bootstrap (Section 3.3.1), 1772 the Session ID (Section 3.6) will act as a nonce to provide 1773 limited protection against third parties injecting responses. A 1774 full analysis of the secure bootstrap process is out of scope for 1775 the present document. 1777 - Authorization and Roles 1779 The GRASP protocol is agnostic about the role of individual ASAs 1780 and about which objectives a particular ASA is authorized to 1781 support. It SHOULD apply obvious precautions such as allowing 1782 only one ASA in a given node to modify a given objective, but 1783 otherwise authorization is out of scope. 1785 - Privacy and confidentiality 1787 Generally speaking, no personal information is expected to be 1788 involved in the signaling protocol, so there should be no direct 1789 impact on personal privacy. Nevertheless, traffic flow paths, 1790 VPNs, etc. could be negotiated, which could be of interest for 1791 traffic analysis. Also, operators generally want to conceal 1792 details of their network topology and traffic density from 1793 outsiders. Therefore, since insider attacks cannot be excluded in 1794 a large network, the security mechanism for the protocol MUST 1795 provide message confidentiality. This is why Section 3.3.1 1796 requires either an ACP or the use of TLS. 1798 - Link-local multicast security 1800 GRASP has no reasonable alternative to using link-local multicast 1801 for Discovery or Flood Synchronization messages and these messages 1802 are sent in clear and with no authentication. They are therefore 1803 available to on-link eavesdroppers, and could be forged by on-link 1804 attackers. In the case of Discovery, the Discovery Responses are 1805 unicast and will therefore be protected (Section 3.3.1), and an 1806 untrusted forger will not be able to receive responses. In the 1807 case of Flood Synchronization, an on-link eavesdropper will be 1808 able to receive the flooded objectives but there is no response 1809 message to consider. Some precautions for Flood Synchronization 1810 messages are suggested in Section 3.3.5.1. 1812 - DoS Attack Protection 1814 GRASP discovery partly relies on insecure link-local multicast. 1815 Since routers participating in GRASP sometimes relay discovery 1816 messages from one link to another, this could be a vector for 1817 denial of service attacks. Relevant mitigations are specified in 1818 Section 3.3.3. Additionally, it is of great importance that 1819 firewalls prevent any GRASP messages from entering the domain from 1820 an untrusted source. 1822 - Security during bootstrap and discovery 1824 A node cannot authenticate GRASP traffic from other nodes until it 1825 has identified the trust anchor and can validate certificates for 1826 other nodes. Also, until it has succesfully enrolled 1827 [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that 1828 other nodes are able to authenticate its own traffic. Therefore, 1829 GRASP discovery during the bootstrap phase for a new device will 1830 inevitably be insecure and GRASP synchronization and negotiation 1831 will be impossible until enrollment is complete. 1833 - Security of discovered locators 1835 When GRASP discovery returns an IP address, it MUST be that of a 1836 node within the secure environment (Section 3.3.1). If it returns 1837 an FQDN or a URI, the ASA that receives it MUST NOT assume that 1838 the target of the locator is within the secure environment. 1840 6. CDDL Specification of GRASP 1842 1843 grasp-message = (message .within message-structure) / noop-message 1845 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 1846 *grasp-option] 1848 MESSAGE_TYPE = 0..255 1849 session-id = 0..16777215 ;up to 24 bits 1850 grasp-option = any 1852 message /= discovery-message 1853 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1855 message /= response-message ;response to Discovery 1856 response-message = [M_RESPONSE, session-id, initiator, 1857 (+locator-option // divert-option), ?objective] 1859 message /= synch-message ;response to Synchronization request 1860 synch-message = [M_SYNCH, session-id, objective] 1862 message /= flood-message 1863 flood-message = [M_FLOOD, session-id, initiator, +objective] 1865 message /= request-negotiation-message 1866 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1868 message /= request-synchronization-message 1869 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1871 message /= negotiation-message 1872 negotiation-message = [M_NEGOTIATE, session-id, objective] 1874 message /= end-message 1875 end-message = [M_END, session-id, accept-option / decline-option ] 1877 message /= wait-message 1878 wait-message = [M_WAIT, session-id, waiting-time] 1880 noop-message = [M_NOOP] 1882 divert-option = [O_DIVERT, +locator-option] 1884 accept-option = [O_ACCEPT] 1886 decline-option = [O_DECLINE, ?reason] 1887 reason = text ;optional error message 1888 waiting-time = 0..4294967295 ; in milliseconds 1890 locator-option /= [O_IPv4_LOCATOR, ipv4-address, 1891 transport-proto, port-number] 1892 ipv4-address = bytes .size 4 1894 locator-option /= [O_IPv6_LOCATOR, ipv6-address, 1895 transport-proto, port-number] 1896 ipv6-address = bytes .size 16 1898 locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number] 1900 transport-proto = IPPROTO_TCP / IPPROTO_UDP 1901 IPPROTO_TCP = 6 1902 IPPROTO_UDP = 17 1903 port-number = 0..65535 1905 locator-option /= [O_URI_LOCATOR, text] 1907 initiator = ipv4-address / ipv6-address 1909 objective-flags = uint .bits objective-flag 1911 objective-flag = &( 1912 F_DISC: 0 ; valid for discovery only 1913 F_NEG: 1 ; valid for discovery and negotiation 1914 F_SYNCH: 2) ; valid for discovery and synchronization 1916 objective = [objective-name, objective-flags, loop-count, ?any] 1918 objective-name = text ;see specification for uniqueness rules 1920 loop-count = 0..255 1922 ; Constants for message types and option types 1924 M_NOOP = 0 1925 M_DISCOVERY = 1 1926 M_RESPONSE = 2 1927 M_REQ_NEG = 3 1928 M_REQ_SYN = 4 1929 M_NEGOTIATE = 5 1930 M_END = 6 1931 M_WAIT = 7 1932 M_SYNCH = 8 1933 M_FLOOD = 9 1935 O_DIVERT = 100 1936 O_ACCEPT = 101 1937 O_DECLINE = 102 1938 O_IPv6_LOCATOR = 103 1939 O_IPv4_LOCATOR = 104 1940 O_FQDN_LOCATOR = 105 1941 O_URI_LOCATOR = 106 1942 1944 7. IANA Considerations 1946 This document defines the General Discovery and Negotiation Protocol 1947 (GRASP). 1949 Section 3.5 explains the following link-local multicast addresses, 1950 which IANA is requested to assign for use by GRASP: 1952 ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in 1953 the IPv6 Link-Local Scope Multicast Addresses registry. 1955 ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in 1956 the IPv4 Multicast Local Network Control Block. 1958 Section 3.5 explains the following UDP and TCP port, which IANA is 1959 requested to assign for use by GRASP: 1961 GRASP_LISTEN_PORT: (TBD3) 1963 The IANA is requested to create a GRASP Parameter Registry including 1964 two registry tables. These are the GRASP Messages and Options 1965 Table and the GRASP Objective Names Table. 1967 GRASP Messages and Options Table. The values in this table are names 1968 paired with decimal integers. Future values MUST be assigned using 1969 the Standards Action policy defined by [RFC5226]. The following 1970 initial values are assigned by this document: 1972 M_NOOP = 0 1973 M_DISCOVERY = 1 1974 M_RESPONSE = 2 1975 M_REQ_NEG = 3 1976 M_REQ_SYN = 4 1977 M_NEGOTIATE = 5 1978 M_END = 6 1979 M_WAIT = 7 1980 M_SYNCH = 8 1981 M_FLOOD = 9 1983 O_DIVERT = 100 1984 O_ACCEPT = 101 1985 O_DECLINE = 102 1986 O_IPv6_LOCATOR = 103 1987 O_IPv4_LOCATOR = 104 1988 O_FQDN_LOCATOR = 105 1989 O_URI_LOCATOR = 106 1991 GRASP Objective Names Table. The values in this table are UTF-8 1992 strings. Future values MUST be assigned using the Specification 1993 Required policy defined by [RFC5226]. The following initial values 1994 are assigned by this document: 1996 EX0 1997 EX1 1998 EX2 1999 EX3 2000 EX4 2001 EX5 2002 EX6 2003 EX7 2004 EX8 2005 EX9 2007 8. Acknowledgements 2009 A major contribution to the original version of this document was 2010 made by Sheng Jiang. 2012 Valuable comments were received from Michael Behringer, Jeferson 2013 Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Toerless Eckert, Yu Fu, 2014 Joel Halpern, Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, 2015 Reshad Rahman, Michael Richardson, Markus Stenberg, Rene Struik, 2016 Dacheng Zhang, and other participants in the NMRG research group and 2017 the ANIMA working group. 2019 9. References 2021 9.1. Normative References 2023 [I-D.greevenbosch-appsawg-cbor-cddl] 2024 Vigano, C. and H. Birkholz, "CBOR data definition language 2025 (CDDL): a notational convention to express CBOR data 2026 structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work 2027 in progress), March 2016. 2029 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2030 Requirement Levels", BCP 14, RFC 2119, 2031 DOI 10.17487/RFC2119, March 1997, 2032 . 2034 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2035 Resource Identifier (URI): Generic Syntax", STD 66, 2036 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2037 . 2039 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2040 "Randomness Requirements for Security", BCP 106, RFC 4086, 2041 DOI 10.17487/RFC4086, June 2005, 2042 . 2044 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2045 (TLS) Protocol Version 1.2", RFC 5246, 2046 DOI 10.17487/RFC5246, August 2008, 2047 . 2049 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2050 Housley, R., and W. Polk, "Internet X.509 Public Key 2051 Infrastructure Certificate and Certificate Revocation List 2052 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2053 . 2055 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2056 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2057 January 2012, . 2059 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2060 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2061 October 2013, . 2063 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2064 Interface Identifiers with IPv6 Stateless Address 2065 Autoconfiguration (SLAAC)", RFC 7217, 2066 DOI 10.17487/RFC7217, April 2014, 2067 . 2069 9.2. Informative References 2071 [I-D.chaparadza-intarea-igcp] 2072 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 2073 Mahkonen, "IP based Generic Control Protocol (IGCP)", 2074 draft-chaparadza-intarea-igcp-00 (work in progress), July 2075 2011. 2077 [I-D.ietf-anima-autonomic-control-plane] 2078 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 2079 Autonomic Control Plane", draft-ietf-anima-autonomic- 2080 control-plane-02 (work in progress), March 2016. 2082 [I-D.ietf-anima-bootstrapping-keyinfra] 2083 Pritikin, M., Richardson, M., Behringer, M., and S. 2084 Bjarnason, "Bootstrapping Key Infrastructures", draft- 2085 ietf-anima-bootstrapping-keyinfra-02 (work in progress), 2086 March 2016. 2088 [I-D.ietf-anima-reference-model] 2089 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 2090 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 2091 for Autonomic Networking", draft-ietf-anima-reference- 2092 model-01 (work in progress), March 2016. 2094 [I-D.ietf-anima-stable-connectivity] 2095 Eckert, T. and M. Behringer, "Using Autonomic Control 2096 Plane for Stable Connectivity of Network OAM", draft-ietf- 2097 anima-stable-connectivity-00 (work in progress), January 2098 2016. 2100 [I-D.ietf-netconf-restconf] 2101 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2102 Protocol", draft-ietf-netconf-restconf-13 (work in 2103 progress), April 2016. 2105 [I-D.liang-iana-pen] 2106 Liang, P., Melnikov, A., and D. Conrad, "Private 2107 Enterprise Number (PEN) practices and Internet Assigned 2108 Numbers Authority (IANA) registration considerations", 2109 draft-liang-iana-pen-06 (work in progress), July 2015. 2111 [I-D.stenberg-anima-adncp] 2112 Stenberg, M., "Autonomic Distributed Node Consensus 2113 Protocol", draft-stenberg-anima-adncp-00 (work in 2114 progress), March 2015. 2116 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2117 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2118 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2119 September 1997, . 2121 [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, 2122 "Server Cache Synchronization Protocol (SCSP)", RFC 2334, 2123 DOI 10.17487/RFC2334, April 1998, 2124 . 2126 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 2127 "Service Location Protocol, Version 2", RFC 2608, 2128 DOI 10.17487/RFC2608, June 1999, 2129 . 2131 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2132 "Remote Authentication Dial In User Service (RADIUS)", 2133 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2134 . 2136 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2137 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2138 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2139 . 2141 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2142 C., and M. Carney, "Dynamic Host Configuration Protocol 2143 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2144 2003, . 2146 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 2147 for the Simple Network Management Protocol (SNMP)", 2148 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 2149 . 2151 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2152 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2153 DOI 10.17487/RFC4861, September 2007, 2154 . 2156 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2157 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2158 DOI 10.17487/RFC5226, May 2008, 2159 . 2161 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2162 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2163 October 2010, . 2165 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 2166 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 2167 March 2011, . 2169 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2170 and A. Bierman, Ed., "Network Configuration Protocol 2171 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2172 . 2174 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2175 Ed., "Diameter Base Protocol", RFC 6733, 2176 DOI 10.17487/RFC6733, October 2012, 2177 . 2179 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2180 DOI 10.17487/RFC6762, February 2013, 2181 . 2183 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2184 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2185 . 2187 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2188 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2189 DOI 10.17487/RFC6887, April 2013, 2190 . 2192 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2193 Constrained-Node Networks", RFC 7228, 2194 DOI 10.17487/RFC7228, May 2014, 2195 . 2197 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 2198 "Requirements for Scalable DNS-Based Service Discovery 2199 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 2200 DOI 10.17487/RFC7558, July 2015, 2201 . 2203 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2204 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2205 Networking: Definitions and Design Goals", RFC 7575, 2206 DOI 10.17487/RFC7575, June 2015, 2207 . 2209 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 2210 Analysis for Autonomic Networking", RFC 7576, 2211 DOI 10.17487/RFC7576, June 2015, 2212 . 2214 [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus 2215 Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, 2216 . 2218 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2219 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2220 2016, . 2222 Appendix A. Open Issues 2224 o 7. Cross-check against other ANIMA WG documents for consistency 2225 and gaps. 2227 o 43. Rapid mode synchronization and negotiation is currently 2228 limited to a single objective for simplicity of design and 2229 implementation. A future consideration is to allow multiple 2230 objectives in rapid mode for greater efficiency. 2232 o 48. Should the Appendix "Capability Analysis of Current 2233 Protocols" be deleted before RFC publication? 2235 Appendix B. Closed Issues [RFC Editor: Please remove] 2237 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 2238 as message transport mechanisms. This is not clarified yet. UDP 2239 is good for short conversations, is necessary for multicast 2240 discovery, and generally fits the discovery and divert scenarios 2241 well. However, it will cause problems with large messages. TCP 2242 is good for stable and long sessions, with a little bit of time 2243 consumption during the session establishment stage. If messages 2244 exceed a reasonable MTU, a TCP mode will be required in any case. 2245 This question may be affected by the security discussion. 2247 RESOLVED by specifying UDP for short message and TCP for longer 2248 one. 2250 o 2. DTLS or TLS vs built-in security mechanism. For now, this 2251 specification has chosen a PKI based built-in security mechanism 2252 based on asymmetric cryptography. However, (D)TLS might be chosen 2253 as security solution to avoid duplication of effort. It also 2254 allows essentially similar security for short messages over UDP 2255 and longer ones over TCP. The implementation trade-offs are 2256 different. The current approach requires expensive asymmetric 2257 cryptographic calculations for every message. (D)TLS has startup 2258 overheads but cheaper crypto per message. DTLS is less mature 2259 than TLS. 2261 RESOLVED by specifying external security (ACP or (D)TLS). 2263 o The following open issues applied only if the original security 2264 model was retained: 2266 * 2.1. For replay protection, GRASP currently requires every 2267 participant to have an NTP-synchronized clock. Is this OK for 2268 low-end devices, and how does it work during device 2269 bootstrapping? We could take the Timestamp out of signature 2270 option, to become an independent and OPTIONAL (or RECOMMENDED) 2271 option. 2273 * 2.2. The Signature Option states that this option could be any 2274 place in a message. Wouldn't it be better to specify a 2275 position (such as the end)? That would be much simpler to 2276 implement. 2278 RESOLVED by changing security model. 2280 o 3. DoS Attack Protection needs work. 2282 RESOLVED by adding text. 2284 o 4. Should we consider preferring a text-based approach to 2285 discovery (after the initial discovery needed for bootstrapping)? 2286 This could be a complementary mechanism for multicast based 2287 discovery, especially for a very large autonomic network. 2288 Centralized registration could be automatically deployed 2289 incrementally. At the very first stage, the repository could be 2290 empty; then it could be filled in by the objectives discovered by 2291 different devices (for example using Dynamic DNS Update). The 2292 more records are stored in the repository, the less the multicast- 2293 based discovery is needed. However, if we adopt such a mechanism, 2294 there would be challenges: stateful solution, and security. 2296 RESOLVED for now by adding optional use of DNS-SD by ASAs. 2297 Subsequently removed by editors as irrelevant to GRASP istelf. 2299 o 5. Need to expand description of the minimum requirements for the 2300 specification of an individual discovery, synchronization or 2301 negotiation objective. 2303 RESOLVED for now by extra wording. 2305 o 6. Use case and protocol walkthrough. A description of how a 2306 node starts up, performs discovery, and conducts negotiation and 2307 synchronisation for a sample use case would help readers to 2308 understand the applicability of this specification. Maybe it 2309 should be an artificial use case or maybe a simple real one, based 2310 on a conceptual API. However, the authors have not yet decided 2311 whether to have a separate document or have it in the protocol 2312 document. 2314 RESOLVED: recommend a separate document. 2316 o 8. Consideration of ADNCP proposal. 2318 RESOLVED by adding optional use of DNCP for flooding-type 2319 synchronization. 2321 o 9. Clarify how a GDNP instance knows whether it is running inside 2322 the ACP. (Sheng) 2324 RESOLVED by improved text. 2326 o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. 2327 (Sheng) 2329 RESOLVED by improved text and declaring DTLS out of scope for this 2330 draft. 2332 o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - 2333 Brian] 2335 RESOLVED by improved text. 2337 o 12. Justify that IP address within ACP or (D)TLS environment is 2338 sufficient to prove AN identity; or explain how Device Identity 2339 Option is used. (Sheng) 2341 RESOLVED for now: we assume that all ASAs in a device are trusted 2342 as soon as the device is trusted, so they share credentials. In 2343 that case the Device Identity Option is useless. This needs to be 2344 reviewed later. 2346 o 13. Emphasise that negotiation/synchronization are independent 2347 from discovery, although the rapid discovery mode includes the 2348 first step of a negotiation/synchronization. (Sheng) 2350 RESOLVED by improved text. 2352 o 14. Do we need an unsolicited flooding mechanism for discovery 2353 (for discovery results that everyone needs), to reduce scaling 2354 impact of flooding discovery messages? (Toerless) 2356 RESOLVED: Yes, added to requirements and solution. 2358 o 15. Do we need flag bits in Objective Options to distinguish 2359 distinguish Synchronization and Negotiation "Request" or rapid 2360 mode "Discovery" messages? (Bing) 2362 RESOLVED: yes, work on the API showed that these flags are 2363 essential. 2365 o 16. (Related to issue 14). Should we revive the "unsolicited 2366 Response" for flooding synchronisation data? This has to be done 2367 carefully due to the well-known issues with flooding, but it could 2368 be useful, e.g. for Intent distribution, where DNCP doesn't seem 2369 applicable. 2371 RESOLVED: Yes, see #14. 2373 o 17. Ensure that the discovery mechanism is completely proof 2374 against loops and protected against duplicate responses. 2376 RESOLVED: Added loop count mechanism. 2378 o 18. Discuss the handling of multiple valid discovery responses. 2380 RESOLVED: Stated that the choice must be available to the ASA but 2381 GRASP implementation should pick a default. 2383 o 19. Should we use a text-oriented format such as JSON/CBOR 2384 instead of native binary TLV format? 2386 RESOLVED: Yes, changed to CBOR. 2388 o 20. Is the Divert option needed? If a discovery response 2389 provides a valid IP address or FQDN, the recipient doesn't gain 2390 any extra knowledge from the Divert. On the other hand, the 2391 presence of Divert informs the receiver that the target is off- 2392 link, which might be useful sometimes. 2394 RESOLVED: Decided to keep Divert option. 2396 o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling 2397 Protocol)? 2399 RESOLVED: Yes, name changed. 2401 o 22. Does discovery mechanism scale robustly as needed? Need hop 2402 limit on relaying? 2404 RESOLVED: Added hop limit. 2406 o 23. Need more details on TTL for caching discovery responses. 2408 RESOLVED: Done. 2410 o 24. Do we need "fast withdrawal" of discovery responses? 2412 RESOLVED: This doesn't seem necessary. If an ASA exits or stops 2413 supporting a given objective, peers will fail to start future 2414 sessions and will simply repeat discovery. 2416 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? 2418 RESOLVED: Decided not to consider this further as a GRASP protocol 2419 issue. GRASP objectives could embed DNS-SD formats if needed. 2421 o 26. Add a URL type to the locator options (for security bootstrap 2422 etc.) 2424 RESOLVED: Done, later renamed as URI. 2426 o 27. Security of Flood multicasts (Section 3.3.5.1). 2428 RESOLVED: added text. 2430 o 28. Does ACP support secure link-local multicast? 2432 RESOLVED by new text in the Security Considerations. 2434 o 29. PEN is used to distinguish vendor options. Would it be 2435 better to use a domain name? Anything unique will do. 2437 RESOLVED: Simplified this by removing PEN field and changing 2438 naming rules for objectives. 2440 o 30. Does response to discovery require randomized delays to 2441 mitigate amplification attacks? 2442 RESOLVED: WG feedback is that it's unnecessary. 2444 o 31. We have specified repeats for failed discovery etc. Is that 2445 sufficient to deal with sleeping nodes? 2447 RESOLVED: WG feedback is that it's unnecessary to say more. 2449 o 32. We have one-to-one synchronization and flooding 2450 synchronization. Do we also need selective flooding to a subset 2451 of nodes? 2453 RESOLVED: This will be discussed as a protocol extension in a 2454 separate draft (draft-liu-anima-grasp-distribution). 2456 o 33. Clarify if/when discovery needs to be repeated. 2458 RESOLVED: Done. 2460 o 34. Clarify what is mandatory for running in ACP, expand 2461 discussion of security boundary when running with no ACP - might 2462 rely on the local PKI infrastructure. 2464 RESOLVED: Done. 2466 o 35. State that role-based authorization of ASAs is out of scope 2467 for GRASP. GRASP doesn't recognize/handle any "roles". 2469 RESOLVED: Done. 2471 o 36. Reconsider CBOR definition for PEN syntax. ( objective-name 2472 = text / [pen, text] ; pen = uint ) 2474 RESOLVED: See issue 29. 2476 o 37. Are URI locators really needed? 2478 RESOLVED: Yes, e.g. for security bootstrap discovery, but added 2479 note that addresses are the normal case (same for FQDN locators). 2481 o 38. Is Session ID sufficient to identify relayed responses? 2482 Isn't the originator's address needed too? 2484 RESOLVED: Yes, this is needed for multicast messages and their 2485 responses. 2487 o 39. Clarify that a node will contain one GRASP instance 2488 supporting multiple ASAs. 2490 RESOLVED: Done. 2492 o 40. Add a "reason" code to the DECLINE option? 2494 RESOLVED: Done. 2496 o 41. What happens if an ASA cannot conveniently use one of the 2497 GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) 2498 simply pass the discovery results to the ASA so that it can open 2499 its own socket? 2501 RESOLVED: Both would be possible, but (b) is preferred. 2503 o 42. Do we need a feature whereby an ASA can bypass the ACP and 2504 use the data plane for efficiency/throughput? This would require 2505 discovery to return non-ACP addresses and would evade ACP 2506 security. 2508 RESOLVED: This is considered out of scope for GRASP, but a comment 2509 has been added in security considerations. 2511 o 44. In requirement T9, the words that encryption "may not be 2512 required in all deployments" were removed. Is that OK?. 2514 RESOLVED: No objections. 2516 o 45. Device Identity Option is unused. Can we remove it 2517 completely?. 2519 RESOLVED: No objections. Done. 2521 o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD 2522 messages is intended to assist in loop prevention. However, we 2523 also have the loop count for that. Also, if we create a new 2524 Session ID each time a DISCOVER or FLOOD is relayed, that ID can 2525 be disambiguated by recipients. It would be simpler to remove the 2526 initiator from the messages, making parsing more uniform. Is that 2527 OK? 2529 RESOLVED: Yes. Done. 2531 o 47. REQUEST is a dual purpose message (request negotiation or 2532 request synchronization). Would it be better to split this into 2533 two different messages (and adjust various message names 2534 accordingly)? 2536 RESOLVED: Yes. Done. 2538 Appendix C. Change log [RFC Editor: Please remove] 2540 draft-ietf-anima-grasp-05, 2016-05-13: 2542 Noted in requirement T1 that it should be possible to implement ASAs 2543 independently as user space programs. 2545 Protocol change: Added protocol number and port to discovery 2546 response. Updated protocol description, CDDL and IANA considerations 2547 accordingly. 2549 Clarified that discovery and flood multicasts are handled by the 2550 GRASP kernel, not directly by ASAs. 2552 Clarified that a node may discover an objective without supporting it 2553 for synchronization or negotiation. 2555 Added Implementation Status section. 2557 Added reference to SCSP. 2559 Editorial fixes. 2561 draft-ietf-anima-grasp-04, 2016-03-11: 2563 Protocol change: Restored initiator field in certain messages and 2564 adjusted relaying rules to provide complete loop detection. 2566 Updated IANA Considerations. 2568 draft-ietf-anima-grasp-03, 2016-02-24: 2570 Protocol change: Removed initiator field from certain messages and 2571 adjusted relaying requirement to simplify loop detection. Also 2572 clarified narrative explanation of discovery relaying. 2574 Protocol change: Split Request message into two (Request Negotiation 2575 and Request Synchronization) and updated other message names for 2576 clarity. 2578 Protocol change: Dropped unused Device ID option. 2580 Further clarified text on transport layer usage. 2582 New text about multicast insecurity in Security Considerations. 2584 Various other clarifications and editorial fixes, including moving 2585 some material to Appendix. 2587 draft-ietf-anima-grasp-02, 2016-01-13: 2589 Resolved numerous issues according to WG discussions. 2591 Renumbered requirements, added D9. 2593 Protocol change: only allow one objective in rapid mode. 2595 Protocol change: added optional error string to DECLINE option. 2597 Protocol change: removed statement that seemed to say that a Request 2598 not preceded by a Discovery should cause a Discovery response. That 2599 made no sense, because there is no way the initiator would know where 2600 to send the Request. 2602 Protocol change: Removed PEN option from vendor objectives, changed 2603 naming rule accordingly. 2605 Protocol change: Added FLOOD message to simplify coding. 2607 Protocol change: Added SYNCH message to simplify coding. 2609 Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD 2610 messages. But also allowed the relay process for DISCOVER and FLOOD 2611 to regenerate a Session ID. 2613 Protocol change: Require that discovered addresses must be global 2614 (except during bootstrap). 2616 Protocol change: Receiver of REQUEST message must close socket if no 2617 ASA is listening for the objective. 2619 Protocol change: Simplified Waiting message. 2621 Protocol change: Added No Operation message. 2623 Renamed URL locator type as URI locator type. 2625 Updated CDDL definition. 2627 Various other clarifications and editorial fixes. 2629 draft-ietf-anima-grasp-01, 2015-10-09: 2631 Updated requirements after list discussion. 2633 Changed from TLV to CBOR format - many detailed changes, added co- 2634 author. 2636 Tightened up loop count and timeouts for various cases. 2638 Noted that GRASP does not provide transactional integrity. 2640 Various other clarifications and editorial fixes. 2642 draft-ietf-anima-grasp-00, 2015-08-14: 2644 File name and protocol name changed following WG adoption. 2646 Added URL locator type. 2648 draft-carpenter-anima-gdn-protocol-04, 2015-06-21: 2650 Tuned wording around hierarchical structure. 2652 Changed "device" to "ASA" in many places. 2654 Reformulated requirements to be clear that the ASA is the main 2655 customer for signaling. 2657 Added requirement for flooding unsolicited synch, and added it to 2658 protocol spec. Recognized DNCP as alternative for flooding synch 2659 data. 2661 Requirements clarified, expanded and rearranged following design team 2662 discussion. 2664 Clarified that GDNP discovery must not be a prerequisite for GDNP 2665 negotiation or synchronization (resolved issue 13). 2667 Specified flag bits for objective options (resolved issue 15). 2669 Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 2670 9,10,11). 2672 Updated DNCP description from latest DNCP draft. 2674 Editorial improvements. 2676 draft-carpenter-anima-gdn-protocol-03, 2015-04-20: 2678 Removed intrinsic security, required external security 2680 Format changes to allow DNCP co-existence 2682 Recognized DNS-SD as alternative discovery method. 2684 Editorial improvements 2686 draft-carpenter-anima-gdn-protocol-02, 2015-02-19: 2688 Tuned requirements to clarify scope, 2690 Clarified relationship between types of objective, 2692 Clarified that objectives may be simple values or complex data 2693 structures, 2695 Improved description of objective options, 2697 Added loop-avoidance mechanisms (loop count and default timeout, 2698 limitations on discovery relaying and on unsolicited responses), 2700 Allow multiple discovery objectives in one response, 2702 Provided for missing or multiple discovery responses, 2704 Indicated how modes such as "dry run" should be supported, 2706 Minor editorial and technical corrections and clarifications, 2708 Reorganized future work list. 2710 draft-carpenter-anima-gdn-protocol-01, restructured the logical flow 2711 of the document, updated to describe synchronization completely, add 2712 unsolicited responses, numerous corrections and clarifications, 2713 expanded future work list, 2015-01-06. 2715 draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- 2716 config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 2717 02, 2014-10-08. 2719 Appendix D. Capability Analysis of Current Protocols 2721 This appendix discusses various existing protocols with properties 2722 related to the above negotiation and synchronisation requirements. 2723 The purpose is to evaluate whether any existing protocol, or a simple 2724 combination of existing protocols, can meet those requirements. 2726 Numerous protocols include some form of discovery, but these all 2727 appear to be very specific in their applicability. Service Location 2728 Protocol (SLP) [RFC2608] provides service discovery for managed 2729 networks, but requires configuration of its own servers. DNS-SD 2730 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 2731 small networks with a single link layer. [RFC7558] aims to extend 2732 this to larger autonomous networks but this is not yet standardized. 2733 However, both SLP and DNS-SD appear to target primarily application 2734 layer services, not the layer 2 and 3 objectives relevant to basic 2735 network configuration. Both SLP and DNS-SD are text-based protocols. 2737 Routing protocols are mainly one-way information announcements. The 2738 receiver makes independent decisions based on the received 2739 information and there is no direct feedback information to the 2740 announcing peer. This remains true even though the protocol is used 2741 in both directions between peer routers; there is state 2742 synchronization, but no negotiation, and each peer runs its route 2743 calculations independently. 2745 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 2746 response model not well suited for peer negotiation. Network 2747 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 2748 does allow positive or negative responses from the target system, but 2749 this is still not adequate for negotiation. 2751 There are various existing protocols that have elementary negotiation 2752 abilities, such as Dynamic Host Configuration Protocol for IPv6 2753 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 2754 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 2755 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 2756 configuration or management protocols. However, they either provide 2757 only a simple request/response model in a master/slave context or 2758 very limited negotiation abilities. 2760 There are some signaling protocols with an element of negotiation. 2761 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 2762 designed for negotiating quality of service parameters along the path 2763 of a unicast or multicast flow. RSVP is a very specialised protocol 2764 aimed at end-to-end flows. However, it has some flexibility, having 2765 been extended for MPLS label distribution [RFC3209]. A more generic 2766 design is General Internet Signalling Transport (GIST) [RFC5971], but 2767 it is complex, tries to solve many problems, and is also aimed at 2768 per-flow signaling across many hops rather than at device-to-device 2769 signaling. However, we cannot completely exclude extended RSVP or 2770 GIST as a synchronization and negotiation protocol. They do not 2771 appear to be directly useable for peer discovery. 2773 We now consider two protocols that are works in progress at the time 2774 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 2775 protocol intended to convey NETCONF information expressed in the YANG 2776 language via HTTP, including the ability to transit HTML 2777 intermediaries. While this is a powerful approach in the context of 2778 centralised configuration of a complex network, it is not well 2779 adapted to efficient interactive negotiation between peer devices, 2780 especially simple ones that are unlikely to include YANG processing 2781 already. 2783 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 2784 [RFC7787]. This is defined as a generic form of state 2785 synchronization protocol, with a proposed usage profile being the 2786 Home Networking Control Protocol (HNCP) [RFC7788] for configuring 2787 Homenet routers. A specific application of DNCP for autonomic 2788 networking was proposed in [I-D.stenberg-anima-adncp]. 2790 DNCP "is designed to provide a way for each participating node to 2791 publish a set of TLV (Type-Length-Value) tuples, and to provide a 2792 shared and common view about the data published... DNCP is most 2793 suitable for data that changes only infrequently... If constant rapid 2794 state changes are needed, the preferable choice is to use an 2795 additional point-to-point channel..." 2797 Specific features of DNCP include: 2799 o Every participating node has a unique node identifier. 2801 o DNCP messages are encoded as a sequence of TLV objects, sent over 2802 unicast UDP or TCP, with or without (D)TLS security. 2804 o Multicast is used only for discovery of DNCP neighbors when lower 2805 security is acceptable. 2807 o Synchronization of state is maintained by a flooding process using 2808 the Trickle algorithm. There is no bilateral synchronization or 2809 negotiation capability. 2811 o The HNCP profile of DNCP is designed to operate between directly 2812 connected neighbors on a shared link using UDP and link-local IPv6 2813 addresses. 2815 DNCP does not meet the needs of a general negotiation protocol, 2816 because it is designed specifically for flooding synchronization. 2817 Also, in its HNCP profile it is limited to link-local messages and to 2818 IPv6. However, at the minimum it is a very interesting test case for 2819 this style of interaction between devices without needing a central 2820 authority, and it is a proven method of network-wide state 2821 synchronization by flooding. 2823 The Server Cache Synchronization Protocol (SCSP) [RFC2334] also 2824 describes a method for cache synchronization and cache replication 2825 among a group of nodes. 2827 A proposal was made some years ago for an IP based Generic Control 2828 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 2829 information exchange and negotiation but not directly at peer 2830 discovery. However, it has many points in common with the present 2831 work. 2833 None of the above solutions appears to completely meet the needs of 2834 generic discovery, state synchronization and negotiation in a single 2835 solution. Many of the protocols assume that they are working in a 2836 traditional top-down or north-south scenario, rather than a fluid 2837 peer-to-peer scenario. Most of them are specialized in one way or 2838 another. As a result, we have not identified a combination of 2839 existing protocols that meets the requirements in Section 2. Also, 2840 we have not identified a path by which one of the existing protocols 2841 could be extended to meet the requirements. 2843 Authors' Addresses 2845 Carsten Bormann 2846 Universitaet Bremen TZI 2847 Postfach 330440 2848 D-28359 Bremen 2849 Germany 2851 Email: cabo@tzi.org 2853 Brian Carpenter (editor) 2854 Department of Computer Science 2855 University of Auckland 2856 PB 92019 2857 Auckland 1142 2858 New Zealand 2860 Email: brian.e.carpenter@gmail.com 2862 Bing Liu (editor) 2863 Huawei Technologies Co., Ltd 2864 Q14, Huawei Campus 2865 No.156 Beiqing Road 2866 Hai-Dian District, Beijing 100095 2867 P.R. China 2869 Email: leo.liubing@huawei.com