idnits 2.17.1 draft-ietf-anima-grasp-08.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 (October 30, 2016) is 2734 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 3272 -- Looks like a reference, but probably isn't: '13767778' on line 3272 -- Looks like a reference, but probably isn't: '34965' on line 3272 == 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-03 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-03 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-02 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-01 == Outdated reference: A later version (-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: May 3, 2017 Univ. of Auckland 6 B. Liu, Ed. 7 Huawei Technologies Co., Ltd 8 October 30, 2016 10 A Generic Autonomic Signaling Protocol (GRASP) 11 draft-ietf-anima-grasp-08 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 May 3, 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 . . . . . 17 71 3.5.1. Required External Security Mechanism . . . . . . . . 17 72 3.5.2. Limited Security 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 . . . . . . . . . . . . . . . . 28 82 3.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 29 83 3.8.4. Discovery Message . . . . . . . . . . . . . . . . . . 29 84 3.8.5. Discovery Response Message . . . . . . . . . . . . . 31 85 3.8.6. Request Messages . . . . . . . . . . . . . . . . . . 31 86 3.8.7. Negotiation Message . . . . . . . . . . . . . . . . . 32 87 3.8.8. Negotiation End Message . . . . . . . . . . . . . . . 33 88 3.8.9. Confirm Waiting Message . . . . . . . . . . . . . 33 89 3.8.10. Synchronization Message . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . . . . . 35 94 3.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 35 95 3.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 36 96 3.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 36 97 3.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 36 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 . . . . 40 103 3.10.4. Organizing of Objective Options . . . . . . . . . . 41 104 3.10.5. Experimental and Example Objective Options . . . . . 42 105 4. Implementation Status [RFC Editor: please remove] . . . . . . 42 106 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 42 107 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 43 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 44 109 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 46 110 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 111 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 113 9.1. Normative References . . . . . . . . . . . . . . . . . . 50 114 9.2. Informative References . . . . . . . . . . . . . . . . . 51 115 Appendix A. Open Issues [RFC Editor: Please remove if empty] . . 54 116 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 54 117 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 62 118 Appendix D. Example Message Formats . . . . . . . . . . . . . . 67 119 D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 68 120 D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 68 121 D.3. Synchronization Example . . . . . . . . . . . . . . . . . 68 122 D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 69 123 D.5. Complete Negotiation Example . . . . . . . . . . . . . . 69 124 Appendix E. Capability Analysis of Current Protocols . . . . . . 70 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 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 in the case of a constrained-node 274 network [RFC7228]. 276 D9. There must be a mechanism for handling stale discovery results. 278 2.2. Requirements for Synchronization and Negotiation Capability 280 As background, consider the example of routing protocols, the closest 281 approximation to autonomic networking already in widespread use. 282 Routing protocols use a largely autonomic model based on distributed 283 devices that communicate repeatedly with each other. The focus is 284 reachability, so current routing protocols mainly consider simple 285 link status, i.e., up or down, and an underlying assumption is that 286 all nodes need a consistent view of the network topology in order for 287 the routing algorithm to converge. Thus, routing is mainly based on 288 information synchronization between peers, rather than on bi- 289 directional negotiation. Other information, such as latency, 290 congestion, capacity, and particularly unused capacity, would be 291 helpful to get better path selection and utilization rate, but is not 292 normally used in distributed routing algorithms. Additionally, 293 autonomic networks need to be able to manage many more dimensions, 294 such as security settings, power saving, load balancing, etc. Status 295 information and traffic metrics need to be shared between nodes for 296 dynamic adjustment of resources and for monitoring purposes. While 297 this might be achieved by existing protocols when they are available, 298 the new protocol needs to be able to support parameter exchange, 299 including mutual synchronization, even when no negotiation as such is 300 required. In general, these parameters do not apply to all 301 participating nodes, but only to a subset. 303 SN1. A basic requirement for the protocol is therefore the ability 304 to represent, discover, synchronize and negotiate almost any kind of 305 network parameter among selected subsets of participating nodes. 307 SN2. Negotiation is a request/response process that must be 308 guaranteed to terminate (with success or failure) and if necessary it 309 must contain tie-breaking rules for each technical objective that 310 requires them. While these must be defined specifically for each use 311 case, the protocol should have some general mechanisms in support of 312 loop and deadlock prevention, such as hop count limits or timeouts. 314 SN3. Synchronization might concern small groups of nodes or very 315 large groups. Different solutions might be needed at different 316 scales. 318 SN4. To avoid "reinventing the wheel", the protocol should be able 319 to encapsulate the data formats used by existing configuration 320 protocols (such as NETCONF/YANG) in cases where that is convenient. 322 SN5. Human intervention in complex situations is costly and error- 323 prone. Therefore, synchronization or negotiation of parameters 324 without human intervention is desirable whenever the coordination of 325 multiple devices can improve overall network performance. It 326 therefore follows that the protocol, as part of the Autonomic 327 Networking Infrastructure, should be capable of running in any device 328 that would otherwise need human intervention. The issue of running 329 in constrained nodes is discussed in 330 [I-D.ietf-anima-reference-model]. 332 SN6. Human intervention in large networks is often replaced by use 333 of a top-down network management system (NMS). It therefore follows 334 that the protocol, as part of the Autonomic Networking 335 Infrastructure, should be capable of running in any device that would 336 otherwise be managed by an NMS, and that it can co-exist with an NMS, 337 and with protocols such as SNMP and NETCONF. 339 SN7. Some features are expected to be implemented by individual 340 ASAs, but the protocol must be general enough to allow them: 342 o Dependencies and conflicts: In order to decide a configuration on 343 a given device, the device may need information from neighbors. 344 This can be established through the negotiation procedure, or 345 through synchronization if that is sufficient. However, a given 346 item in a neighbor may depend on other information from its own 347 neighbors, which may need another negotiation or synchronization 348 procedure to obtain or decide. Therefore, there are potential 349 dependencies and conflicts among negotiation or synchronization 350 procedures. Resolving dependencies and conflicts is a matter for 351 the individual ASAs involved. To allow this, there need to be 352 clear boundaries and convergence mechanisms for negotiations. 353 Also some mechanisms are needed to avoid loop dependencies. In 354 such a case, the protocol's role is limited to bilateral signaling 355 between ASAs. 357 o Recovery from faults and identification of faulty devices should 358 be as automatic as possible. The protocol's role is limited to 359 the ability to handle discovery, synchronization and negotiation 360 at any time, in case an ASA detects an anomaly such as a 361 negotiation 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 value. 482 Normally, a given objective will not occur in negotiation and 483 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: if a node needs to synchronize or 495 negotiate a specific objective but does not know a peer that 496 supports this objective, it starts a discovery process. The 497 objective is called a Discovery Objective during this process. 499 * Synchronization Objective: an objective whose specific 500 technical content needs to be synchronized among two or more 501 ASAs. 503 * Negotiation Objective: an objective whose specific technical 504 content needs to be decided in coordination with another ASA. 506 o Discovery Initiator: an ASA that spontaneously starts discovery by 507 sending a discovery message referring to a specific discovery 508 objective. 510 o Discovery Responder: a peer that either contains an ASA supporting 511 the discovery objective indicated by the discovery initiator, or 512 caches the locator(s) of the ASA(s) supporting the objective. The 513 locator(s) are indicated in a Discovery Response, which is 514 normally sent by the protocol kernel, 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 running in kernel mode. For 548 further details of possible deployment models, see 549 [I-D.ietf-anima-reference-model]. 551 A GRASP instance must be aware of its network interfaces, and of its 552 own global-scope and link-local addresses. In the presence of the 553 ACP, such information will be available from the adjacency table 554 discussed in [I-D.ietf-anima-reference-model]. In other cases, GRASP 555 must determine such information for itself. Details depend on the 556 operating system. 558 Because GRASP needs to work whatever happens, especially during 559 bootstrapping and during fault conditions, it is essential that every 560 implementation is as robust as possible. For example, discovery 561 failures, or any kind of socket error at any time, must not cause 562 irrecoverable failures in GRASP itself, and must return suitable 563 error codes through the API so that ASAs can also recover. 565 GRASP must always start up correctly after a system restart. All run 566 time error conditions, and events such as address renumbering, 567 network interface failures, and CPU sleep/wake cycles, must be 568 handled in such a way that GRASP will still operate correctly and 569 securely (Section 3.5.1) afterwards. 571 An autonomic node will normally run a single instance of GRASP, used 572 by multiple ASAs. However, scenarios where multiple instances of 573 GRASP run in a single node, perhaps with different security 574 properties, are not excluded. In this case, each instance MUST 575 listen independently for GRASP link-local multicasts in order for 576 discovery and flooding to work correctly. 578 3.3. High Level Design Choices 580 This section describes a behavior model and design considerations for 581 GRASP, supporting discovery, synchronization and negotiation, to act 582 as a platform for different technical objectives. 584 o A generic platform 586 The protocol is designed as a generic platform, which is 587 independent from the synchronization or negotiation contents. It 588 takes care of the general intercommunication between counterparts. 589 The technical contents will vary according to the various 590 technical objectives and the different pairs of counterparts. 592 o The protocol is expected to form part of an Autonomic Networking 593 Infrastructure [I-D.ietf-anima-reference-model]. It will provide 594 services to ASAs via a suitable application programming interface 595 (API), which will reflect the protocol elements but will not 596 necessarily be in one-to-one correspondence to them. This API is 597 out of scope for the present document. 599 o It is normally expected that a single main instance of GRASP will 600 exist in an autonomic node, and that the protocol engine and each 601 ASA will run as independent asynchronous processes. However, 602 separate GRASP instances may exist for security reasons 603 (Section 3.5.2). 605 o Security infrastructure and trust relationship 607 Because this negotiation protocol may directly cause changes to 608 device configurations and bring significant impacts to a running 609 network, this protocol is assumed to run within an existing secure 610 environment with strong authentication. As a design choice, the 611 protocol itself is not provided with built-in security 612 functionality. 614 On the other hand, a limited negotiation model might be deployed 615 based on a limited trust relationship. For example, between two 616 administrative domains, ASAs might also exchange limited 617 information and negotiate some particular configurations based on 618 a limited conventional or contractual trust relationship. 620 o Discovery, synchronization and negotiation are designed together. 622 The discovery method and the synchronization and negotiation 623 methods are designed in the same way and can be combined when this 624 is useful. These processes can also be performed independently 625 when appropriate. 627 * GRASP discovery is always available for efficient discovery of 628 GRASP peers and allows a rapid mode of operation described in 629 Section 3.5.4. For some objectives, especially those concerned 630 with application layer services, another discovery mechanism 631 such as the future DNS Service Discovery [RFC7558] or Service 632 Location Protocol [RFC2608] MAY be used. The choice is left to 633 the designers of individual ASAs. 635 o A uniform pattern for technical contents 637 The synchronization and negotiation contents are defined according 638 to a uniform pattern. They could be carried either in simple 639 binary format or in payloads described by a flexible language. 640 The basic protocol design uses the Concise Binary Object 641 Representation (CBOR) [RFC7049]. The format is extensible for 642 unknown future requirements. 644 o A flexible model for synchronization 646 GRASP supports bilateral synchronization, which could be used to 647 perform synchronization among a small number of nodes. It also 648 supports an unsolicited flooding mode when large groups of nodes, 649 possibly including all autonomic nodes, need data for the same 650 technical objective. 652 * There may be some network parameters for which a more 653 traditional flooding mechanism such as DNCP [RFC7787] is 654 considered more appropriate. GRASP can coexist with DNCP. 656 o A simple initiator/responder model for negotiation 658 Multi-party negotiations are too complicated to be modeled and 659 there might be too many dependencies among the parties to converge 660 efficiently. A simple initiator/responder model is more feasible 661 and can complete multi-party negotiations by indirect steps. 663 o Organizing of synchronization or negotiation content 664 Naturally, the technical content will be organized according to 665 the relevant function or service. The content from different 666 functions or services is kept independent from each other. They 667 are not combined into a single option or single session because 668 these contents may be negotiated or synchronized with different 669 counterparts or may be different in response time. Thus a normal 670 arrangement would be a single ASA managing a small set of closely 671 related objectives, with a version of that ASA in each relevant 672 autonomic node. Further discussion of this aspect is out of scope 673 for the current document. 675 o Requests and responses in negotiation procedures 677 The initiator can negotiate with its relevant negotiation 678 counterpart ASAs, which may be different according to the specific 679 negotiation objective. It can request relevant information from 680 the negotiation counterpart so that it can decide its local 681 configuration to give the most coordinated performance. It can 682 request the negotiation counterpart to make a matching 683 configuration in order to set up a successful communication with 684 it. It can request certain simulation or forecast results by 685 sending some dry run conditions. 687 Beyond the traditional yes/no answer, the responder can reply with 688 a suggested alternative value for the objective concerned. This 689 would start a bi-directional negotiation ending in a compromise 690 between the two ASAs. 692 o Convergence of negotiation procedures 694 To enable convergence, when a responder makes a suggestion of a 695 changed condition in a negative reply, it should be as close as 696 possible to the original request or previous suggestion. The 697 suggested value of the third or later negotiation steps should be 698 chosen between the suggested values from the last two negotiation 699 steps. In any case there must be a mechanism to guarantee 700 convergence (or failure) in a small number of steps, such as a 701 timeout or maximum number of iterations. 703 * End of negotiation 705 A limited number of rounds, for example three, or a timeout, is 706 needed on each ASA for each negotiation objective. It may be 707 an implementation choice, a pre-configurable parameter, or 708 network Intent. These choices might vary between different 709 types of ASA. Therefore, the definition of each negotiation 710 objective MUST clearly specify this, so that the negotiation 711 can always be terminated properly. 713 * Failed negotiation 715 There must be a well-defined procedure for concluding that a 716 negotiation cannot succeed, and if so deciding what happens 717 next (deadlock resolution, tie-breaking, or revert to best- 718 effort service). Again, this MUST be specified for individual 719 negotiation objectives, as an implementation choice, a pre- 720 configurable parameter, or network Intent. 722 o Extensibility 724 GRASP does not have a version number. In most cases new semantics 725 will be added by defining new synchronization or negotiation 726 objectives. However, the protocol could be extended by adding new 727 message types and options in future. 729 3.4. Quick Operating Overview 731 GRASP is expected to run as an operating system core module, 732 providing an API (such as [I-D.liu-anima-grasp-api]) to interface to 733 less privileged ASAs. Thus ASAs may operate without special 734 privilege, unless they need it for other reasons (such as configuring 735 IP addresses or manipulating routing tables). 737 The GRASP mechanisms used by the ASA are built around GRASP 738 objectives defined as data structures containing administrative 739 information such as the objective's unique name, and its current 740 value. The format and size of the value is not restricted by the 741 protocol, except that it must be possible to serialise it for 742 transmission in CBOR, which is no restriction at all in practice. 744 The GRASP provides the following mechanisms: 746 o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA 747 can discover other ASAs supporting a given objective. 749 o A negotiation request mechanism (M_REQ_NEG), by which an ASA can 750 start negotiation of an objective with a counterpart ASA. Once a 751 negotiation has started, the process is symmetrical, and there is 752 a negotiation step message (M_NEGOTIATE) for each ASA to use in 753 turn. Two other functions support negotiating steps (M_WAIT, 754 M_END). 756 o A synchronization mechanism (M_REQ_SYN), by which an ASA can 757 request the current value of an objective from a counterpart ASA. 758 With this, there is a corresponding response function (M_SYNCH) 759 for an ASA that wishes to respond to synchronization requests. 761 o A flood mechanism (M_FLOOD), by which an ASA can cause the current 762 value of an objective to be flooded throughout the AN so that any 763 ASA can receive it. 765 3.5. GRASP Protocol Basic Properties and Mechanisms 767 3.5.1. Required External Security Mechanism 769 The protocol SHOULD run within a secure Autonomic Control Plane (ACP) 770 [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to 771 carry all messages securely, including link-local multicast if 772 possible. A GRASP implementation MUST verify whether the ACP is 773 operational. 775 If there is no ACP, the protocol MUST use another form of strong 776 authentication and SHOULD use a form of strong encryption. TLS 777 [RFC5246] is RECOMMENDED for this purpose, based on a local Public 778 Key Infrastructure (PKI) [RFC5280] managed within the autonomic 779 network itself. The details of such a PKI and how its boundary is 780 established are out of scope for this document. DTLS [RFC6347] MAY 781 be used but since GRASP operations usually involve several messages 782 this is not expected to be advantageous. 784 The ACP, or in its absence the local PKI, sets the boundary within 785 which nodes are trusted as GRASP peers. A GRASP implementation MUST 786 refuse to execute GRASP synchronization and negotiation functions if 787 there is neither an operational ACP nor an operational TLS or DTLS 788 environment. 790 Link-local multicast is used for discovery messages. Responses to 791 discovery messages MUST be secured, with one exception mentioned in 792 the next section. 794 3.5.2. Limited Security Instances 796 This section describes three cases where additional instances of 797 GRASP are appropriate. 799 1) As mentioned in Section 3.3, some GRASP operations might be 800 performed across an administrative domain boundary by mutual 801 agreement. Such operations MUST be confined to a separate instance 802 of GRASP with its own copy of all GRASP data structures. Messages 803 MUST be authenticated and SHOULD be encrypted. TLS is RECOMMENDED 804 for this purpose. 806 2) During initialisation, before a node has joined the applicable 807 trust infrastructure, [I-D.ietf-anima-bootstrapping-keyinfra], it is 808 impossible to secure messages. Thus, the security bootstrap process 809 needs to use insecure GRASP discovery, response and flood messages. 810 Such usage MUST be limited to link-local operations and MUST be 811 confined to a separate insecure instance of GRASP with its own copy 812 of all GRASP data structures. This instance is nicknamed DULL - 813 Discovery Unsolicited Link Local. 815 The detailed rules for the DULL instance of GRASP are as follows: 817 o An initiator MUST only send Discovery or Flood Synchronization 818 link-local multicast messages with a loop count of 1. A responder 819 MAY send a Discovery Response message. Other GRASP message types 820 MUST NOT be sent. 822 o A responder MUST silently discard any message whose loop count is 823 not 1. 825 o A responder MUST silently discard any message referring to a GRASP 826 Objective that is not directly part of the bootstrap creation 827 process. 829 o A responder MUST NOT relay any multicast messages. 831 o A Discovery Response MUST indicate a link-local address. 833 o A Discovery Response MUST NOT include a Divert option. 835 o A node MUST silently discard any message whose source address is 836 not link-local. 838 3) During ACP formation [I-D.ietf-anima-autonomic-control-plane], a 839 separate instance of GRASP is used, with unicast messages secured by 840 TLS, and with its own copy of all GRASP data structures. This 841 instance is nicknamed SONN - Secure Only Neighbor Negotiation. 843 The detailed rules for the SONN instance of GRASP are as follows: 845 o Any type of GRASP message MAY be sent. 847 o An initiator MUST send any Discovery or Flood Synchronization 848 link-local multicast messages with a loop count of 1. 850 o A responder MUST silently discard any Discovery or Flood 851 Synchronization message whose loop count is not 1. 853 o A responder MUST silently discard any message referring to a GRASP 854 Objective that is not directly part of the ACP creation process. 856 o A responder MUST NOT relay any multicast messages. 858 o A Discovery Response MUST indicate a link-local address. 860 o A Discovery Response MUST NOT include a Divert option. 862 o A node MUST silently discard any message whose source address is 863 not link-local. 865 3.5.3. Transport Layer Usage 867 GRASP discovery and flooding messages are designed for use over link- 868 local multicast UDP. They MUST NOT be fragmented, and therefore MUST 869 NOT exceed the link MTU size. Nothing in principle prevents them 870 from working over some other method of sending packets to all on-link 871 neighbors, but this is out of scope for the present specification. 873 All other GRASP messages are unicast and could in principle run over 874 any transport protocol. An implementation MUST support use of TCP. 875 It MAY support use of another transport protocol. However, GRASP 876 itself does not provide for error detection or retransmission. Use 877 of an unreliable transport protocol is therefore NOT RECOMMENDED. 879 Nevertheless, when running within a secure ACP on reliable 880 infrastructure, UDP MAY be used for unicast messages not exceeding 881 the minimum IPv6 path MTU; however, TCP MUST be used for longer 882 messages. In other words, IPv6 fragmentation is avoided. If a node 883 receives a UDP message but the reply is too long, it MUST open a TCP 884 connection to the peer for the reply. Note that when the network is 885 under heavy load or in a fault condition, UDP might become 886 unreliable. Since this is when autonomic functions are most 887 necessary, automatic fallback to TCP MUST be implemented. The 888 simplest implementation is therefore to use only TCP. In particular, 889 to guarantee interoperability during bootstrap and startup, using TCP 890 for discovery responses is strongly advised. 892 When running without an ACP, TLS MUST be supported and used by 893 default, except for link-local multicast messages. DTLS MAY be 894 supported as an alternative but the details are out of scope for this 895 document. Transport protocols other than TCP and UDP are also out of 896 scope for this document. 898 For link-local multicast, the GRASP protocol listens to the well- 899 known GRASP Listen Port (Section 3.6). For unicast transport 900 sessions used for discovery responses, synchronization and 901 negotiation, the ASA concerned normally listens on its own 902 dynamically assigned ports, which are communicated to its peers 903 during discovery. However, a minimal implementation MAY use the 904 GRASP Listen Port for this purpose. 906 3.5.4. Discovery Mechanism and Procedures 908 3.5.4.1. Separated discovery and negotiation mechanisms 910 Although discovery and negotiation or synchronization are defined 911 together in GRASP, they are separate mechanisms. The discovery 912 process could run independently from the negotiation or 913 synchronization process. Upon receiving a Discovery (Section 3.8.4) 914 message, the recipient node should return a response message in which 915 it either indicates itself as a discovery responder or diverts the 916 initiator towards another more suitable ASA. 918 The discovery action will normally be followed by a negotiation or 919 synchronization action. The discovery results could be utilized by 920 the negotiation protocol to decide which ASA the initiator will 921 negotiate with. 923 The initiator of a discovery action for a given objective need not be 924 capable of responding to that objective as a Negotiation Counterpart, 925 as a Synchronization Responder or as source for flooding. For 926 example, an ASA might perform discovery even if it only wishes to act 927 a Synchronization Initiator or Negotiation Initiator. Such an ASA 928 does not itself need to respond to discovery messages. 930 It is also entirely possible to use GRASP discovery without any 931 subsequent negotiation or synchronization action. In this case, the 932 discovered objective is simply used as a name during the discovery 933 process and any subsequent operations between the peers are outside 934 the scope of GRASP. 936 3.5.4.2. Discovery Overview 938 A complete discovery process will start with a multicast on the local 939 link. On-link neighbors supporting the discovery objective will 940 respond directly. A neighbor with multiple interfaces will respond 941 with a cached discovery response if any. If not, it will relay the 942 discovery on its other interfaces, for example reaching a higher- 943 level gateway in a hierarchical network. If a node receiving the 944 relayed discovery supports the discovery objective, it will respond 945 to the relayed discovery. If it has a cached response, it will 946 respond with that. If not, it will repeat the discovery process, 947 which thereby becomes recursive. The loop count and timeout will 948 ensure that the process ends. 950 Exceptionally, a Discovery message MAY be sent unicast to a peer 951 node, which will then proceed exactly as if the message had been 952 multicast. However, this mode does not guarantee successful 953 discovery in the general case. 955 3.5.4.3. Discovery Procedures 957 Discovery starts as an on-link operation. The Divert option can tell 958 the discovery initiator to contact an off-link ASA for that discovery 959 objective. Every Discovery message is sent by a discovery initiator 960 via UDP to the ALL_GRASP_NEIGHBOR link-local multicast address 961 (Section 3.6). Every network device that supports GRASP always 962 listens to a well-known UDP port to capture the discovery messages. 963 Because this port is unique in a device, this is a function of the 964 GRASP kernel and not of an individual ASA. As a result, each ASA 965 will need to register the objectives that it supports with the GRASP 966 kernel. 968 If an ASA in a neighbor device supports the requested discovery 969 objective, the device SHOULD respond to the link-local multicast with 970 a unicast Discovery Response message (Section 3.8.5) with locator 971 option(s), unless it is temporarily unavailable. Otherwise, if the 972 neighbor has cached information about an ASA that supports the 973 requested discovery objective (usually because it discovered the same 974 objective before), it SHOULD respond with a Discovery Response 975 message with a Divert option pointing to the appropriate Discovery 976 Responder. 978 If a device has no information about the requested discovery 979 objective, and is not acting as a discovery relay (see below) it MUST 980 silently discard the Discovery message. 982 If no discovery response is received within a reasonable timeout 983 (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery 984 message MAY be repeated, with a newly generated Session ID 985 (Section 3.7). An exponential backoff SHOULD be used for subsequent 986 repetitions, to limit the load during busy periods. Frequent 987 repetition might be symptomatic of a denial of service attack. 989 After a GRASP device successfully discovers a locator for a Discovery 990 Responder supporting a specific objective, it MUST cache this 991 information, including the interface identifier via which it was 992 discovered. This cache record MAY be used for future negotiation or 993 synchronization, and the locator SHOULD be passed on when appropriate 994 as a Divert option to another Discovery Initiator. 996 The cache mechanism MUST include a lifetime for each entry. The 997 lifetime is derived from a time-to-live (ttl) parameter in each 998 Discovery Response message. Cached entries MUST be ignored or 999 deleted after their lifetime expires. In some environments, 1000 unplanned address renumbering might occur. In such cases, the 1001 lifetime SHOULD be short compared to the typical address lifetime and 1002 a mechanism to flush the discovery cache SHOULD be implemented. The 1003 discovery mechanism needs to track the node's current address to 1004 ensure that Discovery Responses always indicate the correct address. 1006 If multiple Discovery Responders are found for the same objective, 1007 they SHOULD all be cached, unless this creates a resource shortage. 1008 The method of choosing between multiple responders is an 1009 implementation choice. This choice MUST be available to each ASA but 1010 the GRASP implementation SHOULD provide a default choice. 1012 Because Discovery Responders will be cached in a finite cache, they 1013 might be deleted at any time. In this case, discovery will need to 1014 be repeated. If an ASA exits for any reason, its locator might still 1015 be cached for some time, and attempts to connect to it will fail. 1016 ASAs need to be robust in these circumstances. 1018 3.5.4.4. Discovery Relaying 1020 A GRASP instance with multiple link-layer interfaces (typically 1021 running in a router) MUST support discovery on all interfaces. We 1022 refer to this as a 'relaying instance'. 1024 However, different interfaces can be at different security levels: 1025 each group of interfaces with the same security level SHOULD be 1026 serviced by the same GRASP process, except for Limited Security 1027 Instances Section 3.5.2 which are always single-interface instances 1028 and MUST NOT perform discovery relaying. 1030 If a relaying instance receives a Discovery message on a given 1031 interface for a specific objective that it does not support and for 1032 which it has not previously cached a Discovery Responder, it MUST 1033 relay the query by re-issuing a Discovery message as a link-local 1034 multicast on its other interfaces. 1036 The relayed discovery message MUST have the same Session ID as the 1037 incoming discovery message and MUST be tagged with the IP address of 1038 its original initiator (see Section 3.8.4). Since the relay device 1039 is unaware of the timeout set by the original initiator it SHOULD set 1040 a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds. 1042 The relaying instance MUST decrement the loop count within the 1043 objective, and MUST NOT relay the Discovery message if the result is 1044 zero. Also, it MUST limit the total rate at which it relays 1045 discovery messages to a reasonable value, in order to mitigate 1046 possible denial of service attacks. It MUST cache the Session ID 1047 value and initiator address of each relayed Discovery message until 1048 any Discovery Responses have arrived or the discovery process has 1049 timed out. To prevent loops, it MUST NOT relay a Discovery message 1050 which carries a given cached Session ID and initiator address more 1051 than once. These precautions avoid discovery loops and mitigate 1052 potential overload. 1054 The discovery results received by the relaying instance MUST in turn 1055 be sent as a Discovery Response message to the Discovery message that 1056 caused the relay action. 1058 This relayed discovery mechanism, with caching of the results, should 1059 be sufficient to support most network bootstrapping scenarios. 1061 3.5.4.5. Rapid Mode (Discovery/Negotiation binding) 1063 A Discovery message MAY include a Negotiation Objective option. This 1064 allows a rapid mode of negotiation described in Section 3.5.5. A 1065 similar mechanism is defined for synchronization in Section 3.5.6. 1067 Note that rapid mode is currently limited to a single objective for 1068 simplicity of design and implementation. A possible future extension 1069 is to allow multiple objectives in rapid mode for greater efficiency. 1071 3.5.5. Negotiation Procedures 1073 A negotiation initiator sends a negotiation request to a counterpart 1074 ASA, including a specific negotiation objective. It may request the 1075 negotiation counterpart to make a specific configuration. 1076 Alternatively, it may request a certain simulation or forecast result 1077 by sending a dry run configuration. The details, including the 1078 distinction between dry run and an actual configuration change, will 1079 be defined separately for each type of negotiation objective. 1081 If no reply message of any kind is received within a reasonable 1082 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the 1083 negotiation request MAY be repeated, with a newly generated Session 1084 ID (Section 3.7). An exponential backoff SHOULD be used for 1085 subsequent repetitions. 1087 If the counterpart can immediately apply the requested configuration, 1088 it will give an immediate positive (accept) answer. This will end 1089 the negotiation phase immediately. Otherwise, it will negotiate. It 1090 will reply with a proposed alternative configuration that it can 1091 apply (typically, a configuration that uses fewer resources than 1092 requested by the negotiation initiator). This will start a bi- 1093 directional negotiation to reach a compromise between the two ASAs. 1095 The negotiation procedure is ended when one of the negotiation peers 1096 sends a Negotiation Ending message, which contains an accept or 1097 decline option and does not need a response from the negotiation 1098 peer. Negotiation may also end in failure (equivalent to a decline) 1099 if a timeout is exceeded or a loop count is exceeded. 1101 A negotiation procedure concerns one objective and one counterpart. 1102 Both the initiator and the counterpart may take part in simultaneous 1103 negotiations with various other ASAs, or in simultaneous negotiations 1104 about different objectives. Thus, GRASP is expected to be used in a 1105 multi-threaded mode. Certain negotiation objectives may have 1106 restrictions on multi-threading, for example to avoid over-allocating 1107 resources. 1109 Some configuration actions, for example wavelength switching in 1110 optical networks, might take considerable time to execute. The ASA 1111 concerned needs to allow for this by design, but GRASP does allow for 1112 a peer to insert latency in a negotiation process if necessary 1113 (Section 3.8.9). 1115 3.5.5.1. Rapid Mode (Discovery/Negotiation Linkage) 1117 A Discovery message MAY include a Negotiation Objective option. In 1118 this case the Discovery message also acts as a Request Negotiation 1119 message to indicate to the Discovery Responder that it could directly 1120 reply to the Discovery Initiator with a Negotiation message for rapid 1121 processing, if it could act as the corresponding negotiation 1122 counterpart. However, the indication is only advisory not 1123 prescriptive. 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 kernel. 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 The relaying device MUST decrement the loop count within the first 1183 objective, and MUST NOT relay the Flood Synchronization message if 1184 the result is zero. Also, it MUST limit the total rate at which it 1185 relays Flood Synchronization messages to a reasonable value, in order 1186 to mitigate possible denial of service attacks. It MUST cache the 1187 Session ID value and initiator address of each relayed Flood 1188 Synchronization message for a finite time not less than twice 1189 GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay 1190 a Flood Synchronization message which carries a given cached Session 1191 ID and initiator address more than once. These precautions avoid 1192 synchronization loops and mitigate potential overload. 1194 Note that this mechanism is unreliable in the case of sleeping nodes, 1195 or new nodes that join the network, or nodes that rejoin the network 1196 after a fault. An ASA that initiates a flood SHOULD repeat the flood 1197 at a suitable frequency and SHOULD also act as a synchronization 1198 responder for the objective(s) concerned. Thus nodes that require an 1199 objective subject to flooding can either wait for the next flood or 1200 request unicast synchronization for that objective. 1202 The multicast messages for synchronization flooding are subject to 1203 the security rules in Section 3.5.1. In practice this means that 1204 they MUST NOT be transmitted and MUST be ignored on receipt unless 1205 there is an operational ACP or equivalent strong security in place. 1206 However, because of the security weakness of link-local multicast 1207 (Section 5), synchronization objectives that are flooded SHOULD NOT 1208 contain unencrypted private information and SHOULD be validated by 1209 the recipient ASA. 1211 3.5.6.2. Rapid Mode (Discovery/Synchronization Linkage) 1213 A Discovery message MAY include a Synchronization Objective option. 1214 In this case the Discovery message also acts as a Request 1215 Synchronization message to indicate to the Discovery Responder that 1216 it could directly reply to the Discovery Initiator with a 1217 Synchronization message Section 3.8.10 with synchronization data for 1218 rapid processing, if the discovery target supports the corresponding 1219 synchronization objective. However, the indication is only advisory 1220 not prescriptive. 1222 It is possible that a Discovery Response will arrive from a responder 1223 that does not support rapid mode, before such a Synchronization 1224 message arrives. In this case, rapid mode will not occur. 1226 This rapid mode could reduce the interactions between nodes so that a 1227 higher efficiency could be achieved. However, a network in which 1228 some nodes support rapid mode and others do not will have complex 1229 timing-dependent behaviors. Therefore, the rapid synchronization 1230 function SHOULD be configured off by default and MAY be configured on 1231 or off by Intent. 1233 3.6. GRASP Constants 1235 o ALL_GRASP_NEIGHBOR 1237 A link-local scope multicast address used by a GRASP-enabled 1238 device to discover GRASP-enabled neighbor (i.e., on-link) devices 1239 . All devices that support GRASP are members of this multicast 1240 group. 1242 * IPv6 multicast address: TBD1 1244 * IPv4 multicast address: TBD2 1246 o GRASP_LISTEN_PORT (TBD3) 1248 A well-known UDP user port that every GRASP-enabled network device 1249 MUST always listen to for link-local multicasts. Additionally, 1250 this user port MAY be used to listen for TCP or UDP unicast 1251 messages in a simple implementation of GRASP (Section 3.5.3). 1253 o GRASP_DEF_TIMEOUT (60000 milliseconds) 1255 The default timeout used to determine that a discovery etc. has 1256 failed to complete. 1258 o GRASP_DEF_LOOPCT (6) 1260 The default loop count used to determine that a negotiation has 1261 failed to complete, and to avoid looping messages. 1263 o GRASP_DEF_MAX_SIZE (2048) 1265 The default maximum message size in bytes. 1267 3.7. Session Identifier (Session ID) 1269 This is an up to 32-bit opaque value used to distinguish multiple 1270 sessions between the same two devices. A new Session ID MUST be 1271 generated by the initiator for every new Discovery, Flood 1272 Synchronization or Request message. All responses and follow-up 1273 messages in the same discovery, synchronization or negotiation 1274 procedure MUST carry the same Session ID. 1276 The Session ID SHOULD have a very low collision rate locally. It 1277 MUST be generated by a pseudo-random algorithm using a locally 1278 generated seed which is unlikely to be used by any other device in 1279 the same network [RFC4086]. When allocating a new Session ID, GRASP 1280 MUST check that the value is not already in use and SHOULD check that 1281 it has not been used recently, by consulting a cache of current and 1282 recent sessions. In the unlikely event of a clash, GRASP MUST 1283 generate a new value. 1285 However, there is a finite probability that two nodes might generate 1286 the same Session ID value. For that reason, when a Session ID is 1287 communicated via GRASP, the receiving node MUST tag it with the 1288 initiator's IP address to allow disambiguation. In the highly 1289 unlikely event of two peers opening sessions with the same Session ID 1290 value, this tag will allow the two sessions to be distinguished. 1291 Multicast GRASP messages and their responses, which may be relayed 1292 between links, therefore include a field that carries the initiator's 1293 global IP address. 1295 There is a highly unlikely race condition in which two peers start 1296 simultaneous negotiation sessions with each other using the same 1297 Session ID value. Depending on various implementation choices, this 1298 might lead to the two sessions being confused. See Section 3.8.6 for 1299 details of how to avoid this. 1301 3.8. GRASP Messages 1303 3.8.1. Message Overview 1305 This section defines the GRASP message format and message types. 1306 Message types not listed here are reserved for future use. 1308 The messages currently defined are: 1310 Discovery and Discovery Response. 1312 Request Negotiation, Negotiation, Confirm Waiting and Negotiation 1313 End. 1315 Request Synchronization, Synchronization, and Flood 1316 Synchronization. 1318 No Operation. 1320 3.8.2. GRASP Message Format 1322 GRASP messages share an identical header format and a variable format 1323 area for options. GRASP message headers and options are transmitted 1324 in Concise Binary Object Representation (CBOR) [RFC7049]. In this 1325 specification, they are described using CBOR data definition language 1326 (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is 1327 used to describe each item in this section. A complete and normative 1328 CDDL specification of GRASP is given in Section 6, including 1329 constants such as message types. 1331 Every GRASP message, except the No Operation message, carries a 1332 Session ID (Section 3.7). Options are then presented serially in the 1333 options field. 1335 In fragmentary CDDL, every GRASP message follows the pattern: 1337 grasp-message = (message .within message-structure) / noop-message 1339 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 1340 *grasp-option] 1342 MESSAGE_TYPE = 1..255 1343 session-id = 0..4294967295 ;up to 32 bits 1344 grasp-option = any 1346 The MESSAGE_TYPE indicates the type of the message and thus defines 1347 the expected options. Any options received that are not consistent 1348 with the MESSAGE_TYPE SHOULD be silently discarded. 1350 The No Operation (noop) message is described in Section 3.8.13. 1352 The various MESSAGE_TYPE values are defined in Section 6. 1354 All other message elements are described below and formally defined 1355 in Section 6. 1357 3.8.3. Message Size 1359 GRASP nodes MUST be able to receive messages of at least 1360 GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send messages longer 1361 than GRASP_DEF_MAX_SIZE bytes unless a longer size is explicitly 1362 allowed for the objective concerned. For example, GRASP negotiation 1363 itself could be used to agree on a longer message size. 1365 3.8.4. Discovery Message 1367 In fragmentary CDDL, a Discovery message follows the pattern: 1369 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1371 A discovery initiator sends a Discovery message to initiate a 1372 discovery process for a particular objective option. 1374 The discovery initiator sends all Discovery messages via UDP to port 1375 GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast 1376 address on each link-layer interface in use by GRASP. It then 1377 listens for unicast TCP responses on a given port, and stores the 1378 discovery results (including responding discovery objectives and 1379 corresponding unicast locators). 1381 The listening port used for TCP MUST be the same port as used for 1382 sending the Discovery UDP multicast, on a given interface. In a low- 1383 end implementation this MAY be GRASP_LISTEN_PORT. In a more complex 1384 implementation, the GRASP discovery mechanism will find, for each 1385 interface, a dynamic port that it can bind to for both UDP and TCP 1386 before initiating any discovery. 1388 The 'initiator' field in the message is a globally unique IP address 1389 of the initiator, for the sole purpose of disambiguating the Session 1390 ID in other nodes. If for some reason the initiator does not have a 1391 globally unique IP address, it MUST use a link-local address for this 1392 purpose that is highly likely to be unique, for example using 1393 [RFC7217]. 1395 A Discovery message MUST include exactly one of the following: 1397 o a discovery objective option (Section 3.10.1). Its loop count 1398 MUST be set to a suitable value to prevent discovery loops 1399 (default value is GRASP_DEF_LOOPCT). If the discovery initiator 1400 requires only on-link responses, the loop count MUST be set to 1. 1402 o a negotiation objective option (Section 3.10.1). This is used 1403 both for the purpose of discovery and to indicate to the discovery 1404 target that it MAY directly reply to the discovery initiatior with 1405 a Negotiation message for rapid processing, if it could act as the 1406 corresponding negotiation counterpart. The sender of such a 1407 Discovery message MUST initialize a negotiation timer and loop 1408 count in the same way as a Request Negotiation message 1409 (Section 3.8.6). 1411 o a synchronization 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 initiator with 1414 a Synchronization message for rapid processing, if it could act as 1415 the corresponding synchronization counterpart. Its loop count 1416 MUST be set to a suitable value to prevent discovery loops 1417 (default value is GRASP_DEF_LOOPCT). 1419 Exceptionally, a Discovery message MAY be sent unicast to a peer 1420 node, which will then proceed exactly as if the message had been 1421 multicast. 1423 3.8.5. Discovery Response Message 1425 In fragmentary CDDL, a Discovery Response message follows the 1426 pattern: 1428 response-message = [M_RESPONSE, session-id, initiator, ttl, 1429 (+locator-option // divert-option), ?objective)] 1431 ttl = 0..4294967295 ; in milliseconds 1433 A node which receives a Discovery message SHOULD send a Discovery 1434 Response message if and only if it can respond to the discovery. 1436 It MUST contain the same Session ID and initiator as the Discovery 1437 message. 1439 It MUST contain a time-to-live (ttl) for the validity of the 1440 response, given as a positive integer value in milliseconds. Zero 1441 is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6). 1443 It MAY include a copy of the discovery objective from the 1444 Discovery message. 1446 It is sent to the sender of the Discovery message via TCP at the port 1447 used to send the Discovery message (as explained in Section 3.8.4). 1449 If the responding node supports the discovery objective of the 1450 discovery, it MUST include at least one kind of locator option 1451 (Section 3.9.5) to indicate its own location. A sequence of multiple 1452 kinds of locator options (e.g. IP address option and FQDN option) is 1453 also valid. 1455 If the responding node itself does not support the discovery 1456 objective, but it knows the locator of the discovery objective, then 1457 it SHOULD respond to the discovery message with a divert option 1458 (Section 3.9.2) embedding a locator option or a combination of 1459 multiple kinds of locator options which indicate the locator(s) of 1460 the discovery objective. 1462 More details on the processing of Discovery Responses are given in 1463 Section 3.5.4. 1465 3.8.6. Request Messages 1467 In fragmentary CDDL, Request Negotiation and Request Synchronization 1468 messages follow the patterns: 1470 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1472 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1474 A negotiation or synchronization requesting node sends the 1475 appropriate Request message to the unicast address (directly stored 1476 or resolved from an FQDN or URI) of the negotiation or 1477 synchronization counterpart, using the appropriate protocol and port 1478 numbers (selected from the discovery results). 1480 A Request message MUST include the relevant objective option. In the 1481 case of Request Negotiation, the objective option MUST include the 1482 requested value. 1484 When an initiator sends a Request Negotiation message, it MUST 1485 initialize a negotiation timer for the new negotiation thread. The 1486 default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is 1487 modified by a Confirm Waiting message (Section 3.8.9), the initiator 1488 will consider that the negotiation has failed when the timer expires. 1490 Similarly, when an initiator sends a Request Synchronization, it 1491 SHOULD initialize a synchronization timer. The default is 1492 GRASP_DEF_TIMEOUT milliseconds. The initiator will consider that 1493 synchronization has failed if there is no response before the timer 1494 expires. 1496 When an initiator sends a Request message, it MUST initialize the 1497 loop count of the objective option with a value defined in the 1498 specification of the option or, if no such value is specified, with 1499 GRASP_DEF_LOOPCT. 1501 If a node receives a Request message for an objective for which no 1502 ASA is currently listening, it MUST immediately close the relevant 1503 socket to indicate this to the initiator. 1505 To avoid the highly unlikely race condition in which two nodes 1506 simultaneously request sessions with each other using the same 1507 Session ID (Section 3.7), when a node receives a Request message, it 1508 MUST verify that the received Session ID is not already locally 1509 active. In case of a clash, it MUST discard the Request message, in 1510 which case the initiator will detect a timeout. 1512 3.8.7. Negotiation Message 1514 In fragmentary CDDL, a Negotiation message follows the pattern: 1516 negotiate-message = [M_NEGOTIATE, session-id, objective] 1518 A negotiation counterpart sends a Negotiation message in response to 1519 a Request Negotiation message, a Negotiation message, or a Discovery 1520 message in Rapid Mode. A negotiation process MAY include multiple 1521 steps. 1523 The Negotiation message MUST include the relevant Negotiation 1524 Objective option, with its value updated according to progress in the 1525 negotiation. The sender MUST decrement the loop count by 1. If the 1526 loop count becomes zero the message MUST NOT be sent. In this case 1527 the negotiation session has failed and will time out. 1529 3.8.8. Negotiation End Message 1531 In fragmentary CDDL, a Negotiation End message follows the pattern: 1533 end-message = [M_END, session-id, accept-option / decline-option] 1535 A negotiation counterpart sends an Negotiation End message to close 1536 the negotiation. It MUST contain either an accept or a decline 1537 option, defined in Section 3.9.3 and Section 3.9.4. It could be sent 1538 either by the requesting node or the responding node. 1540 3.8.9. Confirm Waiting Message 1542 In fragmentary CDDL, a Confirm Waiting message follows the pattern: 1544 wait-message = [M_WAIT, session-id, waiting-time] 1545 waiting-time = 0..4294967295 ; in milliseconds 1547 A responding node sends a Confirm Waiting message to ask the 1548 requesting node to wait for a further negotiation response. It might 1549 be that the local process needs more time or that the negotiation 1550 depends on another triggered negotiation. This message MUST NOT 1551 include any other options. When received, the waiting time value 1552 overwrites and restarts the current negotiation timer 1553 (Section 3.8.6). 1555 The responding node SHOULD send a Negotiation, Negotiation End or 1556 another Confirm Waiting message before the negotiation timer expires. 1557 If not, the initiator MUST abandon or restart the negotiation 1558 procedure, to avoid an indefinite wait. 1560 3.8.10. Synchronization Message 1562 In fragmentary CDDL, a Synchronization message follows the pattern: 1564 synch-message = [M_SYNCH, session-id, objective] 1566 A node which receives a Request Synchronization, or a Discovery 1567 message in Rapid Mode, sends back a unicast Synchronization message 1568 with the synchronization data, in the form of a GRASP Option for the 1569 specific synchronization objective present in the Request 1570 Synchronization. 1572 3.8.11. Flood Synchronization Message 1574 In fragmentary CDDL, a Flood Synchronization message follows the 1575 pattern: 1577 flood-message = [M_FLOOD, session-id, initiator, ttl, 1578 (locator-option / []), +objective] 1580 ttl = 0..4294967295 ; in milliseconds 1582 A node MAY initiate flooding by sending an unsolicited Flood 1583 Synchronization Message with synchronization data. This MAY be sent 1584 to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance 1585 with the rules in Section 3.5.6. 1587 The initiator address is provided as described for Discovery 1588 messages. 1590 The message MUST contain a time-to-live (ttl) for the validity of 1591 the response, given as a positive integer value in milliseconds. 1592 There is no default; zero indicates an indefinite lifetime. 1594 The message MAY contain a locator option indicating the ASA that 1595 initiated the flooded data. In its absence, an empty option MUST 1596 be included. 1598 The synchronization data are in the form of GRASP Option(s) for 1599 specific synchronization objective(s). The loop count(s) MUST be 1600 set to a suitable value to prevent flood loops (default value is 1601 GRASP_DEF_LOOPCT). 1603 A node that receives a Flood Synchronization message MUST cache the 1604 received objectives for use by local ASAs. Each cached objective 1605 MUST be tagged with the locator option sent with it, or with a null 1606 tag if an empty locator option was sent. If a subsequent Flood 1607 Synchronization message carrying the same objective arrives with the 1608 same tag, the corresponding cached copy of the objective MUST be 1609 overwritten. If a subsequent Flood Synchronization message carrying 1610 the same objective arrives with a different tag, a new cached entry 1611 MUST be created. 1613 Note: the purpose of this mechanism is to allow the recipient of 1614 flooded values to distinguish between different senders of the same 1615 objective, and if necessary communicate with them using the locator, 1616 protocol and port included in the locator option. Many objectives 1617 will not need this mechanism, so they will be flooded with a null 1618 locator. 1620 Cached entries MUST be ignored or deleted after their lifetime 1621 expires. 1623 3.8.12. Invalid Message 1625 In fragmentary CDDL, an Invalid message follows the pattern: 1627 invalid-message = [M_INVALID, session-id, ?any] 1629 This message MAY be sent by an implementation in response to an 1630 incoming message that it considers invalid. The session-id MUST be 1631 copied from the incoming message. The content SHOULD be diagnostic 1632 information such as a partial copy of the invalid message. An 1633 M_INVALID message MAY be silently ignored by a recipient. However, 1634 it could be used in support of extensibility, since it indicates that 1635 the remote node does not support a new or obsolete message or option 1637 An M_INVALID message MUST NOT be sent in response to an M_INVALID 1638 message. 1640 3.8.13. No Operation Message 1642 In fragmentary CDDL, a No Operation message follows the pattern: 1644 noop-message = [M_NOOP] 1646 This message MAY be sent by an implementation that for practical 1647 reasons needs to activate a socket. It MUST be silently ignored by a 1648 recipient. 1650 3.9. GRASP Options 1652 This section defines the GRASP options for the negotiation and 1653 synchronization protocol signaling. Additional options may be 1654 defined in the future. 1656 3.9.1. Format of GRASP Options 1658 GRASP options are CBOR objects that MUST start with an unsigned 1659 integer identifying the specific option type carried in this option. 1660 These option types are formally defined in Section 6. Apart from 1661 that the only format requirement is that each option MUST be a well- 1662 formed CBOR object. In general a CBOR array format is RECOMMENDED to 1663 limit overhead. 1665 GRASP options are usually scoped by using encapsulation. However, 1666 this is not a requirement 1668 3.9.2. Divert Option 1670 The Divert option is used to redirect a GRASP request to another 1671 node, which may be more appropriate for the intended negotiation or 1672 synchronization. It may redirect to an entity that is known as a 1673 specific negotiation or synchronization counterpart (on-link or off- 1674 link) or a default gateway. The divert option MUST only be 1675 encapsulated in Discovery Response messages. If found elsewhere, it 1676 SHOULD be silently ignored. 1678 A discovery initiator MAY ignore a Divert option if it only requires 1679 direct discovery responses. 1681 In fragmentary CDDL, the Divert option follows the pattern: 1683 divert-option = [O_DIVERT, +locator-option] 1685 The embedded Locator Option(s) (Section 3.9.5) point to diverted 1686 destination target(s) in response to a Discovery message. 1688 3.9.3. Accept Option 1690 The accept option is used to indicate to the negotiation counterpart 1691 that the proposed negotiation content is accepted. 1693 The accept option MUST only be encapsulated in Negotiation End 1694 messages. If found elsewhere, it SHOULD be silently ignored. 1696 In fragmentary CDDL, the Accept option follows the pattern: 1698 accept-option = [O_ACCEPT] 1700 3.9.4. Decline Option 1702 The decline option is used to indicate to the negotiation counterpart 1703 the proposed negotiation content is declined and end the negotiation 1704 process. 1706 The decline option MUST only be encapsulated in Negotiation End 1707 messages. If found elsewhere, it SHOULD be silently ignored. 1709 In fragmentary CDDL, the Decline option follows the pattern: 1711 decline-option = [O_DECLINE, ?reason] 1712 reason = text ;optional error message 1714 Note: there are scenarios where a negotiation counterpart wants to 1715 decline the proposed negotiation content and continue the negotiation 1716 process. For these scenarios, the negotiation counterpart SHOULD use 1717 a Negotiate message, with either an objective option that contains a 1718 data field set to indicate a meaningless initial value, or a specific 1719 objective option that provides further conditions for convergence. 1721 3.9.5. Locator Options 1723 These locator options are used to present reachability information 1724 for an ASA, a device or an interface. They are Locator IPv6 Address 1725 Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified 1726 Domain Name) Option and URI (Uniform Resource Identifier) Option. 1728 Since ASAs will normally run as independent user programs, locator 1729 options need to indicate the network layer locator plus the transport 1730 protocol and port number for reaching the target. For this reason, 1731 the Locator Options for IP addresses and FQDNs include this 1732 information explicitly. In the case of the URI Option, this 1733 information can be encoded in the URI itself. 1735 Note: It is assumed that all locators are in scope throughout the 1736 GRASP domain. GRASP is not intended to work across disjoint 1737 addressing or naming realms. 1739 3.9.5.1. Locator IPv6 address option 1741 In fragmentary CDDL, the IPv6 address option follows the pattern: 1743 ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address, 1744 transport-proto, port-number] 1745 ipv6-address = bytes .size 16 1747 transport-proto = IPPROTO_TCP / IPPROTO_UDP 1748 IPPROTO_TCP = 6 1749 IPPROTO_UDP = 17 1750 port-number = 0..65535 1752 The content of this option is a binary IPv6 address followed by the 1753 protocol number and port number to be used. 1755 Note 1: The IPv6 address MUST normally have global scope. 1756 Exceptionally, during node bootstrap, a link-local address MAY be 1757 used for specific objectives only. 1759 Note 2: A link-local IPv6 address MUST NOT be used when this option 1760 is included in a Divert option. 1762 3.9.5.2. Locator IPv4 address option 1764 In fragmentary CDDL, the IPv4 address option follows the pattern: 1766 ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address, 1767 transport-proto, port-number] 1768 ipv4-address = bytes .size 4 1770 The content of this option is a binary IPv4 address followed by the 1771 protocol number and port number to be used. 1773 Note: If an operator has internal network address translation for 1774 IPv4, this option MUST NOT be used within the Divert option. 1776 3.9.5.3. Locator FQDN option 1778 In fragmentary CDDL, the FQDN option follows the pattern: 1780 fqdn-locator-option = [O_FQDN_LOCATOR, text, 1781 transport-proto, port-number] 1783 The content of this option is the Fully Qualified Domain Name of the 1784 target followed by the protocol number and port number to be used. 1786 Note 1: Any FQDN which might not be valid throughout the network in 1787 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1788 when this option is used within the Divert option. 1790 Note 2: Normal GRASP operations are not expected to use this option. 1791 It is intended for special purposes such as discovering external 1792 services. 1794 3.9.5.4. Locator URI option 1796 In fragmentary CDDL, the URI option follows the pattern: 1798 uri-locator = [O_URI_LOCATOR, text] 1800 The content of this option is the Uniform Resource Identifier of the 1801 target [RFC3986]. 1803 Note 1: Any URI which might not be valid throughout the network in 1804 question, such as one based on a Multicast DNS name [RFC6762], MUST 1805 NOT be used when this option is used within the Divert option. 1807 Note 2: Normal GRASP operations are not expected to use this option. 1808 It is intended for special purposes such as discovering external 1809 services. 1811 3.10. Objective Options 1813 3.10.1. Format of Objective Options 1815 An objective option is used to identify objectives for the purposes 1816 of discovery, negotiation or synchronization. All objectives MUST be 1817 in the following format, described in fragmentary CDDL: 1819 objective = [objective-name, objective-flags, loop-count, ?any] 1821 objective-name = text 1822 loop-count = 0..255 1824 All objectives are identified by a unique name which is a case- 1825 sensitive UTF-8 string. 1827 The names of generic objectives MUST NOT include a colon (":") and 1828 MUST be registered with IANA (Section 7). 1830 The names of privately defined objectives MUST include at least one 1831 colon (":"). The string preceding the last colon in the name MUST be 1832 globally unique and in some way identify the entity or person 1833 defining the objective. The following three methods MAY be used to 1834 create such a globally unique string: 1836 1. The unique string is a decimal number representing a registered 1837 32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 1838 uniquely identifies the enterprise defining the objective. 1840 2. The unique string is a fully qualified domain name that uniquely 1841 identifies the entity or person defining the objective. 1843 3. The unique string is an email address that uniquely identifies 1844 the entity or person defining the objective. 1846 The GRASP protocol treats the objective name as an opaque string. 1847 For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 1848 and "user@example.org:EX1" would be five different objectives. 1850 The 'objective-flags' field is described below. 1852 The 'loop-count' field is used for terminating negotiation as 1853 described in Section 3.8.7. It is also used for terminating 1854 discovery as described in Section 3.5.4, and for terminating flooding 1855 as described in Section 3.5.6.1. 1857 The 'any' field is to express the actual value of a negotiation or 1858 synchronization objective. Its format is defined in the 1859 specification of the objective and may be a single value or a data 1860 structure of any kind. It is optional because it is optional in a 1861 Discovery or Discovery Response message. 1863 3.10.2. Objective flags 1865 An objective may be relevant for discovery only, for discovery and 1866 negotiation, or for discovery and synchronization. This is expressed 1867 in the objective by logical flags: 1869 objective-flags = uint .bits objective-flag 1870 objective-flag = &( 1871 F_DISC: 0 ; valid for discovery only 1872 F_NEG: 1 ; valid for discovery and negotiation 1873 F_SYNCH: 2 ; valid for discovery and synchronization 1874 ) 1876 3.10.3. General Considerations for Objective Options 1878 As mentioned above, Objective Options MUST be assigned a unique name. 1879 As long as privately defined Objective Options obey the rules above, 1880 this document does not restrict their choice of name, but the entity 1881 or person concerned SHOULD publish the names in use. 1883 All Objective Options MUST respect the CBOR patterns defined above as 1884 "objective" and MUST replace the "any" field with a valid CBOR data 1885 definition for the relevant use case and application. 1887 An Objective Option that contains no additional fields beyond its 1888 "loop-count" can only be a discovery objective and MUST only be used 1889 in Discovery and Discovery Response messages. 1891 The Negotiation Objective Options contain negotiation objectives, 1892 which vary according to different functions/services. They MUST be 1893 carried by Discovery, Request Negotiation or Negotiation messages 1894 only. The negotiation initiator MUST set the initial "loop-count" to 1895 a value specified in the specification of the objective or, if no 1896 such value is specified, to GRASP_DEF_LOOPCT. 1898 For most scenarios, there should be initial values in the negotiation 1899 requests. Consequently, the Negotiation Objective options MUST 1900 always be completely presented in a Request Negotiation message, or 1901 in a Discovery message in rapid mode. If there is no initial value, 1902 the bits in the value field SHOULD all be set to indicate a 1903 meaningless value, unless this is inappropriate for the specific 1904 negotiation objective. 1906 Synchronization Objective Options are similar, but MUST be carried by 1907 Discovery, Discovery Response, Request Synchronization, or Flood 1908 Synchronization messages only. They include value fields only in 1909 Synchronization or Flood Synchronization messages. 1911 3.10.4. Organizing of Objective Options 1913 Generic objective options MUST be specified in documents available to 1914 the public and SHOULD be designed to use either the negotiation or 1915 the synchronization mechanism described above. 1917 As noted earlier, one negotiation objective is handled by each GRASP 1918 negotiation thread. Therefore, a negotiation objective, which is 1919 based on a specific function or action, SHOULD be organized as a 1920 single GRASP option. It is NOT RECOMMENDED to organize multiple 1921 negotiation objectives into a single option, nor to split a single 1922 function or action into multiple negotiation objectives. 1924 It is important to understand that GRASP negotiation does not support 1925 transactional integrity. If transactional integrity is needed for a 1926 specific objective, this must be ensured by the ASA. For example, an 1927 ASA might need to ensure that it only participates in one negotiation 1928 thread at the same time. Such an ASA would need to stop listening 1929 for incoming negotiation requests before generating an outgoing 1930 negotiation request. 1932 A synchronization objective SHOULD be organized as a single GRASP 1933 option. 1935 Some objectives will support more than one operational mode. An 1936 example is a negotiation objective with both a "dry run" mode (where 1937 the negotiation is to find out whether the other end can in fact make 1938 the requested change without problems) and a "live" mode. Such modes 1939 will be defined in the specification of such an objective. These 1940 objectives SHOULD include flags indicating the applicable mode(s). 1942 An objective may have multiple parameters. Parameters can be 1943 categorized into two classes: the obligatory ones presented as fixed 1944 fields; and the optional ones presented in CBOR sub-options or some 1945 other form of data structure embedded in CBOR. The format might be 1946 inherited from an existing management or configuration protocol, the 1947 objective option acting as a carrier for that format. The data 1948 structure might be defined in a formal language, but that is a matter 1949 for the specifications of individual objectives. There are many 1950 candidates, according to the context, such as ABNF, RBNF, XML Schema, 1951 possibly YANG, etc. The GRASP protocol itself is agnostic on these 1952 questions. 1954 It is NOT RECOMMENDED to split parameters in a single objective into 1955 multiple options, unless they have different response periods. An 1956 exception scenario may also be described by split objectives. 1958 All objectives MUST support GRASP discovery. However, as mentioned 1959 in Section 3.3, it is acceptable for an ASA to use an alternative 1960 method of discovery. 1962 Normally, a GRASP objective will refer to specific technical 1963 parameters as explained in Section 3.1. However, it is acceptable to 1964 define an abstract objective for the purpose of managing or 1965 coordinating ASAs. It is also acceptable to define a special-purpose 1966 objective for purposes such as trust bootstrapping or formation of 1967 the ACP. 1969 3.10.5. Experimental and Example Objective Options 1971 The names "EX0" through "EX9" have been reserved for experimental 1972 options. Multiple names have been assigned because a single 1973 experiment may use multiple options simultaneously. These 1974 experimental options are highly likely to have different meanings 1975 when used for different experiments. Therefore, they SHOULD NOT be 1976 used without an explicit human decision and SHOULD NOT be used in 1977 unmanaged networks such as home networks. 1979 These names are also RECOMMENDED for use in documentation examples. 1981 4. Implementation Status [RFC Editor: please remove] 1983 Two prototype implementations of GRASP have been made. 1985 4.1. BUPT C++ Implementation 1987 o Name: BaseNegotiator.cpp, msg.cpp, Client.cpp, Server.cpp 1989 o Description: C++ implementation of GRASP kernel and API 1991 o Maturity: Prototype code, interoperable between Ubuntu. 1993 o Coverage: Corresponds to draft-carpenter-anima-gdn-protocol-03. 1994 Since it was implemented based on the old version draft, the most 1995 significant limitations comparing to current protocol design 1996 include: 1998 * Not support CBOR 2000 * Not support Flooding 2002 * Not support loop avoidance 2004 * only coded for IPv6, any IPv4 is accidental 2006 o Licensing: Huawei License. 2008 o Experience: https://github.com/liubingpang/IETF-Anima-Signaling- 2009 Protocol/blob/master/README.md 2011 o Contact: https://github.com/liubingpang/IETF-Anima-Signaling- 2012 Protocol 2014 4.2. Python Implementation 2016 o Name: graspy 2018 o Description: Python 3 implementation of GRASP kernel and API. 2020 o Maturity: Prototype code, interoperable between Windows 7 and 2021 Linux. 2023 o Coverage: Corresponds to draft-ietf-anima-grasp-08. Limitations 2024 include: 2026 * insecure: uses a dummy ACP module and does not implement TLS 2028 * only coded for IPv6, any IPv4 is accidental 2030 * FQDN and URI locators incompletely supported 2032 * no code for rapid mode 2034 * relay code is lazy (no rate control) 2036 * all unicast transactions use TCP (no unicast UDP). 2037 Experimental code for unicast UDP proved to be complex and 2038 brittle. 2040 * optional Objective option in Response messages not implemented 2041 * workarounds for defects in Python socket module and Windows 2042 socket peculiarities 2044 o Licensing: Simplified BSD 2046 o Experience: https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf 2048 o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ 2050 5. Security Considerations 2052 It is obvious that a successful attack on negotiation-enabled nodes 2053 would be extremely harmful, as such nodes might end up with a 2054 completely undesirable configuration that would also adversely affect 2055 their peers. GRASP nodes and messages therefore require full 2056 protection. 2058 - Authentication 2060 A cryptographically authenticated identity for each device is 2061 needed in an autonomic network. It is not safe to assume that a 2062 large network is physically secured against interference or that 2063 all personnel are trustworthy. Each autonomic node MUST be 2064 capable of proving its identity and authenticating its messages. 2065 GRASP relies on a separate external certificate-based security 2066 mechanism to support authentication, data integrity protection, 2067 and anti-replay protection. 2069 Since GRASP is intended to be deployed in a single administrative 2070 domain operating its own trust anchor and CA, there is no need for 2071 a trusted public third party. In a network requiring "air gap" 2072 security, such a dependency would be unacceptable. 2074 If GRASP is used temporarily without an external security 2075 mechanism, for example during system bootstrap (Section 3.5.1), 2076 the Session ID (Section 3.7) will act as a nonce to provide 2077 limited protection against third parties injecting responses. A 2078 full analysis of the secure bootstrap process is out of scope for 2079 the present document. 2081 - Authorization and Roles 2083 The GRASP protocol is agnostic about the role of individual ASAs 2084 and about which objectives a particular ASA is authorized to 2085 support. An implementation might support precautions such as 2086 allowing only one ASA in a given node to modify a given objective, 2087 but this may not be appropriate in all cases. For example, it 2088 might be operationally useful to allow an old and a new version of 2089 the same ASA to run simultaneously during an overlap period. 2090 These questions are out of scope for the present specification. 2092 - Privacy and confidentiality 2094 Generally speaking, no personal information is expected to be 2095 involved in the signaling protocol, so there should be no direct 2096 impact on personal privacy. Nevertheless, traffic flow paths, 2097 VPNs, etc. could be negotiated, which could be of interest for 2098 traffic analysis. Also, operators generally want to conceal 2099 details of their network topology and traffic density from 2100 outsiders. Therefore, since insider attacks cannot be excluded in 2101 a large network, the security mechanism for the protocol MUST 2102 provide message confidentiality. This is why Section 3.5.1 2103 requires either an ACP or the use of TLS. 2105 - Link-local multicast security 2107 GRASP has no reasonable alternative to using link-local multicast 2108 for Discovery or Flood Synchronization messages and these messages 2109 are sent in clear and with no authentication. They are therefore 2110 available to on-link eavesdroppers, and could be forged by on-link 2111 attackers. In the case of Discovery, the Discovery Responses are 2112 unicast and will therefore be protected (Section 3.5.1), and an 2113 untrusted forger will not be able to receive responses. In the 2114 case of Flood Synchronization, an on-link eavesdropper will be 2115 able to receive the flooded objectives but there is no response 2116 message to consider. Some precautions for Flood Synchronization 2117 messages are suggested in Section 3.5.6.1. 2119 - DoS Attack Protection 2121 GRASP discovery partly relies on insecure link-local multicast. 2122 Since routers participating in GRASP sometimes relay discovery 2123 messages from one link to another, this could be a vector for 2124 denial of service attacks. Some mitigations are specified in 2125 Section 3.5.4. However, malicious code installed inside the 2126 Autonomic Control Plane could always launch DoS attacks consisting 2127 of spurious discovery messages, or of spurious discovery 2128 responses. Additionally, it is of great importance that firewalls 2129 prevent any GRASP messages from entering the domain from an 2130 untrusted source. 2132 - Security during bootstrap and discovery 2134 A node cannot authenticate GRASP traffic from other nodes until it 2135 has identified the trust anchor and can validate certificates for 2136 other nodes. Also, until it has succesfully enrolled 2138 [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that 2139 other nodes are able to authenticate its own traffic. Therefore, 2140 GRASP discovery during the bootstrap phase for a new device will 2141 inevitably be insecure and GRASP synchronization and negotiation 2142 will be impossible until enrollment is complete. Further details 2143 are given in Section 3.5.2. 2145 - Security of discovered locators 2147 When GRASP discovery returns an IP address, it MUST be that of a 2148 node within the secure environment (Section 3.5.1). If it returns 2149 an FQDN or a URI, the ASA that receives it MUST NOT assume that 2150 the target of the locator is within the secure environment. 2152 6. CDDL Specification of GRASP 2154 2155 grasp-message = (message .within message-structure) / noop-message 2157 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 2158 *grasp-option] 2160 MESSAGE_TYPE = 0..255 2161 session-id = 0..4294967295 ;up to 32 bits 2162 grasp-option = any 2164 message /= discovery-message 2165 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 2167 message /= response-message ;response to Discovery 2168 response-message = [M_RESPONSE, session-id, initiator, ttl, 2169 (+locator-option // divert-option), ?objective] 2171 message /= synch-message ;response to Synchronization request 2172 synch-message = [M_SYNCH, session-id, objective] 2174 message /= flood-message 2175 flood-message = [M_FLOOD, session-id, initiator, ttl, 2176 (locator-option / []), +objective] 2178 message /= request-negotiation-message 2179 request-negotiation-message = [M_REQ_NEG, session-id, objective] 2181 message /= request-synchronization-message 2182 request-synchronization-message = [M_REQ_SYN, session-id, objective] 2184 message /= negotiation-message 2185 negotiation-message = [M_NEGOTIATE, session-id, objective] 2186 message /= end-message 2187 end-message = [M_END, session-id, accept-option / decline-option ] 2189 message /= wait-message 2190 wait-message = [M_WAIT, session-id, waiting-time] 2192 message /= invalid-message 2193 invalid-message = [M_INVALID, session-id, ?any] 2195 noop-message = [M_NOOP] 2197 divert-option = [O_DIVERT, +locator-option] 2199 accept-option = [O_ACCEPT] 2201 decline-option = [O_DECLINE, ?reason] 2202 reason = text ;optional error message 2204 waiting-time = 0..4294967295 ; in milliseconds 2205 ttl = 0..4294967295 ; in milliseconds 2207 locator-option /= [O_IPv4_LOCATOR, ipv4-address, 2208 transport-proto, port-number] 2209 ipv4-address = bytes .size 4 2211 locator-option /= [O_IPv6_LOCATOR, ipv6-address, 2212 transport-proto, port-number] 2213 ipv6-address = bytes .size 16 2215 locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number] 2217 transport-proto = IPPROTO_TCP / IPPROTO_UDP 2218 IPPROTO_TCP = 6 2219 IPPROTO_UDP = 17 2220 port-number = 0..65535 2222 locator-option /= [O_URI_LOCATOR, text] 2224 initiator = ipv4-address / ipv6-address 2226 objective-flags = uint .bits objective-flag 2228 objective-flag = &( 2229 F_DISC: 0 ; valid for discovery only 2230 F_NEG: 1 ; valid for discovery and negotiation 2231 F_SYNCH: 2) ; valid for discovery and synchronization 2233 objective = [objective-name, objective-flags, loop-count, ?any] 2234 objective-name = text ;see specification for uniqueness rules 2236 loop-count = 0..255 2238 ; Constants for message types and option types 2240 M_NOOP = 0 2241 M_DISCOVERY = 1 2242 M_RESPONSE = 2 2243 M_REQ_NEG = 3 2244 M_REQ_SYN = 4 2245 M_NEGOTIATE = 5 2246 M_END = 6 2247 M_WAIT = 7 2248 M_SYNCH = 8 2249 M_FLOOD = 9 2250 M_INVALID = 99 2252 O_DIVERT = 100 2253 O_ACCEPT = 101 2254 O_DECLINE = 102 2255 O_IPv6_LOCATOR = 103 2256 O_IPv4_LOCATOR = 104 2257 O_FQDN_LOCATOR = 105 2258 O_URI_LOCATOR = 106 2259 2261 7. IANA Considerations 2263 This document defines the Generic Autonomic Signaling Protocol 2264 (GRASP). 2266 Section 3.6 explains the following link-local multicast addresses, 2267 which IANA is requested to assign for use by GRASP: 2269 ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in 2270 the IPv6 Link-Local Scope Multicast Addresses registry. 2272 ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in 2273 the IPv4 Multicast Local Network Control Block. 2275 Section 3.6 explains the following User Port, which IANA is requested 2276 to assign for use by GRASP for both UDP and TCP: 2278 GRASP_LISTEN_PORT: (TBD3) 2279 Service Name: Generic Autonomic Signaling Protocol (GRASP) 2280 Transport Protocols: UDP, TCP 2281 Assignee: iesg@ietf.org 2282 Contact: chair@ietf.org 2283 Description: See Section 3.6 2284 Reference: RFC XXXX (this document) 2286 The IANA is requested to create a GRASP Parameter Registry including 2287 two registry tables. These are the GRASP Messages and Options 2288 Table and the GRASP Objective Names Table. 2290 GRASP Messages and Options Table. The values in this table are names 2291 paired with decimal integers. Future values MUST be assigned using 2292 the Standards Action policy defined by [RFC5226]. The following 2293 initial values are assigned by this document: 2295 M_NOOP = 0 2296 M_DISCOVERY = 1 2297 M_RESPONSE = 2 2298 M_REQ_NEG = 3 2299 M_REQ_SYN = 4 2300 M_NEGOTIATE = 5 2301 M_END = 6 2302 M_WAIT = 7 2303 M_SYNCH = 8 2304 M_FLOOD = 9 2305 M_INVALID = 99 2307 O_DIVERT = 100 2308 O_ACCEPT = 101 2309 O_DECLINE = 102 2310 O_IPv6_LOCATOR = 103 2311 O_IPv4_LOCATOR = 104 2312 O_FQDN_LOCATOR = 105 2313 O_URI_LOCATOR = 106 2315 GRASP Objective Names Table. The values in this table are UTF-8 2316 strings. Future values MUST be assigned using the Specification 2317 Required policy defined by [RFC5226]. The following initial values 2318 are assigned by this document: 2320 EX0 2321 EX1 2322 EX2 2323 EX3 2324 EX4 2325 EX5 2326 EX6 2327 EX7 2328 EX8 2329 EX9 2331 8. Acknowledgements 2333 A major contribution to the original version of this document was 2334 made by Sheng Jiang. Significant review inputs were received from 2335 Joel Halpern and Michael Richardson. 2337 Valuable comments were received from Michael Behringer, Jeferson 2338 Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Toerless Eckert, Yu Fu, 2339 Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, 2340 Markus Stenberg, Rene Struik, Dacheng Zhang, and other participants 2341 in the NMRG research group and the ANIMA working group. 2343 9. References 2345 9.1. Normative References 2347 [I-D.greevenbosch-appsawg-cbor-cddl] 2348 Vigano, C. and H. Birkholz, "CBOR data definition language 2349 (CDDL): a notational convention to express CBOR data 2350 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 2351 in progress), September 2016. 2353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2354 Requirement Levels", BCP 14, RFC 2119, 2355 DOI 10.17487/RFC2119, March 1997, 2356 . 2358 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2359 Resource Identifier (URI): Generic Syntax", STD 66, 2360 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2361 . 2363 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2364 "Randomness Requirements for Security", BCP 106, RFC 4086, 2365 DOI 10.17487/RFC4086, June 2005, 2366 . 2368 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2369 (TLS) Protocol Version 1.2", RFC 5246, 2370 DOI 10.17487/RFC5246, August 2008, 2371 . 2373 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2374 Housley, R., and W. Polk, "Internet X.509 Public Key 2375 Infrastructure Certificate and Certificate Revocation List 2376 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2377 . 2379 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2380 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2381 January 2012, . 2383 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2384 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2385 October 2013, . 2387 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2388 Interface Identifiers with IPv6 Stateless Address 2389 Autoconfiguration (SLAAC)", RFC 7217, 2390 DOI 10.17487/RFC7217, April 2014, 2391 . 2393 9.2. Informative References 2395 [I-D.chaparadza-intarea-igcp] 2396 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 2397 Mahkonen, "IP based Generic Control Protocol (IGCP)", 2398 draft-chaparadza-intarea-igcp-00 (work in progress), July 2399 2011. 2401 [I-D.ietf-anima-autonomic-control-plane] 2402 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 2403 Control Plane", draft-ietf-anima-autonomic-control- 2404 plane-03 (work in progress), July 2016. 2406 [I-D.ietf-anima-bootstrapping-keyinfra] 2407 Pritikin, M., Richardson, M., Behringer, M., and S. 2408 Bjarnason, "Bootstrapping Remote Secure Key 2409 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2410 keyinfra-03 (work in progress), June 2016. 2412 [I-D.ietf-anima-reference-model] 2413 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 2414 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 2415 Reference Model for Autonomic Networking", draft-ietf- 2416 anima-reference-model-02 (work in progress), July 2016. 2418 [I-D.ietf-anima-stable-connectivity] 2419 Eckert, T. and M. Behringer, "Using Autonomic Control 2420 Plane for Stable Connectivity of Network OAM", draft-ietf- 2421 anima-stable-connectivity-01 (work in progress), July 2422 2016. 2424 [I-D.ietf-netconf-restconf] 2425 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2426 Protocol", draft-ietf-netconf-restconf-18 (work in 2427 progress), October 2016. 2429 [I-D.liang-iana-pen] 2430 Liang, P., Melnikov, A., and D. Conrad, "Private 2431 Enterprise Number (PEN) practices and Internet Assigned 2432 Numbers Authority (IANA) registration considerations", 2433 draft-liang-iana-pen-06 (work in progress), July 2015. 2435 [I-D.liu-anima-grasp-api] 2436 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 2437 Autonomic Signaling Protocol Application Program Interface 2438 (GRASP API)", draft-liu-anima-grasp-api-02 (work in 2439 progress), September 2016. 2441 [I-D.stenberg-anima-adncp] 2442 Stenberg, M., "Autonomic Distributed Node Consensus 2443 Protocol", draft-stenberg-anima-adncp-00 (work in 2444 progress), March 2015. 2446 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2447 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2448 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2449 September 1997, . 2451 [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, 2452 "Server Cache Synchronization Protocol (SCSP)", RFC 2334, 2453 DOI 10.17487/RFC2334, April 1998, 2454 . 2456 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 2457 "Service Location Protocol, Version 2", RFC 2608, 2458 DOI 10.17487/RFC2608, June 1999, 2459 . 2461 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2462 "Remote Authentication Dial In User Service (RADIUS)", 2463 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2464 . 2466 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2467 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2468 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2469 . 2471 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2472 C., and M. Carney, "Dynamic Host Configuration Protocol 2473 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2474 2003, . 2476 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 2477 for the Simple Network Management Protocol (SNMP)", 2478 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 2479 . 2481 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2482 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2483 DOI 10.17487/RFC4861, September 2007, 2484 . 2486 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2487 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2488 DOI 10.17487/RFC5226, May 2008, 2489 . 2491 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2492 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2493 October 2010, . 2495 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 2496 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 2497 March 2011, . 2499 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2500 and A. Bierman, Ed., "Network Configuration Protocol 2501 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2502 . 2504 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2505 Ed., "Diameter Base Protocol", RFC 6733, 2506 DOI 10.17487/RFC6733, October 2012, 2507 . 2509 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2510 DOI 10.17487/RFC6762, February 2013, 2511 . 2513 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2514 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2515 . 2517 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2518 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2519 DOI 10.17487/RFC6887, April 2013, 2520 . 2522 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2523 Constrained-Node Networks", RFC 7228, 2524 DOI 10.17487/RFC7228, May 2014, 2525 . 2527 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 2528 "Requirements for Scalable DNS-Based Service Discovery 2529 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 2530 DOI 10.17487/RFC7558, July 2015, 2531 . 2533 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2534 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2535 Networking: Definitions and Design Goals", RFC 7575, 2536 DOI 10.17487/RFC7575, June 2015, 2537 . 2539 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 2540 Analysis for Autonomic Networking", RFC 7576, 2541 DOI 10.17487/RFC7576, June 2015, 2542 . 2544 [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus 2545 Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, 2546 . 2548 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2549 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2550 2016, . 2552 Appendix A. Open Issues [RFC Editor: Please remove if empty] 2554 o 59. Placeholder. 2556 Appendix B. Closed Issues [RFC Editor: Please remove] 2558 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 2559 as message transport mechanisms. This is not clarified yet. UDP 2560 is good for short conversations, is necessary for multicast 2561 discovery, and generally fits the discovery and divert scenarios 2562 well. However, it will cause problems with large messages. TCP 2563 is good for stable and long sessions, with a little bit of time 2564 consumption during the session establishment stage. If messages 2565 exceed a reasonable MTU, a TCP mode will be required in any case. 2566 This question may be affected by the security discussion. 2568 RESOLVED by specifying UDP for short message and TCP for longer 2569 one. 2571 o 2. DTLS or TLS vs built-in security mechanism. For now, this 2572 specification has chosen a PKI based built-in security mechanism 2573 based on asymmetric cryptography. However, (D)TLS might be chosen 2574 as security solution to avoid duplication of effort. It also 2575 allows essentially similar security for short messages over UDP 2576 and longer ones over TCP. The implementation trade-offs are 2577 different. The current approach requires expensive asymmetric 2578 cryptographic calculations for every message. (D)TLS has startup 2579 overheads but cheaper crypto per message. DTLS is less mature 2580 than TLS. 2582 RESOLVED by specifying external security (ACP or (D)TLS). 2584 o The following open issues applied only if the original security 2585 model was retained: 2587 * 2.1. For replay protection, GRASP currently requires every 2588 participant to have an NTP-synchronized clock. Is this OK for 2589 low-end devices, and how does it work during device 2590 bootstrapping? We could take the Timestamp out of signature 2591 option, to become an independent and OPTIONAL (or RECOMMENDED) 2592 option. 2594 * 2.2. The Signature Option states that this option could be any 2595 place in a message. Wouldn't it be better to specify a 2596 position (such as the end)? That would be much simpler to 2597 implement. 2599 RESOLVED by changing security model. 2601 o 3. DoS Attack Protection needs work. 2603 RESOLVED by adding text. 2605 o 4. Should we consider preferring a text-based approach to 2606 discovery (after the initial discovery needed for bootstrapping)? 2607 This could be a complementary mechanism for multicast based 2608 discovery, especially for a very large autonomic network. 2609 Centralized registration could be automatically deployed 2610 incrementally. At the very first stage, the repository could be 2611 empty; then it could be filled in by the objectives discovered by 2612 different devices (for example using Dynamic DNS Update). The 2613 more records are stored in the repository, the less the multicast- 2614 based discovery is needed. However, if we adopt such a mechanism, 2615 there would be challenges: stateful solution, and security. 2617 RESOLVED for now by adding optional use of DNS-SD by ASAs. 2618 Subsequently removed by editors as irrelevant to GRASP istelf. 2620 o 5. Need to expand description of the minimum requirements for the 2621 specification of an individual discovery, synchronization or 2622 negotiation objective. 2624 RESOLVED for now by extra wording. 2626 o 6. Use case and protocol walkthrough. A description of how a 2627 node starts up, performs discovery, and conducts negotiation and 2628 synchronisation for a sample use case would help readers to 2629 understand the applicability of this specification. Maybe it 2630 should be an artificial use case or maybe a simple real one, based 2631 on a conceptual API. However, the authors have not yet decided 2632 whether to have a separate document or have it in the protocol 2633 document. 2635 RESOLVED: recommend a separate document. 2637 o 7. Cross-check against other ANIMA WG documents for consistency 2638 and gaps. 2640 RESOLVED: Satisfied by WGLC. 2642 o 8. Consideration of ADNCP proposal. 2644 RESOLVED by adding optional use of DNCP for flooding-type 2645 synchronization. 2647 o 9. Clarify how a GDNP instance knows whether it is running inside 2648 the ACP. (Sheng) 2650 RESOLVED by improved text. 2652 o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. 2653 (Sheng) 2655 RESOLVED by improved text and declaring DTLS out of scope for this 2656 draft. 2658 o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - 2659 Brian] 2660 RESOLVED by improved text. 2662 o 12. Justify that IP address within ACP or (D)TLS environment is 2663 sufficient to prove AN identity; or explain how Device Identity 2664 Option is used. (Sheng) 2666 RESOLVED for now: we assume that all ASAs in a device are trusted 2667 as soon as the device is trusted, so they share credentials. In 2668 that case the Device Identity Option is useless. This needs to be 2669 reviewed later. 2671 o 13. Emphasise that negotiation/synchronization are independent 2672 from discovery, although the rapid discovery mode includes the 2673 first step of a negotiation/synchronization. (Sheng) 2675 RESOLVED by improved text. 2677 o 14. Do we need an unsolicited flooding mechanism for discovery 2678 (for discovery results that everyone needs), to reduce scaling 2679 impact of flooding discovery messages? (Toerless) 2681 RESOLVED: Yes, added to requirements and solution. 2683 o 15. Do we need flag bits in Objective Options to distinguish 2684 distinguish Synchronization and Negotiation "Request" or rapid 2685 mode "Discovery" messages? (Bing) 2687 RESOLVED: yes, work on the API showed that these flags are 2688 essential. 2690 o 16. (Related to issue 14). Should we revive the "unsolicited 2691 Response" for flooding synchronisation data? This has to be done 2692 carefully due to the well-known issues with flooding, but it could 2693 be useful, e.g. for Intent distribution, where DNCP doesn't seem 2694 applicable. 2696 RESOLVED: Yes, see #14. 2698 o 17. Ensure that the discovery mechanism is completely proof 2699 against loops and protected against duplicate responses. 2701 RESOLVED: Added loop count mechanism. 2703 o 18. Discuss the handling of multiple valid discovery responses. 2705 RESOLVED: Stated that the choice must be available to the ASA but 2706 GRASP implementation should pick a default. 2708 o 19. Should we use a text-oriented format such as JSON/CBOR 2709 instead of native binary TLV format? 2711 RESOLVED: Yes, changed to CBOR. 2713 o 20. Is the Divert option needed? If a discovery response 2714 provides a valid IP address or FQDN, the recipient doesn't gain 2715 any extra knowledge from the Divert. On the other hand, the 2716 presence of Divert informs the receiver that the target is off- 2717 link, which might be useful sometimes. 2719 RESOLVED: Decided to keep Divert option. 2721 o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling 2722 Protocol)? 2724 RESOLVED: Yes, name changed. 2726 o 22. Does discovery mechanism scale robustly as needed? Need hop 2727 limit on relaying? 2729 RESOLVED: Added hop limit. 2731 o 23. Need more details on TTL for caching discovery responses. 2733 RESOLVED: Done. 2735 o 24. Do we need "fast withdrawal" of discovery responses? 2737 RESOLVED: This doesn't seem necessary. If an ASA exits or stops 2738 supporting a given objective, peers will fail to start future 2739 sessions and will simply repeat discovery. 2741 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? 2743 RESOLVED: Decided not to consider this further as a GRASP protocol 2744 issue. GRASP objectives could embed DNS-SD formats if needed. 2746 o 26. Add a URL type to the locator options (for security bootstrap 2747 etc.) 2749 RESOLVED: Done, later renamed as URI. 2751 o 27. Security of Flood multicasts (Section 3.5.6.1). 2753 RESOLVED: added text. 2755 o 28. Does ACP support secure link-local multicast? 2756 RESOLVED by new text in the Security Considerations. 2758 o 29. PEN is used to distinguish vendor options. Would it be 2759 better to use a domain name? Anything unique will do. 2761 RESOLVED: Simplified this by removing PEN field and changing 2762 naming rules for objectives. 2764 o 30. Does response to discovery require randomized delays to 2765 mitigate amplification attacks? 2767 RESOLVED: WG feedback is that it's unnecessary. 2769 o 31. We have specified repeats for failed discovery etc. Is that 2770 sufficient to deal with sleeping nodes? 2772 RESOLVED: WG feedback is that it's unnecessary to say more. 2774 o 32. We have one-to-one synchronization and flooding 2775 synchronization. Do we also need selective flooding to a subset 2776 of nodes? 2778 RESOLVED: This will be discussed as a protocol extension in a 2779 separate draft (draft-liu-anima-grasp-distribution). 2781 o 33. Clarify if/when discovery needs to be repeated. 2783 RESOLVED: Done. 2785 o 34. Clarify what is mandatory for running in ACP, expand 2786 discussion of security boundary when running with no ACP - might 2787 rely on the local PKI infrastructure. 2789 RESOLVED: Done. 2791 o 35. State that role-based authorization of ASAs is out of scope 2792 for GRASP. GRASP doesn't recognize/handle any "roles". 2794 RESOLVED: Done. 2796 o 36. Reconsider CBOR definition for PEN syntax. ( objective-name 2797 = text / [pen, text] ; pen = uint ) 2799 RESOLVED: See issue 29. 2801 o 37. Are URI locators really needed? 2802 RESOLVED: Yes, e.g. for security bootstrap discovery, but added 2803 note that addresses are the normal case (same for FQDN locators). 2805 o 38. Is Session ID sufficient to identify relayed responses? 2806 Isn't the originator's address needed too? 2808 RESOLVED: Yes, this is needed for multicast messages and their 2809 responses. 2811 o 39. Clarify that a node will contain one GRASP instance 2812 supporting multiple ASAs. 2814 RESOLVED: Done. 2816 o 40. Add a "reason" code to the DECLINE option? 2818 RESOLVED: Done. 2820 o 41. What happens if an ASA cannot conveniently use one of the 2821 GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) 2822 simply pass the discovery results to the ASA so that it can open 2823 its own socket? 2825 RESOLVED: Both would be possible, but (b) is preferred. 2827 o 42. Do we need a feature whereby an ASA can bypass the ACP and 2828 use the data plane for efficiency/throughput? This would require 2829 discovery to return non-ACP addresses and would evade ACP 2830 security. 2832 RESOLVED: This is considered out of scope for GRASP, but a comment 2833 has been added in security considerations. 2835 o 43. Rapid mode synchronization and negotiation is currently 2836 limited to a single objective for simplicity of design and 2837 implementation. A future consideration is to allow multiple 2838 objectives in rapid mode for greater efficiency. 2840 RESOLVED: This is considered out of scope for this version. 2842 o 44. In requirement T9, the words that encryption "may not be 2843 required in all deployments" were removed. Is that OK?. 2845 RESOLVED: No objections. 2847 o 45. Device Identity Option is unused. Can we remove it 2848 completely?. 2850 RESOLVED: No objections. Done. 2852 o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD 2853 messages is intended to assist in loop prevention. However, we 2854 also have the loop count for that. Also, if we create a new 2855 Session ID each time a DISCOVER or FLOOD is relayed, that ID can 2856 be disambiguated by recipients. It would be simpler to remove the 2857 initiator from the messages, making parsing more uniform. Is that 2858 OK? 2860 RESOLVED: Yes. Done. 2862 o 47. REQUEST is a dual purpose message (request negotiation or 2863 request synchronization). Would it be better to split this into 2864 two different messages (and adjust various message names 2865 accordingly)? 2867 RESOLVED: Yes. Done. 2869 o 48. Should the Appendix "Capability Analysis of Current 2870 Protocols" be deleted before RFC publication? 2872 RESOLVED: No (per WG meeting at IETF 96). 2874 o 49. Section 3.5.1 Should say more about signaling between two 2875 autonomic networks/domains. 2877 RESOLVED: Description of separate GRASP instance added. 2879 o 50. Is Rapid mode limited to on-link only? What happens if first 2880 discovery responder does not support Rapid Mode? Section 3.5.5, 2881 Section 3.5.6) 2883 RESOLVED: Not limited to on-link. First responder wins. 2885 o 51. Should flooded objectives have a time-to-live before they are 2886 deleted from the flood cache? And should they be tagged in the 2887 cache with their source locator? 2889 RESOLVED: TTL added to Flood (and Discovery Response) messages. 2890 Cached flooded objectives must be tagged with their originating 2891 ASA locator, and multiple copies must be kept if necessary. 2893 o 52. Describe in detail what is allowed and disallowed in an 2894 insecure instance of GRASP. 2896 RESOLVED: Done. 2898 o 53. Tune IANA Considerations to support early assignment request. 2900 o 54. Is there a highly unlikely race condition if two peers 2901 simultaneously choose the same Session ID and send each other 2902 simultaneous M_REQ_NEG messages? 2904 RESOLVED: Yes. Enhanced text on Session ID generation, and added 2905 precaution when receiving a Request message. 2907 o 55. Could discovery be performed over TCP? 2909 RESOLVED: Unicast discovery added as an option. 2911 o 56. Change Session-ID to 32 bits? 2913 RESOLVED: Done. 2915 o 57. Add M_INVALID message? 2917 RESOLVED: Done. 2919 o 58. Maximum message size? 2921 RESOLVED by specifying default maximum message size (2048 bytes). 2923 Appendix C. Change log [RFC Editor: Please remove] 2925 draft-ietf-anima-grasp-08, 2016-10-30: 2927 Protocol change: Added M_INVALID message. 2929 Protocol change: Increased Session ID space to 32 bits. 2931 Enhanced rules to avoid Session ID clashes. 2933 Corrected and completed description of timeouts for Request messages. 2935 Improved wording about exponential backoff and DoS. 2937 Clarified that discovery relaying is not done by limited security 2938 instances. 2940 Corrected and expanded explanation of port used for Discovery 2941 Response. 2943 Noted that Discovery message could be sent unicast in special cases. 2945 Added paragraph on extensibility. 2947 Specified default maximum message size. 2949 Added Appendix for sample messages. 2951 Added short protocol overview. 2953 Editorial fixes, including minor re-ordering for readability. 2955 draft-ietf-anima-grasp-07, 2016-09-13: 2957 Protocol change: Added TTL field to Flood message (issue 51). 2959 Protocol change: Added Locator option to Flood message (issue 51). 2961 Protocol change: Added TTL field to Discovery Response message 2962 (corrollary to issue 51). 2964 Clarified details of rapid mode (issues 43 and 50). 2966 Description of inter-domain GRASP instance added (issue 49). 2968 Description of limited security GRASP instances added (issue 52). 2970 Strengthened advice to use TCP rather than UDP. 2972 Updated IANA considerations and text about well-known port usage 2973 (issue 53). 2975 Amended text about ASA authorization and roles to allow for 2976 overlapping ASAs. 2978 Added text recommending that Flood should be repeated periodically. 2980 Editorial fixes. 2982 draft-ietf-anima-grasp-06, 2016-06-27: 2984 Added text on discovery cache timeouts. 2986 Noted that ASAs that are only initiators do not need to respond to 2987 discovery message. 2989 Added text on unexpected address changes. 2991 Added text on robust implementation. 2993 Clarifications and editorial fixes for numerous review comments 2995 Added open issues for some review comments. 2997 draft-ietf-anima-grasp-05, 2016-05-13: 2999 Noted in requirement T1 that it should be possible to implement ASAs 3000 independently as user space programs. 3002 Protocol change: Added protocol number and port to discovery 3003 response. Updated protocol description, CDDL and IANA considerations 3004 accordingly. 3006 Clarified that discovery and flood multicasts are handled by the 3007 GRASP kernel, not directly by ASAs. 3009 Clarified that a node may discover an objective without supporting it 3010 for synchronization or negotiation. 3012 Added Implementation Status section. 3014 Added reference to SCSP. 3016 Editorial fixes. 3018 draft-ietf-anima-grasp-04, 2016-03-11: 3020 Protocol change: Restored initiator field in certain messages and 3021 adjusted relaying rules to provide complete loop detection. 3023 Updated IANA Considerations. 3025 draft-ietf-anima-grasp-03, 2016-02-24: 3027 Protocol change: Removed initiator field from certain messages and 3028 adjusted relaying requirement to simplify loop detection. Also 3029 clarified narrative explanation of discovery relaying. 3031 Protocol change: Split Request message into two (Request Negotiation 3032 and Request Synchronization) and updated other message names for 3033 clarity. 3035 Protocol change: Dropped unused Device ID option. 3037 Further clarified text on transport layer usage. 3039 New text about multicast insecurity in Security Considerations. 3041 Various other clarifications and editorial fixes, including moving 3042 some material to Appendix. 3044 draft-ietf-anima-grasp-02, 2016-01-13: 3046 Resolved numerous issues according to WG discussions. 3048 Renumbered requirements, added D9. 3050 Protocol change: only allow one objective in rapid mode. 3052 Protocol change: added optional error string to DECLINE option. 3054 Protocol change: removed statement that seemed to say that a Request 3055 not preceded by a Discovery should cause a Discovery response. That 3056 made no sense, because there is no way the initiator would know where 3057 to send the Request. 3059 Protocol change: Removed PEN option from vendor objectives, changed 3060 naming rule accordingly. 3062 Protocol change: Added FLOOD message to simplify coding. 3064 Protocol change: Added SYNCH message to simplify coding. 3066 Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD 3067 messages. But also allowed the relay process for DISCOVER and FLOOD 3068 to regenerate a Session ID. 3070 Protocol change: Require that discovered addresses must be global 3071 (except during bootstrap). 3073 Protocol change: Receiver of REQUEST message must close socket if no 3074 ASA is listening for the objective. 3076 Protocol change: Simplified Waiting message. 3078 Protocol change: Added No Operation message. 3080 Renamed URL locator type as URI locator type. 3082 Updated CDDL definition. 3084 Various other clarifications and editorial fixes. 3086 draft-ietf-anima-grasp-01, 2015-10-09: 3088 Updated requirements after list discussion. 3090 Changed from TLV to CBOR format - many detailed changes, added co- 3091 author. 3093 Tightened up loop count and timeouts for various cases. 3095 Noted that GRASP does not provide transactional integrity. 3097 Various other clarifications and editorial fixes. 3099 draft-ietf-anima-grasp-00, 2015-08-14: 3101 File name and protocol name changed following WG adoption. 3103 Added URL locator type. 3105 draft-carpenter-anima-gdn-protocol-04, 2015-06-21: 3107 Tuned wording around hierarchical structure. 3109 Changed "device" to "ASA" in many places. 3111 Reformulated requirements to be clear that the ASA is the main 3112 customer for signaling. 3114 Added requirement for flooding unsolicited synch, and added it to 3115 protocol spec. Recognized DNCP as alternative for flooding synch 3116 data. 3118 Requirements clarified, expanded and rearranged following design team 3119 discussion. 3121 Clarified that GDNP discovery must not be a prerequisite for GDNP 3122 negotiation or synchronization (resolved issue 13). 3124 Specified flag bits for objective options (resolved issue 15). 3126 Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 3127 9,10,11). 3129 Updated DNCP description from latest DNCP draft. 3131 Editorial improvements. 3133 draft-carpenter-anima-gdn-protocol-03, 2015-04-20: 3135 Removed intrinsic security, required external security 3137 Format changes to allow DNCP co-existence 3138 Recognized DNS-SD as alternative discovery method. 3140 Editorial improvements 3142 draft-carpenter-anima-gdn-protocol-02, 2015-02-19: 3144 Tuned requirements to clarify scope, 3146 Clarified relationship between types of objective, 3148 Clarified that objectives may be simple values or complex data 3149 structures, 3151 Improved description of objective options, 3153 Added loop-avoidance mechanisms (loop count and default timeout, 3154 limitations on discovery relaying and on unsolicited responses), 3156 Allow multiple discovery objectives in one response, 3158 Provided for missing or multiple discovery responses, 3160 Indicated how modes such as "dry run" should be supported, 3162 Minor editorial and technical corrections and clarifications, 3164 Reorganized future work list. 3166 draft-carpenter-anima-gdn-protocol-01, restructured the logical flow 3167 of the document, updated to describe synchronization completely, add 3168 unsolicited responses, numerous corrections and clarifications, 3169 expanded future work list, 2015-01-06. 3171 draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- 3172 config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 3173 02, 2014-10-08. 3175 Appendix D. Example Message Formats 3177 For readers unfamiliar with CBOR, this appendix shows a number of 3178 example GRASP messages conforming to the CDDL syntax given in 3179 Section 6. Each message is shown three times in the following 3180 formats: 3182 1. CBOR diagnostic notation. 3184 2. Similar, but showing the names of the constants. 3186 3. Hexadecimal version of the CBOR wire format. 3188 Long lines are split for display purposes only. 3190 D.1. Discovery Example 3192 The initiator multicasts a discovery message: 3194 [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 2, 2, 0]] 3195 [M_DISCOVERY, 13948744, h'20010db8f000baaa28ccdc4c97036781', 3196 ["EX1", F_SYNCH, 2, 0]] 3197 h'84011a00d4d7485020010db8f000baaa28ccdc4c970367818463455831020200' 3199 A peer responds with a locator: 3201 [2, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000, 3202 [103, h'20010db8f000baaaf000baaaf000baaa', 6, 49443]] 3203 [M_RESPONSE, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000, 3204 [O_IPv6_LOCATOR, h'20010db8f000baaaf000baaaf000baaa', 3205 IPPROTO_TCP, 49443]] 3206 h'85021a00d4d7485020010db8f000baaa28ccdc4c9703678119ea6084186750 3207 20010db8f000baaaf000baaaf000baaa0619c123' 3209 D.2. Flood Example 3211 The initiator multicasts a flood message. There is no response: 3213 [9, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000, [], 3214 ["EX1", 2, 2, ["Example 1 value=", 100]]] 3215 [M_FLOOD, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000, [], 3216 ["EX1", F_SYNCH, 2, ["Example 1 value=", 100]]] 3217 h'86091a00357b4e5020010db8f000baaa28ccdc4c9703678119271080846345 3218 5831020282704578616d706c6520312076616c75653d1864' 3220 D.3. Synchronization Example 3222 The initiator unicasts a request: 3224 [4, 4038926, ["EX2", 2, 5, 0]] 3225 [M_REQ_SYN, 4038926, ["EX2", F_SYNCH, 5, 0]] 3226 h'83041a003da10e8463455832020500' 3228 The peer responds with a value: 3230 [8, 4038926, ["EX2", 2, 5, ["Example 2 value=", 200]]] 3231 [M_SYNCH, 4038926, ["EX2", F_SYNCH, 5, ["Example 2 value=", 200]]] 3232 h'83081a003da10e8463455832020582704578616d706c6520322076616c75653d18c8' 3234 D.4. Simple Negotiation Example 3236 The initiator unicasts a request: 3238 [3, 802813, ["EX3", 1, 6, ["NZD", 47]]] 3239 [M_REQ_NEG, 802813, ["EX3", 1, 6, ["NZD", 47]]] 3240 h'83031a000c3ffd8463455833010682634e5a44182f' 3242 The peer responds with immediate acceptance. Note that no objective 3243 is needed, because the initiator's request was accepted without 3244 change: 3246 [6, 802813, [101]] 3247 [M_END , 802813, [O_ACCEPT]] 3248 h'83061a000c3ffd811865' 3250 D.5. Complete Negotiation Example 3252 The initiator unicasts a request: 3254 [3, 13767778, ["EX3", 1, 6, ["NZD", 410]]] 3255 [M_REQ_NEG, 13767778, ["EX3", F_NEG, 6, ["NZD", 410]]] 3256 h'83031a00d214628463455833010682634e5a4419019a' 3258 The responder starts to negotiate (making an offer): 3260 [5, 13767778, ["EX3", 1, 6, ["NZD", 80]]] 3261 [M_NEGOTIATE, 13767778, ["EX3", F_NEG, 6, ["NZD", 80]]] 3262 h'83051a00d214628463455833010682634e5a441850' 3264 The initiator continues to negotiate (reducing its request): 3266 [5, 13767778, ["EX3", 1, 5, ["NZD", 307]]] 3267 [M_NEGOTIATE, 13767778, ["EX3", F_NEG, 5, ["NZD", 307]]] 3268 h'83051a00d214628463455833010582634e5a44190133' 3270 The responder asks for more time: 3272 [7, 13767778, 34965] 3273 [M_WAIT, 13767778, 34965] 3274 h'83071a00d21462198895' 3276 The responder continues to negotiate (increasing its offer): 3278 [5, 13767778, ["EX3", 1, 4, ["NZD", 120]]] 3279 [M_NEGOTIATE, 13767778, ["EX3", F_NEG, 4, ["NZD", 120]]] 3280 h'83051a00d214628463455833010482634e5a441878' 3281 The initiator continues to negotiate (reducing its request): 3283 [5, 13767778, ["EX3", 1, 3, ["NZD", 246]]] 3284 [M_NEGOTIATE, 13767778, ["EX3", F_NEG, 3, ["NZD", 246]]] 3285 h'83051a00d214628463455833010382634e5a4418f6' 3287 The responder refuses to negotiate further: 3289 [6, 13767778, [102, "Insufficient funds"]] 3290 [M_END , 13767778, [O_DECLINE, "Insufficient funds"]] 3291 h'83061a00d2146282186672496e73756666696369656e742066756e6473' 3293 This negotiation has failed. If either side had sent [M_END, 3294 13767778, [O_ACCEPT]] it would have succeeded, converging on the 3295 objective value in the preceding M_NEGOTIATE. Note that apart from 3296 the initial M_REQ_NEG, the process is symmetrical. 3298 Appendix E. Capability Analysis of Current Protocols 3300 This appendix discusses various existing protocols with properties 3301 related to the requirements described in Section 2. The purpose is 3302 to evaluate whether any existing protocol, or a simple combination of 3303 existing protocols, can meet those requirements. 3305 Numerous protocols include some form of discovery, but these all 3306 appear to be very specific in their applicability. Service Location 3307 Protocol (SLP) [RFC2608] provides service discovery for managed 3308 networks, but requires configuration of its own servers. DNS-SD 3309 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 3310 small networks with a single link layer. [RFC7558] aims to extend 3311 this to larger autonomous networks but this is not yet standardized. 3312 However, both SLP and DNS-SD appear to target primarily application 3313 layer services, not the layer 2 and 3 objectives relevant to basic 3314 network configuration. Both SLP and DNS-SD are text-based protocols. 3316 Routing protocols are mainly one-way information announcements. The 3317 receiver makes independent decisions based on the received 3318 information and there is no direct feedback information to the 3319 announcing peer. This remains true even though the protocol is used 3320 in both directions between peer routers; there is state 3321 synchronization, but no negotiation, and each peer runs its route 3322 calculations independently. 3324 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 3325 response model not well suited for peer negotiation. Network 3326 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 3327 does allow positive or negative responses from the target system, but 3328 this is still not adequate for negotiation. 3330 There are various existing protocols that have elementary negotiation 3331 abilities, such as Dynamic Host Configuration Protocol for IPv6 3332 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 3333 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 3334 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 3335 configuration or management protocols. However, they either provide 3336 only a simple request/response model in a master/slave context or 3337 very limited negotiation abilities. 3339 There are some signaling protocols with an element of negotiation. 3340 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 3341 designed for negotiating quality of service parameters along the path 3342 of a unicast or multicast flow. RSVP is a very specialised protocol 3343 aimed at end-to-end flows. However, it has some flexibility, having 3344 been extended for MPLS label distribution [RFC3209]. A more generic 3345 design is General Internet Signalling Transport (GIST) [RFC5971], but 3346 it is complex, tries to solve many problems, and is also aimed at 3347 per-flow signaling across many hops rather than at device-to-device 3348 signaling. However, we cannot completely exclude extended RSVP or 3349 GIST as a synchronization and negotiation protocol. They do not 3350 appear to be directly useable for peer discovery. 3352 We now consider two protocols that are works in progress at the time 3353 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 3354 protocol intended to convey NETCONF information expressed in the YANG 3355 language via HTTP, including the ability to transit HTML 3356 intermediaries. While this is a powerful approach in the context of 3357 centralised configuration of a complex network, it is not well 3358 adapted to efficient interactive negotiation between peer devices, 3359 especially simple ones that might not include YANG processing 3360 already. 3362 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 3363 [RFC7787]. This is defined as a generic form of state 3364 synchronization protocol, with a proposed usage profile being the 3365 Home Networking Control Protocol (HNCP) [RFC7788] for configuring 3366 Homenet routers. A specific application of DNCP for autonomic 3367 networking was proposed in [I-D.stenberg-anima-adncp]. 3369 DNCP "is designed to provide a way for each participating node to 3370 publish a set of TLV (Type-Length-Value) tuples, and to provide a 3371 shared and common view about the data published... DNCP is most 3372 suitable for data that changes only infrequently... If constant rapid 3373 state changes are needed, the preferable choice is to use an 3374 additional point-to-point channel..." 3376 Specific features of DNCP include: 3378 o Every participating node has a unique node identifier. 3380 o DNCP messages are encoded as a sequence of TLV objects, sent over 3381 unicast UDP or TCP, with or without (D)TLS security. 3383 o Multicast is used only for discovery of DNCP neighbors when lower 3384 security is acceptable. 3386 o Synchronization of state is maintained by a flooding process using 3387 the Trickle algorithm. There is no bilateral synchronization or 3388 negotiation capability. 3390 o The HNCP profile of DNCP is designed to operate between directly 3391 connected neighbors on a shared link using UDP and link-local IPv6 3392 addresses. 3394 DNCP does not meet the needs of a general negotiation protocol, 3395 because it is designed specifically for flooding synchronization. 3396 Also, in its HNCP profile it is limited to link-local messages and to 3397 IPv6. However, at the minimum it is a very interesting test case for 3398 this style of interaction between devices without needing a central 3399 authority, and it is a proven method of network-wide state 3400 synchronization by flooding. 3402 The Server Cache Synchronization Protocol (SCSP) [RFC2334] also 3403 describes a method for cache synchronization and cache replication 3404 among a group of nodes. 3406 A proposal was made some years ago for an IP based Generic Control 3407 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 3408 information exchange and negotiation but not directly at peer 3409 discovery. However, it has many points in common with the present 3410 work. 3412 None of the above solutions appears to completely meet the needs of 3413 generic discovery, state synchronization and negotiation in a single 3414 solution. Many of the protocols assume that they are working in a 3415 traditional top-down or north-south scenario, rather than a fluid 3416 peer-to-peer scenario. Most of them are specialized in one way or 3417 another. As a result, we have not identified a combination of 3418 existing protocols that meets the requirements in Section 2. Also, 3419 we have not identified a path by which one of the existing protocols 3420 could be extended to meet the requirements. 3422 Authors' Addresses 3424 Carsten Bormann 3425 Universitaet Bremen TZI 3426 Postfach 330440 3427 D-28359 Bremen 3428 Germany 3430 Email: cabo@tzi.org 3432 Brian Carpenter (editor) 3433 Department of Computer Science 3434 University of Auckland 3435 PB 92019 3436 Auckland 1142 3437 New Zealand 3439 Email: brian.e.carpenter@gmail.com 3441 Bing Liu (editor) 3442 Huawei Technologies Co., Ltd 3443 Q14, Huawei Campus 3444 No.156 Beiqing Road 3445 Hai-Dian District, Beijing 100095 3446 P.R. China 3448 Email: leo.liubing@huawei.com