idnits 2.17.1 draft-ietf-anima-grasp-09.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 (December 15, 2016) is 2687 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) -- Looks like a reference, but probably isn't: '7' on line 3351 -- Looks like a reference, but probably isn't: '13767778' on line 3351 -- Looks like a reference, but probably isn't: '34965' on line 3351 == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-09 ** 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-04 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-02 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-01 == Outdated reference: A later version (-06) exists of draft-liu-anima-grasp-api-02 -- 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 (==), 6 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: June 18, 2017 Univ. of Auckland 6 B. Liu, Ed. 7 Huawei Technologies Co., Ltd 8 December 15, 2016 10 A Generic Autonomic Signaling Protocol (GRASP) 11 draft-ietf-anima-grasp-09 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 June 18, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirement Analysis of Discovery, Synchronization and 60 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Requirements for Discovery . . . . . . . . . . . . . . . 5 62 2.2. Requirements for Synchronization and Negotiation 63 Capability . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Specific Technical Requirements . . . . . . . . . . . . . 9 65 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10 66 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. High Level Deployment Model . . . . . . . . . . . . . . . 12 68 3.3. High Level Design Choices . . . . . . . . . . . . . . . . 13 69 3.4. Quick Operating Overview . . . . . . . . . . . . . . . . 16 70 3.5. GRASP Protocol Basic Properties and Mechanisms . . . . . 16 71 3.5.1. Required External Security Mechanism . . . . . . . . 16 72 3.5.2. Constrained Instances . . . . . . . . . . . . . . . . 17 73 3.5.3. Transport Layer Usage . . . . . . . . . . . . . . . . 19 74 3.5.4. Discovery Mechanism and Procedures . . . . . . . . . 20 75 3.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 23 76 3.5.6. Synchronization and Flooding Procedure . . . . . . . 25 77 3.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 27 78 3.7. Session Identifier (Session ID) . . . . . . . . . . . . . 27 79 3.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 28 80 3.8.1. Message Overview . . . . . . . . . . . . . . . . . . 28 81 3.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 29 82 3.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 29 83 3.8.4. Discovery Message . . . . . . . . . . . . . . . . . . 30 84 3.8.5. Discovery Response Message . . . . . . . . . . . . . 31 85 3.8.6. Request Messages . . . . . . . . . . . . . . . . . . 32 86 3.8.7. Negotiation Message . . . . . . . . . . . . . . . . . 33 87 3.8.8. Negotiation End Message . . . . . . . . . . . . . . . 33 88 3.8.9. Confirm Waiting Message . . . . . . . . . . . . . 33 89 3.8.10. Synchronization Message . . . . . . . . . . . . . . . 34 90 3.8.11. Flood Synchronization Message . . . . . . . . . . . . 34 91 3.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 35 92 3.8.13. No Operation Message . . . . . . . . . . . . . . . . 35 93 3.9. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 36 94 3.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 36 95 3.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 36 96 3.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 36 97 3.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 37 98 3.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 37 99 3.10. Objective Options . . . . . . . . . . . . . . . . . . . . 39 100 3.10.1. Format of Objective Options . . . . . . . . . . . . 39 101 3.10.2. Objective flags . . . . . . . . . . . . . . . . . . 40 102 3.10.3. General Considerations for Objective Options . . . . 41 103 3.10.4. Organizing of Objective Options . . . . . . . . . . 41 104 3.10.5. Experimental and Example Objective Options . . . . . 43 105 4. Implementation Status [RFC Editor: please remove] . . . . . . 43 106 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 43 107 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 44 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 109 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 47 110 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 111 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 113 9.1. Normative References . . . . . . . . . . . . . . . . . . 51 114 9.2. Informative References . . . . . . . . . . . . . . . . . 52 115 Appendix A. Open Issues [RFC Editor: Please remove if empty] . . 55 116 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 55 117 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 63 118 Appendix D. Example Message Formats . . . . . . . . . . . . . . 69 119 D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 69 120 D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 70 121 D.3. Synchronization Example . . . . . . . . . . . . . . . . . 70 122 D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 70 123 D.5. Complete Negotiation Example . . . . . . . . . . . . . . 71 124 Appendix E. Capability Analysis of Current Protocols . . . . . . 72 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 127 1. Introduction 129 The success of the Internet has made IP-based networks bigger and 130 more complicated. Large-scale ISP and enterprise networks have 131 become more and more problematic for human based management. Also, 132 operational costs are growing quickly. Consequently, there are 133 increased requirements for autonomic behavior in the networks. 134 General aspects of autonomic networks are discussed in [RFC7575] and 135 [RFC7576]. 137 One approach is to largely decentralize the logic of network 138 management by migrating it into network elements. A reference model 139 for autonomic networking on this basis is given in 140 [I-D.ietf-anima-reference-model]. The reader should consult this 141 document to understand how various autonomic components fit together. 142 In order to fulfil autonomy, devices that embody Autonomic Service 143 Agents (ASAs, [RFC7575]) have specific signaling requirements. In 144 particular they need to discover each other, to synchronize state 145 with each other, and to negotiate parameters and resources directly 146 with each other. There is no limitation on the types of parameters 147 and resources concerned, which can include very basic information 148 needed for addressing and routing, as well as anything else that 149 might be configured in a conventional non-autonomic network. The 150 atomic unit of discovery, synchronization or negotiation is referred 151 to as a technical objective, i.e, a configurable parameter or set of 152 parameters (defined more precisely in Section 3.1). 154 Following this Introduction, Section 2 describes the requirements for 155 discovery, synchronization and negotiation. Negotiation is an 156 iterative process, requiring multiple message exchanges forming a 157 closed loop between the negotiating entities. In fact, these 158 entities are ASAs, normally but not necessarily in different network 159 devices. State synchronization, when needed, can be regarded as a 160 special case of negotiation, without iteration. Section 3.3 161 describes a behavior model for a protocol intended to support 162 discovery, synchronization and negotiation. The design of GeneRic 163 Autonomic Signaling Protocol (GRASP) in Section 3 of this document is 164 mainly based on this behavior model. The relevant capabilities of 165 various existing protocols are reviewed in Appendix E. 167 The proposed discovery mechanism is oriented towards synchronization 168 and negotiation objectives. It is based on a neighbor discovery 169 process, but also supports diversion to off-link peers. There is no 170 assumption of any particular form of network topology. When a device 171 starts up with no pre-configuration, it has no knowledge of the 172 topology. The protocol itself is capable of being used in a small 173 and/or flat network structure such as a small office or home network 174 as well as a professionally managed network. Therefore, the 175 discovery mechanism needs to be able to allow a device to bootstrap 176 itself without making any prior assumptions about network structure. 178 Because GRASP can be used to perform a decision process among 179 distributed devices or between networks, it must run in a secure and 180 strongly authenticated environment. 182 It is understood that in realistic deployments, not all devices will 183 support GRASP. It is expected that some autonomic service agents 184 will directly manage a group of non-autonomic nodes, and that other 185 non-autonomic nodes will be managed traditionally. Such mixed 186 scenarios are not discussed in this specification. 188 2. Requirement Analysis of Discovery, Synchronization and Negotiation 190 This section discusses the requirements for discovery, negotiation 191 and synchronization capabilities. The primary user of the protocol 192 is an autonomic service agent (ASA), so the requirements are mainly 193 expressed as the features needed by an ASA. A single physical device 194 might contain several ASAs, and a single ASA might manage several 195 technical objectives. If a technical objective is managed by several 196 ASAs, any necessary coordination is outside the scope of the 197 signaling protocol itself. 199 Note that requirements for ASAs themselves, such as the processing of 200 Intent [RFC7575] or interfaces for coordination between ASAs are out 201 of scope for the present document. 203 2.1. Requirements for Discovery 205 D1. ASAs may be designed to manage anything, as required in 206 Section 2.2. A basic requirement is therefore that the protocol can 207 represent and discover any kind of technical objective among 208 arbitrary subsets of participating nodes. 210 In an autonomic network we must assume that when a device starts up 211 it has no information about any peer devices, the network structure, 212 or what specific role it must play. The ASA(s) inside the device are 213 in the same situation. In some cases, when a new application session 214 starts up within a device, the device or ASA may again lack 215 information about relevant peers. For example, it might be necessary 216 to set up resources on multiple other devices, coordinated and 217 matched to each other so that there is no wasted resource. Security 218 settings might also need updating to allow for the new device or 219 user. The relevant peers may be different for different technical 220 objectives. Therefore discovery needs to be repeated as often as 221 necessary to find peers capable of acting as counterparts for each 222 objective that a discovery initiator needs to handle. From this 223 background we derive the next three requirements: 225 D2. When an ASA first starts up, it has no knowledge of the specific 226 network to which it is attached. Therefore the discovery process 227 must be able to support any network scenario, assuming only that the 228 device concerned is bootstrapped from factory condition. 230 D3. When an ASA starts up, it must require no configured location 231 information about any peers in order to discover them. 233 D4. If an ASA supports multiple technical objectives, relevant peers 234 may be different for different discovery objectives, so discovery 235 needs to be performed separately to find counterparts for each 236 objective. Thus, there must be a mechanism by which an ASA can 237 separately discover peer ASAs for each of the technical objectives 238 that it needs to manage, whenever necessary. 240 D5. Following discovery, an ASA will normally perform negotiation or 241 synchronization for the corresponding objectives. The design should 242 allow for this by conveniently linking discovery to negotiation and 243 synchronization. It may provide an optional mechanism to combine 244 discovery and negotiation/synchronization in a single call. 246 D6. Some objectives may only be significant on the local link, but 247 others may be significant across the routed network and require off- 248 link operations. Thus, the relevant peers might be immediate 249 neighbors on the same layer 2 link, or they might be more distant and 250 only accessible via layer 3. The mechanism must therefore provide 251 both on-link and off-link discovery of ASAs supporting specific 252 technical objectives. 254 D7. The discovery process should be flexible enough to allow for 255 special cases, such as the following: 257 o During initialisation, a device must be able to establish mutual 258 trust with the rest of the network and join an authentication 259 mechanism. Although this will inevitably start with a discovery 260 action, it is a special case precisely because trust is not yet 261 established. This topic is the subject of 262 [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once 263 trust has been established for a device, all ASAs within the 264 device inherit the device's credentials and are also trusted. 266 o Depending on the type of network involved, discovery of other 267 central functions might be needed, such as the Network Operations 268 Center (NOC) [I-D.ietf-anima-stable-connectivity]. The protocol 269 must be capable of supporting such discovery during 270 initialisation, as well as discovery during ongoing operation. 272 D8. The discovery process must not generate excessive traffic and 273 must take account of sleeping nodes. 275 D9. There must be a mechanism for handling stale discovery results. 277 2.2. Requirements for Synchronization and Negotiation Capability 279 As background, consider the example of routing protocols, the closest 280 approximation to autonomic networking already in widespread use. 281 Routing protocols use a largely autonomic model based on distributed 282 devices that communicate repeatedly with each other. The focus is 283 reachability, so current routing protocols mainly consider simple 284 link status, i.e., up or down, and an underlying assumption is that 285 all nodes need a consistent view of the network topology in order for 286 the routing algorithm to converge. Thus, routing is mainly based on 287 information synchronization between peers, rather than on bi- 288 directional negotiation. Other information, such as latency, 289 congestion, capacity, and particularly unused capacity, would be 290 helpful to get better path selection and utilization rate, but is not 291 normally used in distributed routing algorithms. Additionally, 292 autonomic networks need to be able to manage many more dimensions, 293 such as security settings, power saving, load balancing, etc. Status 294 information and traffic metrics need to be shared between nodes for 295 dynamic adjustment of resources and for monitoring purposes. While 296 this might be achieved by existing protocols when they are available, 297 the new protocol needs to be able to support parameter exchange, 298 including mutual synchronization, even when no negotiation as such is 299 required. In general, these parameters do not apply to all 300 participating nodes, but only to a subset. 302 SN1. A basic requirement for the protocol is therefore the ability 303 to represent, discover, synchronize and negotiate almost any kind of 304 network parameter among selected subsets of participating nodes. 306 SN2. Negotiation is a request/response process that must be 307 guaranteed to terminate (with success or failure) and if necessary it 308 must contain tie-breaking rules for each technical objective that 309 requires them. While these must be defined specifically for each use 310 case, the protocol should have some general mechanisms in support of 311 loop and deadlock prevention, such as hop count limits or timeouts. 313 SN3. Synchronization might concern small groups of nodes or very 314 large groups. Different solutions might be needed at different 315 scales. 317 SN4. To avoid "reinventing the wheel", the protocol should be able 318 to encapsulate the data formats used by existing configuration 319 protocols (such as NETCONF/YANG) in cases where that is convenient. 321 SN5. Human intervention in complex situations is costly and error- 322 prone. Therefore, synchronization or negotiation of parameters 323 without human intervention is desirable whenever the coordination of 324 multiple devices can improve overall network performance. It 325 therefore follows that the protocol, as part of the Autonomic 326 Networking Infrastructure, should be capable of running in any device 327 that would otherwise need human intervention. The issue of running 328 in constrained nodes is discussed in 329 [I-D.ietf-anima-reference-model]. 331 SN6. Human intervention in large networks is often replaced by use 332 of a top-down network management system (NMS). It therefore follows 333 that the protocol, as part of the Autonomic Networking 334 Infrastructure, should be capable of running in any device that would 335 otherwise be managed by an NMS, and that it can co-exist with an NMS, 336 and with protocols such as SNMP and NETCONF. 338 SN7. Some features are expected to be implemented by individual 339 ASAs, but the protocol must be general enough to allow them: 341 o Dependencies and conflicts: In order to decide upon a 342 configuration for a given device, the device may need information 343 from neighbors. This can be established through the negotiation 344 procedure, or through synchronization if that is sufficient. 345 However, a given item in a neighbor may depend on other 346 information from its own neighbors, which may need another 347 negotiation or synchronization procedure to obtain or decide. 348 Therefore, there are potential dependencies and conflicts among 349 negotiation or synchronization procedures. Resolving dependencies 350 and conflicts is a matter for the individual ASAs involved. To 351 allow this, there need to be clear boundaries and convergence 352 mechanisms for negotiations. Also some mechanisms are needed to 353 avoid loop dependencies. In such a case, the protocol's role is 354 limited to bilateral signaling between ASAs. 356 o Recovery from faults and identification of faulty devices should 357 be as automatic as possible. The protocol's role is limited to 358 discovery, synchronization and negotiation. These processes can 359 occur at any time, and an ASA may need to repeat any of these 360 steps when the ASA detects an anomaly such as a negotiation 361 counterpart failing. 363 o Since the goal is to minimize human intervention, it is necessary 364 that the network can in effect "think ahead" before changing its 365 parameters. One aspect of this is an ASA that relies on a 366 knowledge base to predict network behavior. This is out of scope 367 for the signaling protocol. However, another aspect is 368 forecasting the effect of a change by a "dry run" negotiation 369 before actually installing the change. This will be an 370 application of the protocol rather than a feature of the protocol 371 itself. 373 o Management logging, monitoring, alerts and tools for intervention 374 are required. However, these can only be features of individual 375 ASAs. Another document [I-D.ietf-anima-stable-connectivity] 376 discusses how such agents may be linked into conventional OAM 377 systems via an Autonomic Control Plane 378 [I-D.ietf-anima-autonomic-control-plane]. 380 SN8. The protocol will be able to deal with a wide variety of 381 technical objectives, covering any type of network parameter. 382 Therefore the protocol will need a flexible and easily extensible 383 format for describing objectives. At a later stage it may be 384 desirable to adopt an explicit information model. One consideration 385 is whether to adopt an existing information model or to design a new 386 one. 388 2.3. Specific Technical Requirements 390 T1. It should be convenient for ASA designers to define new 391 technical objectives and for programmers to express them, without 392 excessive impact on run-time efficiency and footprint. In 393 particular, it should be possible for ASAs to be implemented 394 independently of each other as user space programs rather than as 395 kernel code. The classes of device in which the protocol might run 396 is discussed in [I-D.ietf-anima-reference-model]. 398 T2. The protocol should be easily extensible in case the initially 399 defined discovery, synchronization and negotiation mechanisms prove 400 to be insufficient. 402 T3. To be a generic platform, the protocol payload format should be 403 independent of the transport protocol or IP version. In particular, 404 it should be able to run over IPv6 or IPv4. However, some functions, 405 such as multicasting on a link, might need to be IP version 406 dependent. In case of doubt, IPv6 should be preferred. 408 T4. The protocol must be able to access off-link counterparts via 409 routable addresses, i.e., must not be restricted to link-local 410 operation. 412 T5. It must also be possible for an external discovery mechanism to 413 be used, if appropriate for a given technical objective. In other 414 words, GRASP discovery must not be a prerequisite for GRASP 415 negotiation or synchronization. 417 T6. The protocol must be capable of supporting multiple simultaneous 418 operations, especially when wait states occur. 420 T7. Intent: There must be provision for general Intent rules to be 421 applied by all devices in the network (e.g., security rules, prefix 422 length, resource sharing rules). However, Intent distribution might 423 not use the signaling protocol itself, but its design should not 424 exclude such use. 426 T8. Management monitoring, alerts and intervention: Devices should 427 be able to report to a monitoring system. Some events must be able 428 to generate operator alerts and some provision for emergency 429 intervention must be possible (e.g. to freeze synchronization or 430 negotiation in a mis-behaving device). These features might not use 431 the signaling protocol itself, but its design should not exclude such 432 use. 434 T9. The protocol needs to be fully secured against forged messages 435 and man-in-the middle attacks, and secured as much as reasonably 436 possible against denial of service attacks. It needs to be capable 437 of encryption in order to resist unwanted monitoring. However, it is 438 not required that the protocol itself provides these security 439 features; it may depend on an existing secure environment. 441 3. GRASP Protocol Overview 443 3.1. Terminology 445 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 446 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 447 "OPTIONAL" in this document are to be interpreted as described in 448 [RFC2119] when they appear in ALL CAPS. When these words are not in 449 ALL CAPS (such as "should" or "Should"), they have their usual 450 English meanings, and are not to be interpreted as [RFC2119] key 451 words. 453 This document uses terminology defined in [RFC7575]. 455 The following additional terms are used throughout this document: 457 o Autonomic Device: identical to Autonomic Node. 459 o Discovery: a process by which an ASA discovers peers according to 460 a specific discovery objective. The discovery results may be 461 different according to the different discovery objectives. The 462 discovered peers may later be used as negotiation counterparts or 463 as sources of synchronization data. 465 o Negotiation: a process by which two ASAs interact iteratively to 466 agree on parameter settings that best satisfy the objectives of 467 both ASAs. 469 o State Synchronization: a process by which ASAs interact to receive 470 the current state of parameter values stored in other ASAs. This 471 is a special case of negotiation in which information is sent but 472 the ASAs do not request their peers to change parameter settings. 473 All other definitions apply to both negotiation and 474 synchronization. 476 o Technical Objective (usually abbreviated as Objective): A 477 technical objective is a configurable parameter or set of 478 parameters of some kind, which occurs in three contexts: 480 Discovery, Negotiation and Synchronization. In the protocol, an 481 objective is represented by an identifier and, if relevant, a 482 value. Normally, a given objective will not occur in negotiation 483 and synchronization contexts simultaneously. 485 * One ASA may support multiple independent objectives. 487 * The parameter described by a given objective is naturally based 488 on a specific service or function or action. It may in 489 principle be anything that can be set to a specific logical, 490 numerical or string value, or a more complex data structure, by 491 a network node. That node is generally expected to contain an 492 ASA which may itself manage subsidiary non-autonomic nodes. 494 * Discovery Objective: an objective in the process of discovery. 495 Its value may be undefined. 497 * Synchronization Objective: an objective whose specific 498 technical content needs to be synchronized among two or more 499 ASAs. 501 * Negotiation Objective: an objective whose specific technical 502 content needs to be decided in coordination with another ASA. 504 A detailed discussion of objectives, including their format, is 505 found in Section 3.10. 507 o Discovery Initiator: an ASA that spontaneously starts discovery by 508 sending a discovery message referring to a specific discovery 509 objective. 511 o Discovery Responder: a peer that either contains an ASA supporting 512 the discovery objective indicated by the discovery initiator, or 513 caches the locator(s) of the ASA(s) supporting the objective. It 514 sends a Discovery Response, as described later. 516 o Synchronization Initiator: an ASA that spontaneously starts 517 synchronization by sending a request message referring to a 518 specific synchronization objective. 520 o Synchronization Responder: a peer ASA which responds with the 521 value of a synchronization objective. 523 o Negotiation Initiator: an ASA that spontaneously starts 524 negotiation by sending a request message referring to a specific 525 negotiation objective. 527 o Negotiation Counterpart: a peer with which the Negotiation 528 Initiator negotiates a specific negotiation objective. 530 3.2. High Level Deployment Model 532 It is expected that a GRASP implementation will reside in an 533 autonomic node that also contains both the appropriate security 534 environment, preferably the Autonomic Control Plane (ACP) 535 [I-D.ietf-anima-autonomic-control-plane], and one or more Autonomic 536 Service Agents (ASAs). In the minimal case of a single-purpose 537 device, these three components might be fully integrated. A more 538 common model is expected to be a multi-purpose device capable of 539 containing several ASAs. In this case it is expected that the ACP, 540 GRASP and the ASAs will be implemented as separate processes, which 541 are probably multi-threaded to support asynchronous and simultaneous 542 operations. It is expected that GRASP will access the ACP by using a 543 typical socket interface. A well defined Application Programming 544 Interface (API) will be needed between GRASP and the ASAs. In some 545 implementations, ASAs would run in user space with a GRASP library 546 providing the API, and this library would in turn communicate via 547 system calls with core GRASP functions. For further details of 548 possible deployment models, see [I-D.ietf-anima-reference-model]. 550 A GRASP instance must be aware of its network interfaces, and of its 551 own global-scope and link-local addresses. In the presence of the 552 ACP, such information will be available from the adjacency table 553 discussed in [I-D.ietf-anima-reference-model]. In other cases, GRASP 554 must determine such information for itself. Details depend on the 555 operating system. 557 Because GRASP needs to work whatever happens, especially during 558 bootstrapping and during fault conditions, it is essential that every 559 implementation is as robust as possible. For example, discovery 560 failures, or any kind of socket error at any time, must not cause 561 irrecoverable failures in GRASP itself, and must return suitable 562 error codes through the API so that ASAs can also recover. 564 GRASP must always start up correctly after a system restart. All run 565 time error conditions, and events such as address renumbering, 566 network interface failures, and CPU sleep/wake cycles, must be 567 handled in such a way that GRASP will still operate correctly and 568 securely (Section 3.5.1) afterwards. 570 An autonomic node will normally run a single instance of GRASP, used 571 by multiple ASAs. However, scenarios where multiple instances of 572 GRASP run in a single node, perhaps with different security 573 properties, are not excluded. In this case, each instance MUST 574 listen independently for GRASP link-local multicasts in order for 575 discovery and flooding to work correctly. 577 3.3. High Level Design Choices 579 This section describes a behavior model and design choices for GRASP, 580 supporting discovery, synchronization and negotiation, to act as a 581 platform for different technical objectives. 583 o A generic platform 585 The protocol is designed as a generic platform, which is 586 independent from the synchronization or negotiation contents. It 587 takes care of the general intercommunication between counterparts. 588 The technical contents will vary according to the various 589 technical objectives and the different pairs of counterparts. 591 o The protocol is expected to form part of an Autonomic Networking 592 Infrastructure [I-D.ietf-anima-reference-model]. It will provide 593 services to ASAs via a suitable application programming interface 594 (API), which will reflect the protocol elements but will not 595 necessarily be in one-to-one correspondence to them. This API is 596 out of scope for the present document. 598 o It is normally expected that a single main instance of GRASP will 599 exist in an autonomic node, and that the protocol engine and each 600 ASA will run as independent asynchronous processes. However, 601 separate GRASP instances may exist for security-related reasons 602 (Section 3.5.2). 604 o Security infrastructure and trust relationship 606 Because this negotiation protocol may directly cause changes to 607 device configurations and bring significant impacts to a running 608 network, this protocol is required to run within an existing 609 secure environment with strong authentication. As a design 610 choice, the protocol itself is not provided with built-in security 611 functionality. 613 On the other hand, a limited negotiation model might be deployed 614 based on a limited trust relationship such as that between two 615 administrative domains. ASAs might then exchange limited 616 information and negotiate some particular configurations. 618 o Discovery, synchronization and negotiation are designed together. 620 The discovery method and the synchronization and negotiation 621 methods are designed in the same way and can be combined when this 622 is useful, allowing a rapid mode of operation described in 623 Section 3.5.4. These processes can also be performed 624 independently when appropriate. 626 * Thus, for some objectives, especially those concerned with 627 application layer services, another discovery mechanism such as 628 the future DNS Service Discovery [RFC7558] MAY be used. The 629 choice is left to the designers of individual ASAs. 631 o A uniform pattern for technical objectives 633 The synchronization and negotiation objectives are defined 634 according to a uniform pattern. The values that they contain 635 could be carried either in a simple binary format or in a complex 636 object format. The basic protocol design uses the Concise Binary 637 Object Representation (CBOR) [RFC7049], which is readily 638 extensible for unknown future requirements. 640 o A flexible model for synchronization 642 GRASP supports bilateral synchronization, which could be used to 643 perform synchronization among a small number of nodes. It also 644 supports an unsolicited flooding mode when large groups of nodes, 645 possibly including all autonomic nodes, need data for the same 646 technical objective. 648 * There may be some network parameters for which a more 649 traditional flooding mechanism such as DNCP [RFC7787] is 650 considered more appropriate. GRASP can coexist with DNCP. 652 o A simple initiator/responder model for negotiation 654 Multi-party negotiations are very complicated to model and cannot 655 readily be guaranteed to converge. GRASP uses a simple bilateral 656 model and can support multi-party negotiations by indirect steps. 658 o Organizing of synchronization or negotiation content 660 The technical content transmitted by GRASP will be organized 661 according to the relevant function or service. The objectives for 662 different functions or services are kept separate, because they 663 may be negotiated or synchronized with different counterparts or 664 have different response times. Thus a normal arrangement would be 665 a single ASA managing a small set of closely related objectives, 666 with a version of that ASA in each relevant autonomic node. 667 Further discussion of this aspect is out of scope for the current 668 document. 670 o Requests and responses in negotiation procedures 672 The initiator can negotiate a specific negotiation objective with 673 relevant counterpart ASAs. It can request relevant information 674 from a counterpart so that it can coordinate its local 675 configuration. It can request the counterpart to make a matching 676 configuration. It can request simulation or forecast results by 677 sending some dry run conditions. 679 Beyond the traditional yes/no answer, the responder can reply with 680 a suggested alternative value for the objective concerned. This 681 would start a bi-directional negotiation ending in a compromise 682 between the two ASAs. 684 o Convergence of negotiation procedures 686 To enable convergence, when a responder suggests a new value or 687 condition in a negotiation step reply, it should be as close as 688 possible to the original request or previous suggestion. The 689 suggested value of later negotiation steps should be chosen 690 between the suggested values from the previous two steps. GRASP 691 provides mechanisms to guarantee convergence (or failure) in a 692 small number of steps, i.e. a timeout and a maximum number of 693 iterations. 695 o Extensibility 697 GRASP does not have a version number. In most cases new semantics 698 will be added by defining new synchronization or negotiation 699 objectives. However, the protocol could be extended by adding new 700 message types and options in future. 702 3.4. Quick Operating Overview 704 GRASP is expected to run as an operating system core module, 705 providing an API (such as [I-D.liu-anima-grasp-api]) to interface to 706 less privileged ASAs. Thus ASAs may operate without special 707 privilege, unless they need it for other reasons (such as configuring 708 IP addresses or manipulating routing tables). 710 The GRASP mechanisms used by the ASA are built around GRASP 711 objectives defined as data structures containing administrative 712 information such as the objective's unique name, and its current 713 value. The format and size of the value is not restricted by the 714 protocol, except that it must be possible to serialise it for 715 transmission in CBOR, which is no restriction at all in practice. 717 The GRASP provides the following mechanisms: 719 o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA 720 can discover other ASAs supporting a given objective. 722 o A negotiation request mechanism (M_REQ_NEG), by which an ASA can 723 start negotiation of an objective with a counterpart ASA. Once a 724 negotiation has started, the process is symmetrical, and there is 725 a negotiation step message (M_NEGOTIATE) for each ASA to use in 726 turn. Two other functions support negotiating steps (M_WAIT, 727 M_END). 729 o A synchronization mechanism (M_REQ_SYN), by which an ASA can 730 request the current value of an objective from a counterpart ASA. 731 With this, there is a corresponding response function (M_SYNCH) 732 for an ASA that wishes to respond to synchronization requests. 734 o A flood mechanism (M_FLOOD), by which an ASA can cause the current 735 value of an objective to be flooded throughout the AN so that any 736 ASA can receive it. One application of this is to act as an 737 announcement, avoiding the need for discovery of a widely 738 applicable objective. 740 Some example messages and simple message flows are provided in 741 Appendix D. 743 3.5. GRASP Protocol Basic Properties and Mechanisms 745 3.5.1. Required External Security Mechanism 747 The protocol SHOULD always run within a secure Autonomic Control 748 Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is 749 assumed to carry all messages securely, including link-local 750 multicast if possible. A GRASP implementation MUST verify whether 751 the ACP is operational. 753 If there is no ACP, the protocol MUST use another form of strong 754 authentication and SHOULD use a form of strong encryption. See 755 Section 3.5.2.1 for further discussion. 757 The ACP, or in its absence another security mechanism, sets the 758 boundary within which nodes are trusted as GRASP peers. A GRASP 759 implementation MUST refuse to execute GRASP synchronization and 760 negotiation functions if there is neither an operational ACP nor 761 another secure environment. 763 Link-local multicast is used for discovery messages. Responses to 764 discovery messages MUST be secured, with one exception mentioned in 765 the next section. 767 3.5.2. Constrained Instances 769 This section describes some examples of cases where additional 770 instances of GRASP subject to certain constraints are appropriate. 772 3.5.2.1. No ACP 774 As mentioned in Section 3.3, some GRASP operations might be performed 775 across an administrative domain boundary by mutual agreement, without 776 the benefit of an ACP. Such operations MUST be confined to a 777 separate instance of GRASP with its own copy of all GRASP data 778 structures. Messages MUST be authenticated and SHOULD be encrypted. 779 TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure 780 (PKI) [RFC5280] are RECOMMENDED for this purpose. Further details 781 are out of scope for this document. 783 3.5.2.2. Discovery Unsolicited Link-Local 785 Some services may need to use insecure GRASP discovery, response and 786 flood messages without being able to use pre-existing security 787 associations. Such operations being intrinsically insecure, they 788 need to be confined to link-local use to minimise the risk of 789 malicious actions. Possible examples include discovery of candidate 790 ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of 791 bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps 792 initialisation services in networks using GRASP without being fully 793 autonomic (e.g., no ACP). Such usage MUST be limited to link-local 794 operations and MUST be confined to a separate insecure instance of 795 GRASP with its own copy of all GRASP data structures. This instance 796 is nicknamed DULL - Discovery Unsolicited Link-Local. 798 The detailed rules for the DULL instance of GRASP are as follows: 800 o An initiator MUST only send Discovery or Flood Synchronization 801 link-local multicast messages with a loop count of 1. A responder 802 SHOULD NOT send a Discovery Response message unless it cannot be 803 avoided. Other GRASP message types MUST NOT be sent. 805 o A responder MUST silently discard any message whose loop count is 806 not 1. 808 o A responder MUST silently discard any message referring to a GRASP 809 Objective that is not directly part of a service that requires 810 this insecure mode. 812 o A responder MUST NOT relay any multicast messages. 814 o A Discovery Response MUST indicate a link-local address. 816 o A Discovery Response MUST NOT include a Divert option. 818 o A node MUST silently discard any message whose source address is 819 not link-local. 821 GRASP traffic SHOULD be minimized by using only Flood Synchronization 822 to announce objectives and their associated locators, rather than by 823 using Discovery and Response. Further details are out of scope for 824 this document 826 3.5.2.3. Secure Only Neighbor Negotiation 828 Some services might use insecure on-link operations as in DULL, but 829 also use unicast synchronization or negotiation operations protected 830 by TLS. A separate instance of GRASP is used, with its own copy of 831 all GRASP data structures. This instance is nicknamed SONN - Secure 832 Only Neighbor Negotiation. 834 The detailed rules for the SONN instance of GRASP are as follows: 836 o Any type of GRASP message MAY be sent. 838 o An initiator MUST send any Discovery or Flood Synchronization 839 link-local multicast messages with a loop count of 1. 841 o A responder MUST silently discard any Discovery or Flood 842 Synchronization message whose loop count is not 1. 844 o A responder MUST silently discard any message referring to a GRASP 845 Objective that is not directly part of the service concerned. 847 o A responder MUST NOT relay any multicast messages. 849 o A Discovery Response MUST indicate a link-local address. 851 o A Discovery Response MUST NOT include a Divert option. 853 o A node MUST silently discard any message whose source address is 854 not link-local. 856 Further details, including TLS and PKI usage, are out of scope for 857 this document. 859 3.5.3. Transport Layer Usage 861 GRASP discovery and flooding messages are designed for use over link- 862 local multicast UDP. They MUST NOT be fragmented, and therefore MUST 863 NOT exceed the link MTU size. Nothing in principle prevents them 864 from working over some other method of sending packets to all on-link 865 neighbors, but this is out of scope for the present specification. 867 All other GRASP messages are unicast and could in principle run over 868 any transport protocol. An implementation MUST support use of TCP. 869 It MAY support use of another transport protocol. However, GRASP 870 itself does not provide for error detection or retransmission. Use 871 of an unreliable transport protocol is therefore NOT RECOMMENDED. 873 Nevertheless, when running within a secure ACP on reliable 874 infrastructure, UDP MAY be used for unicast messages not exceeding 875 the minimum IPv6 path MTU; however, TCP MUST be used for longer 876 messages. In other words, IPv6 fragmentation is avoided. If a node 877 receives a UDP message but the reply is too long, it MUST open a TCP 878 connection to the peer for the reply. Note that when the network is 879 under heavy load or in a fault condition, UDP might become 880 unreliable. Since this is when autonomic functions are most 881 necessary, automatic fallback to TCP MUST be implemented. The 882 simplest implementation is therefore to use only TCP. 884 For considerations when running without an ACP, see Section 3.5.2.1. 886 For link-local multicast, the GRASP protocol listens to the well- 887 known GRASP Listen Port (Section 3.6). For unicast transport 888 sessions used for discovery responses, synchronization and 889 negotiation, the ASA concerned normally listens on its own 890 dynamically assigned ports, which are communicated to its peers 891 during discovery. However, a minimal implementation MAY use the 892 GRASP Listen Port for this purpose. 894 3.5.4. Discovery Mechanism and Procedures 896 3.5.4.1. Separated discovery and negotiation mechanisms 898 Although discovery and negotiation or synchronization are defined 899 together in GRASP, they are separate mechanisms. The discovery 900 process could run independently from the negotiation or 901 synchronization process. Upon receiving a Discovery (Section 3.8.4) 902 message, the recipient node should return a response message in which 903 it either indicates itself as a discovery responder or diverts the 904 initiator towards another more suitable ASA. 906 The discovery action (M_DISCOVERY) will normally be followed by a 907 negotiation (M_REQ_NEG) or synchronization (M_REQ_SYN) action. The 908 discovery results could be utilized by the negotiation protocol to 909 decide which ASA the initiator will negotiate with. 911 The initiator of a discovery action for a given objective need not be 912 capable of responding to that objective as a Negotiation Counterpart, 913 as a Synchronization Responder or as source for flooding. For 914 example, an ASA might perform discovery even if it only wishes to act 915 a Synchronization Initiator or Negotiation Initiator. Such an ASA 916 does not itself need to respond to discovery messages. 918 It is also entirely possible to use GRASP discovery without any 919 subsequent negotiation or synchronization action. In this case, the 920 discovered objective is simply used as a name during the discovery 921 process and any subsequent operations between the peers are outside 922 the scope of GRASP. 924 3.5.4.2. Discovery Overview 926 A complete discovery process will start with a multicast (of 927 M_DISCOVERY) on the local link. On-link neighbors supporting the 928 discovery objective will respond directly (with M_RESPONSE). A 929 neighbor with multiple interfaces will respond with a cached 930 discovery response if any. However, it SHOULD NOT respond with a 931 cached response on an interface if it learnt that information from 932 the same interface. If it has no cached response, it will relay the 933 discovery on its other interfaces, for example reaching a higher- 934 level gateway in a hierarchical network. If a node receiving the 935 relayed discovery supports the discovery objective, it will respond 936 to the relayed discovery. If it has a cached response, it will 937 respond with that. If not, it will repeat the discovery process, 938 which thereby becomes recursive. The loop count and timeout will 939 ensure that the process ends. 941 Exceptionally, a Discovery message MAY be sent unicast (via UDP or 942 TCP) to a peer node, which will then proceed exactly as if the 943 message had been multicast, except that when TCP is used, the 944 response will be on the same socket as the query. However, this mode 945 does not guarantee successful discovery in the general case. 947 3.5.4.3. Discovery Procedures 949 Discovery starts as an on-link operation. The Divert option can tell 950 the discovery initiator to contact an off-link ASA for that discovery 951 objective. Every Discovery message is sent by a discovery initiator 952 via UDP to the ALL_GRASP_NEIGHBOR link-local multicast address 953 (Section 3.6). Every network device that supports GRASP always 954 listens to a well-known UDP port to capture the discovery messages. 955 Because this port is unique in a device, this is a function of the 956 GRASP core and not of an individual ASA. As a result, each ASA will 957 need to register the objectives that it supports with the GRASP core. 959 If an ASA in a neighbor device supports the requested discovery 960 objective, the device SHOULD respond to the link-local multicast with 961 a unicast Discovery Response message (Section 3.8.5) with locator 962 option(s), unless it is temporarily unavailable. Otherwise, if the 963 neighbor has cached information about an ASA that supports the 964 requested discovery objective (usually because it discovered the same 965 objective before), it SHOULD respond with a Discovery Response 966 message with a Divert option pointing to the appropriate Discovery 967 Responder. 969 If a device has no information about the requested discovery 970 objective, and is not acting as a discovery relay (see below) it MUST 971 silently discard the Discovery message. 973 If no discovery response is received within a reasonable timeout 974 (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery 975 message MAY be repeated, with a newly generated Session ID 976 (Section 3.7). An exponential backoff SHOULD be used for subsequent 977 repetitions, to limit the load during busy periods. Frequent 978 repetition might be symptomatic of a denial of service attack. 980 After a GRASP device successfully discovers a locator for a Discovery 981 Responder supporting a specific objective, it MUST cache this 982 information, including the interface identifier via which it was 983 discovered. This cache record MAY be used for future negotiation or 984 synchronization, and the locator SHOULD be passed on when appropriate 985 as a Divert option to another Discovery Initiator. 987 The cache mechanism MUST include a lifetime for each entry. The 988 lifetime is derived from a time-to-live (ttl) parameter in each 989 Discovery Response message. Cached entries MUST be ignored or 990 deleted after their lifetime expires. In some environments, 991 unplanned address renumbering might occur. In such cases, the 992 lifetime SHOULD be short compared to the typical address lifetime and 993 a mechanism to flush the discovery cache SHOULD be implemented. The 994 discovery mechanism needs to track the node's current address to 995 ensure that Discovery Responses always indicate the correct address. 997 If multiple Discovery Responders are found for the same objective, 998 they SHOULD all be cached, unless this creates a resource shortage. 999 The method of choosing between multiple responders is an 1000 implementation choice. This choice MUST be available to each ASA but 1001 the GRASP implementation SHOULD provide a default choice. 1003 Because Discovery Responders will be cached in a finite cache, they 1004 might be deleted at any time. In this case, discovery will need to 1005 be repeated. If an ASA exits for any reason, its locator might still 1006 be cached for some time, and attempts to connect to it will fail. 1007 ASAs need to be robust in these circumstances. 1009 3.5.4.4. Discovery Relaying 1011 A GRASP instance with multiple link-layer interfaces (typically 1012 running in a router) MUST support discovery on all interfaces. We 1013 refer to this as a 'relaying instance'. 1015 However, different interfaces can be at different security levels: 1016 each group of interfaces with the same security level SHOULD be 1017 serviced by the same GRASP process, except for Limited Security 1018 Instances Section 3.5.2 which are always single-interface instances 1019 and MUST NOT perform discovery relaying. 1021 If a relaying instance receives a Discovery message on a given 1022 interface for a specific objective that it does not support and for 1023 which it has not previously cached a Discovery Responder, it MUST 1024 relay the query by re-issuing a Discovery message as a link-local 1025 multicast on its other interfaces. 1027 The relayed discovery message MUST have the same Session ID as the 1028 incoming discovery message and MUST be tagged with the IP address of 1029 its original initiator (see Section 3.8.4). Note that this initiator 1030 address is only used to allow for disambiguation of the Session ID 1031 and is never used to address Response packets. 1033 Since the relay device is unaware of the timeout set by the original 1034 initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT 1035 milliseconds. 1037 The relaying instance MUST decrement the loop count within the 1038 objective, and MUST NOT relay the Discovery message if the result is 1039 zero. Also, it MUST limit the total rate at which it relays 1040 discovery messages to a reasonable value, in order to mitigate 1041 possible denial of service attacks. It MUST cache the Session ID 1042 value and initiator address of each relayed Discovery message until 1043 any Discovery Responses have arrived or the discovery process has 1044 timed out. To prevent loops, it MUST NOT relay a Discovery message 1045 which carries a given cached Session ID and initiator address more 1046 than once. These precautions avoid discovery loops and mitigate 1047 potential overload. 1049 The discovery results received by the relaying instance MUST in turn 1050 be sent as a Discovery Response message to the Discovery message that 1051 caused the relay action. 1053 This relayed discovery mechanism, with caching of the results, should 1054 be sufficient to support most network bootstrapping scenarios. 1056 3.5.4.5. Rapid Mode (Discovery/Negotiation binding) 1058 A Discovery message MAY include a Negotiation Objective option. This 1059 allows a rapid mode of negotiation described in Section 3.5.5. A 1060 similar mechanism is defined for synchronization in Section 3.5.6. 1062 Note that rapid mode is currently limited to a single objective for 1063 simplicity of design and implementation. A possible future extension 1064 is to allow multiple objectives in rapid mode for greater efficiency. 1066 3.5.5. Negotiation Procedures 1068 A negotiation initiator sends a negotiation request to a counterpart 1069 ASA, including a specific negotiation objective. It may request the 1070 negotiation counterpart to make a specific configuration. 1071 Alternatively, it may request a certain simulation or forecast result 1072 by sending a dry run configuration. The details, including the 1073 distinction between dry run and an actual configuration change, will 1074 be defined separately for each type of negotiation objective. 1076 If no reply message of any kind is received within a reasonable 1077 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the 1078 negotiation request MAY be repeated, with a newly generated Session 1079 ID (Section 3.7). An exponential backoff SHOULD be used for 1080 subsequent repetitions. 1082 If the counterpart can immediately apply the requested configuration, 1083 it will give an immediate positive (O_ACCEPT) answer (using M_END). 1084 This will end the negotiation phase immediately. Otherwise, it will 1085 negotiate (using M_NEGOTIATE). It will reply with a proposed 1086 alternative configuration that it can apply (typically, a 1087 configuration that uses fewer resources than requested by the 1088 negotiation initiator). This will start a bi-directional negotiation 1089 (using M_NEGOTIATE) to reach a compromise between the two ASAs. 1091 The negotiation procedure is ended when one of the negotiation peers 1092 sends a Negotiation Ending (M_END) message, which contains an accept 1093 (O_ACCEPT) or decline (O_DECLINE) option and does not need a response 1094 from the negotiation peer. Negotiation may also end in failure 1095 (equivalent to a decline) if a timeout is exceeded or a loop count is 1096 exceeded. 1098 A negotiation procedure concerns one objective and one counterpart. 1099 Both the initiator and the counterpart may take part in simultaneous 1100 negotiations with various other ASAs, or in simultaneous negotiations 1101 about different objectives. Thus, GRASP is expected to be used in a 1102 multi-threaded mode. Certain negotiation objectives may have 1103 restrictions on multi-threading, for example to avoid over-allocating 1104 resources. 1106 Some configuration actions, for example wavelength switching in 1107 optical networks, might take considerable time to execute. The ASA 1108 concerned needs to allow for this by design, but GRASP does allow for 1109 a peer to insert latency in a negotiation process if necessary 1110 (Section 3.8.9, M_WAIT). 1112 3.5.5.1. Rapid Mode (Discovery/Negotiation Linkage) 1114 A Discovery message MAY include a Negotiation Objective option. In 1115 this case it is as if the initiator sent the sequence M_DISCOVERY, 1116 immediately followed by M_REQ_NEG. This has implications for the 1117 construction of the GRASP core, as it must carefully pass the 1118 contents of the Negotiation Objective option to the ASA so that it 1119 may evaluate the objective directly. When a Negotiation Objective 1120 option is present the ASA replies with an M_NEGOTIATE message (or 1121 M_END with O_ACCEPT if it is immediately satisfied with the 1122 proposal), rather than with an M_RESPONSE. However, if the recipient 1123 node does not support rapid mode, discovery will continue normally. 1125 It is possible that a Discovery Response will arrive from a responder 1126 that does not support rapid mode, before such a Negotiation message 1127 arrives. In this case, rapid mode will not occur. 1129 This rapid mode could reduce the interactions between nodes so that a 1130 higher efficiency could be achieved. However, a network in which 1131 some nodes support rapid mode and others do not will have complex 1132 timing-dependent behaviors. Therefore, the rapid negotiation 1133 function SHOULD be configured off by default and MAY be configured on 1134 or off by Intent. 1136 3.5.6. Synchronization and Flooding Procedure 1138 A synchronization initiator sends a synchronization request to a 1139 counterpart, including a specific synchronization objective. The 1140 counterpart responds with a Synchronization message (Section 3.8.10) 1141 containing the current value of the requested synchronization 1142 objective. No further messages are needed. 1144 If no reply message of any kind is received within a reasonable 1145 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the 1146 synchronization request MAY be repeated, with a newly generated 1147 Session ID (Section 3.7). An exponential backoff SHOULD be used for 1148 subsequent repetitions. 1150 3.5.6.1. Flooding 1152 In the case just described, the message exchange is unicast and 1153 concerns only one synchronization objective. For large groups of 1154 nodes requiring the same data, synchronization flooding is available. 1155 For this, a flooding initiator MAY send an unsolicited Flood 1156 Synchronization message containing one or more Synchronization 1157 Objective option(s), if and only if the specification of those 1158 objectives permits it. This is sent as a multicast message to the 1159 ALL_GRASP_NEIGHBOR multicast address (Section 3.6). 1161 Every network device that supports GRASP always listens to a well- 1162 known UDP port to capture flooding messages. Because this port is 1163 unique in a device, this is a function of the GRASP core. 1165 To ensure that flooding does not result in a loop, the originator of 1166 the Flood Synchronization message MUST set the loop count in the 1167 objectives to a suitable value (the default is GRASP_DEF_LOOPCT). 1168 Also, a suitable mechanism is needed to avoid excessive multicast 1169 traffic. This mechanism MUST be defined as part of the specification 1170 of the synchronization objective(s) concerned. It might be a simple 1171 rate limit or a more complex mechanism such as the Trickle algorithm 1172 [RFC6206]. 1174 A GRASP device with multiple link-layer interfaces (typically a 1175 router) MUST support synchronization flooding on all interfaces. If 1176 it receives a multicast Flood Synchronization message on a given 1177 interface, it MUST relay it by re-issuing a Flood Synchronization 1178 message on its other interfaces. The relayed message MUST have the 1179 same Session ID as the incoming message and MUST be tagged with the 1180 IP address of its original initiator. 1182 Link-layer Flooding is supported by GRASP by setting the loop count 1183 to 1, and sending with a link-local source address. Floods with 1184 link-local source addresses and a loop count other than 1 are 1185 invalid, and such messages MUST be discarded. 1187 The relaying device MUST decrement the loop count within the first 1188 objective, and MUST NOT relay the Flood Synchronization message if 1189 the result is zero. Also, it MUST limit the total rate at which it 1190 relays Flood Synchronization messages to a reasonable value, in order 1191 to mitigate possible denial of service attacks. It MUST cache the 1192 Session ID value and initiator address of each relayed Flood 1193 Synchronization message for a finite time not less than twice 1194 GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay 1195 a Flood Synchronization message which carries a given cached Session 1196 ID and initiator address more than once. These precautions avoid 1197 synchronization loops and mitigate potential overload. 1199 Note that this mechanism is unreliable in the case of sleeping nodes, 1200 or new nodes that join the network, or nodes that rejoin the network 1201 after a fault. An ASA that initiates a flood SHOULD repeat the flood 1202 at a suitable frequency and SHOULD also act as a synchronization 1203 responder for the objective(s) concerned. Thus nodes that require an 1204 objective subject to flooding can either wait for the next flood or 1205 request unicast synchronization for that objective. 1207 The multicast messages for synchronization flooding are subject to 1208 the security rules in Section 3.5.1. In practice this means that 1209 they MUST NOT be transmitted and MUST be ignored on receipt unless 1210 there is an operational ACP or equivalent strong security in place. 1211 However, because of the security weakness of link-local multicast 1212 (Section 5), synchronization objectives that are flooded SHOULD NOT 1213 contain unencrypted private information and SHOULD be validated by 1214 the recipient ASA. 1216 3.5.6.2. Rapid Mode (Discovery/Synchronization Linkage) 1218 A Discovery message MAY include a Synchronization Objective option. 1219 In this case the Discovery message also acts as a Request 1220 Synchronization message to indicate to the Discovery Responder that 1221 it could directly reply to the Discovery Initiator with a 1222 Synchronization message Section 3.8.10 with synchronization data for 1223 rapid processing, if the discovery target supports the corresponding 1224 synchronization objective. The design implications are similar to 1225 those discussed in Section 3.5.5.1. 1227 It is possible that a Discovery Response will arrive from a responder 1228 that does not support rapid mode, before such a Synchronization 1229 message arrives. In this case, rapid mode will not occur. 1231 This rapid mode could reduce the interactions between nodes so that a 1232 higher efficiency could be achieved. However, a network in which 1233 some nodes support rapid mode and others do not will have complex 1234 timing-dependent behaviors. Therefore, the rapid synchronization 1235 function SHOULD be configured off by default and MAY be configured on 1236 or off by Intent. 1238 3.6. GRASP Constants 1240 o ALL_GRASP_NEIGHBOR 1242 A link-local scope multicast address used by a GRASP-enabled 1243 device to discover GRASP-enabled neighbor (i.e., on-link) devices 1244 . All devices that support GRASP are members of this multicast 1245 group. 1247 * IPv6 multicast address: TBD1 1249 * IPv4 multicast address: TBD2 1251 o GRASP_LISTEN_PORT (TBD3) 1253 A well-known UDP user port that every GRASP-enabled network device 1254 MUST always listen to for link-local multicasts. Additionally, 1255 this user port MAY be used to listen for TCP or UDP unicast 1256 messages in a simple implementation of GRASP (Section 3.5.3). 1258 o GRASP_DEF_TIMEOUT (60000 milliseconds) 1260 The default timeout used to determine that a discovery etc. has 1261 failed to complete. 1263 o GRASP_DEF_LOOPCT (6) 1265 The default loop count used to determine that a negotiation has 1266 failed to complete, and to avoid looping messages. 1268 o GRASP_DEF_MAX_SIZE (2048) 1270 The default maximum message size in bytes. 1272 3.7. Session Identifier (Session ID) 1274 This is an up to 32-bit opaque value used to distinguish multiple 1275 sessions between the same two devices. A new Session ID MUST be 1276 generated by the initiator for every new Discovery, Flood 1277 Synchronization or Request message. All responses and follow-up 1278 messages in the same discovery, synchronization or negotiation 1279 procedure MUST carry the same Session ID. 1281 The Session ID SHOULD have a very low collision rate locally. It 1282 MUST be generated by a pseudo-random algorithm using a locally 1283 generated seed which is unlikely to be used by any other device in 1284 the same network [RFC4086]. When allocating a new Session ID, GRASP 1285 MUST check that the value is not already in use and SHOULD check that 1286 it has not been used recently, by consulting a cache of current and 1287 recent sessions. In the unlikely event of a clash, GRASP MUST 1288 generate a new value. 1290 However, there is a finite probability that two nodes might generate 1291 the same Session ID value. For that reason, when a Session ID is 1292 communicated via GRASP, the receiving node MUST tag it with the 1293 initiator's IP address to allow disambiguation. In the highly 1294 unlikely event of two peers opening sessions with the same Session ID 1295 value, this tag will allow the two sessions to be distinguished. 1296 Multicast GRASP messages and their responses, which may be relayed 1297 between links, therefore include a field that carries the initiator's 1298 global IP address. 1300 There is a highly unlikely race condition in which two peers start 1301 simultaneous negotiation sessions with each other using the same 1302 Session ID value. Depending on various implementation choices, this 1303 might lead to the two sessions being confused. See Section 3.8.6 for 1304 details of how to avoid this. 1306 3.8. GRASP Messages 1308 3.8.1. Message Overview 1310 This section defines the GRASP message format and message types. 1311 Message types not listed here are reserved for future use. 1313 The messages currently defined are: 1315 Discovery and Discovery Response. 1317 Request Negotiation, Negotiation, Confirm Waiting and Negotiation 1318 End. 1320 Request Synchronization, Synchronization, and Flood 1321 Synchronization. 1323 No Operation. 1325 3.8.2. GRASP Message Format 1327 GRASP messages share an identical header format and a variable format 1328 area for options. GRASP message headers and options are transmitted 1329 in Concise Binary Object Representation (CBOR) [RFC7049]. In this 1330 specification, they are described using CBOR data definition language 1331 (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is 1332 used to describe each item in this section. A complete and normative 1333 CDDL specification of GRASP is given in Section 6, including 1334 constants such as message types. 1336 Every GRASP message, except the No Operation message, carries a 1337 Session ID (Section 3.7). Options are then presented serially in the 1338 options field. 1340 In fragmentary CDDL, every GRASP message follows the pattern: 1342 grasp-message = (message .within message-structure) / noop-message 1344 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 1345 *grasp-option] 1347 MESSAGE_TYPE = 1..255 1348 session-id = 0..4294967295 ;up to 32 bits 1349 grasp-option = any 1351 The MESSAGE_TYPE indicates the type of the message and thus defines 1352 the expected options. Any options received that are not consistent 1353 with the MESSAGE_TYPE SHOULD be silently discarded. 1355 The No Operation (noop) message is described in Section 3.8.13. 1357 The various MESSAGE_TYPE values are defined in Section 6. 1359 All other message elements are described below and formally defined 1360 in Section 6. 1362 3.8.3. Message Size 1364 GRASP nodes MUST be able to receive messages of at least 1365 GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send messages longer 1366 than GRASP_DEF_MAX_SIZE bytes unless a longer size is explicitly 1367 allowed for the objective concerned. For example, GRASP negotiation 1368 itself could be used to agree on a longer message size. 1370 The message parser used by GRASP should be configured to know about 1371 the GRASP_DEF_MAX_SIZE, or any larger negotiated message size, so 1372 that it may defend against overly long messages. 1374 3.8.4. Discovery Message 1376 In fragmentary CDDL, a Discovery message follows the pattern: 1378 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1380 A discovery initiator sends a Discovery message to initiate a 1381 discovery process for a particular objective option. 1383 The discovery initiator sends all Discovery messages via UDP to port 1384 GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast 1385 address on each link-layer interface in use by GRASP. It then 1386 listens for unicast TCP responses on a given port, and stores the 1387 discovery results (including responding discovery objectives and 1388 corresponding unicast locators). 1390 The listening port used for TCP MUST be the same port as used for 1391 sending the Discovery UDP multicast, on a given interface. In a low- 1392 end implementation this MAY be GRASP_LISTEN_PORT. In a more complex 1393 implementation, the GRASP discovery mechanism will find, for each 1394 interface, a dynamic port that it can bind to for both UDP and TCP 1395 before initiating any discovery. 1397 The 'initiator' field in the message is a globally unique IP address 1398 of the initiator, for the sole purpose of disambiguating the Session 1399 ID in other nodes. If for some reason the initiator does not have a 1400 globally unique IP address, it MUST use a link-local address for this 1401 purpose that is highly likely to be unique, for example using 1402 [RFC7217]. 1404 A Discovery message MUST include exactly one of the following: 1406 o a discovery objective option (Section 3.10.1). Its loop count 1407 MUST be set to a suitable value to prevent discovery loops 1408 (default value is GRASP_DEF_LOOPCT). If the discovery initiator 1409 requires only on-link responses, the loop count MUST be set to 1. 1411 o a negotiation objective option (Section 3.10.1). This is used 1412 both for the purpose of discovery and to indicate to the discovery 1413 target that it MAY directly reply to the discovery initiatior with 1414 a Negotiation message for rapid processing, if it could act as the 1415 corresponding negotiation counterpart. The sender of such a 1416 Discovery message MUST initialize a negotiation timer and loop 1417 count in the same way as a Request Negotiation message 1418 (Section 3.8.6). 1420 o a synchronization objective option (Section 3.10.1). This is used 1421 both for the purpose of discovery and to indicate to the discovery 1422 target that it MAY directly reply to the discovery initiator with 1423 a Synchronization message for rapid processing, if it could act as 1424 the corresponding synchronization counterpart. Its loop count 1425 MUST be set to a suitable value to prevent discovery loops 1426 (default value is GRASP_DEF_LOOPCT). 1428 Exceptionally, a Discovery message MAY be sent unicast to a peer 1429 node, which will then proceed exactly as if the message had been 1430 multicast. 1432 3.8.5. Discovery Response Message 1434 In fragmentary CDDL, a Discovery Response message follows the 1435 pattern: 1437 response-message = [M_RESPONSE, session-id, initiator, ttl, 1438 (+locator-option // divert-option), ?objective)] 1440 ttl = 0..4294967295 ; in milliseconds 1442 A node which receives a Discovery message SHOULD send a Discovery 1443 Response message if and only if it can respond to the discovery. 1445 It MUST contain the same Session ID and initiator as the Discovery 1446 message. 1448 It MUST contain a time-to-live (ttl) for the validity of the 1449 response, given as a positive integer value in milliseconds. Zero 1450 is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6). 1452 It MAY include a copy of the discovery objective from the 1453 Discovery message. 1455 It is sent to the sender of the Discovery message via TCP at the port 1456 used to send the Discovery message (as explained in Section 3.8.4). 1458 If the responding node supports the discovery objective of the 1459 discovery, it MUST include at least one kind of locator option 1460 (Section 3.9.5) to indicate its own location. A sequence of multiple 1461 kinds of locator options (e.g. IP address option and FQDN option) is 1462 also valid. 1464 If the responding node itself does not support the discovery 1465 objective, but it knows the locator of the discovery objective, then 1466 it SHOULD respond to the discovery message with a divert option 1467 (Section 3.9.2) embedding a locator option or a combination of 1468 multiple kinds of locator options which indicate the locator(s) of 1469 the discovery objective. 1471 More details on the processing of Discovery Responses are given in 1472 Section 3.5.4. 1474 3.8.6. Request Messages 1476 In fragmentary CDDL, Request Negotiation and Request Synchronization 1477 messages follow the patterns: 1479 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1481 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1483 A negotiation or synchronization requesting node sends the 1484 appropriate Request message to the unicast address (directly stored 1485 or resolved from an FQDN or URI) of the negotiation or 1486 synchronization counterpart, using the appropriate protocol and port 1487 numbers (selected from the discovery results). 1489 A Request message MUST include the relevant objective option. In the 1490 case of Request Negotiation, the objective option MUST include the 1491 requested value. 1493 When an initiator sends a Request Negotiation message, it MUST 1494 initialize a negotiation timer for the new negotiation thread. The 1495 default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is 1496 modified by a Confirm Waiting message (Section 3.8.9), the initiator 1497 will consider that the negotiation has failed when the timer expires. 1499 Similarly, when an initiator sends a Request Synchronization, it 1500 SHOULD initialize a synchronization timer. The default is 1501 GRASP_DEF_TIMEOUT milliseconds. The initiator will consider that 1502 synchronization has failed if there is no response before the timer 1503 expires. 1505 When an initiator sends a Request message, it MUST initialize the 1506 loop count of the objective option with a value defined in the 1507 specification of the option or, if no such value is specified, with 1508 GRASP_DEF_LOOPCT. 1510 If a node receives a Request message for an objective for which no 1511 ASA is currently listening, it MUST immediately close the relevant 1512 socket to indicate this to the initiator. This is to avoid 1513 unnecessary timeouts if, for example, an ASA exits prematurely but 1514 the GRASP core is listening on its behalf. 1516 To avoid the highly unlikely race condition in which two nodes 1517 simultaneously request sessions with each other using the same 1518 Session ID (Section 3.7), when a node receives a Request message, it 1519 MUST verify that the received Session ID is not already locally 1520 active. In case of a clash, it MUST discard the Request message, in 1521 which case the initiator will detect a timeout. 1523 3.8.7. Negotiation Message 1525 In fragmentary CDDL, a Negotiation message follows the pattern: 1527 negotiate-message = [M_NEGOTIATE, session-id, objective] 1529 A negotiation counterpart sends a Negotiation message in response to 1530 a Request Negotiation message, a Negotiation message, or a Discovery 1531 message in Rapid Mode. A negotiation process MAY include multiple 1532 steps. 1534 The Negotiation message MUST include the relevant Negotiation 1535 Objective option, with its value updated according to progress in the 1536 negotiation. The sender MUST decrement the loop count by 1. If the 1537 loop count becomes zero the message MUST NOT be sent. In this case 1538 the negotiation session has failed and will time out. 1540 3.8.8. Negotiation End Message 1542 In fragmentary CDDL, a Negotiation End message follows the pattern: 1544 end-message = [M_END, session-id, accept-option / decline-option] 1546 A negotiation counterpart sends an Negotiation End message to close 1547 the negotiation. It MUST contain either an accept or a decline 1548 option, defined in Section 3.9.3 and Section 3.9.4. It could be sent 1549 either by the requesting node or the responding node. 1551 3.8.9. Confirm Waiting Message 1553 In fragmentary CDDL, a Confirm Waiting message follows the pattern: 1555 wait-message = [M_WAIT, session-id, waiting-time] 1556 waiting-time = 0..4294967295 ; in milliseconds 1558 A responding node sends a Confirm Waiting message to ask the 1559 requesting node to wait for a further negotiation response. It might 1560 be that the local process needs more time or that the negotiation 1561 depends on another triggered negotiation. This message MUST NOT 1562 include any other options. When received, the waiting time value 1563 overwrites and restarts the current negotiation timer 1564 (Section 3.8.6). 1566 The responding node SHOULD send a Negotiation, Negotiation End or 1567 another Confirm Waiting message before the negotiation timer expires. 1568 If not, the initiator MUST abandon or restart the negotiation 1569 procedure, to avoid an indefinite wait. 1571 3.8.10. Synchronization Message 1573 In fragmentary CDDL, a Synchronization message follows the pattern: 1575 synch-message = [M_SYNCH, session-id, objective] 1577 A node which receives a Request Synchronization, or a Discovery 1578 message in Rapid Mode, sends back a unicast Synchronization message 1579 with the synchronization data, in the form of a GRASP Option for the 1580 specific synchronization objective present in the Request 1581 Synchronization. 1583 3.8.11. Flood Synchronization Message 1585 In fragmentary CDDL, a Flood Synchronization message follows the 1586 pattern: 1588 flood-message = [M_FLOOD, session-id, initiator, ttl, 1589 +[objective, (locator-option / [])]] 1591 ttl = 0..4294967295 ; in milliseconds 1593 A node MAY initiate flooding by sending an unsolicited Flood 1594 Synchronization Message with synchronization data. This MAY be sent 1595 to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance 1596 with the rules in Section 3.5.6. 1598 The initiator address is provided, as described for Discovery 1599 messages (Section 3.8.4), only to disambiguate the Session ID. 1601 The message MUST contain a time-to-live (ttl) for the validity of 1602 the contents, given as a positive integer value in milliseconds. 1603 There is no default; zero indicates an indefinite lifetime. 1605 The synchronization data are in the form of GRASP Option(s) for 1606 specific synchronization objective(s). The loop count(s) MUST be 1607 set to a suitable value to prevent flood loops (default value is 1608 GRASP_DEF_LOOPCT). 1610 Each objective option MAY be followed by a locator option 1611 associated with the flooded objective. In its absence, an empty 1612 option MUST be included to indicate a null locator. 1614 A node that receives a Flood Synchronization message MUST cache the 1615 received objectives for use by local ASAs. Each cached objective 1616 MUST be tagged with the locator option sent with it, or with a null 1617 tag if an empty locator option was sent. If a subsequent Flood 1618 Synchronization message carrying the same objective arrives with the 1619 same tag, the corresponding cached copy of the objective MUST be 1620 overwritten. If a subsequent Flood Synchronization message carrying 1621 the same objective arrives with a different tag, a new cached entry 1622 MUST be created. 1624 Note: the purpose of this mechanism is to allow the recipient of 1625 flooded values to distinguish between different senders of the same 1626 objective, and if necessary communicate with them using the locator, 1627 protocol and port included in the locator option. Many objectives 1628 will not need this mechanism, so they will be flooded with a null 1629 locator. 1631 Cached entries MUST be ignored or deleted after their lifetime 1632 expires. 1634 3.8.12. Invalid Message 1636 In fragmentary CDDL, an Invalid message follows the pattern: 1638 invalid-message = [M_INVALID, session-id, ?any] 1640 This message MAY be sent by an implementation in response to an 1641 incoming message that it considers invalid. The session-id MUST be 1642 copied from the incoming message. The content SHOULD be diagnostic 1643 information such as a partial copy of the invalid message. An 1644 M_INVALID message MAY be silently ignored by a recipient. However, 1645 it could be used in support of extensibility, since it indicates that 1646 the remote node does not support a new or obsolete message or option 1648 An M_INVALID message MUST NOT be sent in response to an M_INVALID 1649 message. 1651 3.8.13. No Operation Message 1653 In fragmentary CDDL, a No Operation message follows the pattern: 1655 noop-message = [M_NOOP] 1657 This message MAY be sent by an implementation that for practical 1658 reasons needs to activate a socket. It MUST be silently ignored by a 1659 recipient. 1661 3.9. GRASP Options 1663 This section defines the GRASP options for the negotiation and 1664 synchronization protocol signaling. Additional options may be 1665 defined in the future. 1667 3.9.1. Format of GRASP Options 1669 GRASP options are CBOR objects that MUST start with an unsigned 1670 integer identifying the specific option type carried in this option. 1671 These option types are formally defined in Section 6. Apart from 1672 that the only format requirement is that each option MUST be a well- 1673 formed CBOR object. In general a CBOR array format is RECOMMENDED to 1674 limit overhead. 1676 GRASP options are usually scoped by using encapsulation. However, 1677 this is not a requirement 1679 3.9.2. Divert Option 1681 The Divert option is used to redirect a GRASP request to another 1682 node, which may be more appropriate for the intended negotiation or 1683 synchronization. It may redirect to an entity that is known as a 1684 specific negotiation or synchronization counterpart (on-link or off- 1685 link) or a default gateway. The divert option MUST only be 1686 encapsulated in Discovery Response messages. If found elsewhere, it 1687 SHOULD be silently ignored. 1689 A discovery initiator MAY ignore a Divert option if it only requires 1690 direct discovery responses. 1692 In fragmentary CDDL, the Divert option follows the pattern: 1694 divert-option = [O_DIVERT, +locator-option] 1696 The embedded Locator Option(s) (Section 3.9.5) point to diverted 1697 destination target(s) in response to a Discovery message. 1699 3.9.3. Accept Option 1701 The accept option is used to indicate to the negotiation counterpart 1702 that the proposed negotiation content is accepted. 1704 The accept option MUST only be encapsulated in Negotiation End 1705 messages. If found elsewhere, it SHOULD be silently ignored. 1707 In fragmentary CDDL, the Accept option follows the pattern: 1709 accept-option = [O_ACCEPT] 1711 3.9.4. Decline Option 1713 The decline option is used to indicate to the negotiation counterpart 1714 the proposed negotiation content is declined and end the negotiation 1715 process. 1717 The decline option MUST only be encapsulated in Negotiation End 1718 messages. If found elsewhere, it SHOULD be silently ignored. 1720 In fragmentary CDDL, the Decline option follows the pattern: 1722 decline-option = [O_DECLINE, ?reason] 1723 reason = text ;optional error message 1725 Note: there are scenarios where a negotiation counterpart wants to 1726 decline the proposed negotiation content and continue the negotiation 1727 process. For these scenarios, the negotiation counterpart SHOULD use 1728 a Negotiate message, with either an objective option that contains a 1729 data field set to indicate a meaningless initial value, or a specific 1730 objective option that provides further conditions for convergence. 1732 3.9.5. Locator Options 1734 These locator options are used to present reachability information 1735 for an ASA, a device or an interface. They are Locator IPv6 Address 1736 Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified 1737 Domain Name) Option and URI (Uniform Resource Identifier) Option. 1739 Since ASAs will normally run as independent user programs, locator 1740 options need to indicate the network layer locator plus the transport 1741 protocol and port number for reaching the target. For this reason, 1742 the Locator Options for IP addresses and FQDNs include this 1743 information explicitly. In the case of the URI Option, this 1744 information can be encoded in the URI itself. 1746 Note: It is assumed that all locators are in scope throughout the 1747 GRASP domain. GRASP is not intended to work across disjoint 1748 addressing or naming realms. 1750 3.9.5.1. Locator IPv6 address option 1752 In fragmentary CDDL, the IPv6 address option follows the pattern: 1754 ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address, 1755 transport-proto, port-number] 1756 ipv6-address = bytes .size 16 1758 transport-proto = IPPROTO_TCP / IPPROTO_UDP 1759 IPPROTO_TCP = 6 1760 IPPROTO_UDP = 17 1761 port-number = 0..65535 1763 The content of this option is a binary IPv6 address followed by the 1764 protocol number and port number to be used. 1766 Note 1: The IPv6 address MUST normally have global scope. 1767 Exceptionally, during initialisation, a link-local address MAY be 1768 used for specific objectives only (Section 3.5.2). In this case the 1769 corresponding Discovery Response message MUST be sent via the 1770 interface to which the link-local address applies. 1772 Note 2: A link-local IPv6 address MUST NOT be used when this option 1773 is included in a Divert option. 1775 3.9.5.2. Locator IPv4 address option 1777 In fragmentary CDDL, the IPv4 address option follows the pattern: 1779 ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address, 1780 transport-proto, port-number] 1781 ipv4-address = bytes .size 4 1783 The content of this option is a binary IPv4 address followed by the 1784 protocol number and port number to be used. 1786 Note: If an operator has internal network address translation for 1787 IPv4, this option MUST NOT be used within the Divert option. 1789 3.9.5.3. Locator FQDN option 1791 In fragmentary CDDL, the FQDN option follows the pattern: 1793 fqdn-locator-option = [O_FQDN_LOCATOR, text, 1794 transport-proto, port-number] 1796 The content of this option is the Fully Qualified Domain Name of the 1797 target followed by the protocol number and port number to be used. 1799 Note 1: Any FQDN which might not be valid throughout the network in 1800 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1801 when this option is used within the Divert option. 1803 Note 2: Normal GRASP operations are not expected to use this option. 1804 It is intended for special purposes such as discovering external 1805 services. 1807 3.9.5.4. Locator URI option 1809 In fragmentary CDDL, the URI option follows the pattern: 1811 uri-locator = [O_URI_LOCATOR, text] 1813 The content of this option is the Uniform Resource Identifier of the 1814 target [RFC3986]. 1816 Note 1: Any URI which might not be valid throughout the network in 1817 question, such as one based on a Multicast DNS name [RFC6762], MUST 1818 NOT be used when this option is used within the Divert option. 1820 Note 2: Normal GRASP operations are not expected to use this option. 1821 It is intended for special purposes such as discovering external 1822 services. 1824 3.10. Objective Options 1826 3.10.1. Format of Objective Options 1828 An objective option is used to identify objectives for the purposes 1829 of discovery, negotiation or synchronization. All objectives MUST be 1830 in the following format, described in fragmentary CDDL: 1832 objective = [objective-name, objective-flags, loop-count, ?any] 1834 objective-name = text 1835 loop-count = 0..255 1837 All objectives are identified by a unique name which is a case- 1838 sensitive UTF-8 string. 1840 The names of generic objectives MUST NOT include a colon (":") and 1841 MUST be registered with IANA (Section 7). 1843 The names of privately defined objectives MUST include at least one 1844 colon (":"). The string preceding the last colon in the name MUST be 1845 globally unique and in some way identify the entity or person 1846 defining the objective. The following three methods MAY be used to 1847 create such a globally unique string: 1849 1. The unique string is a decimal number representing a registered 1850 32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 1851 uniquely identifies the enterprise defining the objective. 1853 2. The unique string is a fully qualified domain name that uniquely 1854 identifies the entity or person defining the objective. 1856 3. The unique string is an email address that uniquely identifies 1857 the entity or person defining the objective. 1859 The GRASP protocol treats the objective name as an opaque string. 1860 For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 1861 and "user@example.org:EX1" would be five different objectives. 1863 The 'objective-flags' field is described below. 1865 The 'loop-count' field is used for terminating negotiation as 1866 described in Section 3.8.7. It is also used for terminating 1867 discovery as described in Section 3.5.4, and for terminating flooding 1868 as described in Section 3.5.6.1. 1870 The 'any' field is to express the actual value of a negotiation or 1871 synchronization objective. Its format is defined in the 1872 specification of the objective and may be a single value or a data 1873 structure of any kind. It is optional because it is optional in a 1874 Discovery or Discovery Response message. 1876 3.10.2. Objective flags 1878 An objective may be relevant for discovery only, for discovery and 1879 negotiation, or for discovery and synchronization. This is expressed 1880 in the objective by logical flag bits: 1882 objective-flags = uint .bits objective-flag 1883 objective-flag = &( 1884 F_DISC: 0 ; valid for discovery 1885 F_NEG: 1 ; valid for negotiation 1886 F_SYNCH: 2 ; valid for synchronization 1887 F_NEG_DRY: 3 ; negotiation is dry-run 1888 ) 1890 These bits are independent and may be combined appropriately, e.g. 1891 (F_DISC and F_SYNCH) or (F_DISC and F_NEG) or (F_DISC and F_NEG and 1892 F_NEG_DRY). 1894 Note that for a given negotiation session, an objective must be 1895 either used for negotiation, or for dry-run negotiation. Mixing the 1896 two modes in a single negotiation is not possible. 1898 3.10.3. General Considerations for Objective Options 1900 As mentioned above, Objective Options MUST be assigned a unique name. 1901 As long as privately defined Objective Options obey the rules above, 1902 this document does not restrict their choice of name, but the entity 1903 or person concerned SHOULD publish the names in use. 1905 All Objective Options MUST respect the CBOR patterns defined above as 1906 "objective" and MUST replace the "any" field with a valid CBOR data 1907 definition for the relevant use case and application. 1909 An Objective Option that contains no additional fields beyond its 1910 "loop-count" can only be a discovery objective and MUST only be used 1911 in Discovery and Discovery Response messages. 1913 The Negotiation Objective Options contain negotiation objectives, 1914 which vary according to different functions/services. They MUST be 1915 carried by Discovery, Request Negotiation or Negotiation messages 1916 only. The negotiation initiator MUST set the initial "loop-count" to 1917 a value specified in the specification of the objective or, if no 1918 such value is specified, to GRASP_DEF_LOOPCT. 1920 For most scenarios, there should be initial values in the negotiation 1921 requests. Consequently, the Negotiation Objective options MUST 1922 always be completely presented in a Request Negotiation message, or 1923 in a Discovery message in rapid mode. If there is no initial value, 1924 the bits in the value field SHOULD all be set to indicate a 1925 meaningless value, unless this is inappropriate for the specific 1926 negotiation objective. 1928 Synchronization Objective Options are similar, but MUST be carried by 1929 Discovery, Discovery Response, Request Synchronization, or Flood 1930 Synchronization messages only. They include value fields only in 1931 Synchronization or Flood Synchronization messages. 1933 3.10.4. Organizing of Objective Options 1935 Generic objective options MUST be specified in documents available to 1936 the public and SHOULD be designed to use either the negotiation or 1937 the synchronization mechanism described above. 1939 As noted earlier, one negotiation objective is handled by each GRASP 1940 negotiation thread. Therefore, a negotiation objective, which is 1941 based on a specific function or action, SHOULD be organized as a 1942 single GRASP option. It is NOT RECOMMENDED to organize multiple 1943 negotiation objectives into a single option, nor to split a single 1944 function or action into multiple negotiation objectives. 1946 It is important to understand that GRASP negotiation does not support 1947 transactional integrity. If transactional integrity is needed for a 1948 specific objective, this must be ensured by the ASA. For example, an 1949 ASA might need to ensure that it only participates in one negotiation 1950 thread at the same time. Such an ASA would need to stop listening 1951 for incoming negotiation requests before generating an outgoing 1952 negotiation request. 1954 A synchronization objective SHOULD be organized as a single GRASP 1955 option. 1957 Some objectives will support more than one operational mode. An 1958 example is a negotiation objective with both a "dry run" mode (where 1959 the negotiation is to find out whether the other end can in fact make 1960 the requested change without problems) and a "live" mode. Such modes 1961 will be defined in the specification of such an objective. These 1962 objectives SHOULD include flags indicating the applicable mode(s). 1964 An objective may have multiple parameters. Parameters can be 1965 categorized into two classes: the obligatory ones presented as fixed 1966 fields; and the optional ones presented in CBOR sub-options or some 1967 other form of data structure embedded in CBOR. The format might be 1968 inherited from an existing management or configuration protocol, the 1969 objective option acting as a carrier for that format. The data 1970 structure might be defined in a formal language, but that is a matter 1971 for the specifications of individual objectives. There are many 1972 candidates, according to the context, such as ABNF, RBNF, XML Schema, 1973 possibly YANG, etc. The GRASP protocol itself is agnostic on these 1974 questions. 1976 It is NOT RECOMMENDED to split parameters in a single objective into 1977 multiple options, unless they have different response periods. An 1978 exception scenario may also be described by split objectives. 1980 All objectives MUST support GRASP discovery. However, as mentioned 1981 in Section 3.3, it is acceptable for an ASA to use an alternative 1982 method of discovery. 1984 Normally, a GRASP objective will refer to specific technical 1985 parameters as explained in Section 3.1. However, it is acceptable to 1986 define an abstract objective for the purpose of managing or 1987 coordinating ASAs. It is also acceptable to define a special-purpose 1988 objective for purposes such as trust bootstrapping or formation of 1989 the ACP. 1991 To guarantee convergence, a limited number of rounds or a timeout is 1992 needed for each negotiation objective. Therefore, the definition of 1993 each negotiation objective SHOULD clearly specify this, for example a 1994 default loop count and timeout, so that the negotiation can always be 1995 terminated properly. If not, the GRASP defaults will apply. 1997 There must be a well-defined procedure for concluding that a 1998 negotiation cannot succeed, and if so deciding what happens next 1999 (e.g., deadlock resolution, tie-breaking, or revert to best-effort 2000 service). This MUST be specified for individual negotiation 2001 objectives. 2003 3.10.5. Experimental and Example Objective Options 2005 The names "EX0" through "EX9" have been reserved for experimental 2006 options. Multiple names have been assigned because a single 2007 experiment may use multiple options simultaneously. These 2008 experimental options are highly likely to have different meanings 2009 when used for different experiments. Therefore, they SHOULD NOT be 2010 used without an explicit human decision and SHOULD NOT be used in 2011 unmanaged networks such as home networks. 2013 These names are also RECOMMENDED for use in documentation examples. 2015 4. Implementation Status [RFC Editor: please remove] 2017 Two prototype implementations of GRASP have been made. 2019 4.1. BUPT C++ Implementation 2021 o Name: BaseNegotiator.cpp, msg.cpp, Client.cpp, Server.cpp 2023 o Description: C++ implementation of GRASP core and API 2025 o Maturity: Prototype code, interoperable between Ubuntu. 2027 o Coverage: Corresponds to draft-carpenter-anima-gdn-protocol-03. 2028 Since it was implemented based on the old version draft, the most 2029 significant limitations comparing to current protocol design 2030 include: 2032 * Not support CBOR 2034 * Not support Flooding 2036 * Not support loop avoidance 2038 * only coded for IPv6, any IPv4 is accidental 2040 o Licensing: Huawei License. 2042 o Experience: https://github.com/liubingpang/IETF-Anima-Signaling- 2043 Protocol/blob/master/README.md 2045 o Contact: https://github.com/liubingpang/IETF-Anima-Signaling- 2046 Protocol 2048 4.2. Python Implementation 2050 o Name: graspy 2052 o Description: Python 3 implementation of GRASP core and API. 2054 o Maturity: Prototype code, interoperable between Windows 7 and 2055 Linux. 2057 o Coverage: Corresponds to draft-ietf-anima-grasp-08. Limitations 2058 include: 2060 * insecure: uses a dummy ACP module and does not implement TLS 2062 * only coded for IPv6, any IPv4 is accidental 2064 * FQDN and URI locators incompletely supported 2066 * no code for rapid mode 2068 * relay code is lazy (no rate control) 2070 * all unicast transactions use TCP (no unicast UDP). 2071 Experimental code for unicast UDP proved to be complex and 2072 brittle. 2074 * optional Objective option in Response messages not implemented 2076 * workarounds for defects in Python socket module and Windows 2077 socket peculiarities 2079 o Licensing: Simplified BSD 2081 o Experience: https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf 2083 o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ 2085 5. Security Considerations 2087 It is obvious that a successful attack on negotiation-enabled nodes 2088 would be extremely harmful, as such nodes might end up with a 2089 completely undesirable configuration that would also adversely affect 2090 their peers. GRASP nodes and messages therefore require full 2091 protection. 2093 - Authentication 2095 A cryptographically authenticated identity for each device is 2096 needed in an autonomic network. It is not safe to assume that a 2097 large network is physically secured against interference or that 2098 all personnel are trustworthy. Each autonomic node MUST be 2099 capable of proving its identity and authenticating its messages. 2100 GRASP relies on a separate external certificate-based security 2101 mechanism to support authentication, data integrity protection, 2102 and anti-replay protection. 2104 Since GRASP is intended to be deployed in a single administrative 2105 domain operating its own trust anchor and CA, there is no need for 2106 a trusted public third party. In a network requiring "air gap" 2107 security, such a dependency would be unacceptable. 2109 If GRASP is used temporarily without an external security 2110 mechanism, for example during system bootstrap (Section 3.5.1), 2111 the Session ID (Section 3.7) will act as a nonce to provide 2112 limited protection against third parties injecting responses. A 2113 full analysis of the secure bootstrap process is out of scope for 2114 the present document. 2116 - Authorization and Roles 2118 The GRASP protocol is agnostic about the role of individual ASAs 2119 and about which objectives a particular ASA is authorized to 2120 support. An implementation might support precautions such as 2121 allowing only one ASA in a given node to modify a given objective, 2122 but this may not be appropriate in all cases. For example, it 2123 might be operationally useful to allow an old and a new version of 2124 the same ASA to run simultaneously during an overlap period. 2125 These questions are out of scope for the present specification. 2127 - Privacy and confidentiality 2129 Generally speaking, no personal information is expected to be 2130 involved in the signaling protocol, so there should be no direct 2131 impact on personal privacy. Nevertheless, traffic flow paths, 2132 VPNs, etc. could be negotiated, which could be of interest for 2133 traffic analysis. Also, operators generally want to conceal 2134 details of their network topology and traffic density from 2135 outsiders. Therefore, since insider attacks cannot be excluded in 2136 a large network, the security mechanism for the protocol MUST 2137 provide message confidentiality. This is why Section 3.5.1 2138 requires either an ACP or an alternative security mechanism. 2140 - Link-local multicast security 2142 GRASP has no reasonable alternative to using link-local multicast 2143 for Discovery or Flood Synchronization messages and these messages 2144 are sent in clear and with no authentication. They are therefore 2145 available to on-link eavesdroppers, and could be forged by on-link 2146 attackers. In the case of Discovery, the Discovery Responses are 2147 unicast and will therefore be protected (Section 3.5.1), and an 2148 untrusted forger will not be able to receive responses. In the 2149 case of Flood Synchronization, an on-link eavesdropper will be 2150 able to receive the flooded objectives but there is no response 2151 message to consider. Some precautions for Flood Synchronization 2152 messages are suggested in Section 3.5.6.1. 2154 - DoS Attack Protection 2156 GRASP discovery partly relies on insecure link-local multicast. 2157 Since routers participating in GRASP sometimes relay discovery 2158 messages from one link to another, this could be a vector for 2159 denial of service attacks. Some mitigations are specified in 2160 Section 3.5.4. However, malicious code installed inside the 2161 Autonomic Control Plane could always launch DoS attacks consisting 2162 of spurious discovery messages, or of spurious discovery 2163 responses. Additionally, it is of great importance that firewalls 2164 prevent any GRASP messages from entering the domain from an 2165 untrusted source. 2167 - Security during bootstrap and discovery 2169 A node cannot authenticate GRASP traffic from other nodes until it 2170 has identified the trust anchor and can validate certificates for 2171 other nodes. Also, until it has succesfully enrolled 2172 [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that 2173 other nodes are able to authenticate its own traffic. Therefore, 2174 GRASP discovery during the bootstrap phase for a new device will 2175 inevitably be insecure and GRASP synchronization and negotiation 2176 will be impossible until enrollment is complete. Further details 2177 are given in Section 3.5.2. 2179 - Security of discovered locators 2180 When GRASP discovery returns an IP address, it MUST be that of a 2181 node within the secure environment (Section 3.5.1). If it returns 2182 an FQDN or a URI, the ASA that receives it MUST NOT assume that 2183 the target of the locator is within the secure environment. 2185 6. CDDL Specification of GRASP 2187 2188 grasp-message = (message .within message-structure) / noop-message 2190 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 2191 *grasp-option] 2193 MESSAGE_TYPE = 0..255 2194 session-id = 0..4294967295 ;up to 32 bits 2195 grasp-option = any 2197 message /= discovery-message 2198 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 2200 message /= response-message ;response to Discovery 2201 response-message = [M_RESPONSE, session-id, initiator, ttl, 2202 (+locator-option // divert-option), ?objective] 2204 message /= synch-message ;response to Synchronization request 2205 synch-message = [M_SYNCH, session-id, objective] 2207 message /= flood-message 2208 flood-message = [M_FLOOD, session-id, initiator, ttl, 2209 +[objective, (locator-option / [])]] 2211 message /= request-negotiation-message 2212 request-negotiation-message = [M_REQ_NEG, session-id, objective] 2214 message /= request-synchronization-message 2215 request-synchronization-message = [M_REQ_SYN, session-id, objective] 2217 message /= negotiation-message 2218 negotiation-message = [M_NEGOTIATE, session-id, objective] 2220 message /= end-message 2221 end-message = [M_END, session-id, accept-option / decline-option ] 2223 message /= wait-message 2224 wait-message = [M_WAIT, session-id, waiting-time] 2226 message /= invalid-message 2227 invalid-message = [M_INVALID, session-id, ?any] 2228 noop-message = [M_NOOP] 2230 divert-option = [O_DIVERT, +locator-option] 2232 accept-option = [O_ACCEPT] 2234 decline-option = [O_DECLINE, ?reason] 2235 reason = text ;optional error message 2237 waiting-time = 0..4294967295 ; in milliseconds 2238 ttl = 0..4294967295 ; in milliseconds 2240 locator-option /= [O_IPv4_LOCATOR, ipv4-address, 2241 transport-proto, port-number] 2242 ipv4-address = bytes .size 4 2244 locator-option /= [O_IPv6_LOCATOR, ipv6-address, 2245 transport-proto, port-number] 2246 ipv6-address = bytes .size 16 2248 locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number] 2250 transport-proto = IPPROTO_TCP / IPPROTO_UDP 2251 IPPROTO_TCP = 6 2252 IPPROTO_UDP = 17 2253 port-number = 0..65535 2255 locator-option /= [O_URI_LOCATOR, text] 2257 initiator = ipv4-address / ipv6-address 2259 objective-flags = uint .bits objective-flag 2261 objective-flag = &( 2262 F_DISC: 0 ; valid for discovery 2263 F_NEG: 1 ; valid for negotiation 2264 F_SYNCH: 2 ; valid for synchronization 2265 F_NEG_DRY: 3 ; negotiation is dry-run 2266 ) 2268 objective = [objective-name, objective-flags, loop-count, ?any] 2270 objective-name = text ;see specification for uniqueness rules 2272 loop-count = 0..255 2274 ; Constants for message types and option types 2275 M_NOOP = 0 2276 M_DISCOVERY = 1 2277 M_RESPONSE = 2 2278 M_REQ_NEG = 3 2279 M_REQ_SYN = 4 2280 M_NEGOTIATE = 5 2281 M_END = 6 2282 M_WAIT = 7 2283 M_SYNCH = 8 2284 M_FLOOD = 9 2285 M_INVALID = 99 2287 O_DIVERT = 100 2288 O_ACCEPT = 101 2289 O_DECLINE = 102 2290 O_IPv6_LOCATOR = 103 2291 O_IPv4_LOCATOR = 104 2292 O_FQDN_LOCATOR = 105 2293 O_URI_LOCATOR = 106 2294 2296 7. IANA Considerations 2298 This document defines the Generic Autonomic Signaling Protocol 2299 (GRASP). 2301 Section 3.6 explains the following link-local multicast addresses, 2302 which IANA is requested to assign for use by GRASP: 2304 ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in 2305 the IPv6 Link-Local Scope Multicast Addresses registry. 2307 ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in 2308 the IPv4 Multicast Local Network Control Block. 2310 Section 3.6 explains the following User Port, which IANA is requested 2311 to assign for use by GRASP for both UDP and TCP: 2313 GRASP_LISTEN_PORT: (TBD3) 2314 Service Name: Generic Autonomic Signaling Protocol (GRASP) 2315 Transport Protocols: UDP, TCP 2316 Assignee: iesg@ietf.org 2317 Contact: chair@ietf.org 2318 Description: See Section 3.6 2319 Reference: RFC XXXX (this document) 2320 The IANA is requested to create a GRASP Parameter Registry including 2321 two registry tables. These are the GRASP Messages and Options 2322 Table and the GRASP Objective Names Table. 2324 GRASP Messages and Options Table. The values in this table are names 2325 paired with decimal integers. Future values MUST be assigned using 2326 the Standards Action policy defined by [RFC5226]. The following 2327 initial values are assigned by this document: 2329 M_NOOP = 0 2330 M_DISCOVERY = 1 2331 M_RESPONSE = 2 2332 M_REQ_NEG = 3 2333 M_REQ_SYN = 4 2334 M_NEGOTIATE = 5 2335 M_END = 6 2336 M_WAIT = 7 2337 M_SYNCH = 8 2338 M_FLOOD = 9 2339 M_INVALID = 99 2341 O_DIVERT = 100 2342 O_ACCEPT = 101 2343 O_DECLINE = 102 2344 O_IPv6_LOCATOR = 103 2345 O_IPv4_LOCATOR = 104 2346 O_FQDN_LOCATOR = 105 2347 O_URI_LOCATOR = 106 2349 GRASP Objective Names Table. The values in this table are UTF-8 2350 strings. Future values MUST be assigned using the Specification 2351 Required policy defined by [RFC5226]. The following initial values 2352 are assigned by this document: 2354 EX0 2355 EX1 2356 EX2 2357 EX3 2358 EX4 2359 EX5 2360 EX6 2361 EX7 2362 EX8 2363 EX9 2365 8. Acknowledgements 2367 A major contribution to the original version of this document was 2368 made by Sheng Jiang. Significant review inputs were received from 2369 Joel Halpern, Toerless Eckert and Michael Richardson. 2371 Valuable comments were received from Michael Behringer, Jeferson 2372 Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Zhenbin Li, 2373 Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Markus Stenberg, 2374 Rene Struik, Dacheng Zhang, and other participants in the NMRG 2375 research group and the ANIMA working group. 2377 9. References 2379 9.1. Normative References 2381 [I-D.greevenbosch-appsawg-cbor-cddl] 2382 Vigano, C. and H. Birkholz, "CBOR data definition language 2383 (CDDL): a notational convention to express CBOR data 2384 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 2385 in progress), September 2016. 2387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2388 Requirement Levels", BCP 14, RFC 2119, 2389 DOI 10.17487/RFC2119, March 1997, 2390 . 2392 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2393 Resource Identifier (URI): Generic Syntax", STD 66, 2394 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2395 . 2397 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2398 "Randomness Requirements for Security", BCP 106, RFC 4086, 2399 DOI 10.17487/RFC4086, June 2005, 2400 . 2402 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2403 (TLS) Protocol Version 1.2", RFC 5246, 2404 DOI 10.17487/RFC5246, August 2008, 2405 . 2407 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2408 Housley, R., and W. Polk, "Internet X.509 Public Key 2409 Infrastructure Certificate and Certificate Revocation List 2410 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2411 . 2413 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2414 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2415 January 2012, . 2417 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2418 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2419 October 2013, . 2421 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2422 Interface Identifiers with IPv6 Stateless Address 2423 Autoconfiguration (SLAAC)", RFC 7217, 2424 DOI 10.17487/RFC7217, April 2014, 2425 . 2427 9.2. Informative References 2429 [I-D.chaparadza-intarea-igcp] 2430 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 2431 Mahkonen, "IP based Generic Control Protocol (IGCP)", 2432 draft-chaparadza-intarea-igcp-00 (work in progress), July 2433 2011. 2435 [I-D.ietf-anima-autonomic-control-plane] 2436 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 2437 Control Plane", draft-ietf-anima-autonomic-control- 2438 plane-04 (work in progress), October 2016. 2440 [I-D.ietf-anima-bootstrapping-keyinfra] 2441 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2442 S., and K. Watsen, "Bootstrapping Remote Secure Key 2443 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2444 keyinfra-04 (work in progress), October 2016. 2446 [I-D.ietf-anima-reference-model] 2447 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 2448 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 2449 Reference Model for Autonomic Networking", draft-ietf- 2450 anima-reference-model-02 (work in progress), July 2016. 2452 [I-D.ietf-anima-stable-connectivity] 2453 Eckert, T. and M. Behringer, "Using Autonomic Control 2454 Plane for Stable Connectivity of Network OAM", draft-ietf- 2455 anima-stable-connectivity-01 (work in progress), July 2456 2016. 2458 [I-D.ietf-netconf-restconf] 2459 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2460 Protocol", draft-ietf-netconf-restconf-18 (work in 2461 progress), October 2016. 2463 [I-D.liang-iana-pen] 2464 Liang, P., Melnikov, A., and D. Conrad, "Private 2465 Enterprise Number (PEN) practices and Internet Assigned 2466 Numbers Authority (IANA) registration considerations", 2467 draft-liang-iana-pen-06 (work in progress), July 2015. 2469 [I-D.liu-anima-grasp-api] 2470 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 2471 Autonomic Signaling Protocol Application Program Interface 2472 (GRASP API)", draft-liu-anima-grasp-api-02 (work in 2473 progress), September 2016. 2475 [I-D.stenberg-anima-adncp] 2476 Stenberg, M., "Autonomic Distributed Node Consensus 2477 Protocol", draft-stenberg-anima-adncp-00 (work in 2478 progress), March 2015. 2480 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2481 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2482 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2483 September 1997, . 2485 [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, 2486 "Server Cache Synchronization Protocol (SCSP)", RFC 2334, 2487 DOI 10.17487/RFC2334, April 1998, 2488 . 2490 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 2491 "Service Location Protocol, Version 2", RFC 2608, 2492 DOI 10.17487/RFC2608, June 1999, 2493 . 2495 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2496 "Remote Authentication Dial In User Service (RADIUS)", 2497 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2498 . 2500 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2501 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2502 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2503 . 2505 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2506 C., and M. Carney, "Dynamic Host Configuration Protocol 2507 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2508 2003, . 2510 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 2511 for the Simple Network Management Protocol (SNMP)", 2512 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 2513 . 2515 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2516 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2517 DOI 10.17487/RFC4861, September 2007, 2518 . 2520 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2521 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2522 DOI 10.17487/RFC5226, May 2008, 2523 . 2525 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2526 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2527 October 2010, . 2529 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 2530 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 2531 March 2011, . 2533 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2534 and A. Bierman, Ed., "Network Configuration Protocol 2535 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2536 . 2538 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2539 Ed., "Diameter Base Protocol", RFC 6733, 2540 DOI 10.17487/RFC6733, October 2012, 2541 . 2543 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2544 DOI 10.17487/RFC6762, February 2013, 2545 . 2547 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2548 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2549 . 2551 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2552 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2553 DOI 10.17487/RFC6887, April 2013, 2554 . 2556 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 2557 "Requirements for Scalable DNS-Based Service Discovery 2558 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 2559 DOI 10.17487/RFC7558, July 2015, 2560 . 2562 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2563 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2564 Networking: Definitions and Design Goals", RFC 7575, 2565 DOI 10.17487/RFC7575, June 2015, 2566 . 2568 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 2569 Analysis for Autonomic Networking", RFC 7576, 2570 DOI 10.17487/RFC7576, June 2015, 2571 . 2573 [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus 2574 Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, 2575 . 2577 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2578 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2579 2016, . 2581 Appendix A. Open Issues [RFC Editor: Please remove if empty] 2583 o 63. Placeholder 2585 Appendix B. Closed Issues [RFC Editor: Please remove] 2587 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 2588 as message transport mechanisms. This is not clarified yet. UDP 2589 is good for short conversations, is necessary for multicast 2590 discovery, and generally fits the discovery and divert scenarios 2591 well. However, it will cause problems with large messages. TCP 2592 is good for stable and long sessions, with a little bit of time 2593 consumption during the session establishment stage. If messages 2594 exceed a reasonable MTU, a TCP mode will be required in any case. 2595 This question may be affected by the security discussion. 2597 RESOLVED by specifying UDP for short message and TCP for longer 2598 one. 2600 o 2. DTLS or TLS vs built-in security mechanism. For now, this 2601 specification has chosen a PKI based built-in security mechanism 2602 based on asymmetric cryptography. However, (D)TLS might be chosen 2603 as security solution to avoid duplication of effort. It also 2604 allows essentially similar security for short messages over UDP 2605 and longer ones over TCP. The implementation trade-offs are 2606 different. The current approach requires expensive asymmetric 2607 cryptographic calculations for every message. (D)TLS has startup 2608 overheads but cheaper crypto per message. DTLS is less mature 2609 than TLS. 2611 RESOLVED by specifying external security (ACP or (D)TLS). 2613 o The following open issues applied only if the original security 2614 model was retained: 2616 * 2.1. For replay protection, GRASP currently requires every 2617 participant to have an NTP-synchronized clock. Is this OK for 2618 low-end devices, and how does it work during device 2619 bootstrapping? We could take the Timestamp out of signature 2620 option, to become an independent and OPTIONAL (or RECOMMENDED) 2621 option. 2623 * 2.2. The Signature Option states that this option could be any 2624 place in a message. Wouldn't it be better to specify a 2625 position (such as the end)? That would be much simpler to 2626 implement. 2628 RESOLVED by changing security model. 2630 o 3. DoS Attack Protection needs work. 2632 RESOLVED by adding text. 2634 o 4. Should we consider preferring a text-based approach to 2635 discovery (after the initial discovery needed for bootstrapping)? 2636 This could be a complementary mechanism for multicast based 2637 discovery, especially for a very large autonomic network. 2638 Centralized registration could be automatically deployed 2639 incrementally. At the very first stage, the repository could be 2640 empty; then it could be filled in by the objectives discovered by 2641 different devices (for example using Dynamic DNS Update). The 2642 more records are stored in the repository, the less the multicast- 2643 based discovery is needed. However, if we adopt such a mechanism, 2644 there would be challenges: stateful solution, and security. 2646 RESOLVED for now by adding optional use of DNS-SD by ASAs. 2647 Subsequently removed by editors as irrelevant to GRASP istelf. 2649 o 5. Need to expand description of the minimum requirements for the 2650 specification of an individual discovery, synchronization or 2651 negotiation objective. 2653 RESOLVED for now by extra wording. 2655 o 6. Use case and protocol walkthrough. A description of how a 2656 node starts up, performs discovery, and conducts negotiation and 2657 synchronisation for a sample use case would help readers to 2658 understand the applicability of this specification. Maybe it 2659 should be an artificial use case or maybe a simple real one, based 2660 on a conceptual API. However, the authors have not yet decided 2661 whether to have a separate document or have it in the protocol 2662 document. 2664 RESOLVED: recommend a separate document. 2666 o 7. Cross-check against other ANIMA WG documents for consistency 2667 and gaps. 2669 RESOLVED: Satisfied by WGLC. 2671 o 8. Consideration of ADNCP proposal. 2673 RESOLVED by adding optional use of DNCP for flooding-type 2674 synchronization. 2676 o 9. Clarify how a GDNP instance knows whether it is running inside 2677 the ACP. (Sheng) 2679 RESOLVED by improved text. 2681 o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. 2682 (Sheng) 2684 RESOLVED by improved text and declaring DTLS out of scope for this 2685 draft. 2687 o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - 2688 Brian] 2690 RESOLVED by improved text. 2692 o 12. Justify that IP address within ACP or (D)TLS environment is 2693 sufficient to prove AN identity; or explain how Device Identity 2694 Option is used. (Sheng) 2695 RESOLVED for now: we assume that all ASAs in a device are trusted 2696 as soon as the device is trusted, so they share credentials. In 2697 that case the Device Identity Option is useless. This needs to be 2698 reviewed later. 2700 o 13. Emphasise that negotiation/synchronization are independent 2701 from discovery, although the rapid discovery mode includes the 2702 first step of a negotiation/synchronization. (Sheng) 2704 RESOLVED by improved text. 2706 o 14. Do we need an unsolicited flooding mechanism for discovery 2707 (for discovery results that everyone needs), to reduce scaling 2708 impact of flooding discovery messages? (Toerless) 2710 RESOLVED: Yes, added to requirements and solution. 2712 o 15. Do we need flag bits in Objective Options to distinguish 2713 distinguish Synchronization and Negotiation "Request" or rapid 2714 mode "Discovery" messages? (Bing) 2716 RESOLVED: yes, work on the API showed that these flags are 2717 essential. 2719 o 16. (Related to issue 14). Should we revive the "unsolicited 2720 Response" for flooding synchronisation data? This has to be done 2721 carefully due to the well-known issues with flooding, but it could 2722 be useful, e.g. for Intent distribution, where DNCP doesn't seem 2723 applicable. 2725 RESOLVED: Yes, see #14. 2727 o 17. Ensure that the discovery mechanism is completely proof 2728 against loops and protected against duplicate responses. 2730 RESOLVED: Added loop count mechanism. 2732 o 18. Discuss the handling of multiple valid discovery responses. 2734 RESOLVED: Stated that the choice must be available to the ASA but 2735 GRASP implementation should pick a default. 2737 o 19. Should we use a text-oriented format such as JSON/CBOR 2738 instead of native binary TLV format? 2740 RESOLVED: Yes, changed to CBOR. 2742 o 20. Is the Divert option needed? If a discovery response 2743 provides a valid IP address or FQDN, the recipient doesn't gain 2744 any extra knowledge from the Divert. On the other hand, the 2745 presence of Divert informs the receiver that the target is off- 2746 link, which might be useful sometimes. 2748 RESOLVED: Decided to keep Divert option. 2750 o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling 2751 Protocol)? 2753 RESOLVED: Yes, name changed. 2755 o 22. Does discovery mechanism scale robustly as needed? Need hop 2756 limit on relaying? 2758 RESOLVED: Added hop limit. 2760 o 23. Need more details on TTL for caching discovery responses. 2762 RESOLVED: Done. 2764 o 24. Do we need "fast withdrawal" of discovery responses? 2766 RESOLVED: This doesn't seem necessary. If an ASA exits or stops 2767 supporting a given objective, peers will fail to start future 2768 sessions and will simply repeat discovery. 2770 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? 2772 RESOLVED: Decided not to consider this further as a GRASP protocol 2773 issue. GRASP objectives could embed DNS-SD formats if needed. 2775 o 26. Add a URL type to the locator options (for security bootstrap 2776 etc.) 2778 RESOLVED: Done, later renamed as URI. 2780 o 27. Security of Flood multicasts (Section 3.5.6.1). 2782 RESOLVED: added text. 2784 o 28. Does ACP support secure link-local multicast? 2786 RESOLVED by new text in the Security Considerations. 2788 o 29. PEN is used to distinguish vendor options. Would it be 2789 better to use a domain name? Anything unique will do. 2791 RESOLVED: Simplified this by removing PEN field and changing 2792 naming rules for objectives. 2794 o 30. Does response to discovery require randomized delays to 2795 mitigate amplification attacks? 2797 RESOLVED: WG feedback is that it's unnecessary. 2799 o 31. We have specified repeats for failed discovery etc. Is that 2800 sufficient to deal with sleeping nodes? 2802 RESOLVED: WG feedback is that it's unnecessary to say more. 2804 o 32. We have one-to-one synchronization and flooding 2805 synchronization. Do we also need selective flooding to a subset 2806 of nodes? 2808 RESOLVED: This will be discussed as a protocol extension in a 2809 separate draft (draft-liu-anima-grasp-distribution). 2811 o 33. Clarify if/when discovery needs to be repeated. 2813 RESOLVED: Done. 2815 o 34. Clarify what is mandatory for running in ACP, expand 2816 discussion of security boundary when running with no ACP - might 2817 rely on the local PKI infrastructure. 2819 RESOLVED: Done. 2821 o 35. State that role-based authorization of ASAs is out of scope 2822 for GRASP. GRASP doesn't recognize/handle any "roles". 2824 RESOLVED: Done. 2826 o 36. Reconsider CBOR definition for PEN syntax. ( objective-name 2827 = text / [pen, text] ; pen = uint ) 2829 RESOLVED: See issue 29. 2831 o 37. Are URI locators really needed? 2833 RESOLVED: Yes, e.g. for security bootstrap discovery, but added 2834 note that addresses are the normal case (same for FQDN locators). 2836 o 38. Is Session ID sufficient to identify relayed responses? 2837 Isn't the originator's address needed too? 2838 RESOLVED: Yes, this is needed for multicast messages and their 2839 responses. 2841 o 39. Clarify that a node will contain one GRASP instance 2842 supporting multiple ASAs. 2844 RESOLVED: Done. 2846 o 40. Add a "reason" code to the DECLINE option? 2848 RESOLVED: Done. 2850 o 41. What happens if an ASA cannot conveniently use one of the 2851 GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) 2852 simply pass the discovery results to the ASA so that it can open 2853 its own socket? 2855 RESOLVED: Both would be possible, but (b) is preferred. 2857 o 42. Do we need a feature whereby an ASA can bypass the ACP and 2858 use the data plane for efficiency/throughput? This would require 2859 discovery to return non-ACP addresses and would evade ACP 2860 security. 2862 RESOLVED: This is considered out of scope for GRASP, but a comment 2863 has been added in security considerations. 2865 o 43. Rapid mode synchronization and negotiation is currently 2866 limited to a single objective for simplicity of design and 2867 implementation. A future consideration is to allow multiple 2868 objectives in rapid mode for greater efficiency. 2870 RESOLVED: This is considered out of scope for this version. 2872 o 44. In requirement T9, the words that encryption "may not be 2873 required in all deployments" were removed. Is that OK?. 2875 RESOLVED: No objections. 2877 o 45. Device Identity Option is unused. Can we remove it 2878 completely?. 2880 RESOLVED: No objections. Done. 2882 o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD 2883 messages is intended to assist in loop prevention. However, we 2884 also have the loop count for that. Also, if we create a new 2885 Session ID each time a DISCOVER or FLOOD is relayed, that ID can 2886 be disambiguated by recipients. It would be simpler to remove the 2887 initiator from the messages, making parsing more uniform. Is that 2888 OK? 2890 RESOLVED: Yes. Done. 2892 o 47. REQUEST is a dual purpose message (request negotiation or 2893 request synchronization). Would it be better to split this into 2894 two different messages (and adjust various message names 2895 accordingly)? 2897 RESOLVED: Yes. Done. 2899 o 48. Should the Appendix "Capability Analysis of Current 2900 Protocols" be deleted before RFC publication? 2902 RESOLVED: No (per WG meeting at IETF 96). 2904 o 49. Section 3.5.1 Should say more about signaling between two 2905 autonomic networks/domains. 2907 RESOLVED: Description of separate GRASP instance added. 2909 o 50. Is Rapid mode limited to on-link only? What happens if first 2910 discovery responder does not support Rapid Mode? Section 3.5.5, 2911 Section 3.5.6) 2913 RESOLVED: Not limited to on-link. First responder wins. 2915 o 51. Should flooded objectives have a time-to-live before they are 2916 deleted from the flood cache? And should they be tagged in the 2917 cache with their source locator? 2919 RESOLVED: TTL added to Flood (and Discovery Response) messages. 2920 Cached flooded objectives must be tagged with their originating 2921 ASA locator, and multiple copies must be kept if necessary. 2923 o 52. Describe in detail what is allowed and disallowed in an 2924 insecure instance of GRASP. 2926 RESOLVED: Done. 2928 o 53. Tune IANA Considerations to support early assignment request. 2930 o 54. Is there a highly unlikely race condition if two peers 2931 simultaneously choose the same Session ID and send each other 2932 simultaneous M_REQ_NEG messages? 2933 RESOLVED: Yes. Enhanced text on Session ID generation, and added 2934 precaution when receiving a Request message. 2936 o 55. Could discovery be performed over TCP? 2938 RESOLVED: Unicast discovery added as an option. 2940 o 56. Change Session-ID to 32 bits? 2942 RESOLVED: Done. 2944 o 57. Add M_INVALID message? 2946 RESOLVED: Done. 2948 o 58. Maximum message size? 2950 RESOLVED by specifying default maximum message size (2048 bytes). 2952 o 59. Add F_NEG_DRY flag to specify a "dry run" objective?. 2954 RESOLVED: Done. 2956 o 60. Change M_FLOOD syntax to associate a locator with each 2957 objective? 2959 RESOLVED: Done. 2961 o 61. Is the SONN constrained instance really needed? 2963 RESOLVED: Retained but only as an option. 2965 o 62. Is it helpful to tag descriptive text with message names 2966 (M_DISCOVER etc.)? 2968 RESOLVED: Yes, done in various parts of the text. 2970 Appendix C. Change log [RFC Editor: Please remove] 2972 draft-ietf-anima-grasp-09, 2016-12-15: 2974 Protocol change: Add F_NEG_DRY flag to specify a "dry run" objective. 2976 Protocol change: Change M_FLOOD syntax to associate a locator with 2977 each objective. 2979 Concentrated mentions of TLS in one section, with all details out of 2980 scope. 2982 Clarified text around constrained instances of GRASP. 2984 Strengthened text restricting LL addresses in locator options. 2986 Clarified description of rapid mode processsing. 2988 Specified that cached discovery results should not be returned on the 2989 same interface where they were learned. 2991 Shortened text in "High Level Design Choices" 2993 Dropped the word 'kernel' to avoid confusion with o/s kernel mode. 2995 Editorial improvements and clarifications. 2997 draft-ietf-anima-grasp-08, 2016-10-30: 2999 Protocol change: Added M_INVALID message. 3001 Protocol change: Increased Session ID space to 32 bits. 3003 Enhanced rules to avoid Session ID clashes. 3005 Corrected and completed description of timeouts for Request messages. 3007 Improved wording about exponential backoff and DoS. 3009 Clarified that discovery relaying is not done by limited security 3010 instances. 3012 Corrected and expanded explanation of port used for Discovery 3013 Response. 3015 Noted that Discovery message could be sent unicast in special cases. 3017 Added paragraph on extensibility. 3019 Specified default maximum message size. 3021 Added Appendix for sample messages. 3023 Added short protocol overview. 3025 Editorial fixes, including minor re-ordering for readability. 3027 draft-ietf-anima-grasp-07, 2016-09-13: 3029 Protocol change: Added TTL field to Flood message (issue 51). 3031 Protocol change: Added Locator option to Flood message (issue 51). 3033 Protocol change: Added TTL field to Discovery Response message 3034 (corrollary to issue 51). 3036 Clarified details of rapid mode (issues 43 and 50). 3038 Description of inter-domain GRASP instance added (issue 49). 3040 Description of limited security GRASP instances added (issue 52). 3042 Strengthened advice to use TCP rather than UDP. 3044 Updated IANA considerations and text about well-known port usage 3045 (issue 53). 3047 Amended text about ASA authorization and roles to allow for 3048 overlapping ASAs. 3050 Added text recommending that Flood should be repeated periodically. 3052 Editorial fixes. 3054 draft-ietf-anima-grasp-06, 2016-06-27: 3056 Added text on discovery cache timeouts. 3058 Noted that ASAs that are only initiators do not need to respond to 3059 discovery message. 3061 Added text on unexpected address changes. 3063 Added text on robust implementation. 3065 Clarifications and editorial fixes for numerous review comments 3067 Added open issues for some review comments. 3069 draft-ietf-anima-grasp-05, 2016-05-13: 3071 Noted in requirement T1 that it should be possible to implement ASAs 3072 independently as user space programs. 3074 Protocol change: Added protocol number and port to discovery 3075 response. Updated protocol description, CDDL and IANA considerations 3076 accordingly. 3078 Clarified that discovery and flood multicasts are handled by the 3079 GRASP core, not directly by ASAs. 3081 Clarified that a node may discover an objective without supporting it 3082 for synchronization or negotiation. 3084 Added Implementation Status section. 3086 Added reference to SCSP. 3088 Editorial fixes. 3090 draft-ietf-anima-grasp-04, 2016-03-11: 3092 Protocol change: Restored initiator field in certain messages and 3093 adjusted relaying rules to provide complete loop detection. 3095 Updated IANA Considerations. 3097 draft-ietf-anima-grasp-03, 2016-02-24: 3099 Protocol change: Removed initiator field from certain messages and 3100 adjusted relaying requirement to simplify loop detection. Also 3101 clarified narrative explanation of discovery relaying. 3103 Protocol change: Split Request message into two (Request Negotiation 3104 and Request Synchronization) and updated other message names for 3105 clarity. 3107 Protocol change: Dropped unused Device ID option. 3109 Further clarified text on transport layer usage. 3111 New text about multicast insecurity in Security Considerations. 3113 Various other clarifications and editorial fixes, including moving 3114 some material to Appendix. 3116 draft-ietf-anima-grasp-02, 2016-01-13: 3118 Resolved numerous issues according to WG discussions. 3120 Renumbered requirements, added D9. 3122 Protocol change: only allow one objective in rapid mode. 3124 Protocol change: added optional error string to DECLINE option. 3126 Protocol change: removed statement that seemed to say that a Request 3127 not preceded by a Discovery should cause a Discovery response. That 3128 made no sense, because there is no way the initiator would know where 3129 to send the Request. 3131 Protocol change: Removed PEN option from vendor objectives, changed 3132 naming rule accordingly. 3134 Protocol change: Added FLOOD message to simplify coding. 3136 Protocol change: Added SYNCH message to simplify coding. 3138 Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD 3139 messages. But also allowed the relay process for DISCOVER and FLOOD 3140 to regenerate a Session ID. 3142 Protocol change: Require that discovered addresses must be global 3143 (except during bootstrap). 3145 Protocol change: Receiver of REQUEST message must close socket if no 3146 ASA is listening for the objective. 3148 Protocol change: Simplified Waiting message. 3150 Protocol change: Added No Operation message. 3152 Renamed URL locator type as URI locator type. 3154 Updated CDDL definition. 3156 Various other clarifications and editorial fixes. 3158 draft-ietf-anima-grasp-01, 2015-10-09: 3160 Updated requirements after list discussion. 3162 Changed from TLV to CBOR format - many detailed changes, added co- 3163 author. 3165 Tightened up loop count and timeouts for various cases. 3167 Noted that GRASP does not provide transactional integrity. 3169 Various other clarifications and editorial fixes. 3171 draft-ietf-anima-grasp-00, 2015-08-14: 3173 File name and protocol name changed following WG adoption. 3175 Added URL locator type. 3177 draft-carpenter-anima-gdn-protocol-04, 2015-06-21: 3179 Tuned wording around hierarchical structure. 3181 Changed "device" to "ASA" in many places. 3183 Reformulated requirements to be clear that the ASA is the main 3184 customer for signaling. 3186 Added requirement for flooding unsolicited synch, and added it to 3187 protocol spec. Recognized DNCP as alternative for flooding synch 3188 data. 3190 Requirements clarified, expanded and rearranged following design team 3191 discussion. 3193 Clarified that GDNP discovery must not be a prerequisite for GDNP 3194 negotiation or synchronization (resolved issue 13). 3196 Specified flag bits for objective options (resolved issue 15). 3198 Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 3199 9,10,11). 3201 Updated DNCP description from latest DNCP draft. 3203 Editorial improvements. 3205 draft-carpenter-anima-gdn-protocol-03, 2015-04-20: 3207 Removed intrinsic security, required external security 3209 Format changes to allow DNCP co-existence 3211 Recognized DNS-SD as alternative discovery method. 3213 Editorial improvements 3215 draft-carpenter-anima-gdn-protocol-02, 2015-02-19: 3217 Tuned requirements to clarify scope, 3219 Clarified relationship between types of objective, 3221 Clarified that objectives may be simple values or complex data 3222 structures, 3223 Improved description of objective options, 3225 Added loop-avoidance mechanisms (loop count and default timeout, 3226 limitations on discovery relaying and on unsolicited responses), 3228 Allow multiple discovery objectives in one response, 3230 Provided for missing or multiple discovery responses, 3232 Indicated how modes such as "dry run" should be supported, 3234 Minor editorial and technical corrections and clarifications, 3236 Reorganized future work list. 3238 draft-carpenter-anima-gdn-protocol-01, restructured the logical flow 3239 of the document, updated to describe synchronization completely, add 3240 unsolicited responses, numerous corrections and clarifications, 3241 expanded future work list, 2015-01-06. 3243 draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- 3244 config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 3245 02, 2014-10-08. 3247 Appendix D. Example Message Formats 3249 For readers unfamiliar with CBOR, this appendix shows a number of 3250 example GRASP messages conforming to the CDDL syntax given in 3251 Section 6. Each message is shown three times in the following 3252 formats: 3254 1. CBOR diagnostic notation. 3256 2. Similar, but showing the names of the constants. (Details of the 3257 flag bit encoding are omitted.) 3259 3. Hexadecimal version of the CBOR wire format. 3261 Long lines are split for display purposes only. 3263 D.1. Discovery Example 3265 The initiator (2001:db8:f000:baaa:28cc:dc4c:9703:6781) multicasts a 3266 discovery message looking for objective EX1: 3268 [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 5, 2, 0]] 3269 [M_DISCOVERY, 13948744, h'20010db8f000baaa28ccdc4c97036781', 3270 ["EX1", F_SYNCH_bits, 2, 0]] 3271 h'84011a00d4d7485020010db8f000baaa28ccdc4c970367818463455831050200' 3273 A peer (2001:0db8:f000:baaa:f000:baaa:f000:baaa) responds with a 3274 locator: 3276 [2, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000, 3277 [103, h'20010db8f000baaaf000baaaf000baaa', 6, 49443]] 3278 [M_RESPONSE, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000, 3279 [O_IPv6_LOCATOR, h'20010db8f000baaaf000baaaf000baaa', 3280 IPPROTO_TCP, 49443]] 3281 h'85021a00d4d7485020010db8f000baaa28ccdc4c9703678119ea6084186750 3282 20010db8f000baaaf000baaaf000baaa0619c123' 3284 D.2. Flood Example 3286 The initiator multicasts a flood message. The single objective has a 3287 null locator. There is no response: 3289 [9, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000, 3290 [["EX1", 5, 2, ["Example 1 value=", 100]],[] ] ] 3291 [M_FLOOD, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000, 3292 [["EX1", F_SYNCH_bits, 2, ["Example 1 value=", 100]],[] ] ] 3293 h'86091a00357b4e5020010db8f000baaa28ccdc4c97036781192710 3294 828463455831050282704578616d706c6520312076616c75653d186480' 3296 D.3. Synchronization Example 3298 Following successful discovery of objective EX2, the initiator 3299 unicasts a request: 3301 [4, 4038926, ["EX2", 5, 5, 0]] 3302 [M_REQ_SYN, 4038926, ["EX2", F_SYNCH_bits, 5, 0]] 3303 h'83041a003da10e8463455832050500' 3305 The peer responds with a value: 3307 [8, 4038926, ["EX2", 5, 5, ["Example 2 value=", 200]]] 3308 [M_SYNCH, 4038926, ["EX2", F_SYNCH_bits, 5, ["Example 2 value=", 200]]] 3309 h'83081a003da10e8463455832050582704578616d706c6520322076616c75653d18c8' 3311 D.4. Simple Negotiation Example 3313 Following successful discovery of objective EX3, the initiator 3314 unicasts a request: 3316 [3, 802813, ["EX3", 3, 6, ["NZD", 47]]] 3317 [M_REQ_NEG, 802813, ["EX3", F_NEG_bits, 6, ["NZD", 47]]] 3318 h'83031a000c3ffd8463455833030682634e5a44182f' 3320 The peer responds with immediate acceptance. Note that no objective 3321 is needed, because the initiator's request was accepted without 3322 change: 3324 [6, 802813, [101]] 3325 [M_END , 802813, [O_ACCEPT]] 3326 h'83061a000c3ffd811865' 3328 D.5. Complete Negotiation Example 3330 Again the initiator unicasts a request: 3332 [3, 13767778, ["EX3", 3, 6, ["NZD", 410]]] 3333 [M_REQ_NEG, 13767778, ["EX3", F_NEG_bits, 6, ["NZD", 410]]] 3334 h'83031a00d214628463455833030682634e5a4419019a' 3336 The responder starts to negotiate (making an offer): 3338 [5, 13767778, ["EX3", 3, 6, ["NZD", 80]]] 3339 [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 6, ["NZD", 80]]] 3340 h'83051a00d214628463455833030682634e5a441850' 3342 The initiator continues to negotiate (reducing its request, and note 3343 that the loop count is decremented): 3345 [5, 13767778, ["EX3", 3, 5, ["NZD", 307]]] 3346 [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 5, ["NZD", 307]]] 3347 h'83051a00d214628463455833030582634e5a44190133' 3349 The responder asks for more time: 3351 [7, 13767778, 34965] 3352 [M_WAIT, 13767778, 34965] 3353 h'83071a00d21462198895' 3355 The responder continues to negotiate (increasing its offer): 3357 [5, 13767778, ["EX3", 3, 4, ["NZD", 120]]] 3358 [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 4, ["NZD", 120]]] 3359 h'83051a00d214628463455833030482634e5a441878' 3361 The initiator continues to negotiate (reducing its request): 3363 [5, 13767778, ["EX3", 3, 3, ["NZD", 246]]] 3364 [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 3, ["NZD", 246]]] 3365 h'83051a00d214628463455833030382634e5a4418f6' 3367 The responder refuses to negotiate further: 3369 [6, 13767778, [102, "Insufficient funds"]] 3370 [M_END , 13767778, [O_DECLINE, "Insufficient funds"]] 3371 h'83061a00d2146282186672496e73756666696369656e742066756e6473' 3373 This negotiation has failed. If either side had sent [M_END, 3374 13767778, [O_ACCEPT]] it would have succeeded, converging on the 3375 objective value in the preceding M_NEGOTIATE. Note that apart from 3376 the initial M_REQ_NEG, the process is symmetrical. 3378 Appendix E. Capability Analysis of Current Protocols 3380 This appendix discusses various existing protocols with properties 3381 related to the requirements described in Section 2. The purpose is 3382 to evaluate whether any existing protocol, or a simple combination of 3383 existing protocols, can meet those requirements. 3385 Numerous protocols include some form of discovery, but these all 3386 appear to be very specific in their applicability. Service Location 3387 Protocol (SLP) [RFC2608] provides service discovery for managed 3388 networks, but requires configuration of its own servers. DNS-SD 3389 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 3390 small networks with a single link layer. [RFC7558] aims to extend 3391 this to larger autonomous networks but this is not yet standardized. 3392 However, both SLP and DNS-SD appear to target primarily application 3393 layer services, not the layer 2 and 3 objectives relevant to basic 3394 network configuration. Both SLP and DNS-SD are text-based protocols. 3396 Routing protocols are mainly one-way information announcements. The 3397 receiver makes independent decisions based on the received 3398 information and there is no direct feedback information to the 3399 announcing peer. This remains true even though the protocol is used 3400 in both directions between peer routers; there is state 3401 synchronization, but no negotiation, and each peer runs its route 3402 calculations independently. 3404 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 3405 response model not well suited for peer negotiation. Network 3406 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 3407 does allow positive or negative responses from the target system, but 3408 this is still not adequate for negotiation. 3410 There are various existing protocols that have elementary negotiation 3411 abilities, such as Dynamic Host Configuration Protocol for IPv6 3412 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 3413 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 3414 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 3415 configuration or management protocols. However, they either provide 3416 only a simple request/response model in a master/slave context or 3417 very limited negotiation abilities. 3419 There are some signaling protocols with an element of negotiation. 3420 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 3421 designed for negotiating quality of service parameters along the path 3422 of a unicast or multicast flow. RSVP is a very specialised protocol 3423 aimed at end-to-end flows. However, it has some flexibility, having 3424 been extended for MPLS label distribution [RFC3209]. A more generic 3425 design is General Internet Signalling Transport (GIST) [RFC5971], but 3426 it is complex, tries to solve many problems, and is also aimed at 3427 per-flow signaling across many hops rather than at device-to-device 3428 signaling. However, we cannot completely exclude extended RSVP or 3429 GIST as a synchronization and negotiation protocol. They do not 3430 appear to be directly useable for peer discovery. 3432 We now consider two protocols that are works in progress at the time 3433 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 3434 protocol intended to convey NETCONF information expressed in the YANG 3435 language via HTTP, including the ability to transit HTML 3436 intermediaries. While this is a powerful approach in the context of 3437 centralised configuration of a complex network, it is not well 3438 adapted to efficient interactive negotiation between peer devices, 3439 especially simple ones that might not include YANG processing 3440 already. 3442 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 3443 [RFC7787]. This is defined as a generic form of state 3444 synchronization protocol, with a proposed usage profile being the 3445 Home Networking Control Protocol (HNCP) [RFC7788] for configuring 3446 Homenet routers. A specific application of DNCP for autonomic 3447 networking was proposed in [I-D.stenberg-anima-adncp]. 3449 DNCP "is designed to provide a way for each participating node to 3450 publish a set of TLV (Type-Length-Value) tuples, and to provide a 3451 shared and common view about the data published... DNCP is most 3452 suitable for data that changes only infrequently... If constant rapid 3453 state changes are needed, the preferable choice is to use an 3454 additional point-to-point channel..." 3456 Specific features of DNCP include: 3458 o Every participating node has a unique node identifier. 3460 o DNCP messages are encoded as a sequence of TLV objects, sent over 3461 unicast UDP or TCP, with or without (D)TLS security. 3463 o Multicast is used only for discovery of DNCP neighbors when lower 3464 security is acceptable. 3466 o Synchronization of state is maintained by a flooding process using 3467 the Trickle algorithm. There is no bilateral synchronization or 3468 negotiation capability. 3470 o The HNCP profile of DNCP is designed to operate between directly 3471 connected neighbors on a shared link using UDP and link-local IPv6 3472 addresses. 3474 DNCP does not meet the needs of a general negotiation protocol, 3475 because it is designed specifically for flooding synchronization. 3476 Also, in its HNCP profile it is limited to link-local messages and to 3477 IPv6. However, at the minimum it is a very interesting test case for 3478 this style of interaction between devices without needing a central 3479 authority, and it is a proven method of network-wide state 3480 synchronization by flooding. 3482 The Server Cache Synchronization Protocol (SCSP) [RFC2334] also 3483 describes a method for cache synchronization and cache replication 3484 among a group of nodes. 3486 A proposal was made some years ago for an IP based Generic Control 3487 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 3488 information exchange and negotiation but not directly at peer 3489 discovery. However, it has many points in common with the present 3490 work. 3492 None of the above solutions appears to completely meet the needs of 3493 generic discovery, state synchronization and negotiation in a single 3494 solution. Many of the protocols assume that they are working in a 3495 traditional top-down or north-south scenario, rather than a fluid 3496 peer-to-peer scenario. Most of them are specialized in one way or 3497 another. As a result, we have not identified a combination of 3498 existing protocols that meets the requirements in Section 2. Also, 3499 we have not identified a path by which one of the existing protocols 3500 could be extended to meet the requirements. 3502 Authors' Addresses 3504 Carsten Bormann 3505 Universitaet Bremen TZI 3506 Postfach 330440 3507 D-28359 Bremen 3508 Germany 3510 Email: cabo@tzi.org 3512 Brian Carpenter (editor) 3513 Department of Computer Science 3514 University of Auckland 3515 PB 92019 3516 Auckland 1142 3517 New Zealand 3519 Email: brian.e.carpenter@gmail.com 3521 Bing Liu (editor) 3522 Huawei Technologies Co., Ltd 3523 Q14, Huawei Campus 3524 No.156 Beiqing Road 3525 Hai-Dian District, Beijing 100095 3526 P.R. China 3528 Email: leo.liubing@huawei.com