idnits 2.17.1 draft-ietf-anima-grasp-06.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 (June 27, 2016) is 2859 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-08 ** Downref: Normative reference to an Informational draft: draft-greevenbosch-appsawg-cbor-cddl (ref. 'I-D.greevenbosch-appsawg-cbor-cddl') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-02 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-02 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-01 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-00 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-13 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track B. Carpenter, Ed. 5 Expires: December 29, 2016 Univ. of Auckland 6 B. Liu, Ed. 7 Huawei Technologies Co., Ltd 8 June 27, 2016 10 A Generic Autonomic Signaling Protocol (GRASP) 11 draft-ietf-anima-grasp-06 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 December 29, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirement Analysis of Discovery, Synchronization and 60 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Requirements for Discovery . . . . . . . . . . . . . . . 5 62 2.2. Requirements for Synchronization and Negotiation 63 Capability . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Specific Technical Requirements . . . . . . . . . . . . . 8 65 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10 66 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 11 68 3.3. GRASP Protocol Basic Properties and Mechanisms . . . . . 15 69 3.3.1. Required External Security Mechanism . . . . . . . . 15 70 3.3.2. Transport Layer Usage . . . . . . . . . . . . . . . . 16 71 3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16 72 3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 20 73 3.3.5. Synchronization and Flooding Procedure . . . . . . . 21 74 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 23 75 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 24 76 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 24 77 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 25 78 3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 25 79 3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 25 80 3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 26 81 3.7.4. Discovery Response Message . . . . . . . . . . . . . 27 82 3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 27 83 3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 28 84 3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 28 85 3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 29 86 3.7.9. Synchronization Message . . . . . . . . . . . . . . . 29 87 3.7.10. Flood Synchronization Message . . . . . . . . . . . . 29 88 3.7.11. No Operation Message . . . . . . . . . . . . . . . . 30 89 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 30 90 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 30 91 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 30 92 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 31 93 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 31 94 3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 31 95 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 33 96 3.9.1. Format of Objective Options . . . . . . . . . . . . . 33 97 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 34 98 3.9.3. General Considerations for Objective Options . . . . 35 99 3.9.4. Organizing of Objective Options . . . . . . . . . . . 35 100 3.9.5. Experimental and Example Objective Options . . . . . 37 101 4. Implementation Status [RFC Editor: please remove] . . . . . . 37 102 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 37 103 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 38 104 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 105 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 40 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 109 9.1. Normative References . . . . . . . . . . . . . . . . . . 44 110 9.2. Informative References . . . . . . . . . . . . . . . . . 45 111 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 48 112 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 49 113 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 55 114 Appendix D. Capability Analysis of Current Protocols . . . . . . 59 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 117 1. Introduction 119 The success of the Internet has made IP-based networks bigger and 120 more complicated. Large-scale ISP and enterprise networks have 121 become more and more problematic for human based management. Also, 122 operational costs are growing quickly. Consequently, there are 123 increased requirements for autonomic behavior in the networks. 124 General aspects of autonomic networks are discussed in [RFC7575] and 125 [RFC7576]. 127 One approach is to largely decentralize the logic of network 128 management by migrating it into network elements. A reference model 129 for autonomic networking on this basis is given in 130 [I-D.ietf-anima-reference-model]. The reader should consult this 131 document to understand how various autonomic components fit together. 132 In order to fulfil autonomy, devices that embody Autonomic Service 133 Agents (ASAs, [RFC7575]) have specific signaling requirements. In 134 particular they need to discover each other, to synchronize state 135 with each other, and to negotiate parameters and resources directly 136 with each other. There is no limitation on the types of parameters 137 and resources concerned, which can include very basic information 138 needed for addressing and routing, as well as anything else that 139 might be configured in a conventional non-autonomic network. The 140 atomic unit of discovery, synchronization or negotiation is referred 141 to as a technical objective, i.e, a configurable parameter or set of 142 parameters (defined more precisely in Section 3.1). 144 Following this Introduction, Section 2 describes the requirements for 145 discovery, synchronization and negotiation. Negotiation is an 146 iterative process, requiring multiple message exchanges forming a 147 closed loop between the negotiating entities. In fact, these 148 entities are ASAs, normally but not necessarily in different network 149 devices. State synchronization, when needed, can be regarded as a 150 special case of negotiation, without iteration. Section 3.2 151 describes a behavior model for a protocol intended to support 152 discovery, synchronization and negotiation. The design of GeneRic 153 Autonomic Signaling Protocol (GRASP) in Section 3 of this document is 154 mainly based on this behavior model. The relevant capabilities of 155 various existing protocols are reviewed in Appendix D. 157 The proposed discovery mechanism is oriented towards synchronization 158 and negotiation objectives. It is based on a neighbor discovery 159 process, but also supports diversion to off-link peers. There is no 160 assumption of any particular form of network topology. When a device 161 starts up with no pre-configuration, it has no knowledge of the 162 topology. The protocol itself is capable of being used in a small 163 and/or flat network structure such as a small office or home network 164 as well as a professionally managed network. Therefore, the 165 discovery mechanism needs to be able to allow a device to bootstrap 166 itself without making any prior assumptions about network structure. 168 Because GRASP can be used to perform a decision process among 169 distributed devices or between networks, it must run in a secure and 170 strongly authenticated environment. 172 It is understood that in realistic deployments, not all devices will 173 support GRASP. It is expected that some autonomic service agents 174 will directly manage a group of non-autonomic nodes, and that other 175 non-autonomic nodes will be managed traditionally. Such mixed 176 scenarios are not discussed in this specification. 178 2. Requirement Analysis of Discovery, Synchronization and Negotiation 180 This section discusses the requirements for discovery, negotiation 181 and synchronization capabilities. The primary user of the protocol 182 is an autonomic service agent (ASA), so the requirements are mainly 183 expressed as the features needed by an ASA. A single physical device 184 might contain several ASAs, and a single ASA might manage several 185 technical objectives. If a technical objective is managed by several 186 ASAs, any necessary coordination is outside the scope of the 187 signaling protocol itself. 189 Note that requirements for ASAs themselves, such as the processing of 190 Intent [RFC7575] or interfaces for coordination between ASAs are out 191 of scope for the present document. 193 2.1. Requirements for Discovery 195 D1. ASAs may be designed to manage anything, as required in 196 Section 2.2. A basic requirement is therefore that the protocol can 197 represent and discover any kind of technical objective among 198 arbitrary subsets of participating nodes. 200 In an autonomic network we must assume that when a device starts up 201 it has no information about any peer devices, the network structure, 202 or what specific role it must play. The ASA(s) inside the device are 203 in the same situation. In some cases, when a new application session 204 starts up within a device, the device or ASA may again lack 205 information about relevant peers. For example, it might be necessary 206 to set up resources on multiple other devices, coordinated and 207 matched to each other so that there is no wasted resource. Security 208 settings might also need updating to allow for the new device or 209 user. The relevant peers may be different for different technical 210 objectives. Therefore discovery needs to be repeated as often as 211 necessary to find peers capable of acting as counterparts for each 212 objective that a discovery initiator needs to handle. From this 213 background we derive the next three requirements: 215 D2. When an ASA first starts up, it has no knowledge of the specific 216 network to which it is attached. Therefore the discovery process 217 must be able to support any network scenario, assuming only that the 218 device concerned is bootstrapped from factory condition. 220 D3. When an ASA starts up, it must require no configured location 221 information about any peers in order to discover them. 223 D4. If an ASA supports multiple technical objectives, relevant peers 224 may be different for different discovery objectives, so discovery 225 needs to be performed separately to find counterparts for each 226 objective. Thus, there must be a mechanism by which an ASA can 227 separately discover peer ASAs for each of the technical objectives 228 that it needs to manage, whenever necessary. 230 D5. Following discovery, an ASA will normally perform negotiation or 231 synchronization for the corresponding objectives. The design should 232 allow for this by conveniently linking discovery to negotiation and 233 synchronization. It may provide an optional mechanism to combine 234 discovery and negotiation/synchronization in a single call. 236 D6. Some objectives may only be significant on the local link, but 237 others may be significant across the routed network and require off- 238 link operations. Thus, the relevant peers might be immediate 239 neighbors on the same layer 2 link, or they might be more distant and 240 only accessible via layer 3. The mechanism must therefore provide 241 both on-link and off-link discovery of ASAs supporting specific 242 technical objectives. 244 D7. The discovery process should be flexible enough to allow for 245 special cases, such as the following: 247 o During initialisation, a device must be able to establish mutual 248 trust with the rest of the network and join an authentication 249 mechanism. Although this will inevitably start with a discovery 250 action, it is a special case precisely because trust is not yet 251 established. This topic is the subject of 252 [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once 253 trust has been established for a device, all ASAs within the 254 device inherit the device's credentials and are also trusted. 256 o Depending on the type of network involved, discovery of other 257 central functions might be needed, such as the Network Operations 258 Center (NOC) [I-D.ietf-anima-stable-connectivity]. The protocol 259 must be capable of supporting such discovery during 260 initialisation, as well as discovery during ongoing operation. 262 D8. The discovery process must not generate excessive traffic and 263 must take account of sleeping nodes in the case of a constrained-node 264 network [RFC7228]. 266 D9. There must be a mechanism for handling stale discovery results. 268 2.2. Requirements for Synchronization and Negotiation Capability 270 As background, consider the example of routing protocols, the closest 271 approximation to autonomic networking already in widespread use. 272 Routing protocols use a largely autonomic model based on distributed 273 devices that communicate repeatedly with each other. The focus is 274 reachability, so current routing protocols mainly consider simple 275 link status, i.e., up or down, and an underlying assumption is that 276 all nodes need a consistent view of the network topology in order for 277 the routing algorithm to converge. Thus, routing is mainly based on 278 information synchronization between peers, rather than on bi- 279 directional negotiation. Other information, such as latency, 280 congestion, capacity, and particularly unused capacity, would be 281 helpful to get better path selection and utilization rate, but is not 282 normally used in distributed routing algorithms. Additionally, 283 autonomic networks need to be able to manage many more dimensions, 284 such as security settings, power saving, load balancing, etc. Status 285 information and traffic metrics need to be shared between nodes for 286 dynamic adjustment of resources and for monitoring purposes. While 287 this might be achieved by existing protocols when they are available, 288 the new protocol needs to be able to support parameter exchange, 289 including mutual synchronization, even when no negotiation as such is 290 required. In general, these parameters do not apply to all 291 participating nodes, but only to a subset. 293 SN1. A basic requirement for the protocol is therefore the ability 294 to represent, discover, synchronize and negotiate almost any kind of 295 network parameter among selected subsets of participating nodes. 297 SN2. Negotiation is a request/response process that must be 298 guaranteed to terminate (with success or failure) and if necessary it 299 must contain tie-breaking rules for each technical objective that 300 requires them. While these must be defined specifically for each use 301 case, the protocol should have some general mechanisms in support of 302 loop and deadlock prevention, such as hop count limits or timeouts. 304 SN3. Synchronization might concern small groups of nodes or very 305 large groups. Different solutions might be needed at different 306 scales. 308 SN4. To avoid "reinventing the wheel", the protocol should be able 309 to encapsulate the data formats used by existing configuration 310 protocols (such as NETCONF/YANG) in cases where that is convenient. 312 SN5. Human intervention in complex situations is costly and error- 313 prone. Therefore, synchronization or negotiation of parameters 314 without human intervention is desirable whenever the coordination of 315 multiple devices can improve overall network performance. It 316 therefore follows that the protocol, as part of the Autonomic 317 Networking Infrastructure, should be capable of running in any device 318 that would otherwise need human intervention. The issue of running 319 in constrained nodes is discussed in 320 [I-D.ietf-anima-reference-model]. 322 SN6. Human intervention in large networks is often replaced by use 323 of a top-down network management system (NMS). It therefore follows 324 that the protocol, as part of the Autonomic Networking 325 Infrastructure, should be capable of running in any device that would 326 otherwise be managed by an NMS, and that it can co-exist with an NMS, 327 and with protocols such as SNMP and NETCONF. 329 SN7. Some features are expected to be implemented by individual 330 ASAs, but the protocol must be general enough to allow them: 332 o Dependencies and conflicts: In order to decide a configuration on 333 a given device, the device may need information from neighbors. 334 This can be established through the negotiation procedure, or 335 through synchronization if that is sufficient. However, a given 336 item in a neighbor may depend on other information from its own 337 neighbors, which may need another negotiation or synchronization 338 procedure to obtain or decide. Therefore, there are potential 339 dependencies and conflicts among negotiation or synchronization 340 procedures. Resolving dependencies and conflicts is a matter for 341 the individual ASAs involved. To allow this, there need to be 342 clear boundaries and convergence mechanisms for negotiations. 343 Also some mechanisms are needed to avoid loop dependencies. In 344 such a case, the protocol's role is limited to bilateral signaling 345 between ASAs. 347 o Recovery from faults and identification of faulty devices should 348 be as automatic as possible. The protocol's role is limited to 349 the ability to handle discovery, synchronization and negotiation 350 at any time, in case an ASA detects an anomaly such as a 351 negotiation counterpart failing. 353 o Since the goal is to minimize human intervention, it is necessary 354 that the network can in effect "think ahead" before changing its 355 parameters. One aspect of this is an ASA that relies on a 356 knowledge base to predict network behavior. This is out of scope 357 for the signaling protocol. However, another aspect is 358 forecasting the effect of a change by a "dry run" negotiation 359 before actually installing the change. This will be an 360 application of the protocol rather than a feature of the protocol 361 itself. 363 o Management logging, monitoring, alerts and tools for intervention 364 are required. However, these can only be features of individual 365 ASAs. Another document [I-D.ietf-anima-stable-connectivity] 366 discusses how such agents may be linked into conventional OAM 367 systems via an Autonomic Control Plane 368 [I-D.ietf-anima-autonomic-control-plane]. 370 SN8. The protocol will be able to deal with a wide variety of 371 technical objectives, covering any type of network parameter. 372 Therefore the protocol will need a flexible and easily extensible 373 format for describing objectives. At a later stage it may be 374 desirable to adopt an explicit information model. One consideration 375 is whether to adopt an existing information model or to design a new 376 one. 378 2.3. Specific Technical Requirements 380 T1. It should be convenient for ASA designers to define new 381 technical objectives and for programmers to express them, without 382 excessive impact on run-time efficiency and footprint. In 383 particular, it should be possible for ASAs to be implemented 384 independently of each other as user space programs rather than as 385 kernel code. The classes of device in which the protocol might run 386 is discussed in [I-D.ietf-anima-reference-model]. 388 T2. The protocol should be easily extensible in case the initially 389 defined discovery, synchronization and negotiation mechanisms prove 390 to be insufficient. 392 T3. To be a generic platform, the protocol payload format should be 393 independent of the transport protocol or IP version. In particular, 394 it should be able to run over IPv6 or IPv4. However, some functions, 395 such as multicasting on a link, might need to be IP version 396 dependent. In case of doubt, IPv6 should be preferred. 398 T4. The protocol must be able to access off-link counterparts via 399 routable addresses, i.e., must not be restricted to link-local 400 operation. 402 T5. It must also be possible for an external discovery mechanism to 403 be used, if appropriate for a given technical objective. In other 404 words, GRASP discovery must not be a prerequisite for GRASP 405 negotiation or synchronization. 407 T6. The protocol must be capable of supporting multiple simultaneous 408 operations, especially when wait states occur. 410 T7. Intent: There must be provision for general Intent rules to be 411 applied by all devices in the network (e.g., security rules, prefix 412 length, resource sharing rules). However, Intent distribution might 413 not use the signaling protocol itself, but its design should not 414 exclude such use. 416 T8. Management monitoring, alerts and intervention: Devices should 417 be able to report to a monitoring system. Some events must be able 418 to generate operator alerts and some provision for emergency 419 intervention must be possible (e.g. to freeze synchronization or 420 negotiation in a mis-behaving device). These features might not use 421 the signaling protocol itself, but its design should not exclude such 422 use. 424 T9. The protocol needs to be fully secured against forged messages 425 and man-in-the middle attacks, and secured as much as reasonably 426 possible against denial of service attacks. It needs to be capable 427 of encryption in order to resist unwanted monitoring. However, it is 428 not required that the protocol itself provides these security 429 features; it may depend on an existing secure environment. 431 3. GRASP Protocol Overview 433 3.1. Terminology 435 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 436 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 437 "OPTIONAL" in this document are to be interpreted as described in 438 [RFC2119] when they appear in ALL CAPS. When these words are not in 439 ALL CAPS (such as "should" or "Should"), they have their usual 440 English meanings, and are not to be interpreted as [RFC2119] key 441 words. 443 This document uses terminology defined in [RFC7575]. 445 The following additional terms are used throughout this document: 447 o Autonomic Device: identical to Autonomic Node. 449 o Discovery: a process by which an ASA discovers peers according to 450 a specific discovery objective. The discovery results may be 451 different according to the different discovery objectives. The 452 discovered peers may later be used as negotiation counterparts or 453 as sources of synchronization data. 455 o Negotiation: a process by which two ASAs interact iteratively to 456 agree on parameter settings that best satisfy the objectives of 457 both ASAs. 459 o State Synchronization: a process by which ASAs interact to receive 460 the current state of parameter values stored in other ASAs. This 461 is a special case of negotiation in which information is sent but 462 the ASAs do not request their peers to change parameter settings. 463 All other definitions apply to both negotiation and 464 synchronization. 466 o Technical Objective (usually abbreviated as Objective): A 467 technical objective is a configurable parameter or set of 468 parameters of some kind, which occurs in three contexts: 469 Discovery, Negotiation and Synchronization. In the protocol, an 470 objective is represented by an identifier and if relevant a value. 471 Normally, a given objective will not occur in negotiation and 472 synchronization contexts simultaneously. 474 * One ASA may support multiple independent objectives. 476 * The parameter described by a given objective is naturally based 477 on a specific service or function or action. It may in 478 principle be anything that can be set to a specific logical, 479 numerical or string value, or a more complex data structure, by 480 a network node. That node is generally expected to contain an 481 ASA which may itself manage subsidiary non-autonomic nodes. 483 * Discovery Objective: if a node needs to synchronize or 484 negotiate a specific objective but does not know a peer that 485 supports this objective, it starts a discovery process. The 486 objective is called a Discovery Objective during this process. 488 * Synchronization Objective: an objective whose specific 489 technical content needs to be synchronized among two or more 490 ASAs. 492 * Negotiation Objective: an objective whose specific technical 493 content needs to be decided in coordination with another ASA. 495 o Discovery Initiator: an ASA that spontaneously starts discovery by 496 sending a discovery message referring to a specific discovery 497 objective. 499 o Discovery Responder: a peer that either contains an ASA supporting 500 the discovery objective indicated by the discovery initiator, or 501 caches the locator(s) of the ASA(s) supporting the objective. The 502 locator(s) are indicated in a Discovery Response, which is 503 normally sent by the protocol kernel, as described later. 505 o Synchronization Initiator: an ASA that spontaneously starts 506 synchronization by sending a request message referring to a 507 specific synchronization objective. 509 o Synchronization Responder: a peer ASA which responds with the 510 value of a synchronization objective. 512 o Negotiation Initiator: an ASA that spontaneously starts 513 negotiation by sending a request message referring to a specific 514 negotiation objective. 516 o Negotiation Counterpart: a peer with which the Negotiation 517 Initiator negotiates a specific negotiation objective. 519 3.2. High-Level Design Choices 521 This section describes a behavior model and some considerations for 522 designing a generic signaling protocol initially supporting 523 discovery, synchronization and negotiation, which can act as a 524 platform for different technical objectives. 526 o A generic platform 527 The protocol is designed as a generic platform, which is 528 independent from the synchronization or negotiation contents. It 529 takes care of the general intercommunication between counterparts. 530 The technical contents will vary according to the various 531 technical objectives and the different pairs of counterparts. 533 o The protocol is expected to form part of an Autonomic Networking 534 Infrastructure [I-D.ietf-anima-reference-model]. It will provide 535 services to ASAs via a suitable application programming interface 536 (API), which will reflect the protocol elements but will not 537 necessarily be in one-to-one correspondence to them. This API is 538 out of scope for the present document. 540 o It is normally expected that a single instance of GRASP will exist 541 in an autonomic node, and that the protocol engine and each ASA 542 will run as independent asynchronous processes. 544 o Security infrastructure and trust relationship 546 Because this negotiation protocol may directly cause changes to 547 device configurations and bring significant impacts to a running 548 network, this protocol is assumed to run within an existing secure 549 environment with strong authentication. As a design choice, the 550 protocol itself is not provided with built-in security 551 functionality. 553 On the other hand, a limited negotiation model might be deployed 554 based on a limited trust relationship. For example, between two 555 administrative domains, ASAs might also exchange limited 556 information and negotiate some particular configurations based on 557 a limited conventional or contractual trust relationship. 559 o Discovery, synchronization and negotiation are designed together. 561 The discovery method and the synchronization and negotiation 562 methods are designed in the same way and can be combined when this 563 is useful. These processes can also be performed independently 564 when appropriate. 566 * GRASP discovery is always available for efficient discovery of 567 GRASP peers and allows a rapid mode of operation described in 568 Section 3.3.3. For some objectives, especially those concerned 569 with application layer services, another discovery mechanism 570 such as the future DNS Service Discovery [RFC7558] or Service 571 Location Protocol [RFC2608] MAY be used. The choice is left to 572 the designers of individual ASAs. 574 o A uniform pattern for technical contents 576 The synchronization and negotiation contents are defined according 577 to a uniform pattern. They could be carried either in simple 578 binary format or in payloads described by a flexible language. 579 The basic protocol design uses the Concise Binary Object 580 Representation (CBOR) [RFC7049]. The format is extensible for 581 unknown future requirements. 583 o A flexible model for synchronization 585 GRASP supports bilateral synchronization, which could be used to 586 perform synchronization among a small number of nodes. It also 587 supports an unsolicited flooding mode when large groups of nodes, 588 possibly including all autonomic nodes, need data for the same 589 technical objective. 591 * There may be some network parameters for which a more 592 traditional flooding mechanism such as DNCP [RFC7787] is 593 considered more appropriate. GRASP can coexist with DNCP. 595 o A simple initiator/responder model for negotiation 597 Multi-party negotiations are too complicated to be modeled and 598 there might be too many dependencies among the parties to converge 599 efficiently. A simple initiator/responder model is more feasible 600 and can complete multi-party negotiations by indirect steps. 602 o Organizing of synchronization or negotiation content 604 Naturally, the technical content will be organized according to 605 the relevant function or service. The content from different 606 functions or services is kept independent from each other. They 607 are not combined into a single option or single session because 608 these contents may be negotiated or synchronized with different 609 counterparts or may be different in response time. Thus a normal 610 arrangement would be a single ASA managing a small set of closely 611 related objectives, with a version of that ASA in each relevant 612 autonomic node. Further discussion of this aspect is out of scope 613 for the current document. 615 o Requests and responses in negotiation procedures 617 The initiator can negotiate with its relevant negotiation 618 counterpart ASAs, which may be different according to the specific 619 negotiation objective. It can request relevant information from 620 the negotiation counterpart so that it can decide its local 621 configuration to give the most coordinated performance. It can 622 request the negotiation counterpart to make a matching 623 configuration in order to set up a successful communication with 624 it. It can request certain simulation or forecast results by 625 sending some dry run conditions. 627 Beyond the traditional yes/no answer, the responder can reply with 628 a suggested alternative value for the objective concerned. This 629 would start a bi-directional negotiation ending in a compromise 630 between the two ASAs. 632 o Convergence of negotiation procedures 634 To enable convergence, when a responder makes a suggestion of a 635 changed condition in a negative reply, it should be as close as 636 possible to the original request or previous suggestion. The 637 suggested value of the third or later negotiation steps should be 638 chosen between the suggested values from the last two negotiation 639 steps. In any case there must be a mechanism to guarantee 640 convergence (or failure) in a small number of steps, such as a 641 timeout or maximum number of iterations. 643 * End of negotiation 645 A limited number of rounds, for example three, or a timeout, is 646 needed on each ASA for each negotiation objective. It may be 647 an implementation choice, a pre-configurable parameter, or 648 network Intent. These choices might vary between different 649 types of ASA. Therefore, the definition of each negotiation 650 objective MUST clearly specify this, so that the negotiation 651 can always be terminated properly. 653 * Failed negotiation 655 There must be a well-defined procedure for concluding that a 656 negotiation cannot succeed, and if so deciding what happens 657 next (deadlock resolution, tie-breaking, or revert to best- 658 effort service). Again, this MUST be specified for individual 659 negotiation objectives, as an implementation choice, a pre- 660 configurable parameter, or network Intent. 662 3.3. GRASP Protocol Basic Properties and Mechanisms 664 3.3.1. Required External Security Mechanism 666 The protocol SHOULD run within a secure Autonomic Control Plane (ACP) 667 [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to 668 carry all messages securely, including link-local multicast if 669 possible. A GRASP implementation MUST verify whether the ACP is 670 operational. 672 If there is no ACP, the protocol MUST use another form of strong 673 authentication and SHOULD use a form of strong encryption. TLS 674 [RFC5246] is RECOMMENDED for this purpose, based on a local Public 675 Key Infrastructure (PKI) [RFC5280] managed within the autonomic 676 network itself. The details of such a PKI and how its boundary is 677 established are out of scope for this document. DTLS [RFC6347] MAY 678 be used but since GRASP operations usually involve several messages 679 this is not expected to be advantageous. 681 The ACP, or in its absence the local PKI, sets the boundary within 682 which nodes are trusted as GRASP peers. A GRASP implementation MUST 683 refuse to execute any GRASP functions except discovery if there is 684 neither an operational ACP nor an operational TLS environment. 686 As mentioned in Section 3.2, limited GRASP operations might be 687 performed across an administrative domain boundary by mutual 688 agreement. Such operations MUST be authenticated and SHOULD be 689 encrypted. TLS is RECOMMENDED for this purpose. 691 Link-local multicast is used for discovery messages. Responses to 692 discovery messages MUST be secured, with one exception. 694 The exception is that during initialisation, before a node has joined 695 the applicable trust infrastructure, e.g., 696 [I-D.ietf-anima-bootstrapping-keyinfra], or before the ACP is fully 697 established, it might be impossible to secure messages. Indeed, both 698 the security bootstrap process and the ACP creation process might use 699 insecure GRASP discovery and response messages. Such usage MUST be 700 limited to the strictly necessary minimum. A full analysis of the 701 initialisation process is out of scope for the present document. 703 3.3.2. Transport Layer Usage 705 GRASP discovery and flooding messages are designed for use over link- 706 local multicast UDP. They MUST NOT be fragmented, and therefore MUST 707 NOT exceed the link MTU size. Nothing in principle prevents them 708 from working over some other method of sending packets to all on-link 709 neighbors, but this is out of scope for the present specification. 711 All other GRASP messages are unicast and could in principle run over 712 any transport protocol. An implementation MUST support use of TCP. 713 It MAY support use of another transport protocol. However, GRASP 714 itself does not provide for error detection or retransmission. Use 715 of an unreliable transport protocol is therefore NOT RECOMMENDED. 717 When running within a secure ACP on reliable infrastructure, UDP MAY 718 be used for unicast messages not exceeding the minimum IPv6 path MTU; 719 however, TCP MUST be used for longer messages. In other words, IPv6 720 fragmentation is avoided. If a node receives a UDP message but the 721 reply is too long, it MUST open a TCP connection to the peer for the 722 reply. Note that when the network is under heavy load or in a fault 723 condition, UDP might become unreliable. Since this is when autonomic 724 functions are most necessary, automatic fallback to TCP MUST be 725 implemented. The simplest implementation is therefore to use only 726 TCP. 728 When running without an ACP, TLS MUST be supported and used by 729 default, except for link-local multicast messages. DTLS MAY be 730 supported as an alternative but the details are out of scope for this 731 document. 733 For link-local multicast, the GRASP protocol listens to the GRASP 734 Listen Port (Section 3.5). This port is also used to listen for 735 unicast discovery responses. For unicast transport sessions used for 736 synchronization and negotiation, the ASA concerned listens on its own 737 dynamically assigned port, which is communicated to its peers during 738 discovery. 740 3.3.3. Discovery Mechanism and Procedures 742 o Separated discovery and negotiation mechanisms 744 Although discovery and negotiation or synchronization are 745 defined together in the GRASP, they are separated mechanisms. 746 The discovery process could run independently from the 747 negotiation or synchronization process. Upon receiving a 748 Discovery (Section 3.7.3) message, the recipient node should 749 return a response message in which it either indicates itself 750 as a discovery responder or diverts the initiator towards 751 another more suitable ASA. 753 The discovery action will normally be followed by a negotiation 754 or synchronization action. The discovery results could be 755 utilized by the negotiation protocol to decide which ASA the 756 initiator will negotiate with. 758 The initiator of a discovery action for a given objective need 759 not be capable of responding to that objective as a Negotiation 760 Counterpart, as a Synchronization Responder or as source for 761 flooding. For example, an ASA might perform discovery even if 762 it only wishes to act a Synchronization Initiator or 763 Negotiation Initiator. Such an ASA does not itself need to 764 respond to discovery messages. 766 It is also entirely possible to use GRASP discovery without any 767 subsequent negotiation or synchronization action. In this 768 case, the discovered objective is simply used as a name during 769 the discovery process and any subsequent operations between the 770 peers are outside the scope of GRASP. 772 o Discovery Procedures 774 Discovery starts as an on-link operation. The Divert option 775 can tell the discovery initiator to contact an off-link ASA for 776 that discovery objective. Every Discovery message is sent by a 777 discovery initiator via UDP to the ALL_GRASP_NEIGHBOR link- 778 local multicast address (Section 3.5). Every network device 779 that supports GRASP always listens to a well-known UDP port to 780 capture the discovery messages. Because this port is unique in 781 a device, this is a function of the GRASP kernel and not of an 782 individual ASA. As a result, each ASA will need to register 783 the objectives that it supports with the GRASP kernel. 785 If an ASA in a neighbor device supports the requested discovery 786 objective, the device SHOULD respond to the link-local 787 multicast with a unicast Discovery Response message 788 (Section 3.7.4) with locator option(s), unless it is 789 temporarily unavailable. Otherwise, if the neighbor has cached 790 information about an ASA that supports the requested discovery 791 objective (usually because it discovered the same objective 792 before), it SHOULD respond with a Discovery Response message 793 with a Divert option pointing to the appropriate Discovery 794 Responder. 796 If a device has no information about the requested discovery 797 objective, and is not acting as a discovery relay (see below) 798 it MUST silently discard the Discovery message. 800 If no discovery response is received within a reasonable 801 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), 802 the Discovery message MAY be repeated, with a newly generated 803 Session ID (Section 3.6). An exponential backoff SHOULD be 804 used for subsequent repetitions, in order to mitigate possible 805 denial of service attacks. 807 After a GRASP device successfully discovers a locator for a 808 Discovery Responder supporting a specific objective, it MUST 809 cache this information, including the interface identifier via 810 which it was discovered. This cache record MAY be used for 811 future negotiation or synchronization, and the locator SHOULD 812 be passed on when appropriate as a Divert option to another 813 Discovery Initiator. 815 The cache mechanism MUST include a lifetime for each entry. 816 The lifetime is an implementation choice that MAY be modified 817 by network Intent. In some environments, unplanned address 818 renumbering might occur. In such cases, the cache lifetime 819 SHOULD be short compared to the typical address lifetime and a 820 mechanism to flush the discovery cache SHOULD be implemented. 821 The discovery mechanism needs to track the node's current 822 address to ensure that Discovery Responses always indicate the 823 correct address. 825 If multiple Discovery Responders are found for the same 826 objective, they SHOULD all be cached, unless this creates a 827 resource shortage. The method of choosing between multiple 828 responders is an implementation choice. This choice MUST be 829 available to each ASA but the GRASP implementation SHOULD 830 provide a default choice. 832 Because Discovery Responders will be cached in a finite cache, 833 they might be deleted at any time. In this case, discovery 834 will need to be repeated. If an ASA exits for any reason, its 835 locator might still be cached for some time, and attempts to 836 connect to it will fail. ASAs need to be robust in these 837 circumstances. 839 A GRASP device with multiple link-layer interfaces (typically a 840 router) MUST support discovery on all interfaces. If it 841 receives a Discovery message on a given interface for a 842 specific objective that it does not support and for which it 843 has not previously cached a Discovery Responder, it MUST relay 844 the query by re-issuing a Discovery message as a link-local 845 multicast on its other interfaces. The relayed discovery 846 message MUST have the same Session ID as the incoming discovery 847 message and MUST be tagged with the IP address of its original 848 initiator. Since the relay device is unaware of the timeout 849 set by the original initiator it SHOULD set a timeout at least 850 equal to GRASP_DEF_TIMEOUT milliseconds. 852 The relaying device MUST decrement the loop count within the 853 objective, and MUST NOT relay the Discovery message if the 854 result is zero. Also, it MUST limit the total rate at which it 855 relays discovery messages to a reasonable value, in order to 856 mitigate possible denial of service attacks. It MUST cache the 857 Session ID value and initiator address of each relayed 858 Discovery message until any Discovery Responses have arrived or 859 the discovery process has timed out. To prevent loops, it MUST 860 NOT relay a Discovery message which carries a given cached 861 Session ID and initiator address more than once. These 862 precautions avoid discovery loops and mitigate potential 863 overload. 865 The discovery results received by the relaying device MUST in 866 turn be sent as a Discovery Response message to the Discovery 867 message that caused the relay action. 869 This relayed discovery mechanism, with caching of the results, 870 should be sufficient to support most network bootstrapping 871 scenarios. 873 o A complete discovery process will start with a multicast on the 874 local link. On-link neighbors supporting the discovery objective 875 will respond directly. A neighbor with multiple interfaces will 876 respond with a cached discovery response if any. If not, it will 877 relay the discovery on its other interfaces, for example reaching 878 a higher-level gateway in a hierarchical network. If a node 879 receiving the relayed discovery supports the discovery objective, 880 it will respond to the relayed discovery. If it has a cached 881 response, it will respond with that. If not, it will repeat the 882 discovery process, which thereby becomes recursive. The loop 883 count and timeout will ensure that the process ends. 885 o Rapid Mode (Discovery/Negotiation binding) 887 A Discovery message MAY include a Negotiation Objective option. 888 This allows a rapid mode of negotiation described in 889 Section 3.3.4. A similar mechanism is defined for 890 synchronization in Section 3.3.5. 892 3.3.4. Negotiation Procedures 894 A negotiation initiator sends a negotiation request to a counterpart 895 ASA, including a specific negotiation objective. It may request the 896 negotiation counterpart to make a specific configuration. 897 Alternatively, it may request a certain simulation or forecast result 898 by sending a dry run configuration. The details, including the 899 distinction between dry run and an actual configuration change, will 900 be defined separately for each type of negotiation objective. 902 If no reply message of any kind is received within a reasonable 903 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 904 negotiation request MAY be repeated, with a newly generated Session 905 ID (Section 3.6). An exponential backoff SHOULD be used for 906 subsequent repetitions. 908 If the counterpart can immediately apply the requested configuration, 909 it will give an immediate positive (accept) answer. This will end 910 the negotiation phase immediately. Otherwise, it will negotiate. It 911 will reply with a proposed alternative configuration that it can 912 apply (typically, a configuration that uses fewer resources than 913 requested by the negotiation initiator). This will start a bi- 914 directional negotiation to reach a compromise between the two ASAs. 916 The negotiation procedure is ended when one of the negotiation peers 917 sends a Negotiation Ending message, which contains an accept or 918 decline option and does not need a response from the negotiation 919 peer. Negotiation may also end in failure (equivalent to a decline) 920 if a timeout is exceeded or a loop count is exceeded. 922 A negotiation procedure concerns one objective and one counterpart. 923 Both the initiator and the counterpart may take part in simultaneous 924 negotiations with various other ASAs, or in simultaneous negotiations 925 about different objectives. Thus, GRASP is expected to be used in a 926 multi-threaded mode. Certain negotiation objectives may have 927 restrictions on multi-threading, for example to avoid over-allocating 928 resources. 930 Some configuration actions, for example wavelength switching in 931 optical networks, might take considerable time to execute. The ASA 932 concerned needs to allow for this by design, but GRASP does allow for 933 a peer to insert latency in a negotiation process if necessary 934 (Section 3.7.8). 936 3.3.4.1. Rapid Mode (Discovery/Negotiation Linkage) 938 A Discovery message MAY include a Negotiation Objective option. In 939 this case the Discovery message also acts as a Request Negotiation 940 message to indicate to the Discovery Responder that it could directly 941 reply to the Discovery Initiator with a Negotiation message for rapid 942 processing, if it could act as the corresponding negotiation 943 counterpart. However, the indication is only advisory not 944 prescriptive. 946 This rapid mode could reduce the interactions between nodes so that a 947 higher efficiency could be achieved. However, a network in which 948 some nodes support rapid mode and others do not will have complex 949 timing-dependent behaviors. Therefore, the rapid negotiation 950 function SHOULD be configured off by default and MAY be configured on 951 or off by Intent. 953 3.3.5. Synchronization and Flooding Procedure 955 A synchronization initiator sends a synchronization request to a 956 counterpart, including a specific synchronization objective. The 957 counterpart responds with a Synchronization message (Section 3.7.9) 958 containing the current value of the requested synchronization 959 objective. No further messages are needed. 961 If no reply message of any kind is received within a reasonable 962 timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the 963 synchronization request MAY be repeated, with a newly generated 964 Session ID (Section 3.6). An exponential backoff SHOULD be used for 965 subsequent repetitions. 967 3.3.5.1. Flooding 969 In the case just described, the message exchange is unicast and 970 concerns only one synchronization objective. For large groups of 971 nodes requiring the same data, synchronization flooding is available. 972 For this, a flooding initiator MAY send an unsolicited Flood 973 Synchronization message containing one or more Synchronization 974 Objective option(s), if and only if the specification of those 975 objectives permits it. This is sent as a multicast message to the 976 ALL_GRASP_NEIGHBOR multicast address (Section 3.5). 978 Every network device that supports GRASP always listens to a well- 979 known UDP port to capture flooding messages. Because this port is 980 unique in a device, this is a function of the GRASP kernel. 982 To ensure that flooding does not result in a loop, the originator of 983 the Flood Synchronization message MUST set the loop count in the 984 objectives to a suitable value (the default is GRASP_DEF_LOOPCT). 985 Also, a suitable mechanism is needed to avoid excessive multicast 986 traffic. This mechanism MUST be defined as part of the specification 987 of the synchronization objective(s) concerned. It might be a simple 988 rate limit or a more complex mechanism such as the Trickle algorithm 989 [RFC6206]. 991 A GRASP device with multiple link-layer interfaces (typically a 992 router) MUST support synchronization flooding on all interfaces. If 993 it receives a multicast Flood Synchronization message on a given 994 interface, it MUST relay it by re-issuing a Flood Synchronization 995 message on its other interfaces. The relayed message MUST have the 996 same Session ID as the incoming message and MUST be tagged with the 997 IP address of its original initiator. 999 The relaying device MUST decrement the loop count within the first 1000 objective, and MUST NOT relay the Flood Synchronization message if 1001 the result is zero. Also, it MUST limit the total rate at which it 1002 relays Flood Synchronization messages to a reasonable value, in order 1003 to mitigate possible denial of service attacks. It MUST cache the 1004 Session ID value and initiator address of each relayed Flood 1005 Synchronization message for a finite time not less than twice 1006 GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay 1007 a Flood Synchronization message which carries a given cached Session 1008 ID and initiator address more than once. These precautions avoid 1009 synchronization loops and mitigate potential overload. 1011 Note that this mechanism is unreliable in the case of sleeping nodes. 1012 Sleeping nodes that require an objective subject to flooding SHOULD 1013 periodically request unicast synchronization for that objective. 1015 The multicast messages for synchronization flooding are subject to 1016 the security rules in Section 3.3.1. In practice this means that 1017 they MUST NOT be transmitted and MUST be ignored on receipt unless 1018 there is an operational ACP or equivalent strong security in place. 1019 However, because of the security weakness of link-local multicast 1020 (Section 5), synchronization objectives that are flooded SHOULD NOT 1021 contain unencrypted private information and SHOULD be validated by 1022 the recipient ASA. 1024 3.3.5.2. Rapid Mode (Discovery/Synchronization Linkage) 1026 A Discovery message MAY include a Synchronization Objective option. 1027 In this case the Discovery message also acts as a Request 1028 Synchronization message to indicate to the Discovery Responder that 1029 it could directly reply to the Discovery Initiator with a 1030 Synchronization message Section 3.7.9 with synchronization data for 1031 rapid processing, if the discovery target supports the corresponding 1032 synchronization objective. However, the indication is only advisory 1033 not prescriptive. 1035 This rapid mode could reduce the interactions between nodes so that a 1036 higher efficiency could be achieved. However, a network in which 1037 some nodes support rapid mode and others do not will have complex 1038 timing-dependent behaviors. Therefore, the rapid synchronization 1039 function SHOULD be configured off by default and MAY be configured on 1040 or off by Intent. 1042 3.4. High Level Deployment Model 1044 It is expected that a GRASP implementation will reside in an 1045 autonomic node that also contains both the appropriate security 1046 environment (preferably the ACP) and one or more Autonomic Service 1047 Agents (ASAs). In the minimal case of a single-purpose device, these 1048 three components might be fully integrated. A more common model is 1049 expected to be a multi-purpose device capable of containing several 1050 ASAs. In this case it is expected that the ACP, GRASP and the ASAs 1051 will be implemented as separate processes, which are probably multi- 1052 threaded to support asynchronous and simultaneous operations. It is 1053 expected that GRASP will access the ACP by using a typical socket 1054 interface. A well defined Application Programming Interface (API) 1055 will be needed between GRASP and the ASAs. In some implementations, 1056 ASAs would run in user space with a GRASP library providing the API, 1057 and this library would in turn communicate via system calls with core 1058 GRASP functions running in kernel mode. For further details of 1059 possible deployment models, see [I-D.ietf-anima-reference-model]. 1061 Because GRASP needs to work whatever happens, especially during 1062 bootstrapping and during fault conditions, it is essential that every 1063 implementation is as robust as possible. For example, discovery 1064 failures, or any kind of socket error at any time, must not cause 1065 irrecoverable failures in GRASP itself, and must return suitable 1066 error codes through the API so that ASAs can also recover. 1068 GRASP must always start up correctly after a system restart. All run 1069 time error conditions, and events such as address renumbering, 1070 network interface failures, and CPU sleep/wake cycles, must be 1071 handled in such a way that GRASP will still operate correctly and 1072 securely (Section 3.3.1) afterwards. 1074 An autonomic node will normally run a single instance of GRASP, used 1075 by multiple ASAs. However, scenarios where multiple instances of 1076 GRASP run in a single node, perhaps with different security 1077 properties, are not excluded. In this case, each instance MUST 1078 listen independently for GRASP link-local muticasts in order for 1079 discovery and flooding to work correctly. 1081 3.5. GRASP Constants 1083 o ALL_GRASP_NEIGHBOR 1085 A link-local scope multicast address used by a GRASP-enabled 1086 device to discover GRASP-enabled neighbor (i.e., on-link) devices 1087 . All devices that support GRASP are members of this multicast 1088 group. 1090 * IPv6 multicast address: TBD1 1092 * IPv4 multicast address: TBD2 1094 o GRASP_LISTEN_PORT (TBD3) 1096 A UDP and TCP port that every GRASP-enabled network device always 1097 listens to. 1099 o GRASP_DEF_TIMEOUT (60000 milliseconds) 1101 The default timeout used to determine that a discovery etc. has 1102 failed to complete. 1104 o GRASP_DEF_LOOPCT (6) 1106 The default loop count used to determine that a negotiation has 1107 failed to complete, and to avoid looping messages. 1109 3.6. Session Identifier (Session ID) 1111 This is an up to 24-bit opaque value used to distinguish multiple 1112 sessions between the same two devices. A new Session ID MUST be 1113 generated by the initiator for every new Discovery, Flood 1114 Synchronization or Request message. All responses and follow-up 1115 messages in the same discovery, synchronization or negotiation 1116 procedure MUST carry the same Session ID. 1118 The Session ID SHOULD have a very low collision rate locally. It 1119 MUST be generated by a pseudo-random algorithm using a locally 1120 generated seed which is unlikely to be used by any other device in 1121 the same network [RFC4086]. 1123 However, there is a finite probability that two nodes might generate 1124 the same Session ID value. For that reason, when a Session ID is 1125 communicated via GRASP, the receiving node MUST tag it with the 1126 initiator's IP address to allow disambiguation. Multicast GRASP 1127 messages and their responses, which may be relayed between links, 1128 therefore include a field that carries the initiator's global IP 1129 address. 1131 3.7. GRASP Messages 1133 3.7.1. Message Overview 1135 This section defines the GRASP message format and message types. 1136 Message types not listed here are reserved for future use. 1138 The messages currently defined are: 1140 Discovery and Discovery Response. 1142 Request Negotiation, Negotiation, Confirm Waiting and Negotiation 1143 End. 1145 Request Synchronization, Synchronization, and Flood 1146 Synchronization. 1148 No Operation. 1150 3.7.2. GRASP Message Format 1152 GRASP messages share an identical header format and a variable format 1153 area for options. GRASP message headers and options are transmitted 1154 in Concise Binary Object Representation (CBOR) [RFC7049]. In this 1155 specification, they are described using CBOR data definition language 1156 (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is 1157 used to describe each item in this section. A complete and normative 1158 CDDL specification of GRASP is given in Section 6, including 1159 constants such as message types. 1161 Every GRASP message, except the No Operation message, carries a 1162 Session ID (Section 3.6). Options are then presented serially in the 1163 options field. 1165 In fragmentary CDDL, every GRASP message follows the pattern: 1167 grasp-message = (message .within message-structure) / noop-message 1169 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 1170 *grasp-option] 1172 MESSAGE_TYPE = 1..255 1173 session-id = 0..16777215 ;up to 24 bits 1174 grasp-option = any 1176 The MESSAGE_TYPE indicates the type of the message and thus defines 1177 the expected options. Any options received that are not consistent 1178 with the MESSAGE_TYPE SHOULD be silently discarded. 1180 The No Operation (noop) message is described in Section 3.7.11. 1182 The various MESSAGE_TYPE values are defined in Section 6. 1184 All other message elements are described below and formally defined 1185 in Section 6. 1187 3.7.3. Discovery Message 1189 In fragmentary CDDL, a Discovery message follows the pattern: 1191 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1193 A discovery initiator sends a Discovery message to initiate a 1194 discovery process for a particular objective option. 1196 The discovery initiator sends the Discovery messages via UDP to port 1197 GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast 1198 address. It then listens for unicast TCP responses on the same port, 1199 and stores the discovery results (including responding discovery 1200 objectives and corresponding unicast locators). 1202 The 'initiator' field in the message is a globally unique IP address 1203 of the initiator, for the sole purpose of disambiguating the Session 1204 ID in other nodes. If for some reason the initiator does not have a 1205 globally unique IP address, it MUST use a link-local address for this 1206 purpose that is highly likely to be unique, for example using 1207 [RFC7217]. 1209 A Discovery message MUST include exactly one of the following: 1211 o a discovery objective option (Section 3.9.1). Its loop count MUST 1212 be set to a suitable value to prevent discovery loops (default 1213 value is GRASP_DEF_LOOPCT). If the discovery initiator requires 1214 only on-link responses, the loop count MUST be set to 1. 1216 o a negotiation objective option (Section 3.9.1). This is used both 1217 for the purpose of discovery and to indicate to the discovery 1218 target that it MAY directly reply to the discovery initiatior with 1219 a Negotiation message for rapid processing, if it could act as the 1220 corresponding negotiation counterpart. The sender of such a 1221 Discovery message MUST initialize a negotiation timer and loop 1222 count in the same way as a Request Negotiation message 1223 (Section 3.7.5). 1225 o a synchronization objective option (Section 3.9.1). This is used 1226 both for the purpose of discovery and to indicate to the discovery 1227 target that it MAY directly reply to the discovery initiator with 1228 a Synchronization message for rapid processing, if it could act as 1229 the corresponding synchronization counterpart. Its loop count 1230 MUST be set to a suitable value to prevent discovery loops 1231 (default value is GRASP_DEF_LOOPCT). 1233 3.7.4. Discovery Response Message 1235 In fragmentary CDDL, a Discovery Response message follows the 1236 pattern: 1238 response-message = [M_RESPONSE, session-id, initiator, 1239 (+locator-option // divert-option), ?objective)] 1241 A node which receives a Discovery message SHOULD send a Discovery 1242 Response message if and only if it can respond to the discovery. It 1243 MUST contain the same Session ID and initiator as the Discovery 1244 message. It MAY include a copy of the discovery objective from the 1245 Discovery message. It is sent to the sender of the Discovery message 1246 via TCP at the port GRASP_LISTEN_PORT. 1248 If the responding node supports the discovery objective of the 1249 discovery, it MUST include at least one kind of locator option 1250 (Section 3.8.5) to indicate its own location. A sequence of multiple 1251 kinds of locator options (e.g. IP address option and FQDN option) is 1252 also valid. 1254 If the responding node itself does not support the discovery 1255 objective, but it knows the locator of the discovery objective, then 1256 it SHOULD respond to the discovery message with a divert option 1257 (Section 3.8.2) embedding a locator option or a combination of 1258 multiple kinds of locator options which indicate the locator(s) of 1259 the discovery objective. 1261 3.7.5. Request Messages 1263 In fragmentary CDDL, Request Negotiation and Request Synchronization 1264 messages follow the patterns: 1266 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1268 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1269 A negotiation or synchronization requesting node sends the 1270 appropriate Request message to the unicast address (directly stored 1271 or resolved from an FQDN or URI) of the negotiation or 1272 synchronization counterpart, using the appropriate protocol and port 1273 numbers (selected from the discovery results). 1275 A Request message MUST include the relevant objective option. In the 1276 case of Request Negotiation, the objective option MUST include the 1277 requested value. 1279 When an initiator sends a Request Negotiation message, it MUST 1280 initialize a negotiation timer for the new negotiation thread with 1281 the value GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is 1282 modified by a Confirm Waiting message (Section 3.7.8), the initiator 1283 will consider that the negotiation has failed when the timer expires. 1285 When an initiator sends a Request message, it MUST initialize the 1286 loop count of the objective option with a value defined in the 1287 specification of the option or, if no such value is specified, with 1288 GRASP_DEF_LOOPCT. 1290 If a node receives a Request message for an objective for which no 1291 ASA is currently listening, it MUST immediately close the relevant 1292 socket to indicate this to the initiator. 1294 3.7.6. Negotiation Message 1296 In fragmentary CDDL, a Negotiation message follows the pattern: 1298 discovery-message = [M_NEGOTIATE, session-id, objective] 1300 A negotiation counterpart sends a Negotiation message in response to 1301 a Request Negotiation message, a Negotiation message, or a Discovery 1302 message in Rapid Mode. A negotiation process MAY include multiple 1303 steps. 1305 The Negotiation message MUST include the relevant Negotiation 1306 Objective option, with its value updated according to progress in the 1307 negotiation. The sender MUST decrement the loop count by 1. If the 1308 loop count becomes zero the message MUST NOT be sent. In this case 1309 the negotiation session has failed and will time out. 1311 3.7.7. Negotiation End Message 1313 In fragmentary CDDL, a Negotiation End message follows the pattern: 1315 end-message = [M_END, session-id, accept-option / decline-option] 1317 A negotiation counterpart sends an Negotiation End message to close 1318 the negotiation. It MUST contain either an accept or a decline 1319 option, defined in Section 3.8.3 and Section 3.8.4. It could be sent 1320 either by the requesting node or the responding node. 1322 3.7.8. Confirm Waiting Message 1324 In fragmentary CDDL, a Confirm Waiting message follows the pattern: 1326 wait-message = [M_WAIT, session-id, waiting-time] 1327 waiting-time = 0..4294967295 ; in milliseconds 1329 A responding node sends a Confirm Waiting message to ask the 1330 requesting node to wait for a further negotiation response. It might 1331 be that the local process needs more time or that the negotiation 1332 depends on another triggered negotiation. This message MUST NOT 1333 include any other options. When received, the waiting time value 1334 overwrites and restarts the current negotiation timer 1335 (Section 3.7.5). 1337 The responding node SHOULD send a Negotiation, Negotiation End or 1338 another Confirm Waiting message before the negotiation timer expires. 1339 If not, the initiator MUST abandon or restart the negotiation 1340 procedure, to avoid an indefinite wait. 1342 3.7.9. Synchronization Message 1344 In fragmentary CDDL, a Synchronization message follows the pattern: 1346 synch-message = [M_SYNCH, session-id, objective] 1348 A node which receives a Request Synchronization, or a Discovery 1349 message in Rapid Mode, sends back a unicast Synchronization message 1350 with the synchronization data, in the form of a GRASP Option for the 1351 specific synchronization objective present in the Request 1352 Synchronization. 1354 3.7.10. Flood Synchronization Message 1356 In fragmentary CDDL, a Flood Synchronization message follows the 1357 pattern: 1359 flood-message = [M_FLOOD, session-id, initiator, +objective] 1361 A node MAY initiate flooding by sending an unsolicited Flood 1362 Synchronization Message with synchronization data. This MAY be sent 1363 to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance 1364 with the rules in Section 3.3.5. The initiator address is provided 1365 as described for Discovery messages. The synchronization data will 1366 be in the form of GRASP Option(s) for specific synchronization 1367 objective(s). The loop count(s) MUST be set to a suitable value to 1368 prevent flood loops (default value is GRASP_DEF_LOOPCT). 1370 A node that receives a Flood Synchronization message SHOULD cache the 1371 received objectives for use by local ASAs. 1373 3.7.11. No Operation Message 1375 In fragmentary CDDL, a No Operation message follows the pattern: 1377 noop-message = [M_NOOP] 1379 This message MAY be sent by an implementation that for practical 1380 reasons needs to activate a socket. It MUST be silently ignored by a 1381 recipient. 1383 3.8. GRASP Options 1385 This section defines the GRASP options for the negotiation and 1386 synchronization protocol signaling. Additional options may be 1387 defined in the future. 1389 3.8.1. Format of GRASP Options 1391 GRASP options are CBOR objects that MUST start with an unsigned 1392 integer identifying the specific option type carried in this option. 1393 These option types are formally defined in Section 6. Apart from 1394 that the only format requirement is that each option MUST be a well- 1395 formed CBOR object. In general a CBOR array format is RECOMMENDED to 1396 limit overhead. 1398 GRASP options are usually scoped by using encapsulation. However, 1399 this is not a requirement 1401 3.8.2. Divert Option 1403 The Divert option is used to redirect a GRASP request to another 1404 node, which may be more appropriate for the intended negotiation or 1405 synchronization. It may redirect to an entity that is known as a 1406 specific negotiation or synchronization counterpart (on-link or off- 1407 link) or a default gateway. The divert option MUST only be 1408 encapsulated in Discovery Response messages. If found elsewhere, it 1409 SHOULD be silently ignored. 1411 A discovery initiator MAY ignore a Divert option if it only requires 1412 direct discovery responses. 1414 In fragmentary CDDL, the Divert option follows the pattern: 1416 divert-option = [O_DIVERT, +locator-option] 1418 The embedded Locator Option(s) (Section 3.8.5) point to diverted 1419 destination target(s) in response to a Discovery message. 1421 3.8.3. Accept Option 1423 The accept option is used to indicate to the negotiation counterpart 1424 that the proposed negotiation content is accepted. 1426 The accept option MUST only be encapsulated in Negotiation End 1427 messages. If found elsewhere, it SHOULD be silently ignored. 1429 In fragmentary CDDL, the Accept option follows the pattern: 1431 accept-option = [O_ACCEPT] 1433 3.8.4. Decline Option 1435 The decline option is used to indicate to the negotiation counterpart 1436 the proposed negotiation content is declined and end the negotiation 1437 process. 1439 The decline option MUST only be encapsulated in Negotiation End 1440 messages. If found elsewhere, it SHOULD be silently ignored. 1442 In fragmentary CDDL, the Decline option follows the pattern: 1444 decline-option = [O_DECLINE, ?reason] 1445 reason = text ;optional error message 1447 Note: there are scenarios where a negotiation counterpart wants to 1448 decline the proposed negotiation content and continue the negotiation 1449 process. For these scenarios, the negotiation counterpart SHOULD use 1450 a Negotiate message, with either an objective option that contains a 1451 data field set to indicate a meaningless initial value, or a specific 1452 objective option that provides further conditions for convergence. 1454 3.8.5. Locator Options 1456 These locator options are used to present reachability information 1457 for an ASA, a device or an interface. They are Locator IPv6 Address 1458 Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified 1459 Domain Name) Option and URI (Uniform Resource Identifier) Option. 1461 Since ASAs will normally run as independent user programs, locator 1462 options need to indicate the network layer locator plus the transport 1463 protocol and port number for reaching the target. For this reason, 1464 the Locator Options for IP addresses and FQDNs include this 1465 information explicitly. In the case of the URI Option, this 1466 information can be encoded in the URI itself. 1468 Note: It is assumed that all locators are in scope throughout the 1469 GRASP domain. GRASP is not intended to work across disjoint 1470 addressing or naming realms. 1472 3.8.5.1. Locator IPv6 address option 1474 In fragmentary CDDL, the IPv6 address option follows the pattern: 1476 ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address, 1477 transport-proto, port-number] 1478 ipv6-address = bytes .size 16 1480 transport-proto = IPPROTO_TCP / IPPROTO_UDP 1481 IPPROTO_TCP = 6 1482 IPPROTO_UDP = 17 1483 port-number = 0..65535 1485 The content of this option is a binary IPv6 address followed by the 1486 protocol number and port number to be used. 1488 Note 1: The IPv6 address MUST normally have global scope. 1489 Exceptionally, during node bootstrap, a link-local address MAY be 1490 used for specific objectives only. 1492 Note 2: A link-local IPv6 address MUST NOT be used when this option 1493 is included in a Divert option. 1495 3.8.5.2. Locator IPv4 address option 1497 In fragmentary CDDL, the IPv4 address option follows the pattern: 1499 ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address, 1500 transport-proto, port-number] 1501 ipv4-address = bytes .size 4 1503 The content of this option is a binary IPv4 address followed by the 1504 protocol number and port number to be used. 1506 Note: If an operator has internal network address translation for 1507 IPv4, this option MUST NOT be used within the Divert option. 1509 3.8.5.3. Locator FQDN option 1511 In fragmentary CDDL, the FQDN option follows the pattern: 1513 fqdn-locator-option = [O_FQDN_LOCATOR, text, 1514 transport-proto, port-number] 1516 The content of this option is the Fully Qualified Domain Name of the 1517 target followed by the protocol number and port number to be used. 1519 Note 1: Any FQDN which might not be valid throughout the network in 1520 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1521 when this option is used within the Divert option. 1523 Note 2: Normal GRASP operations are not expected to use this option. 1524 It is intended for special purposes such as discovering external 1525 services. 1527 3.8.5.4. Locator URI option 1529 In fragmentary CDDL, the URI option follows the pattern: 1531 uri-locator = [O_URI_LOCATOR, text] 1533 The content of this option is the Uniform Resource Identifier of the 1534 target [RFC3986]. 1536 Note 1: Any URI which might not be valid throughout the network in 1537 question, such as one based on a Multicast DNS name [RFC6762], MUST 1538 NOT be used when this option is used within the Divert option. 1540 Note 2: Normal GRASP operations are not expected to use this option. 1541 It is intended for special purposes such as discovering external 1542 services. 1544 3.9. Objective Options 1546 3.9.1. Format of Objective Options 1548 An objective option is used to identify objectives for the purposes 1549 of discovery, negotiation or synchronization. All objectives MUST be 1550 in the following format, described in fragmentary CDDL: 1552 objective = [objective-name, objective-flags, loop-count, ?any] 1554 objective-name = text 1555 loop-count = 0..255 1557 All objectives are identified by a unique name which is a case- 1558 sensitive UTF-8 string. 1560 The names of generic objectives MUST NOT include a colon (":") and 1561 MUST be registered with IANA (Section 7). 1563 The names of privately defined objectives MUST include at least one 1564 colon (":"). The string preceding the last colon in the name MUST be 1565 globally unique and in some way identify the entity or person 1566 defining the objective. The following three methods MAY be used to 1567 create such a globally unique string: 1569 1. The unique string is a decimal number representing a registered 1570 32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 1571 uniquely identifies the enterprise defining the objective. 1573 2. The unique string is a fully qualified domain name that uniquely 1574 identifies the entity or person defining the objective. 1576 3. The unique string is an email address that uniquely identifies 1577 the entity or person defining the objective. 1579 The GRASP protocol treats the objective name as an opaque string. 1580 For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 1581 and "user@example.org:EX1" would be five different objectives. 1583 The 'objective-flags' field is described below. 1585 The 'loop-count' field is used for terminating negotiation as 1586 described in Section 3.7.6. It is also used for terminating 1587 discovery as described in Section 3.3.3, and for terminating flooding 1588 as described in Section 3.3.5.1. 1590 The 'any' field is to express the actual value of a negotiation or 1591 synchronization objective. Its format is defined in the 1592 specification of the objective and may be a single value or a data 1593 structure of any kind. It is optional because it is optional in a 1594 Discovery or Discovery Response message. 1596 3.9.2. Objective flags 1598 An objective may be relevant for discovery only, for discovery and 1599 negotiation, or for discovery and synchronization. This is expressed 1600 in the objective by logical flags: 1602 objective-flags = uint .bits objective-flag 1603 objective-flag = &( 1604 F_DISC: 0 ; valid for discovery only 1605 F_NEG: 1 ; valid for discovery and negotiation 1606 F_SYNCH: 2 ; valid for discovery and synchronization 1607 ) 1609 3.9.3. General Considerations for Objective Options 1611 As mentioned above, Objective Options MUST be assigned a unique name. 1612 As long as privately defined Objective Options obey the rules above, 1613 this document does not restrict their choice of name, but the entity 1614 or person concerned SHOULD publish the names in use. 1616 All Objective Options MUST respect the CBOR patterns defined above as 1617 "objective" and MUST replace the "any" field with a valid CBOR data 1618 definition for the relevant use case and application. 1620 An Objective Option that contains no additional fields beyond its 1621 "loop-count" can only be a discovery objective and MUST only be used 1622 in Discovery and Discovery Response messages. 1624 The Negotiation Objective Options contain negotiation objectives, 1625 which vary according to different functions/services. They MUST be 1626 carried by Discovery, Request Negotiation or Negotiation messages 1627 only. The negotiation initiator MUST set the initial "loop-count" to 1628 a value specified in the specification of the objective or, if no 1629 such value is specified, to GRASP_DEF_LOOPCT. 1631 For most scenarios, there should be initial values in the negotiation 1632 requests. Consequently, the Negotiation Objective options MUST 1633 always be completely presented in a Request Negotiation message, or 1634 in a Discovery message in rapid mode. If there is no initial value, 1635 the bits in the value field SHOULD all be set to indicate a 1636 meaningless value, unless this is inappropriate for the specific 1637 negotiation objective. 1639 Synchronization Objective Options are similar, but MUST be carried by 1640 Discovery, Discovery Response, Request Synchronization, or Flood 1641 Synchronization messages only. They include value fields only in 1642 Synchronization or Flood Synchronization messages. 1644 3.9.4. Organizing of Objective Options 1646 Generic objective options MUST be specified in documents available to 1647 the public and SHOULD be designed to use either the negotiation or 1648 the synchronization mechanism described above. 1650 As noted earlier, one negotiation objective is handled by each GRASP 1651 negotiation thread. Therefore, a negotiation objective, which is 1652 based on a specific function or action, SHOULD be organized as a 1653 single GRASP option. It is NOT RECOMMENDED to organize multiple 1654 negotiation objectives into a single option, nor to split a single 1655 function or action into multiple negotiation objectives. 1657 It is important to understand that GRASP negotiation does not support 1658 transactional integrity. If transactional integrity is needed for a 1659 specific objective, this must be ensured by the ASA. For example, an 1660 ASA might need to ensure that it only participates in one negotiation 1661 thread at the same time. Such an ASA would need to stop listening 1662 for incoming negotiation requests before generating an outgoing 1663 negotiation request. 1665 A synchronization objective SHOULD be organized as a single GRASP 1666 option. 1668 Some objectives will support more than one operational mode. An 1669 example is a negotiation objective with both a "dry run" mode (where 1670 the negotiation is to find out whether the other end can in fact make 1671 the requested change without problems) and a "live" mode. Such modes 1672 will be defined in the specification of such an objective. These 1673 objectives SHOULD include flags indicating the applicable mode(s). 1675 An objective may have multiple parameters. Parameters can be 1676 categorized into two classes: the obligatory ones presented as fixed 1677 fields; and the optional ones presented in CBOR sub-options or some 1678 other form of data structure embedded in CBOR. The format might be 1679 inherited from an existing management or configuration protocol, the 1680 objective option acting as a carrier for that format. The data 1681 structure might be defined in a formal language, but that is a matter 1682 for the specifications of individual objectives. There are many 1683 candidates, according to the context, such as ABNF, RBNF, XML Schema, 1684 possibly YANG, etc. The GRASP protocol itself is agnostic on these 1685 questions. 1687 It is NOT RECOMMENDED to split parameters in a single objective into 1688 multiple options, unless they have different response periods. An 1689 exception scenario may also be described by split objectives. 1691 All objectives MUST support GRASP discovery. However, as mentioned 1692 in Section 3.2, it is acceptable for an ASA to use an alternative 1693 method of discovery. 1695 Normally, a GRASP objective will refer to specific technical 1696 parameters as explained in Section 3.1. However, it is acceptable to 1697 define an abstract objective for the purpose of managing or 1698 coordinating ASAs. It is also acceptable to define a special-purpose 1699 objective for purposes such as trust bootstrapping or formation of 1700 the ACP. 1702 3.9.5. Experimental and Example Objective Options 1704 The names "EX0" through "EX9" have been reserved for experimental 1705 options. Multiple names have been assigned because a single 1706 experiment may use multiple options simultaneously. These 1707 experimental options are highly likely to have different meanings 1708 when used for different experiments. Therefore, they SHOULD NOT be 1709 used without an explicit human decision and SHOULD NOT be used in 1710 unmanaged networks such as home networks. 1712 These names are also RECOMMENDED for use in documentation examples. 1714 4. Implementation Status [RFC Editor: please remove] 1716 Two prototype implementations of GRASP have been made. 1718 4.1. BUPT C++ Implementation 1720 o Name: BaseNegotiator.cpp, msg.cpp, Client.cpp, Server.cpp 1722 o Description: C++ implementation of GRASP kernel and API 1724 o Maturity: Prototype code, interoperable between Ubuntu. 1726 o Coverage: Corresponds to draft-carpenter-anima-gdn-protocol-03. 1727 Since it was implemented based on the old version draft, the most 1728 significant limitations comparing to current protocol design 1729 include: 1731 * Not support CBOR 1733 * Not support Flooding 1735 * Not support loop avoidance 1737 * only coded for IPv6, any IPv4 is accidental 1739 o Licensing: Huawei License. 1741 o Experience: https://github.com/liubingpang/IETF-Anima-Signaling- 1742 Protocol/blob/master/README.md 1744 o Contact: https://github.com/liubingpang/IETF-Anima-Signaling- 1745 Protocol 1747 4.2. Python Implementation 1749 o Name: graspy 1751 o Description: Python 3 implementation of GRASP kernel and API. 1753 o Maturity: Prototype code, interoperable between Windows 7 and 1754 Debian. 1756 o Coverage: Corresponds to draft-ietf-anima-grasp-05. Limitations 1757 include: 1759 * insecure: uses a dummy ACP module and does not implement TLS 1761 * only coded for IPv6, any IPv4 is accidental 1763 * FQDN and URI locators incompletely supported 1765 * no code for rapid mode 1767 * relay code is lazy (no rate control) 1769 * all unicast transactions use TCP (no unicast UDP) 1771 * optional Objective option in Response messages not implemented 1773 * workarounds for defects in Python socket module and Windows 1774 socket peculiarities 1776 o Licensing: Simplified BSD 1778 o Experience: https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf 1780 o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ 1782 5. Security Considerations 1784 It is obvious that a successful attack on negotiation-enabled nodes 1785 would be extremely harmful, as such nodes might end up with a 1786 completely undesirable configuration that would also adversely affect 1787 their peers. GRASP nodes and messages therefore require full 1788 protection. 1790 - Authentication 1792 A cryptographically authenticated identity for each device is 1793 needed in an autonomic network. It is not safe to assume that a 1794 large network is physically secured against interference or that 1795 all personnel are trustworthy. Each autonomic node MUST be 1796 capable of proving its identity and authenticating its messages. 1797 GRASP relies on a separate external certificate-based security 1798 mechanism to support authentication, data integrity protection, 1799 and anti-replay protection. 1801 Since GRASP is intended to be deployed in a single administrative 1802 domain operating its own trust anchor and CA, there is no need for 1803 a trusted public third party. In a network requiring "air gap" 1804 security, such a dependency would be unacceptable. 1806 If GRASP is used temporarily without an external security 1807 mechanism, for example during system bootstrap (Section 3.3.1), 1808 the Session ID (Section 3.6) will act as a nonce to provide 1809 limited protection against third parties injecting responses. A 1810 full analysis of the secure bootstrap process is out of scope for 1811 the present document. 1813 - Authorization and Roles 1815 The GRASP protocol is agnostic about the role of individual ASAs 1816 and about which objectives a particular ASA is authorized to 1817 support. It SHOULD apply obvious precautions such as allowing 1818 only one ASA in a given node to modify a given objective, but 1819 otherwise authorization is out of scope. 1821 - Privacy and confidentiality 1823 Generally speaking, no personal information is expected to be 1824 involved in the signaling protocol, so there should be no direct 1825 impact on personal privacy. Nevertheless, traffic flow paths, 1826 VPNs, etc. could be negotiated, which could be of interest for 1827 traffic analysis. Also, operators generally want to conceal 1828 details of their network topology and traffic density from 1829 outsiders. Therefore, since insider attacks cannot be excluded in 1830 a large network, the security mechanism for the protocol MUST 1831 provide message confidentiality. This is why Section 3.3.1 1832 requires either an ACP or the use of TLS. 1834 - Link-local multicast security 1836 GRASP has no reasonable alternative to using link-local multicast 1837 for Discovery or Flood Synchronization messages and these messages 1838 are sent in clear and with no authentication. They are therefore 1839 available to on-link eavesdroppers, and could be forged by on-link 1840 attackers. In the case of Discovery, the Discovery Responses are 1841 unicast and will therefore be protected (Section 3.3.1), and an 1842 untrusted forger will not be able to receive responses. In the 1843 case of Flood Synchronization, an on-link eavesdropper will be 1844 able to receive the flooded objectives but there is no response 1845 message to consider. Some precautions for Flood Synchronization 1846 messages are suggested in Section 3.3.5.1. 1848 - DoS Attack Protection 1850 GRASP discovery partly relies on insecure link-local multicast. 1851 Since routers participating in GRASP sometimes relay discovery 1852 messages from one link to another, this could be a vector for 1853 denial of service attacks. Relevant mitigations are specified in 1854 Section 3.3.3. Additionally, it is of great importance that 1855 firewalls prevent any GRASP messages from entering the domain from 1856 an untrusted source. 1858 - Security during bootstrap and discovery 1860 A node cannot authenticate GRASP traffic from other nodes until it 1861 has identified the trust anchor and can validate certificates for 1862 other nodes. Also, until it has succesfully enrolled 1863 [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that 1864 other nodes are able to authenticate its own traffic. Therefore, 1865 GRASP discovery during the bootstrap phase for a new device will 1866 inevitably be insecure and GRASP synchronization and negotiation 1867 will be impossible until enrollment is complete. 1869 - Security of discovered locators 1871 When GRASP discovery returns an IP address, it MUST be that of a 1872 node within the secure environment (Section 3.3.1). If it returns 1873 an FQDN or a URI, the ASA that receives it MUST NOT assume that 1874 the target of the locator is within the secure environment. 1876 6. CDDL Specification of GRASP 1878 1879 grasp-message = (message .within message-structure) / noop-message 1881 message-structure = [MESSAGE_TYPE, session-id, ?initiator, 1882 *grasp-option] 1884 MESSAGE_TYPE = 0..255 1885 session-id = 0..16777215 ;up to 24 bits 1886 grasp-option = any 1888 message /= discovery-message 1889 discovery-message = [M_DISCOVERY, session-id, initiator, objective] 1890 message /= response-message ;response to Discovery 1891 response-message = [M_RESPONSE, session-id, initiator, 1892 (+locator-option // divert-option), ?objective] 1894 message /= synch-message ;response to Synchronization request 1895 synch-message = [M_SYNCH, session-id, objective] 1897 message /= flood-message 1898 flood-message = [M_FLOOD, session-id, initiator, +objective] 1900 message /= request-negotiation-message 1901 request-negotiation-message = [M_REQ_NEG, session-id, objective] 1903 message /= request-synchronization-message 1904 request-synchronization-message = [M_REQ_SYN, session-id, objective] 1906 message /= negotiation-message 1907 negotiation-message = [M_NEGOTIATE, session-id, objective] 1909 message /= end-message 1910 end-message = [M_END, session-id, accept-option / decline-option ] 1912 message /= wait-message 1913 wait-message = [M_WAIT, session-id, waiting-time] 1915 noop-message = [M_NOOP] 1917 divert-option = [O_DIVERT, +locator-option] 1919 accept-option = [O_ACCEPT] 1921 decline-option = [O_DECLINE, ?reason] 1922 reason = text ;optional error message 1924 waiting-time = 0..4294967295 ; in milliseconds 1926 locator-option /= [O_IPv4_LOCATOR, ipv4-address, 1927 transport-proto, port-number] 1928 ipv4-address = bytes .size 4 1930 locator-option /= [O_IPv6_LOCATOR, ipv6-address, 1931 transport-proto, port-number] 1932 ipv6-address = bytes .size 16 1934 locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number] 1936 transport-proto = IPPROTO_TCP / IPPROTO_UDP 1937 IPPROTO_TCP = 6 1938 IPPROTO_UDP = 17 1939 port-number = 0..65535 1941 locator-option /= [O_URI_LOCATOR, text] 1943 initiator = ipv4-address / ipv6-address 1945 objective-flags = uint .bits objective-flag 1947 objective-flag = &( 1948 F_DISC: 0 ; valid for discovery only 1949 F_NEG: 1 ; valid for discovery and negotiation 1950 F_SYNCH: 2) ; valid for discovery and synchronization 1952 objective = [objective-name, objective-flags, loop-count, ?any] 1954 objective-name = text ;see specification for uniqueness rules 1956 loop-count = 0..255 1958 ; Constants for message types and option types 1960 M_NOOP = 0 1961 M_DISCOVERY = 1 1962 M_RESPONSE = 2 1963 M_REQ_NEG = 3 1964 M_REQ_SYN = 4 1965 M_NEGOTIATE = 5 1966 M_END = 6 1967 M_WAIT = 7 1968 M_SYNCH = 8 1969 M_FLOOD = 9 1971 O_DIVERT = 100 1972 O_ACCEPT = 101 1973 O_DECLINE = 102 1974 O_IPv6_LOCATOR = 103 1975 O_IPv4_LOCATOR = 104 1976 O_FQDN_LOCATOR = 105 1977 O_URI_LOCATOR = 106 1978 1980 7. IANA Considerations 1982 This document defines the General Discovery and Negotiation Protocol 1983 (GRASP). 1985 Section 3.5 explains the following link-local multicast addresses, 1986 which IANA is requested to assign for use by GRASP: 1988 ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in 1989 the IPv6 Link-Local Scope Multicast Addresses registry. 1991 ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in 1992 the IPv4 Multicast Local Network Control Block. 1994 Section 3.5 explains the following UDP and TCP port, which IANA is 1995 requested to assign for use by GRASP: 1997 GRASP_LISTEN_PORT: (TBD3) 1999 The IANA is requested to create a GRASP Parameter Registry including 2000 two registry tables. These are the GRASP Messages and Options 2001 Table and the GRASP Objective Names Table. 2003 GRASP Messages and Options Table. The values in this table are names 2004 paired with decimal integers. Future values MUST be assigned using 2005 the Standards Action policy defined by [RFC5226]. The following 2006 initial values are assigned by this document: 2008 M_NOOP = 0 2009 M_DISCOVERY = 1 2010 M_RESPONSE = 2 2011 M_REQ_NEG = 3 2012 M_REQ_SYN = 4 2013 M_NEGOTIATE = 5 2014 M_END = 6 2015 M_WAIT = 7 2016 M_SYNCH = 8 2017 M_FLOOD = 9 2019 O_DIVERT = 100 2020 O_ACCEPT = 101 2021 O_DECLINE = 102 2022 O_IPv6_LOCATOR = 103 2023 O_IPv4_LOCATOR = 104 2024 O_FQDN_LOCATOR = 105 2025 O_URI_LOCATOR = 106 2027 GRASP Objective Names Table. The values in this table are UTF-8 2028 strings. Future values MUST be assigned using the Specification 2029 Required policy defined by [RFC5226]. The following initial values 2030 are assigned by this document: 2032 EX0 2033 EX1 2034 EX2 2035 EX3 2036 EX4 2037 EX5 2038 EX6 2039 EX7 2040 EX8 2041 EX9 2043 8. Acknowledgements 2045 A major contribution to the original version of this document was 2046 made by Sheng Jiang. 2048 Valuable comments were received from Michael Behringer, Jeferson 2049 Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Toerless Eckert, Yu Fu, 2050 Joel Halpern, Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, 2051 Reshad Rahman, Michael Richardson, Markus Stenberg, Rene Struik, 2052 Dacheng Zhang, and other participants in the NMRG research group and 2053 the ANIMA working group. 2055 9. References 2057 9.1. Normative References 2059 [I-D.greevenbosch-appsawg-cbor-cddl] 2060 Vigano, C. and H. Birkholz, "CBOR data definition language 2061 (CDDL): a notational convention to express CBOR data 2062 structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work 2063 in progress), March 2016. 2065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2066 Requirement Levels", BCP 14, RFC 2119, 2067 DOI 10.17487/RFC2119, March 1997, 2068 . 2070 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2071 Resource Identifier (URI): Generic Syntax", STD 66, 2072 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2073 . 2075 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2076 "Randomness Requirements for Security", BCP 106, RFC 4086, 2077 DOI 10.17487/RFC4086, June 2005, 2078 . 2080 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2081 (TLS) Protocol Version 1.2", RFC 5246, 2082 DOI 10.17487/RFC5246, August 2008, 2083 . 2085 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2086 Housley, R., and W. Polk, "Internet X.509 Public Key 2087 Infrastructure Certificate and Certificate Revocation List 2088 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2089 . 2091 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2092 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2093 January 2012, . 2095 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2096 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2097 October 2013, . 2099 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2100 Interface Identifiers with IPv6 Stateless Address 2101 Autoconfiguration (SLAAC)", RFC 7217, 2102 DOI 10.17487/RFC7217, April 2014, 2103 . 2105 9.2. Informative References 2107 [I-D.chaparadza-intarea-igcp] 2108 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 2109 Mahkonen, "IP based Generic Control Protocol (IGCP)", 2110 draft-chaparadza-intarea-igcp-00 (work in progress), July 2111 2011. 2113 [I-D.ietf-anima-autonomic-control-plane] 2114 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 2115 Autonomic Control Plane", draft-ietf-anima-autonomic- 2116 control-plane-02 (work in progress), March 2016. 2118 [I-D.ietf-anima-bootstrapping-keyinfra] 2119 Pritikin, M., Richardson, M., Behringer, M., and S. 2120 Bjarnason, "Bootstrapping Key Infrastructures", draft- 2121 ietf-anima-bootstrapping-keyinfra-02 (work in progress), 2122 March 2016. 2124 [I-D.ietf-anima-reference-model] 2125 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 2126 Liu, B., Nobre, J., and J. Strassner, "A Reference Model 2127 for Autonomic Networking", draft-ietf-anima-reference- 2128 model-01 (work in progress), March 2016. 2130 [I-D.ietf-anima-stable-connectivity] 2131 Eckert, T. and M. Behringer, "Using Autonomic Control 2132 Plane for Stable Connectivity of Network OAM", draft-ietf- 2133 anima-stable-connectivity-00 (work in progress), January 2134 2016. 2136 [I-D.ietf-netconf-restconf] 2137 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2138 Protocol", draft-ietf-netconf-restconf-13 (work in 2139 progress), April 2016. 2141 [I-D.liang-iana-pen] 2142 Liang, P., Melnikov, A., and D. Conrad, "Private 2143 Enterprise Number (PEN) practices and Internet Assigned 2144 Numbers Authority (IANA) registration considerations", 2145 draft-liang-iana-pen-06 (work in progress), July 2015. 2147 [I-D.stenberg-anima-adncp] 2148 Stenberg, M., "Autonomic Distributed Node Consensus 2149 Protocol", draft-stenberg-anima-adncp-00 (work in 2150 progress), March 2015. 2152 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2153 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2154 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2155 September 1997, . 2157 [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, 2158 "Server Cache Synchronization Protocol (SCSP)", RFC 2334, 2159 DOI 10.17487/RFC2334, April 1998, 2160 . 2162 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 2163 "Service Location Protocol, Version 2", RFC 2608, 2164 DOI 10.17487/RFC2608, June 1999, 2165 . 2167 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2168 "Remote Authentication Dial In User Service (RADIUS)", 2169 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2170 . 2172 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2173 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2174 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2175 . 2177 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2178 C., and M. Carney, "Dynamic Host Configuration Protocol 2179 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2180 2003, . 2182 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 2183 for the Simple Network Management Protocol (SNMP)", 2184 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 2185 . 2187 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2188 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2189 DOI 10.17487/RFC4861, September 2007, 2190 . 2192 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2193 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2194 DOI 10.17487/RFC5226, May 2008, 2195 . 2197 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2198 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2199 October 2010, . 2201 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 2202 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 2203 March 2011, . 2205 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2206 and A. Bierman, Ed., "Network Configuration Protocol 2207 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2208 . 2210 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 2211 Ed., "Diameter Base Protocol", RFC 6733, 2212 DOI 10.17487/RFC6733, October 2012, 2213 . 2215 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2216 DOI 10.17487/RFC6762, February 2013, 2217 . 2219 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2220 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2221 . 2223 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2224 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2225 DOI 10.17487/RFC6887, April 2013, 2226 . 2228 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2229 Constrained-Node Networks", RFC 7228, 2230 DOI 10.17487/RFC7228, May 2014, 2231 . 2233 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 2234 "Requirements for Scalable DNS-Based Service Discovery 2235 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 2236 DOI 10.17487/RFC7558, July 2015, 2237 . 2239 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2240 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2241 Networking: Definitions and Design Goals", RFC 7575, 2242 DOI 10.17487/RFC7575, June 2015, 2243 . 2245 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 2246 Analysis for Autonomic Networking", RFC 7576, 2247 DOI 10.17487/RFC7576, June 2015, 2248 . 2250 [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus 2251 Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, 2252 . 2254 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2255 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2256 2016, . 2258 Appendix A. Open Issues 2260 o 7. Cross-check against other ANIMA WG documents for consistency 2261 and gaps. 2263 o 43. Rapid mode synchronization and negotiation is currently 2264 limited to a single objective for simplicity of design and 2265 implementation. A future consideration is to allow multiple 2266 objectives in rapid mode for greater efficiency. 2268 o 48. Should the Appendix "Capability Analysis of Current 2269 Protocols" be deleted before RFC publication? 2271 o 49. Section 3.3.1 should say more about signaling between two 2272 autonomic networks/domains. 2274 o 50. Is Rapid mode limited to on-link only? What happens if first 2275 discovery responder does not support Rapid Mode? (Section 3.3.4, 2276 Section 3.3.5) 2278 Appendix B. Closed Issues [RFC Editor: Please remove] 2280 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 2281 as message transport mechanisms. This is not clarified yet. UDP 2282 is good for short conversations, is necessary for multicast 2283 discovery, and generally fits the discovery and divert scenarios 2284 well. However, it will cause problems with large messages. TCP 2285 is good for stable and long sessions, with a little bit of time 2286 consumption during the session establishment stage. If messages 2287 exceed a reasonable MTU, a TCP mode will be required in any case. 2288 This question may be affected by the security discussion. 2290 RESOLVED by specifying UDP for short message and TCP for longer 2291 one. 2293 o 2. DTLS or TLS vs built-in security mechanism. For now, this 2294 specification has chosen a PKI based built-in security mechanism 2295 based on asymmetric cryptography. However, (D)TLS might be chosen 2296 as security solution to avoid duplication of effort. It also 2297 allows essentially similar security for short messages over UDP 2298 and longer ones over TCP. The implementation trade-offs are 2299 different. The current approach requires expensive asymmetric 2300 cryptographic calculations for every message. (D)TLS has startup 2301 overheads but cheaper crypto per message. DTLS is less mature 2302 than TLS. 2304 RESOLVED by specifying external security (ACP or (D)TLS). 2306 o The following open issues applied only if the original security 2307 model was retained: 2309 * 2.1. For replay protection, GRASP currently requires every 2310 participant to have an NTP-synchronized clock. Is this OK for 2311 low-end devices, and how does it work during device 2312 bootstrapping? We could take the Timestamp out of signature 2313 option, to become an independent and OPTIONAL (or RECOMMENDED) 2314 option. 2316 * 2.2. The Signature Option states that this option could be any 2317 place in a message. Wouldn't it be better to specify a 2318 position (such as the end)? That would be much simpler to 2319 implement. 2321 RESOLVED by changing security model. 2323 o 3. DoS Attack Protection needs work. 2325 RESOLVED by adding text. 2327 o 4. Should we consider preferring a text-based approach to 2328 discovery (after the initial discovery needed for bootstrapping)? 2329 This could be a complementary mechanism for multicast based 2330 discovery, especially for a very large autonomic network. 2331 Centralized registration could be automatically deployed 2332 incrementally. At the very first stage, the repository could be 2333 empty; then it could be filled in by the objectives discovered by 2334 different devices (for example using Dynamic DNS Update). The 2335 more records are stored in the repository, the less the multicast- 2336 based discovery is needed. However, if we adopt such a mechanism, 2337 there would be challenges: stateful solution, and security. 2339 RESOLVED for now by adding optional use of DNS-SD by ASAs. 2340 Subsequently removed by editors as irrelevant to GRASP istelf. 2342 o 5. Need to expand description of the minimum requirements for the 2343 specification of an individual discovery, synchronization or 2344 negotiation objective. 2346 RESOLVED for now by extra wording. 2348 o 6. Use case and protocol walkthrough. A description of how a 2349 node starts up, performs discovery, and conducts negotiation and 2350 synchronisation for a sample use case would help readers to 2351 understand the applicability of this specification. Maybe it 2352 should be an artificial use case or maybe a simple real one, based 2353 on a conceptual API. However, the authors have not yet decided 2354 whether to have a separate document or have it in the protocol 2355 document. 2357 RESOLVED: recommend a separate document. 2359 o 8. Consideration of ADNCP proposal. 2361 RESOLVED by adding optional use of DNCP for flooding-type 2362 synchronization. 2364 o 9. Clarify how a GDNP instance knows whether it is running inside 2365 the ACP. (Sheng) 2367 RESOLVED by improved text. 2369 o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. 2370 (Sheng) 2372 RESOLVED by improved text and declaring DTLS out of scope for this 2373 draft. 2375 o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - 2376 Brian] 2378 RESOLVED by improved text. 2380 o 12. Justify that IP address within ACP or (D)TLS environment is 2381 sufficient to prove AN identity; or explain how Device Identity 2382 Option is used. (Sheng) 2384 RESOLVED for now: we assume that all ASAs in a device are trusted 2385 as soon as the device is trusted, so they share credentials. In 2386 that case the Device Identity Option is useless. This needs to be 2387 reviewed later. 2389 o 13. Emphasise that negotiation/synchronization are independent 2390 from discovery, although the rapid discovery mode includes the 2391 first step of a negotiation/synchronization. (Sheng) 2393 RESOLVED by improved text. 2395 o 14. Do we need an unsolicited flooding mechanism for discovery 2396 (for discovery results that everyone needs), to reduce scaling 2397 impact of flooding discovery messages? (Toerless) 2399 RESOLVED: Yes, added to requirements and solution. 2401 o 15. Do we need flag bits in Objective Options to distinguish 2402 distinguish Synchronization and Negotiation "Request" or rapid 2403 mode "Discovery" messages? (Bing) 2405 RESOLVED: yes, work on the API showed that these flags are 2406 essential. 2408 o 16. (Related to issue 14). Should we revive the "unsolicited 2409 Response" for flooding synchronisation data? This has to be done 2410 carefully due to the well-known issues with flooding, but it could 2411 be useful, e.g. for Intent distribution, where DNCP doesn't seem 2412 applicable. 2414 RESOLVED: Yes, see #14. 2416 o 17. Ensure that the discovery mechanism is completely proof 2417 against loops and protected against duplicate responses. 2419 RESOLVED: Added loop count mechanism. 2421 o 18. Discuss the handling of multiple valid discovery responses. 2423 RESOLVED: Stated that the choice must be available to the ASA but 2424 GRASP implementation should pick a default. 2426 o 19. Should we use a text-oriented format such as JSON/CBOR 2427 instead of native binary TLV format? 2429 RESOLVED: Yes, changed to CBOR. 2431 o 20. Is the Divert option needed? If a discovery response 2432 provides a valid IP address or FQDN, the recipient doesn't gain 2433 any extra knowledge from the Divert. On the other hand, the 2434 presence of Divert informs the receiver that the target is off- 2435 link, which might be useful sometimes. 2437 RESOLVED: Decided to keep Divert option. 2439 o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling 2440 Protocol)? 2442 RESOLVED: Yes, name changed. 2444 o 22. Does discovery mechanism scale robustly as needed? Need hop 2445 limit on relaying? 2447 RESOLVED: Added hop limit. 2449 o 23. Need more details on TTL for caching discovery responses. 2451 RESOLVED: Done. 2453 o 24. Do we need "fast withdrawal" of discovery responses? 2455 RESOLVED: This doesn't seem necessary. If an ASA exits or stops 2456 supporting a given objective, peers will fail to start future 2457 sessions and will simply repeat discovery. 2459 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? 2461 RESOLVED: Decided not to consider this further as a GRASP protocol 2462 issue. GRASP objectives could embed DNS-SD formats if needed. 2464 o 26. Add a URL type to the locator options (for security bootstrap 2465 etc.) 2467 RESOLVED: Done, later renamed as URI. 2469 o 27. Security of Flood multicasts (Section 3.3.5.1). 2471 RESOLVED: added text. 2473 o 28. Does ACP support secure link-local multicast? 2475 RESOLVED by new text in the Security Considerations. 2477 o 29. PEN is used to distinguish vendor options. Would it be 2478 better to use a domain name? Anything unique will do. 2480 RESOLVED: Simplified this by removing PEN field and changing 2481 naming rules for objectives. 2483 o 30. Does response to discovery require randomized delays to 2484 mitigate amplification attacks? 2486 RESOLVED: WG feedback is that it's unnecessary. 2488 o 31. We have specified repeats for failed discovery etc. Is that 2489 sufficient to deal with sleeping nodes? 2491 RESOLVED: WG feedback is that it's unnecessary to say more. 2493 o 32. We have one-to-one synchronization and flooding 2494 synchronization. Do we also need selective flooding to a subset 2495 of nodes? 2497 RESOLVED: This will be discussed as a protocol extension in a 2498 separate draft (draft-liu-anima-grasp-distribution). 2500 o 33. Clarify if/when discovery needs to be repeated. 2502 RESOLVED: Done. 2504 o 34. Clarify what is mandatory for running in ACP, expand 2505 discussion of security boundary when running with no ACP - might 2506 rely on the local PKI infrastructure. 2508 RESOLVED: Done. 2510 o 35. State that role-based authorization of ASAs is out of scope 2511 for GRASP. GRASP doesn't recognize/handle any "roles". 2513 RESOLVED: Done. 2515 o 36. Reconsider CBOR definition for PEN syntax. ( objective-name 2516 = text / [pen, text] ; pen = uint ) 2518 RESOLVED: See issue 29. 2520 o 37. Are URI locators really needed? 2522 RESOLVED: Yes, e.g. for security bootstrap discovery, but added 2523 note that addresses are the normal case (same for FQDN locators). 2525 o 38. Is Session ID sufficient to identify relayed responses? 2526 Isn't the originator's address needed too? 2528 RESOLVED: Yes, this is needed for multicast messages and their 2529 responses. 2531 o 39. Clarify that a node will contain one GRASP instance 2532 supporting multiple ASAs. 2534 RESOLVED: Done. 2536 o 40. Add a "reason" code to the DECLINE option? 2538 RESOLVED: Done. 2540 o 41. What happens if an ASA cannot conveniently use one of the 2541 GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) 2542 simply pass the discovery results to the ASA so that it can open 2543 its own socket? 2545 RESOLVED: Both would be possible, but (b) is preferred. 2547 o 42. Do we need a feature whereby an ASA can bypass the ACP and 2548 use the data plane for efficiency/throughput? This would require 2549 discovery to return non-ACP addresses and would evade ACP 2550 security. 2552 RESOLVED: This is considered out of scope for GRASP, but a comment 2553 has been added in security considerations. 2555 o 44. In requirement T9, the words that encryption "may not be 2556 required in all deployments" were removed. Is that OK?. 2558 RESOLVED: No objections. 2560 o 45. Device Identity Option is unused. Can we remove it 2561 completely?. 2563 RESOLVED: No objections. Done. 2565 o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD 2566 messages is intended to assist in loop prevention. However, we 2567 also have the loop count for that. Also, if we create a new 2568 Session ID each time a DISCOVER or FLOOD is relayed, that ID can 2569 be disambiguated by recipients. It would be simpler to remove the 2570 initiator from the messages, making parsing more uniform. Is that 2571 OK? 2573 RESOLVED: Yes. Done. 2575 o 47. REQUEST is a dual purpose message (request negotiation or 2576 request synchronization). Would it be better to split this into 2577 two different messages (and adjust various message names 2578 accordingly)? 2580 RESOLVED: Yes. Done. 2582 Appendix C. Change log [RFC Editor: Please remove] 2584 draft-ietf-anima-grasp-06, 2016-06-27: 2586 Added text on discovery cache timeouts. 2588 Noted that ASAs that are only initiators do not need to respond to 2589 discovery message. 2591 Added text on unexpected address changes. 2593 Added text on robust implementation. 2595 Clarifications and editorial fixes for numerous review comments 2597 Added open issues for some review comments. 2599 draft-ietf-anima-grasp-05, 2016-05-13: 2601 Noted in requirement T1 that it should be possible to implement ASAs 2602 independently as user space programs. 2604 Protocol change: Added protocol number and port to discovery 2605 response. Updated protocol description, CDDL and IANA considerations 2606 accordingly. 2608 Clarified that discovery and flood multicasts are handled by the 2609 GRASP kernel, not directly by ASAs. 2611 Clarified that a node may discover an objective without supporting it 2612 for synchronization or negotiation. 2614 Added Implementation Status section. 2616 Added reference to SCSP. 2618 Editorial fixes. 2620 draft-ietf-anima-grasp-04, 2016-03-11: 2622 Protocol change: Restored initiator field in certain messages and 2623 adjusted relaying rules to provide complete loop detection. 2625 Updated IANA Considerations. 2627 draft-ietf-anima-grasp-03, 2016-02-24: 2629 Protocol change: Removed initiator field from certain messages and 2630 adjusted relaying requirement to simplify loop detection. Also 2631 clarified narrative explanation of discovery relaying. 2633 Protocol change: Split Request message into two (Request Negotiation 2634 and Request Synchronization) and updated other message names for 2635 clarity. 2637 Protocol change: Dropped unused Device ID option. 2639 Further clarified text on transport layer usage. 2641 New text about multicast insecurity in Security Considerations. 2643 Various other clarifications and editorial fixes, including moving 2644 some material to Appendix. 2646 draft-ietf-anima-grasp-02, 2016-01-13: 2648 Resolved numerous issues according to WG discussions. 2650 Renumbered requirements, added D9. 2652 Protocol change: only allow one objective in rapid mode. 2654 Protocol change: added optional error string to DECLINE option. 2656 Protocol change: removed statement that seemed to say that a Request 2657 not preceded by a Discovery should cause a Discovery response. That 2658 made no sense, because there is no way the initiator would know where 2659 to send the Request. 2661 Protocol change: Removed PEN option from vendor objectives, changed 2662 naming rule accordingly. 2664 Protocol change: Added FLOOD message to simplify coding. 2666 Protocol change: Added SYNCH message to simplify coding. 2668 Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD 2669 messages. But also allowed the relay process for DISCOVER and FLOOD 2670 to regenerate a Session ID. 2672 Protocol change: Require that discovered addresses must be global 2673 (except during bootstrap). 2675 Protocol change: Receiver of REQUEST message must close socket if no 2676 ASA is listening for the objective. 2678 Protocol change: Simplified Waiting message. 2680 Protocol change: Added No Operation message. 2682 Renamed URL locator type as URI locator type. 2684 Updated CDDL definition. 2686 Various other clarifications and editorial fixes. 2688 draft-ietf-anima-grasp-01, 2015-10-09: 2690 Updated requirements after list discussion. 2692 Changed from TLV to CBOR format - many detailed changes, added co- 2693 author. 2695 Tightened up loop count and timeouts for various cases. 2697 Noted that GRASP does not provide transactional integrity. 2699 Various other clarifications and editorial fixes. 2701 draft-ietf-anima-grasp-00, 2015-08-14: 2703 File name and protocol name changed following WG adoption. 2705 Added URL locator type. 2707 draft-carpenter-anima-gdn-protocol-04, 2015-06-21: 2709 Tuned wording around hierarchical structure. 2711 Changed "device" to "ASA" in many places. 2713 Reformulated requirements to be clear that the ASA is the main 2714 customer for signaling. 2716 Added requirement for flooding unsolicited synch, and added it to 2717 protocol spec. Recognized DNCP as alternative for flooding synch 2718 data. 2720 Requirements clarified, expanded and rearranged following design team 2721 discussion. 2723 Clarified that GDNP discovery must not be a prerequisite for GDNP 2724 negotiation or synchronization (resolved issue 13). 2726 Specified flag bits for objective options (resolved issue 15). 2728 Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 2729 9,10,11). 2731 Updated DNCP description from latest DNCP draft. 2733 Editorial improvements. 2735 draft-carpenter-anima-gdn-protocol-03, 2015-04-20: 2737 Removed intrinsic security, required external security 2739 Format changes to allow DNCP co-existence 2741 Recognized DNS-SD as alternative discovery method. 2743 Editorial improvements 2745 draft-carpenter-anima-gdn-protocol-02, 2015-02-19: 2747 Tuned requirements to clarify scope, 2748 Clarified relationship between types of objective, 2750 Clarified that objectives may be simple values or complex data 2751 structures, 2753 Improved description of objective options, 2755 Added loop-avoidance mechanisms (loop count and default timeout, 2756 limitations on discovery relaying and on unsolicited responses), 2758 Allow multiple discovery objectives in one response, 2760 Provided for missing or multiple discovery responses, 2762 Indicated how modes such as "dry run" should be supported, 2764 Minor editorial and technical corrections and clarifications, 2766 Reorganized future work list. 2768 draft-carpenter-anima-gdn-protocol-01, restructured the logical flow 2769 of the document, updated to describe synchronization completely, add 2770 unsolicited responses, numerous corrections and clarifications, 2771 expanded future work list, 2015-01-06. 2773 draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- 2774 config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 2775 02, 2014-10-08. 2777 Appendix D. Capability Analysis of Current Protocols 2779 This appendix discusses various existing protocols with properties 2780 related to the above negotiation and synchronisation requirements. 2781 The purpose is to evaluate whether any existing protocol, or a simple 2782 combination of existing protocols, can meet those requirements. 2784 Numerous protocols include some form of discovery, but these all 2785 appear to be very specific in their applicability. Service Location 2786 Protocol (SLP) [RFC2608] provides service discovery for managed 2787 networks, but requires configuration of its own servers. DNS-SD 2788 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 2789 small networks with a single link layer. [RFC7558] aims to extend 2790 this to larger autonomous networks but this is not yet standardized. 2791 However, both SLP and DNS-SD appear to target primarily application 2792 layer services, not the layer 2 and 3 objectives relevant to basic 2793 network configuration. Both SLP and DNS-SD are text-based protocols. 2795 Routing protocols are mainly one-way information announcements. The 2796 receiver makes independent decisions based on the received 2797 information and there is no direct feedback information to the 2798 announcing peer. This remains true even though the protocol is used 2799 in both directions between peer routers; there is state 2800 synchronization, but no negotiation, and each peer runs its route 2801 calculations independently. 2803 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 2804 response model not well suited for peer negotiation. Network 2805 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 2806 does allow positive or negative responses from the target system, but 2807 this is still not adequate for negotiation. 2809 There are various existing protocols that have elementary negotiation 2810 abilities, such as Dynamic Host Configuration Protocol for IPv6 2811 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 2812 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 2813 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 2814 configuration or management protocols. However, they either provide 2815 only a simple request/response model in a master/slave context or 2816 very limited negotiation abilities. 2818 There are some signaling protocols with an element of negotiation. 2819 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 2820 designed for negotiating quality of service parameters along the path 2821 of a unicast or multicast flow. RSVP is a very specialised protocol 2822 aimed at end-to-end flows. However, it has some flexibility, having 2823 been extended for MPLS label distribution [RFC3209]. A more generic 2824 design is General Internet Signalling Transport (GIST) [RFC5971], but 2825 it is complex, tries to solve many problems, and is also aimed at 2826 per-flow signaling across many hops rather than at device-to-device 2827 signaling. However, we cannot completely exclude extended RSVP or 2828 GIST as a synchronization and negotiation protocol. They do not 2829 appear to be directly useable for peer discovery. 2831 We now consider two protocols that are works in progress at the time 2832 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 2833 protocol intended to convey NETCONF information expressed in the YANG 2834 language via HTTP, including the ability to transit HTML 2835 intermediaries. While this is a powerful approach in the context of 2836 centralised configuration of a complex network, it is not well 2837 adapted to efficient interactive negotiation between peer devices, 2838 especially simple ones that are unlikely to include YANG processing 2839 already. 2841 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 2842 [RFC7787]. This is defined as a generic form of state 2843 synchronization protocol, with a proposed usage profile being the 2844 Home Networking Control Protocol (HNCP) [RFC7788] for configuring 2845 Homenet routers. A specific application of DNCP for autonomic 2846 networking was proposed in [I-D.stenberg-anima-adncp]. 2848 DNCP "is designed to provide a way for each participating node to 2849 publish a set of TLV (Type-Length-Value) tuples, and to provide a 2850 shared and common view about the data published... DNCP is most 2851 suitable for data that changes only infrequently... If constant rapid 2852 state changes are needed, the preferable choice is to use an 2853 additional point-to-point channel..." 2855 Specific features of DNCP include: 2857 o Every participating node has a unique node identifier. 2859 o DNCP messages are encoded as a sequence of TLV objects, sent over 2860 unicast UDP or TCP, with or without (D)TLS security. 2862 o Multicast is used only for discovery of DNCP neighbors when lower 2863 security is acceptable. 2865 o Synchronization of state is maintained by a flooding process using 2866 the Trickle algorithm. There is no bilateral synchronization or 2867 negotiation capability. 2869 o The HNCP profile of DNCP is designed to operate between directly 2870 connected neighbors on a shared link using UDP and link-local IPv6 2871 addresses. 2873 DNCP does not meet the needs of a general negotiation protocol, 2874 because it is designed specifically for flooding synchronization. 2875 Also, in its HNCP profile it is limited to link-local messages and to 2876 IPv6. However, at the minimum it is a very interesting test case for 2877 this style of interaction between devices without needing a central 2878 authority, and it is a proven method of network-wide state 2879 synchronization by flooding. 2881 The Server Cache Synchronization Protocol (SCSP) [RFC2334] also 2882 describes a method for cache synchronization and cache replication 2883 among a group of nodes. 2885 A proposal was made some years ago for an IP based Generic Control 2886 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 2887 information exchange and negotiation but not directly at peer 2888 discovery. However, it has many points in common with the present 2889 work. 2891 None of the above solutions appears to completely meet the needs of 2892 generic discovery, state synchronization and negotiation in a single 2893 solution. Many of the protocols assume that they are working in a 2894 traditional top-down or north-south scenario, rather than a fluid 2895 peer-to-peer scenario. Most of them are specialized in one way or 2896 another. As a result, we have not identified a combination of 2897 existing protocols that meets the requirements in Section 2. Also, 2898 we have not identified a path by which one of the existing protocols 2899 could be extended to meet the requirements. 2901 Authors' Addresses 2903 Carsten Bormann 2904 Universitaet Bremen TZI 2905 Postfach 330440 2906 D-28359 Bremen 2907 Germany 2909 Email: cabo@tzi.org 2911 Brian Carpenter (editor) 2912 Department of Computer Science 2913 University of Auckland 2914 PB 92019 2915 Auckland 1142 2916 New Zealand 2918 Email: brian.e.carpenter@gmail.com 2920 Bing Liu (editor) 2921 Huawei Technologies Co., Ltd 2922 Q14, Huawei Campus 2923 No.156 Beiqing Road 2924 Hai-Dian District, Beijing 100095 2925 P.R. China 2927 Email: leo.liubing@huawei.com