idnits 2.17.1 draft-carpenter-anima-gdn-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2015) is 3353 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) ** Downref: Normative reference to an Informational RFC: RFC 3174 == Outdated reference: A later version (-03) exists of draft-behringer-anima-autonomic-control-plane-00 == Outdated reference: A later version (-02) exists of draft-eckert-anima-stable-connectivity-00 == Outdated reference: A later version (-06) exists of draft-ietf-dnssd-requirements-04 == Outdated reference: A later version (-12) exists of draft-ietf-homenet-dncp-00 == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-03 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-04 == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-03 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-05 == Outdated reference: A later version (-06) exists of draft-liang-iana-pen-04 == Outdated reference: A later version (-02) exists of draft-pritikin-anima-bootstrapping-keyinfra-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Standards Track B. Liu 5 Expires: August 23, 2015 Huawei Technologies Co., Ltd 6 February 19, 2015 8 A Generic Discovery and Negotiation Protocol for Autonomic Networking 9 draft-carpenter-anima-gdn-protocol-02 11 Abstract 13 This document establishes requirements for a protocol that enables 14 intelligent devices to dynamically discover peer devices, to 15 synchronize state with them, and to negotiate parameter settings 16 mutually with them. The document then defines a general protocol for 17 discovery, synchronization and negotiation, while the technical 18 objectives for specific scenarios are to be described in separate 19 documents. An Appendix briefly discusses existing protocols with 20 comparable features. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 23, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirement Analysis of Discovery, Synchronization and 58 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Requirements for Discovery . . . . . . . . . . . . . . . 4 60 2.2. Requirements for Synchronization and Negotiation 61 Capability . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Specific Technical Requirements . . . . . . . . . . . . . 7 63 3. GDNP Protocol Overview . . . . . . . . . . . . . . . . . . . 8 64 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 10 66 3.3. GDNP Protocol Basic Properties and Mechanisms . . . . . . 13 67 3.3.1. Discovery Mechanism and Procedures . . . . . . . . . 13 68 3.3.2. Certificate-based Security Mechanism . . . . . . . . 15 69 3.3.3. Negotiation Procedures . . . . . . . . . . . . . . . 18 70 3.3.4. Synchronization Procedure . . . . . . . . . . . . . . 19 71 3.4. GDNP Constants . . . . . . . . . . . . . . . . . . . . . 20 72 3.5. Device Identifier and Certificate Tag . . . . . . . . . . 20 73 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 21 74 3.7. GDNP Messages . . . . . . . . . . . . . . . . . . . . . . 21 75 3.7.1. GDNP Message Format . . . . . . . . . . . . . . . . . 21 76 3.7.2. Discovery Message . . . . . . . . . . . . . . . . . . 22 77 3.7.3. Response Message . . . . . . . . . . . . . . . . . . 23 78 3.7.4. Request Message . . . . . . . . . . . . . . . . . . . 23 79 3.7.5. Negotiation Message . . . . . . . . . . . . . . . . . 24 80 3.7.6. Negotiation-ending Message . . . . . . . . . . . . . 24 81 3.7.7. Confirm-waiting Message . . . . . . . . . . . . . . . 24 82 3.8. GDNP General Options . . . . . . . . . . . . . . . . . . 25 83 3.8.1. Format of GDNP Options . . . . . . . . . . . . . . . 25 84 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 25 85 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 26 86 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 26 87 3.8.5. Waiting Time Option . . . . . . . . . . . . . . . . . 27 88 3.8.6. Certificate Option . . . . . . . . . . . . . . . . . 28 89 3.8.7. Signature Option . . . . . . . . . . . . . . . . . . 28 90 3.8.8. Locator Options . . . . . . . . . . . . . . . . . . . 29 91 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 31 92 3.9.1. Format of Objective Options . . . . . . . . . . . . . 31 93 3.9.2. General Considerations for Objective Options . . . . 32 94 3.9.3. Organizing of Objective Options . . . . . . . . . . . 32 95 3.9.4. Vendor Specific Objective Options . . . . . . . . . . 33 96 3.9.5. Experimental Objective Options . . . . . . . . . . . 34 98 4. Items for Future Work . . . . . . . . . . . . . . . . . . . . 34 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 102 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 39 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 104 9.1. Normative References . . . . . . . . . . . . . . . . . . 40 105 9.2. Informative References . . . . . . . . . . . . . . . . . 40 106 Appendix A. Capability Analysis of Current Protocols . . . . . . 43 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 109 1. Introduction 111 The success of the Internet has made IP-based networks bigger and 112 more complicated. Large-scale ISP and enterprise networks have 113 become more and more problematic for human based management. Also, 114 operational costs are growing quickly. Consequently, there are 115 increased requirements for autonomic behavior in the networks. 116 General aspects of autonomic networks are discussed in 117 [I-D.irtf-nmrg-autonomic-network-definitions] and 118 [I-D.irtf-nmrg-an-gap-analysis]. In order to fulfil autonomy, 119 devices that embody autonomic service agents need to be able to 120 discover each other, to synchronize state with each other, and to 121 negotiate parameters and resources directly with each other. There 122 is no restriction on the type of parameters and resources concerned, 123 which include very basic information needed for addressing and 124 routing, as well as anything else that might be configured in a 125 conventional network. 127 Following this Introduction, Section 2 describes the requirements for 128 network device discovery, synchronization and negotiation. 129 Negotiation is an iterative process, requiring multiple message 130 exchanges forming a closed loop between the negotiating devices. 131 State synchronization, when needed, can be regarded as a special case 132 of negotiation, without iteration. Section 3.2 describes a behavior 133 model for a protocol intended to support discovery, synchronization 134 and negotiation. The design of Generic Discovery and Negotiation 135 Protocol (GDNP) in Section 3 of this document is mainly based on this 136 behavior model. The relevant capabilities of various existing 137 protocols are reviewed in Appendix A. 139 The proposed discovery mechanism is oriented towards synchronization 140 and negotiation objectives. It is based on a neighbor discovery 141 process, but also supports diversion to off-link peers. Although 142 many negotiations will occur between horizontally distributed peers, 143 many target scenarios are hierarchical networks, which is the 144 predominant structure of current large-scale networks. However, when 145 a device starts up with no pre-configuration, it has no knowledge of 146 a hierarchical superior. The protocol itself is capable of being 147 used in a small and/or flat network structure such as a small office 148 or home network as well as a professionally managed network. 149 Therefore, the discovery mechanism needs to be able to allow a device 150 to bootstrap itself without making any prior assumptions about 151 network structure. 153 Because GDNP can be used to perform a decision process among 154 distributed devices or between networks, it adopts a tight 155 certificate-based security mechanism, which needs a Public Key 156 Infrastructure (PKI) [RFC5280] system. The PKI may be managed by an 157 operator or be autonomic, as discussed in 158 [I-D.pritikin-anima-bootstrapping-keyinfra]. 160 It is understood that in realistic deployments, not all devices will 161 support GDNP. It is expected that some autonomic service agents will 162 manage a group of non-autonomic nodes, and that other non-autonomic 163 nodes will be managed traditionally. Such mixed scenarios are not 164 discussed in this specification. 166 2. Requirement Analysis of Discovery, Synchronization and Negotiation 168 This section discusses the requirements for discovery, negotiation 169 and synchronization capabilities. 171 2.1. Requirements for Discovery 173 In an autonomic network we must assume that when a device starts up 174 it has no information about any peer devices, the network structure, 175 or what specific role it must play. In some cases, when a new 176 application session starts up within a device, the device may again 177 lack information about relevant peer devices. It might be necessary 178 to set up resources on multiple other devices, coordinated and 179 matched to each other so that there is no wasted resource. Security 180 settings might also need updating to allow for the new device or 181 user. Therefore a basic requirement is that there must be a 182 mechanism by which a device can separately discover peer devices for 183 each of the technical objectives that it needs to manage. Some 184 objectives may only be significant on the local link, but others may 185 be significant across the routed network and require off-link 186 operations. Thus, the relevant peer devices might be immediate 187 neighbors on the same layer 2 link or they might be more distant and 188 only accessible via layer 3. The mechanism must therefore support 189 both on-link discovery and off-link discovery of peers that support 190 specific technical objectives. 192 The relevant peer devices may be different for different technical 193 objectives. Therefore discovery needs to be repeated as often as 194 necessary to find peers capable of acting as counterparts for each 195 objective that a discovery initiator needs to handle. In many 196 scenarios, the discovery process may be followed by a synchronization 197 or negotiation process. Therefore, a discovery objective may be 198 associated with one or more synchronization or negotiation 199 objectives. 201 When a device first starts up, it has no knowledge of the network 202 structure. Therefore the discovery process must be able to support 203 any network scenario, assuming only that the device concerned is 204 bootstrapped from factory condition. 206 In some networks, as mentioned above, there will be some hierarchical 207 structure, at least for certain synchronization or negotiation 208 objectives. A special case of discovery is that each device must be 209 able to discover its hierarchical superior for each such objective 210 that it is capable of handling. This is part of the more general 211 requirement to discover off-link devices. 213 During initialisation, a device must be able to establish mutual 214 trust with the rest of the network and join the PKI. Although this 215 must inevitably start with a discovery action, it is a special case 216 precisely because trust is not yet established. This topic is the 217 subject of [I-D.pritikin-anima-bootstrapping-keyinfra]. In addition, 218 depending on the type of network involved, discovery of other central 219 functions might be needed, such as the Network Operations Center 220 (NOC) [I-D.eckert-anima-stable-connectivity]. 222 2.2. Requirements for Synchronization and Negotiation Capability 224 We start by considering routing protocols, the closest approximation 225 to autonomic networking in widespread use. Routing protocols use a 226 largely autonomic model based on distributed devices that communicate 227 repeatedly with each other. However, routing is mainly based on one- 228 way information synchronization (in either direction), rather than on 229 bi-directional negotiation. The focus is reachability, so current 230 routing protocols only consider simple link status, i.e., up or down. 231 More information, such as latency, congestion, capacity, and 232 particularly unused capacity, would be helpful to get better path 233 selection and utilization rate. Also, autonomic networks need to be 234 able to manage many more dimensions, such as security settings, power 235 saving, load balancing, etc. A basic requirement for the protocol is 236 therefore the ability to represent, discover, synchronize and 237 negotiate almost any kind of network parameter. 239 Human intervention in complex situations is costly and error-prone. 240 Therefore, synchronization or negotiation of parameters without human 241 intervention is desirable whenever the coordination of multiple 242 devices can improve overall network performance. It follows that a 243 requirement for the protocol is to be capable of running in any 244 device that would otherwise need human intervention. 246 Human intervention in large networks is often replaced by use of a 247 top-down network management system (NMS). It therefore follows that 248 a requirement for the protocol is to be capable of running in any 249 device that would otherwise be managed by an NMS, and that it can co- 250 exist with an NMS. 252 Since the goal is to minimize human intervention, it is necessary 253 that the network can in effect "think ahead" before changing its 254 parameters. In other words there must be a possibility of 255 forecasting the effect of a change by a "dry run" mechanism before 256 actually installing the change. This will be an application of the 257 protocol rather than a feature of the protocol itself. 259 Status information and traffic metrics need to be shared between 260 nodes for dynamic adjustment of resources and for monitoring 261 purposes. While this might be achieved by existing protocols when 262 they are available, the new protocol needs to be able to support 263 parameter exchange, including mutual synchronization, even when no 264 negotiation as such is required. 266 Recovery from faults and identification of faulty devices should be 267 as automatic as possible. However, the protocol's role is limited to 268 the ability to handle discovery, synchronization and negotiation at 269 any time, in case an autonomic service agent detects an anomaly such 270 as a negotiation counterpart failing. 272 Management logging, monitoring, alerts and tools for intervention are 273 required. However, these can only be features of individual 274 autonomic service agents. Another document 275 [I-D.eckert-anima-stable-connectivity] discusses how such agents may 276 be linked into conventional OAM systems via an Autonomic Control 277 Plane [I-D.behringer-anima-autonomic-control-plane]. 279 The protocol needs to be able to deal with a wide variety of 280 technical objectives, covering any type of network parameter. 281 Therefore the protocol will need either an explicit information model 282 describing its messages, or at least a flexible and extensible 283 message format. One design consideration is whether to adopt an 284 existing information model or to design a new one. Another 285 consideration is whether it should be able to carry some or all of 286 the message formats used by existing configuration protocols. 288 2.3. Specific Technical Requirements 290 To be a generic platform, the protocol payload format should be 291 independent of the transport protocol or IP version. In particular, 292 it should be able to run over IPv6 or IPv4. However, some functions, 293 such as multicasting or broadcasting on a link, might need to be IP 294 version dependent. In case of doubt, IPv6 should be preferred. 296 The protocol must be able to access off-link counterparts via 297 routable addresses, i.e., must not be restricted to link-local 298 operation. 300 The negotiation process must be guaranteed to terminate (with success 301 or failure) and if necessary it must contain tie-breaking rules for 302 each technical objective that requires them. While this must be 303 defined specifically for each use case, the protocol should have some 304 general mechanisms in support of loop and deadlock prevention. 306 Dependencies: In order to decide a configuration on a given device, 307 the device may need information from neighbors. This can be 308 established through the negotiation procedure, or through 309 synchronization if that is sufficient. However, a given item in a 310 neighbor may depend on other information from its own neighbors, 311 which may need another negotiation or synchronization procedure to 312 obtain or decide. Therefore, there are potential dependencies among 313 negotiation or synchronization procedures. Thus, there need to be 314 clear boundaries and convergence mechanisms for these negotiation 315 dependencies. Also some mechanisms are needed to avoid loop 316 dependencies. 318 Policy constraints: There must be provision for general policy intent 319 rules to be applied by all devices in the network (e.g., security 320 rules, prefix length, resource sharing rules). However, policy 321 intent distribution might not use the negotiation protocol itself. 323 Management monitoring, alerts and intervention: Devices should be 324 able to report to a monitoring system. Some events must be able to 325 generate operator alerts and some provision for emergency 326 intervention must be possible (e.g. to freeze synchronization or 327 negotiation in a mis-behaving device). These features may not use 328 the negotiation protocol itself. 330 The protocol needs to be fully secure against forged messages and 331 man-in-the middle attacks, and as secure as reasonably possible 332 against denial of service attacks. It needs to be capable of 333 encryption in order to resist unwanted monitoring, although this 334 capability may not be required in all deployments. 336 3. GDNP Protocol Overview 338 3.1. Terminology 340 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 341 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 342 "OPTIONAL" in this document are to be interpreted as described in 343 [RFC2119] when they appear in ALL CAPS. When these words are not in 344 ALL CAPS (such as "should" or "Should"), they have their usual 345 English meanings, and are not to be interpreted as [RFC2119] key 346 words. 348 The following terms are used throughout this document: 350 o Discovery: a process by which a device discovers peer devices 351 according to a specific discovery objective. The discovery 352 results may be different according to the different discovery 353 objectives. The discovered peer devices may later be used as 354 negotiation counterparts or as sources of synchronization data. 356 o Negotiation: a process by which two (or more) devices interact 357 iteratively to agree on parameter settings that best satisfy the 358 objectives of one or more devices. 360 o State Synchronization: a process by which two (or more) devices 361 interact to agree on the current state of parameter values stored 362 in each device. This is a special case of negotiation in which 363 information is sent but the devices do not request their peers to 364 change parameter settings. All other definitions apply to both 365 negotiation and synchronization. 367 o Objective: An objective in GDNP is a configurable state of some 368 kind, which occurs in three contexts: Discovery, Negotiation and 369 Synchronization. In the protocol, an objective is represented by 370 an identifier (actually a GDNP option number) and if relevant a 371 value. Normally, a given objective will occur during discovery 372 and negotiation, or during discovery and synchronization, but not 373 in all three contexts. 375 * One device may support multiple independent objectives. 377 * The parameter described by a given objective is naturally based 378 on a specific service or function or action. It may in 379 principle be anything that can be set to a specific logical, 380 numerical or string value, or a more complex data structure, by 381 a network node. That node is generally expected to be an 382 autonomic service agent which may itself manage other nodes. 384 * Discovery Objective: if a node needs to synchronize or 385 negotiate a specific objective but does not know a peer that 386 supports this objective, it starts a discovery process. The 387 objective is called a Discovery Objective during this process. 389 * Synchronization Objective: an objective whose specific 390 technical content needs to be synchronized among two or more 391 devices. 393 * Negotiation Objective: an objective whose specific technical 394 content needs to be decided in coordination with another 395 network device. 397 o Discovery Initiator: a device that spontaneously starts discovery 398 by sending a discovery message referring to a specific discovery 399 objective. 401 o Discovery Responder: a peer device which responds to the discovery 402 objective initiated by the discovery initiator. 404 o Synchronization Initiator: a device that spontaneously starts 405 synchronization by sending a request message referring to a 406 specific synchronization objective. 408 o Synchronization Responder: a peer device which responds with the 409 value of a synchronization objective. 411 o Negotiation Initiator: a device that spontaneously starts 412 negotiation by sending a request message referring to a specific 413 negotiation objective. 415 o Negotiation Counterpart: a peer device with which the Negotiation 416 Initiator negotiates a specific negotiation objective. 418 o Device Identifier: a public key, which identifies the device in 419 GDNP messages. It is assumed that its associated private key is 420 maintained in the device only. 422 o Device Certificate: A certificate for a single device, also the 423 identifier of the device, further described in Section 3.5. 425 o Device Certificate Tag: a tag, which is bound to the device 426 identifier. It is used to present a Device Certificate in short 427 form. 429 3.2. High-Level Design Choices 431 This section describes a behavior model and some considerations for 432 designing a generic discovery, synchronization and negotiation 433 protocol, which can act as a platform for different technical 434 objectives. 436 NOTE: This protocol is described here in a stand-alone fashion as a 437 proof of concept. An elementary version has been prototyped by 438 Huawei and the Beijing University of Posts and Telecommunications. 439 However, this is not yet a definitive proposal for IETF adoption. In 440 particular, adaptation and extension of one of the protocols 441 discussed in Appendix A might be an option. Also, the security model 442 outlined below would in practice be part of a general security 443 mechanism in an autonomic control plane 444 [I-D.behringer-anima-autonomic-control-plane]. This whole 445 specification is subject to change as a result. 447 o A generic platform 449 The protocol is designed as a generic platform, which is 450 independent from the synchronization or negotiation contents. It 451 takes care of the general intercommunication between counterparts. 452 The technical contents will vary according to the various 453 synchronization or negotiation objectives and the different pairs 454 of counterparts. 456 o Security infrastructure and trust relationship 458 Because this negotiation protocol may directly cause changes to 459 device configurations and bring significant impacts to a running 460 network, this protocol is based on a restrictive security 461 infrastructure, allowing it to be trusted and monitored so that 462 every device in this negotiation system behaves well and remains 463 well protected. 465 On the other hand, a limited negotiation model might be deployed 466 based on a limited trust relationship. For example, between two 467 administrative domains, devices might also exchange limited 468 information and negotiate some particular configurations based on 469 a limited conventional or contractual trust relationship. 471 o Discovery, synchronization and negotiation designed together 473 The discovery method and the synchronization and negotiation 474 methods are designed in the same way and can be combined when this 475 is useful. These processes can also be performed independently 476 when appropriate. 478 o A uniform pattern for technical contents 480 The synchronization and negotiation contents are defined according 481 to a uniform pattern. They could be carried either in simple TLV 482 (Type, Length and Value) format or in payloads described by a 483 flexible language. The initial protocol design uses the TLV 484 approach. The format is extensible for unknown future 485 requirements. 487 o A conservative model for synchronization 489 Synchronization across a number of nodes is not a new problem and 490 the Trickle model that is already known to be effective and 491 efficient is suggested. 493 o A simple initiator/responder model for negotiation 495 Multi-party negotiations are too complicated to be modeled and 496 there might be too many dependencies among the parties to converge 497 efficiently. A simple initiator/responder model is more feasible 498 and can complete multiple-party negotiations by indirect steps. 500 o Organizing of synchronization or negotiation content 502 Naturally, the technical content will be organized according to 503 the relevant function or service. The content from different 504 functions or services is kept independent from each other. They 505 are not combined into a single option or single session because 506 these contents may be negotiated or synchronized with different 507 counterparts or may be different in response time. 509 o Self aware network device 511 Every network device will be pre-loaded with various functions and 512 be aware of its own capabilities, typically decided by the 513 hardware, firmware or pre-installed software. Its exact role may 514 depend on the surrounding network behaviors, which may include 515 forwarding behaviors, aggregation properties, topology location, 516 bandwidth, tunnel or translation properties, etc. The surrounding 517 topology will depend on the network planning. Following an 518 initial discovery phase, the device properties and those of its 519 neighbors are the foundation of the synchronization or negotiation 520 behavior of a specific device. A device has no pre-configuration 521 for the particular network in which it is installed. 523 o Requests and responses in negotiation procedures 525 The initiator can negotiate with its relevant negotiation 526 counterpart devices, which may be different according to the 527 specific negotiation objective. It can request relevant 528 information from the negotiation counterpart so that it can decide 529 its local configuration to give the most coordinated performance. 530 It can request the negotiation counterpart to make a matching 531 configuration in order to set up a successful communication with 532 it. It can request certain simulation or forecast results by 533 sending some dry run conditions. 535 Beyond the traditional yes/no answer, the responder can reply with 536 a suggested alternative if its answer is 'no'. This would start a 537 bi-directional negotiation ending in a compromise between the two 538 devices. 540 o Convergence of negotiation procedures 542 To enable convergence, when a responder makes a suggestion of a 543 changed condition in a negative reply, it should be as close as 544 possible to the original request or previous suggestion. The 545 suggested value of the third or later negotiation steps should be 546 chosen between the suggested values from the last two negotiation 547 steps. In any case there must be a mechanism to guarantee 548 convergence (or failure) in a small number of steps, such as a 549 timeout or maximum number of iterations. 551 * End of negotiation 553 A limited number of rounds, for example three, or a timeout, is 554 needed on each device for each negotiation objective. It may 555 be an implementation choice, a pre-configurable parameter, or a 556 network-wide policy intent. These choices might vary between 557 different types of autonomic service agent. Therefore, the 558 definition of each negotiation objective MUST clearly specify 559 this, so that the negotiation can always be terminated 560 properly. 562 * Failed negotiation 564 There must be a well-defined procedure for concluding that a 565 negotiation cannot succeed, and if so deciding what happens 566 next (deadlock resolution, tie-breaking, or revert to best- 567 effort service). Again, this MUST be specified for individual 568 negotiation objectives, as an implementation choice, a pre- 569 configurable parameter, or a network-wide policy intent. 571 3.3. GDNP Protocol Basic Properties and Mechanisms 573 3.3.1. Discovery Mechanism and Procedures 575 o Separated discovery and negotiation mechanisms 577 Although discovery and negotiation or synchronization are 578 defined together in the GDNP, they are separated mechanisms. 579 The discovery process could run independently from the 580 negotiation or synchronization process. Upon receiving a 581 discovery (Section 3.7.2) or request (Section 3.7.4) message, 582 the recipient device should return a message in which it either 583 indicates itself as a discovery responder or diverts the 584 initiator towards another more suitable device. 586 The discovery action will normally be followed by a negotiation 587 or synchronization action. The discovery results could be 588 utilized by the negotiation protocol to decide which device the 589 initiator will negotiate with. 591 o Discovery Procedures 593 Discovery starts as an on-link operation. The Divert option 594 can tell the discovery initiator to contact an off-link 595 discovery objective device. Every DISCOVERY message is sent by 596 a discovery initiator via UDP to the ALL_GDNP_NEIGHBOR 597 multicast address (Section 3.4). Every network device that 598 supports the GDNP always listens to a well-known UDP port to 599 capture the discovery messages. 601 If the neighbor device supports the requested discovery 602 objective, it MAY respond with a Response message 603 (Section 3.7.3) with locator option(s). Otherwise, if the 604 neigbor device has cached information about a device that 605 supports the requested discovery objective (usually because it 606 discovered the same objective before), it SHOULD respond with a 607 Response message with a Divert option pointing to the 608 appropriate Discovery Responder. 610 If no discovery response is received within a reasonable 611 timeout (default GDNP_DEF_TIMEOUT milliseconds, Section 3.4), 612 the DISCOVERY message MAY be repeated, with a newly generated 613 Session ID (Section 3.6). An exponential backoff MAY be used 614 for subsequent repetitions. 616 After a GDNP device successfully discovers a Discovery 617 Responder supporting a specific objective, it MUST cache this 618 information. This cache record MAY be used for future 619 negotiation or synchronization, and SHOULD be passed on when 620 appropriate as a Divert option to another Discovery Initiator. 621 The cache lifetime is an implementation choice. 623 If multiple Discovery Responders are found for the same 624 objective, they SHOULD all be cached, unless this creates a 625 resource shortage. The method of choosing between multiple 626 responders is an implementation choice. 628 A GDNP device with multiple link-layer interfaces (typically a 629 router) MUST support discovery on all interfaces. If it 630 receives a DISCOVERY message on a given interface for a 631 specific objective that it does not support and for which it 632 has not previously discovered a Discovery Responder, it MUST 633 relay the query by re-issuing the same DISCOVERY message on its 634 other interfaces. However, it SHOULD limit the total rate at 635 which it relays discovery messages to a reasonable value. It 636 MUST cache the Session ID value of each relayed discovery 637 message and, to prevent loops, MUST NOT relay a DISCOVERY 638 message which carries such a cached Session ID. 640 This relayed discovery mechanism, with caching of the results, 641 should be sufficient to support most network bootstrapping 642 scenarios. 644 o A complete discovery process will start with multicast on the 645 local link; a neighbor might divert it to an off-link destination, 646 which could be a default higher-level gateway in a hierarchical 647 network. Then discovery would continue with a unicast to that 648 gateway; if that gateway is still not the right counterpart, it 649 should divert to another device, which is in principle closer to 650 the right counterpart. Finally the right counterpart responds to 651 start the negotiation or synchronization process. 653 o Rapid Mode (Discovery/Negotiation binding) 655 A Discovery message MAY include one or more Negotiation 656 Objective option(s). This allows a rapid mode of negotiation 657 described in Section 3.3.3. A similar mechanism is defined for 658 synchronization. 660 3.3.2. Certificate-based Security Mechanism 662 A certificate-based security mechanism provides security properties 663 for GDNP: 665 o the identity of a GDNP message sender can be verified by a 666 recipient. 668 o the integrity of a GDNP message can be checked by the recipient of 669 the message. 671 o anti-replay protection can be assured by the GDNP message 672 recipient. 674 The authority of the GDNP message sender depends on a Public Key 675 Infrastructure (PKI) system with a Certification Authority (CA), 676 which should normally be run by the network operator. In the case of 677 a network with no operator, such as a small office or home network, 678 the PKI itself needs to be established by an autonomic process, which 679 is out of scope for this specification. 681 A Request message MUST carry a Certificate option, defined in 682 Section 3.8.6. The first Negotiation Message, responding to a 683 Request message, SHOULD also carry a Certificate option. Using these 684 messages, recipients build their certificate stores, indexed by the 685 Device Certificate Tags included in every GDNP message. This process 686 is described in more detail below. 688 Every message MUST carry a signature option (Section 3.8.7). 690 For now, the authors do not think packet size is a problem. In this 691 GDNP specification, there SHOULD NOT be multiple certificates in a 692 single message. The current most used public keys are 1024/2048 693 bits; some may reach 4096. With overhead included, a single 694 certificate is less than 500 bytes. Messages are expected to be far 695 shorter than the normal packet MTU within a modern network. 697 3.3.2.1. Support for algorithm agility 699 Hash functions are used to provide message integrity checks. In 700 order to provide a means of addressing problems that may emerge in 701 the future with existing hash algorithms, as recommended in 702 [RFC4270], a mechanism for negotiating the use of more secure hashes 703 in the future is provided. 705 In addition to hash algorithm agility, a mechanism for signature 706 algorithm agility is also provided. 708 The support for algorithm agility in this document is mainly a 709 unilateral notification mechanism from sender to recipient. If the 710 recipient does not support the algorithm used by the sender, it 711 cannot authenticate the message. Senders in a single administrative 712 domain are not required to upgrade to a new algorithm simultaneously. 714 So far, the algorithm agility is supported by one-way notification, 715 rather than negotiation mode. As defined in Section 3.8.7, the 716 sender notifies the recipient what hash/signature algorithms it uses. 717 If the responder doesn't know a new algorithm used by the sender, the 718 negotiation request would fail. In order to establish a negotiation 719 session, the sender MAY fall back to an older, less preferred 720 algorithm. Certificates and network policy intent SHOULD limit the 721 choice of algorithms. 723 3.3.2.2. Message validation on reception 725 When receiving a GDNP message, a recipient MUST discard the GDNP 726 message if the Signature option is absent, or the Certificate option 727 is in a Request Message. 729 For the Request message and the Response message with a Certification 730 Option, the recipient MUST first check the authority of this sender 731 following the rules defined in [RFC5280]. After successful authority 732 validation, an implementation MUST add the sender's certification 733 into the local trust certificate record indexed by the associated 734 Device Certificate Tag (Section 3.5). 736 The recipient MUST now authenticate the sender by verifying the 737 Signature and checking a timestamp, as specified in Section 3.3.2.3. 738 The order of two procedures is left as an implementation decision. 739 It is RECOMMENDED to check timestamp first, because signature 740 verification is much more computationally expensive. 742 The signature field verification MUST show that the signature has 743 been calculated as specified in Section 3.8.7. The public key used 744 for signature validation is obtained from the certificate either 745 carried by the message or found from a local trust certificate record 746 by searching the message-carried Device Certificate Tag. 748 Only the messages that get through both the signature verifications 749 and timestamp check are accepted and continue to be handled for their 750 contained GDNP options. Messages that do not pass the above tests 751 MUST be discarded as insecure messages. 753 3.3.2.3. TimeStamp checking 755 Recipients SHOULD be configured with an allowed timestamp Delta 756 value, a "fuzz factor" for comparisons, and an allowed clock drift 757 parameter. The recommended default value for the allowed Delta is 758 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 759 drift, 0.01 second. 761 The timestamp is defined in the Signature Option, Section 3.8.7. To 762 facilitate timestamp checking, each recipient SHOULD store the 763 following information for each sender: 765 o The receive time of the last received and accepted GDNP message. 766 This is called RDlast. 768 o The time stamp in the last received and accepted GDNP message. 769 This is called TSlast. 771 An accepted GDNP message is any successfully verified (for both 772 timestamp check and signature verification) GDNP message from the 773 given peer. It initiates the update of the above variables. 774 Recipients MUST then check the Timestamp field as follows: 776 o When a message is received from a new peer (i.e., one that is not 777 stored in the cache), the received timestamp, TSnew, is checked, 778 and the message is accepted if the timestamp is recent enough to 779 the reception time of the packet, RDnew: 781 -Delta < (RDnew - TSnew) < +Delta 783 The RDnew and TSnew values SHOULD be stored in the cache as RDlast 784 and TSlast. 786 o When a message is received from a known peer (i.e., one that 787 already has an entry in the cache), the timestamp is checked 788 against the previously received GDNP message: 790 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 792 If this inequality does not hold, the recipient SHOULD silently 793 discard the message. If, on the other hand, the inequality holds, 794 the recipient SHOULD process the message. 796 Moreover, if the above inequality holds and TSnew > TSlast, the 797 recipient SHOULD update RDlast and TSlast. Otherwise, the 798 recipient MUST NOT update RDlast or TSlast. 800 An implementation MAY use some mechanism such as a timestamp cache to 801 strengthen resistance to replay attacks. When there is a very large 802 number of nodes on the same link, or when a cache filling attack is 803 in progress, it is possible that the cache holding the most recent 804 timestamp per sender will become full. In this case, the node MUST 805 remove some entries from the cache or refuse some new requested 806 entries. The specific policy as to which entries are preferred over 807 others is left as an implementation decision. 809 3.3.3. Negotiation Procedures 811 A negotiation initiator sends a negotiation request to a counterpart 812 device, including a specific negotiation objective. It may request 813 the negotiation counterpart to make a specific configuration. 814 Alternatively, it may request a certain simulation or forecast result 815 by sending a dry run configuration. The details, including the 816 distinction between dry run and an actual configuration change, will 817 be defined separately for each type of negotiation objective. 819 If the counterpart can immediately apply the requested configuration, 820 it will give an immediate positive (accept) answer. This will end 821 the negotiation phase immediately. Otherwise, it will negotiate. It 822 will reply with a proposed alternative configuration that it can 823 apply (typically, a configuration that uses fewer resources than 824 requested by the negotiation initiator). This will start a bi- 825 directional negotiation to reach a compromise between the two network 826 devices. 828 The negotiation procedure is ended when one of the negotiation peers 829 sends a Negotiation Ending message, which contains an accept or 830 decline option and does not need a response from the negotiation 831 peer. Negotiation may also end in failure (equivalent to a decline) 832 if a timeout is exceeded or a loop count is exceeded. 834 A negotiation procedure concerns one objective and one counterpart. 835 Both the initiator and the counterpart may take part in simultaneous 836 negotiations with various other devices, or in simultaneous 837 negotiations about different objectives. Thus, GDNP is expected to 838 be used in a multi-threaded mode. Certain negotiation objectives may 839 have restrictions on multi-threading, for example to avoid over- 840 allocating resources. 842 Rapid Mode (Discovery/Negotiation linkage) 844 A Discovery message MAY include a Negotiation Objective option. 845 In this case the Discovery message also acts as a Request message 846 to indicate to the Discovery Responder that it could directly 847 reply to the Discovery Initiator with a Negotiation message for 848 rapid processing, if it could act as the corresponding negotiation 849 counterpart. However, the indication is only advisory not 850 prescriptive. 852 This rapid mode could reduce the interactions between nodes so 853 that a higher efficiency could be achieved. This rapid 854 negotiation function SHOULD be configured off by default and MAY 855 be configured on or off by policy intent. 857 3.3.4. Synchronization Procedure 859 A synchronization initiator sends a synchronization request to a 860 counterpart device, including a specific synchronization objective. 861 The counterpart responds with a Response message containing the 862 current value of the requested synchronization objective. No further 863 messages are needed. If no Response message is received, the 864 synchronization request MAY be repeated after a suitable timeout. 866 In the case just described, the message exchange is unicast and 867 concerns only one synchronization objective. In the following two 868 cases, multiple synchronization objectives may be combined. 870 A synchronization responder MAY send an unsolicited Response message 871 containing one or more Synchronization Objective option(s), if and 872 only if the specification of those objectives permits it. This MAY 873 be sent as a multicast message to the ALL_GDNP_NEIGHBOR multicast 874 address (Section 3.4). In this case a suitable mechanism is needed 875 to avoid excessive multicast traffic. This mechanism MUST be defined 876 as part of the specification of the synchronization objective(s) 877 concerned. It might be a simple rate limit or a more complex 878 mechanism such as the Trickle algorithm [RFC6206]. 880 Rapid Mode (Discovery/Synchronization linkage) 882 A Discovery message MAY include one or more Synchronization 883 Objective option(s). In this case the Discovery message also acts 884 as a Request message to indicate to the Discovery Responder that 885 it could directly reply to the Discovery Initiator with a Response 886 message with synchronization data for rapid processing, if the 887 discovery target supports the corresponding synchronization 888 objective. However, the indication is only advisory not 889 prescriptive. 891 This rapid mode could reduce the interactions between nodes so 892 that a higher efficiency could be achieved. This rapid 893 synchronization function SHOULD be configured off by default and 894 MAY be configured on or off by policy intent. 896 3.4. GDNP Constants 898 o ALL_GDNP_NEIGHBOR (TBD1) 900 A link-local scope multicast address used by a GDNP-enabled device 901 to discover GDNP-enabled neighbor (i.e., on-link) devices . All 902 devices that support GDNP are members of this multicast group. 904 * IPv6 multicast address: TBD1 906 * IPv4 multicast address: TBD2 908 o GDNP Listen Port (TBD3) 910 A UDP and TCP port that every GDNP-enabled network device always 911 listens to. 913 o GDNP_DEF_TIMEOUT (60000 milliseconds) 915 The default timeout used to determine that a discovery or 916 negotiation has failed to complete. 918 o GDNP_DEF_LOOPCT (6) 920 The default loop count used to determine that a negotiation has 921 failed to complete. 923 3.5. Device Identifier and Certificate Tag 925 A GDNP-enabled Device MUST generate a stable public/private key pair 926 before it participates in GDNP. There MUST NOT be any way of 927 accessing the private key via the network or an operator interface. 928 The device then uses the public key as its identifier, which is 929 cryptographic in nature. It is a GDNP unique identifier for a GDNP 930 participant. 932 It then gets a certificate for this public key, signed by a 933 Certificate Authority that is trusted by other network devices. The 934 Certificate Authority SHOULD be managed within the local 935 administrative domain, to avoid needing to trust a third party. The 936 signed certificate would be used for authentication of the message 937 sender. In a managed network, this certification process could be 938 performed at a central location before the device is physically 939 installed at its intended location. In an unmanaged network, this 940 process must be autonomic, including the bootstrap phase. 942 A 128-bit Device Certifcate Tag, which is generated by taking a 943 cryptographic hash over the device certificate, is a short 944 presentation for GDNP messages. It is the index key to find the 945 device certificate in a recipient's local trusted certificate record. 947 The tag value is formed by taking a SHA-1 hash algorithm [RFC3174] 948 over the corresponding device certificate and taking the leftmost 128 949 bits of the hash result. 951 3.6. Session Identifier (Session ID) 953 A 24-bit opaque value used to distinguish multiple sessions between 954 the same two devices. A new Session ID MUST be generated for every 955 new Discovery or Request message, and for every unsolicited Response 956 message. All follow-up messages in the same discovery, 957 synchronization or negotiation procedure, which is initiated by the 958 request message, MUST carry the same Session ID. 960 The Session ID SHOULD have a very low collision rate locally. It is 961 RECOMMENDED to be generated by a pseudo-random algorithm using a seed 962 which is unlikely to be used by any other device in the same network 963 [RFC4086]. 965 3.7. GDNP Messages 967 This document defines the following GDNP message format and types. 968 Message types not listed here are reserved for future use. The 969 numeric encoding for each message type is shown in parentheses. 971 3.7.1. GDNP Message Format 973 All GDNP messages share an identical fixed format header and a 974 variable format area for options. Every Message carries the Device 975 Certificate Tag of its sender and a Session ID. Options are 976 presented serially in the options field, with no padding between the 977 options. Options are byte-aligned. 979 The following diagram illustrates the format of GDNP messages: 981 0 1 2 3 982 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | MESSAGE_TYPE | Session ID | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | | 987 | Device Certificate Tag | 988 | | 989 | | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Options (variable length) | 992 . . 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 MESSAGE_TYPE: Identifies the GDNP message type. 8-bit. 997 Session ID: Identifies this negotiation session, as defined in 998 Section 3.6. 24-bit. 1000 Device Certificate Tag: Represents the Device Certificate, which 1001 identifies the negotiation devices, as defined in Section 3.5. 1002 The Device Certificate Tag is 128 bit, also defined in 1003 Section 3.5. It is used as index key to find the device 1004 certificate. 1006 Options: GDNP Options carried in this message. Options are defined 1007 starting at Section 3.8. 1009 3.7.2. Discovery Message 1011 DISCOVERY (MESSAGE_TYPE = 1): 1013 A discovery initiator sends a DISCOVERY message to initiate a 1014 discovery process. 1016 The discovery initiator sends the DISCOVERY messages to the link- 1017 local ALL_GDNP_NEIGHBOR multicast address for discovery, and stores 1018 the discovery results (including responding discovery objectives and 1019 corresponding unicast addresses or FQDNs). 1021 A DISCOVERY message MUST include exactly one of the following: 1023 o a discovery objective option (Section 3.9.1). 1025 o a negotiation objective option (Section 3.9.1) to indicate to the 1026 discovery target that it MAY directly reply to the discovery 1027 initiatior with a NEGOTIATION message for rapid processing, if it 1028 could act as the corresponding negotiation counterpart. The 1029 sender of such a DISCOVERY message MUST initialize a negotiation 1030 timer and loop count in the same way as a REQUEST message 1031 (Section 3.7.4). 1033 o one or more synchronization objective options (Section 3.9.1) to 1034 indicate to the discovery target that it MAY directly reply to the 1035 discovery initiator with a RESPONSE message for rapid processing, 1036 if it could act as the corresponding synchronization counterpart. 1038 3.7.3. Response Message 1040 RESPONSE (MESSAGE_TYPE = 2): 1042 A node which receives a DISCOVERY message sends a Response message to 1043 respond to a discovery. It MUST contain the same Session ID as the 1044 DISCOVERY message. It MAY include a copy of the discovery objective 1045 from the DISCOVERY message. 1047 If the responding node supports the discovery objective of the 1048 discovery, it MUST include at least one kind of locator option 1049 (Section 3.8.8) to indicate its own location. A combination of 1050 multiple kinds of locator options (e.g. IP address option + FQDN 1051 option) is also valid. 1053 If the responding node itself does not support the discovery 1054 objective, but it knows the locator of the discovery objective, then 1055 it SHOULD respond to the discovery message with a divert option 1056 (Section 3.8.2) embedding a locator option or a combination of 1057 multiple kinds of locator options which indicate the locator(s) of 1058 the discovery objective. 1060 A node which receives a synchronization request sends a Response 1061 message with the synchronization data. A node MAY send an 1062 unsolicited Response Message with synchronization data and this MAY 1063 be sent to the link-local ALL_GDNP_NEIGHBOR multicast address, in 1064 accordance with the rules in Section 3.3.4. 1066 If the response contains synchronization data, this will be in the 1067 form of GDNP Option(s) for the specific synchronization objective(s). 1069 3.7.4. Request Message 1071 REQUEST (MESSAGE_TYPE = 3): 1073 A negotiation or synchronization requesting node sends the REQUEST 1074 message to the unicast address (directly stored or resolved from the 1075 FQDN) of the negotiation or synchronization counterpart (selected 1076 from the discovery results). 1078 A request message MUST include the relevant objective option, with 1079 the requested value in the case of negotiation. 1081 When an initiator sends a REQUEST message, it MUST initialize a 1082 negotiation timer for the new negotiation thread with the value 1083 GDNP_DEF_TIMEOUT milliseconds. Unless this timeout is modified by a 1084 CONFIRM-WAITING message (Section 3.7.7), the initiator will consider 1085 that the negotiation has failed when the timer expires. 1087 When an initiator sends a REQUEST message, it MUST initialize the 1088 loop count of the objective option with a value defined in the 1089 specification of the option or, if no such value is specified, with 1090 GDNP_DEF_LOOPCT. 1092 3.7.5. Negotiation Message 1094 NEGOTIATION (MESSAGE_TYPE = 4): 1096 A negotiation counterpart sends a NEGOTIATION message in response to 1097 a REQUEST message, a NEGOTIATION message, or a DISCOVERY message in 1098 Rapid Mode. A negotiation process MAY include multiple steps. 1100 The NEGOTIATION message MUST include the relevant Negotiation 1101 Objective option, with its value updated according to progress in the 1102 negotiation. The sender MUST decrement the loop count by 1. If the 1103 loop count becomes zero both parties will consider that the 1104 negotiation has failed. 1106 3.7.6. Negotiation-ending Message 1108 NEGOTIATION-ENDING (MESSAGE_TYPE = 5): 1110 A negotiation counterpart sends an NEGOTIATION-ENDING message to 1111 close the negotiation. It MUST contain one, but only one of accept/ 1112 decline option, defined in Section 3.8.3 and Section 3.8.4. It could 1113 be sent either by the requesting node or the responding node. 1115 3.7.7. Confirm-waiting Message 1117 CONFIRM-WAITING (MESSAGE_TYPE = 6): 1119 A responding node sends a CONFIRM-WAITING message to indicate the 1120 requesting node to wait for a further negotiation response. It might 1121 be that the local process needs more time or that the negotiation 1122 depends on another triggered negotiation. This message MUST NOT 1123 include any other options than the Waiting Time Option 1124 (Section 3.8.5). 1126 3.8. GDNP General Options 1128 This section defines the GDNP general option for the negotiation and 1129 synchronization protocol signalling. Option types 10~63 are reserved 1130 for GDNP general options defined in the future. 1132 3.8.1. Format of GDNP Options 1134 0 1 2 3 1135 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | option-code | option-len | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | option-data | 1140 | (option-len octets) | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 Option-code: An unsigned integer identifying the specific option 1144 type carried in this option. 1146 Option-len: An unsigned integer giving the length of the option-data 1147 field in this option in octets. 1149 Option-data: The data for the option; the format of this data 1150 depends on the definition of the option. 1152 GDNP options are scoped by using encapsulation. If an option 1153 contains other options, the outer Option-len includes the total size 1154 of the encapsulated options, and the latter apply only to the outer 1155 option. 1157 3.8.2. Divert Option 1159 The divert option is used to redirect a GDNP request to another node, 1160 which may be more appropriate for the intended negotiation or 1161 synchronization. It may redirect to an entity that is known as a 1162 specific negotiation or synchronization counterpart (on-link or off- 1163 link) or a default gateway. The divert option MUST only be 1164 encapsulated in Response messages. If found elsewhere, it SHOULD be 1165 silently ignored. 1167 0 1 2 3 1168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | OPTION_DIVERT | option-len | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Locator Option(s) of Diversion Device(s) | 1173 . . 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 Option-code: OPTION_DIVERT (1). 1178 Option-len: The total length of diverted destination sub-option(s) 1179 in octets. 1181 Locator Option(s) of Diversion Device(s): Embedded Locator Option(s) 1182 (Section 3.8.8) that point to diverted destination device(s). 1184 3.8.3. Accept Option 1186 The accept option is used to indicate to the negotiation counterpart 1187 that the proposed negotiation content is accepted. 1189 The accept option MUST only be encapsulated in Negotiation-ending 1190 messages. If found elsewhere, it SHOULD be silently ignored. 1192 0 1 2 3 1193 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | OPTION_ACCEPT | option-len | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Option-code: OPTION_ACCEPT (2) 1200 Option-len: 0 1202 3.8.4. Decline Option 1204 The decline option is used to indicate to the negotiation counterpart 1205 the proposed negotiation content is declined and end the negotiation 1206 process. 1208 The decline option MUST only be encapsulated in Negotiation-ending 1209 messages. If found elsewhere, it SHOULD be silently ignored. 1211 0 1 2 3 1212 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | OPTION_DECLINE | option-len | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 Option-code: OPTION_DECLINE (3) 1219 Option-len: 0 1221 Notes: there are scenarios where a negotiation counterpart wants to 1222 decline the proposed negotiation content and continue the negotiation 1223 process. For these scenarios, the negotiation counterpart SHOULD use 1224 a Negotiate message, with either an objective option that contains at 1225 least one data field with all bits set to 1 to indicate a meaningless 1226 initial value, or a specific objective option that provides further 1227 conditions for convergence. 1229 3.8.5. Waiting Time Option 1231 The waiting time option is used to indicate that the negotiation 1232 counterpart needs to wait for a further negotiation response, since 1233 the processing might need more time than usual or it might depend on 1234 another triggered negotiation. 1236 The waiting time option MUST only be encapsulated in Confirm-waiting 1237 messages. If found elsewhere, it SHOULD be silently ignored. When 1238 received, its value overwrites the negotiation timer (Section 3.7.4). 1240 The counterpart SHOULD send a Negotiation, Negotiation-Ending or 1241 another Confirm-waiting message before the negotiation timer expires. 1242 If not, the initiator MUST abandon or restart the negotiation 1243 procedure, to avoid an indefinite wait. 1245 0 1 2 3 1246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | OPTION_WAITING | option-len | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Time | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 Option-code: OPTION_WAITING (4) 1255 Option-len: 4, in octets 1257 Time: Time in milliseconds 1259 3.8.6. Certificate Option 1261 The Certificate option carries the certificate of the sender. The 1262 format of the Certificate option is as follows: 1264 0 1 2 3 1265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | OPTION Certificate | option-len | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | | 1270 . Certificate (variable length) . 1271 . . 1272 | | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Option-code: OPTION_CERT_PARAMETER (5) 1277 Option-len: Length of certificate in octets 1279 Public key: A variable-length field containing a certificate 1281 3.8.7. Signature Option 1283 The Signature option allows public key-based signatures to be 1284 attached to a GDNP message. The Signature option is REQUIRED in 1285 every GDNP message and could be any place within the GDNP message. 1286 It protects the entire GDNP header and options. A TimeStamp has been 1287 integrated in the Signature Option for anti-replay protection. The 1288 format of the Signature option is described as follows: 1290 0 1 2 3 1291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | OPTION_SIGNATURE | option-len | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | HA-id | SA-id | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Timestamp (64-bit) | 1298 | | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | | 1301 . Signature (variable length) . 1302 . . 1303 | | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 Option-code: OPTION_SIGNATURE (6) 1307 Option-len: 12 + Length of Signature field in octets. 1309 HA-id: Hash Algorithm id. The hash algorithm is used for computing 1310 the signature result. This design is adopted in order to provide 1311 hash algorithm agility. The value is from the Hash Algorithm for 1312 GDNP registry in IANA. The initial value assigned for SHA-1 is 1313 0x0001. 1315 SA-id: Signature Algorithm id. The signature algorithm is used for 1316 computing the signature result. This design is adopted in order 1317 to provide signature algorithm agility. The value is from the 1318 Signature Algorithm for GDNP registry in IANA. The initial value 1319 assigned for RSASSA-PKCS1-v1_5 is 0x0001. 1321 Timestamp: The current time of day (NTP-format timestamp [RFC5905] 1322 in UTC (Coordinated Universal Time), a 64-bit unsigned fixed-point 1323 number, in seconds relative to 0h on 1 January 1900.). It can 1324 reduce the danger of replay attacks. 1326 Signature: A variable-length field containing a digital signature. 1327 The signature value is computed with the hash algorithm and the 1328 signature algorithm, as described in HA-id and SA-id. The 1329 signature constructed by using the sender's private key protects 1330 the following sequence of octets: 1332 1. The GDNP message header. 1334 2. All GDNP options including the Signature option (fill the 1335 signature field with zeroes). 1337 The signature field MUST be padded, with all 0, to the next 16 bit 1338 boundary if its size is not an even multiple of 8 bits. The 1339 padding length depends on the signature algorithm, which is 1340 indicated in the SA-id field. 1342 3.8.8. Locator Options 1344 These locator options are used to present a device's or interface's 1345 reachability information. They are Locator IPv4 Address Option, 1346 Locator IPv6 Address Option and Locator FQDN (Fully Qualified Domain 1347 Name) Option. 1349 Note that it is assumed that all locators are in scope throughout the 1350 GDNP domain. GDNP is not intended to work across disjoint addressing 1351 or naming realms. 1353 3.8.8.1. Locator IPv4 address option 1355 0 1 2 3 1356 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | OPTION_LOCATOR_IPV4ADDR | option-len | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | IPv4-Address | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 Option-code: OPTION_LOCATOR_IPV4ADDR (7) 1365 Option-len: 4, in octets 1367 IPv4-Address: The IPv4 address locator of the device/interface 1369 Note: If an operator has internal network address translation for 1370 IPv4, this option MUST NOT be used within the Divert option. 1372 3.8.8.2. Locator IPv6 address option 1374 0 1 2 3 1375 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | OPTION_LOCATOR_IPV6ADDR | option-len | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | | 1380 | IPv6-Address | 1381 | | 1382 | | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 Option-code: OPTION_LOCATOR_IPV6ADDR (8) 1387 Option-len: 16, in octets 1389 IPv6-Address: The IPv6 address locator of the device/interface 1391 Note: A link-local IPv6 address MUST NOT be used when this option is 1392 used within the Divert option. 1394 3.8.8.3. Locator FQDN option 1395 0 1 2 3 1396 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | OPTION_FQDN | option-len | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Fully Qualified Domain Name | 1401 | (variable length) | 1402 . . 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 Option-code: OPTION_FQDN (9) 1407 Option-len: Length of Fully Qualified Domain Name in octets 1409 Domain-Name: The Fully Qualified Domain Name of the entity 1411 Note: Any FQDN which might not be valid throughout the network in 1412 question, such as a Multicast DNS name [RFC6762], MUST NOT be used 1413 when this option is used within the Divert option. 1415 3.9. Objective Options 1417 3.9.1. Format of Objective Options 1419 An objective option is used to identify objectives for the purposes 1420 of discovery, negotiation or synchronization. All objectives must 1421 follow a common format as follows: 1423 0 1 2 3 1424 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | OPTION_XXX | option-len | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | loop-count | flags | | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ value | 1430 . (variable length) . 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 Option-code: OPTION_XXX: The option code assigned in the 1434 specification of the XXX objective. 1436 option-len: The total length in octets. 1438 loop-count: The loop count. This field is present if and only if 1439 the objective is a negotiation objective. 1441 flags: Flag bits. This field is present if and only if defined in 1442 the specification of the objective. 1444 value: This field is to express the actual value of a negotiation or 1445 synchronization objective. Its format is defined in the 1446 specification of the objective and may be a single value or a data 1447 structure of any kind. 1449 3.9.2. General Considerations for Objective Options 1451 Objective Options MUST be assigned an option type greater than 64 in 1452 the GDNP option table. 1454 An Objective Option that contains no additional fields, i.e., has a 1455 length of 4 octets, is a discovery objective and MUST only be used in 1456 Discovery and Response messages. 1458 The Negotiation Objective Options contain negotiation objectives, 1459 which are various according to different functions/services. They 1460 MUST be carried by Discovery, Request or Negotiation Messages only. 1461 The negotiation initiator MUST set the initial "loop-count" to a 1462 value specified in the specification of the objective or, if no such 1463 value is specified, to GDNP_DEF_LOOPCT. 1465 For most scenarios, there should be initial values in the negotiation 1466 requests. Consequently, the Negotiation Objective options MUST 1467 always be completely presented in a Request message, or in a 1468 Discovery message in rapid mode. If there is no initial value, the 1469 bits in the value field SHOULD all be set to 1 to indicate a 1470 meaningless value, unless this is inappropriate for the specific 1471 negotiation objective. 1473 Synchronization Objective Options are similar, but MUST be carried by 1474 Discovery, Request or Response messages only. They include value 1475 fields only in Response messages. 1477 3.9.3. Organizing of Objective Options 1479 As noted earlier, one negotiation objective is handled by each GDNP 1480 negotiation thread. Therefore, a negotiation objective, which is 1481 based on a specific function or action, SHOULD be organized as a 1482 single GDNP option. It is NOT RECOMMENDED to organize multiple 1483 negotiation objectives into a single option, nor to split a single 1484 function or action into multiple negotiation objectives. 1486 A synchronization objective SHOULD also be organized as a single GDNP 1487 option. 1489 Some objectives will support more than one operational mode. An 1490 example is a negotiation objective with both a "dry run" mode (where 1491 the negotiation is to find out whether the other end can in fact make 1492 the requested change without problems) and a "live" mode. Such modes 1493 will be defined in the specification of such an objective. These 1494 objectives SHOULD include a "flags" octet, with bits indicating the 1495 applicable mode(s). 1497 An objective may have multiple parameters. Parameters can be 1498 categorized into two classes: the obligatory ones presented as fixed 1499 fields; and the optional ones presented in TLV sub-options or some 1500 other form of data structure. The format might be inherited from an 1501 existing management or configuration protocol, the objective option 1502 acting as a carrier for that format. The data structure might be 1503 defined in a formal language, but that is a matter for the 1504 specifications of individual objectives. There are many candidates, 1505 according to the context, such as ABNF, RBNF, XML Schema, possibly 1506 YANG, etc. The GDNP protocol itself is agnostic on these questions. 1508 It is NOT RECOMMENDED to split parameters in a single objective into 1509 multiple options, unless they have different response periods. An 1510 exception scenario may also be described by split objectives. 1512 3.9.4. Vendor Specific Objective Options 1514 Option codes 128~159 have been reserved for vendor specific options. 1515 Multiple option codes have been assigned because a single vendor 1516 might use multiple options simultaneously. These vendor specific 1517 options are highly likely to have different meanings when used by 1518 different vendors. Therefore, they SHOULD NOT be used without an 1519 explicit human decision and SHOULD NOT be used in unmanaged networks 1520 such as home networks. 1522 There is one general requirement that applies to all vendor specific 1523 options. They MUST start with a field that uniquely identifies the 1524 enterprise that defines the option, in the form of a registered 32 1525 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen]. There is 1526 no default value for this field. Note that it is not used during 1527 discovery. It MUST be verified during negotiation or 1528 synchronization. 1530 In the case of a vendor-specific objective, the loop count and flags, 1531 if present, follow the PEN. 1533 0 1 2 3 1534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | OPTION_vendor | option-len | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | PEN | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | loop-count | flags | | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ value | 1542 . (variable length) . 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 Option-code: OPTION_vendor (128~159) 1547 Option-len: The total length in octets. 1549 PEN: Private Enterprise Number. 1551 loop-count: The loop count. This field is present if and only if 1552 the objective is a negotiation objective. 1554 flags: Flag bits. This field is present if and only if defined in 1555 the specification of the objective. 1557 value: This field is to express the actual value of a negotiation or 1558 synchronization objective. Its format is defined in the vendor's 1559 specification of the objective. 1561 3.9.5. Experimental Objective Options 1563 Option code 176~191 have been reserved for experimental options. 1564 Multiple option codes have been assigned because a single experiment 1565 may use multiple options simultaneously. These experimental options 1566 are highly likely to have different meanings when used for different 1567 experiments. Therefore, they SHOULD NOT be used without an explicit 1568 human decision and SHOULD NOT be used in unmanaged networks such as 1569 home networks. 1571 These option codes are also RECOMMENDED for use in documentation 1572 examples. 1574 4. Items for Future Work 1576 There are various design questions that are worthy of more work in 1577 the near future, as listed below (statically numbered for reference 1578 purposes): 1580 o 1. UDP vs TCP: For now, this specification suggests UDP and TCP 1581 as message transport mechanisms. This is not clarified yet. UDP 1582 is good for short conversations, is necessary for multicast 1583 discovery, and generally fits the discovery and divert scenarios 1584 well. However, it will cause problems with large messages. TCP 1585 is good for stable and long sessions, with a little bit of time 1586 consumption during the session establishment stage. If messages 1587 exceed a reasonable MTU, a TCP mode will be required in any case. 1588 This question may be affected by the security discussion. 1590 o 2. DTLS or TLS vs built-in security mechanism. For now, this 1591 specification has chosen a PKI based built-in security mechanism 1592 based on asymmetric cryptography. However, (D)TLS might be chosen 1593 as security solution to avoid duplication of effort. It also 1594 allows essentially similar security for short messages over UDP 1595 and longer ones over TCP. The implementation trade-offs are 1596 different. The current approach requires expensive asymmetric 1597 cryptographic calculations for every message. (D)TLS has startup 1598 overheads but cheaper crypto per message. DTLS is less mature 1599 than TLS. 1601 o The following open issues apply only if the current security model 1602 is retained: 1604 * 2.1. For replay protection, GDNP currently requires every 1605 participant to have an NTP-synchronized clock. Is this OK for 1606 low-end devices, and how does it work during device 1607 bootstrapping? We could take the Timestamp out of signature 1608 option, to become an independent and OPTIONAL (or RECOMMENDED) 1609 option. 1611 * 2.2. The Signature Option (Section 3.8.7) states that this 1612 option could be any place in a message. Wouldn't it be better 1613 to specify a position (such as the end)? That would be much 1614 simpler to implement. 1616 o 3. DoS Attack Protection needs work. 1618 o 4. Should we consider a distributed or centralised DNS-like 1619 approach to discovery (after the initial discovery needed for 1620 bootstrapping)? This topic is deferred for now, but the following 1621 considerations apply: This could be a complementary mechanism for 1622 multicast based discovery, especially for a very large autonomic 1623 network. Centralized registration could be automatically deployed 1624 incrementally. At the very first stage, the repository could be 1625 empty; then it could be filled in by the objectives discovered by 1626 different devices (for example using Dynamic DNS Update). The 1627 more records are stored in the repository, the less the multicast- 1628 based discovery is needed. However, if we adopt such a mechanism, 1629 there would be challenges: stateful solution, and security. 1631 o 5. Need to expand description of the minimum requirements for the 1632 specification of an individual discovery, synchronization or 1633 negotiation objective. 1635 o 6. Use case and protocol walkthrough. A description of how a 1636 node starts up, performs discovery, and conducts negotiation and 1637 synchronisation for a sample use case would help readers to 1638 understand the applicability of this specification. Maybe it 1639 should be an artificial use case or maybe a simple real one. 1640 However, the authors have not yet decided whether to have a 1641 separate document or have it in this document. 1643 o 7. Cross-check against other ANIMA WG documents for consistency 1644 and gaps. 1646 5. Security Considerations 1648 It is obvious that a successful attack on negotiation-enabled nodes 1649 would be extremely harmful, as such nodes might end up with a 1650 completely undesirable configuration that would also adversely affect 1651 their peers. GDNP nodes and messages therefore require full 1652 protection. 1654 - Authentication 1656 A cryptographically authenticated identity for each device is 1657 needed in an autonomic network. It is not safe to assume that a 1658 large network is physically secured against interference or that 1659 all personnel are trustworthy. Each autonomic device should be 1660 capable of proving its identity and authenticating its messages. 1661 GDNP adopts a certificate-based security mechanism to support 1662 authentication and data integrity protection. 1664 The timestamp mechanism provides an anti-replay function. 1666 Since GDNP is intended to be deployed in a single administrative 1667 domain operating its own trust anchor and CA, there is no need for 1668 a trusted public third party. 1670 - Privacy and confidentiality 1672 Generally speaking, no personal information is expected to be 1673 involved in the negotiation protocol, so there should be no direct 1674 impact on personal privacy. Nevertheless, traffic flow paths, 1675 VPNs, etc. could be negotiated, which could be of interest for 1676 traffic analysis. Also, operators generally want to conceal 1677 details of their network topology and traffic density from 1678 outsiders. Therefore, since insider attacks cannot be excluded in 1679 a large network, the security mechanism for the protocol MUST 1680 provide message confidentiality. 1682 - DoS Attack Protection 1684 TBD. 1686 - Security during bootstrap and discovery 1688 A node cannot authenticate GDNP traffic from other nodes until it 1689 has identified the trust anchor and can validate certificates for 1690 other nodes. Also, until it has succesfully enrolled 1691 [I-D.pritikin-anima-bootstrapping-keyinfra] it cannot assume that 1692 other nodes are able to authenticate its own traffic. Therefore, 1693 GDNP discovery during the bootstrap phase for a new device will 1694 inevitably be insecure and GDNP synchronization and negotiation 1695 will be impossible until enrollment is complete. 1697 6. IANA Considerations 1699 Section 3.4 defines the following multicast addresses, which have 1700 been assigned by IANA for use by GDNP: 1702 ALL_GDNP_NEIGHBOR multicast address (IPv6): (TBD1) 1704 ALL_GDNP_NEIGHBOR multicast address (IPv4): (TBD2) 1706 Section 3.4 defines the following UDP and TCP port, which has been 1707 assigned by IANA for use by GDNP: 1709 GDNP Listen Port: (TBD3) 1711 This document defined a new General Discovery and Negotiation 1712 Protocol. The IANA is requested to create a new GDNP registry. The 1713 IANA is also requested to add two new registry tables to the newly- 1714 created GDNP registry. The two tables are the GDNP Messages table 1715 and GDNP Options table. 1717 Initial values for these registries are given below. Future 1718 assignments are to be made through Standards Action or Specification 1719 Required [RFC5226]. Assignments for each registry consist of a type 1720 code value, a name and a document where the usage is defined. 1722 GDNP Messages table. The values in this table are 16-bit unsigned 1723 integers. The following initial values are assigned in Section 3.7 1724 in this document: 1726 Type | Name | RFCs 1727 ---------+-----------------------------+------------ 1728 0 |Reserved | this document 1729 1 |Discovery | this document 1730 2 |Response | this document 1731 3 |Request Message | this document 1732 4 |Negotiation Message | this document 1733 5 |Negotiation-end Message | this document 1734 6 |Confirm-waiting Message | this document 1736 GDNP Options table. The values in this table are 16-bit unsigned 1737 integers. The following initial values are assigned in Section 3.8 1738 and Section 3.9.1 in this document: 1740 Type | Name | RFCs 1741 ---------+-----------------------------+------------ 1742 0 |Reserved | this document 1743 1 |Divert Option | this document 1744 2 |Accept Option | this document 1745 3 |Decline Option | this document 1746 4 |Waiting Time Option | this document 1747 5 |Certificate Option | this document 1748 6 |Signature Option | this document 1749 7 |Device IPv4 Address Option | this document 1750 8 |Device IPv6 Address Option | this document 1751 9 |Device FQDN Option | this document 1752 10~63 |Reserved for future GDNP | 1753 |General Options | 1754 64~127 |Reserved for future GDNP | 1755 |Objective Options | 1756 128~159 |Vendor Specific Options | this document 1757 160~175 |Reserved for future use | 1758 176~191 |Experimental Options | this document 1759 192~65535|Reserved for future use | 1761 The IANA is also requested to create two new registry tables in the 1762 GDNP Parameters registry. The two tables are the Hash Algorithm for 1763 GDNP table and the Signature Algorithm for GDNP table. 1765 Initial values for these registries are given below. Future 1766 assignments are to be made through Standards Action or Specification 1767 Required [RFC5226]. Assignments for each registry consist of a name, 1768 a value and a document where the algorithm is defined. 1770 Hash Algorithm for GDNP. The values in this table are 16-bit 1771 unsigned integers. The following initial values are assigned for 1772 Hash Algorithm for GDNP in this document: 1774 Name | Value | RFCs 1775 ---------------------+-----------+------------ 1776 Reserved | 0x0000 | this document 1777 SHA-1 | 0x0001 | this document 1778 SHA-256 | 0x0002 | this document 1780 Signature Algorithm for GDNP. The values in this table are 16-bit 1781 unsigned integers. The following initial values are assigned for 1782 Signature Algorithm for GDNP in this document: 1784 Name | Value | RFCs 1785 ---------------------+-----------+------------ 1786 Reserved | 0x0000 | this document 1787 RSASSA-PKCS1-v1_5 | 0x0001 | this document 1789 7. Acknowledgements 1791 A major contribution to the original version of this document was 1792 made by Sheng Jiang. 1794 Valuable comments were received from Michael Behringer, Zongpeng Du, 1795 Yu Fu, Zhenbin Li, Dimitri Papadimitriou, Michael Richardson, Markus 1796 Stenberg, Rene Struik, Dacheng Zhang, and other participants in the 1797 NMRG research group and the ANIMA working group. 1799 This document was produced using the xml2rfc tool [RFC2629]. 1801 8. Change log [RFC Editor: Please remove] 1803 draft-carpenter-anima-discovery-negotiation-protocol-02, 2015-02-19: 1805 Tuned requirements to clarify scope, 1807 Clarified relationship between types of objective, 1809 Clarified that objectives may be simple values or complex data 1810 structures, 1812 Improved description of objective options, 1814 Added loop-avoidance mechanisms (loop count and default timeout, 1815 limitations on discovery relaying and on unsolicited responses), 1817 Allow multiple discovery objectives in one response, 1818 Provided for missing or multiple discovery responses, 1820 Indicated how modes such as "dry run" should be supported, 1822 Minor editorial and technical corrections and clarifications, 1824 Reorganized future work list. 1826 draft-carpenter-anima-discovery-negotiation-protocol-01, restructured 1827 the logical flow of the document, updated to describe synchronization 1828 completely, add unsolicited responses, numerous corrections and 1829 clarifications, expanded future work list, 2015-01-06. 1831 draft-carpenter-anima-discovery-negotiation-protocol-00, combination 1832 of draft-jiang-config-negotiation-ps-03 and draft-jiang-config- 1833 negotiation-protocol-02, 2014-10-08. 1835 9. References 1837 9.1. Normative References 1839 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1840 Requirement Levels", BCP 14, RFC 2119, March 1997. 1842 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1843 (SHA1)", RFC 3174, September 2001. 1845 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1846 Requirements for Security", BCP 106, RFC 4086, June 2005. 1848 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1849 Housley, R., and W. Polk, "Internet X.509 Public Key 1850 Infrastructure Certificate and Certificate Revocation List 1851 (CRL) Profile", RFC 5280, May 2008. 1853 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1854 "The Trickle Algorithm", RFC 6206, March 2011. 1856 9.2. Informative References 1858 [I-D.behringer-anima-autonomic-control-plane] 1859 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 1860 Autonomic Control Plane", draft-behringer-anima-autonomic- 1861 control-plane-00 (work in progress), October 2014. 1863 [I-D.chaparadza-intarea-igcp] 1864 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 1865 Mahkonen, "IP based Generic Control Protocol (IGCP)", 1866 draft-chaparadza-intarea-igcp-00 (work in progress), July 1867 2011. 1869 [I-D.eckert-anima-stable-connectivity] 1870 Eckert, T. and M. Behringer, "Autonomic Network Stable 1871 Connectivity", draft-eckert-anima-stable-connectivity-00 1872 (work in progress), October 2014. 1874 [I-D.ietf-dnssd-requirements] 1875 Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 1876 "Requirements for Scalable DNS-SD/mDNS Extensions", draft- 1877 ietf-dnssd-requirements-04 (work in progress), October 1878 2014. 1880 [I-D.ietf-homenet-dncp] 1881 Stenberg, M. and S. Barth, "Distributed Node Consensus 1882 Protocol", draft-ietf-homenet-dncp-00 (work in progress), 1883 January 2015. 1885 [I-D.ietf-homenet-hncp] 1886 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1887 Control Protocol", draft-ietf-homenet-hncp-03 (work in 1888 progress), January 2015. 1890 [I-D.ietf-netconf-restconf] 1891 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1892 Protocol", draft-ietf-netconf-restconf-04 (work in 1893 progress), January 2015. 1895 [I-D.irtf-nmrg-an-gap-analysis] 1896 Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis 1897 for Autonomic Networking", draft-irtf-nmrg-an-gap- 1898 analysis-03 (work in progress), December 2014. 1900 [I-D.irtf-nmrg-autonomic-network-definitions] 1901 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1902 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1903 Networking - Definitions and Design Goals", draft-irtf- 1904 nmrg-autonomic-network-definitions-05 (work in progress), 1905 December 2014. 1907 [I-D.liang-iana-pen] 1908 Liang, P., Melnikov, A., and D. Conrad, "Private 1909 Enterprise Number (PEN) practices and Internet Assigned 1910 Numbers Authority (IANA) registration considerations", 1911 draft-liang-iana-pen-04 (work in progress), July 2014. 1913 [I-D.pritikin-anima-bootstrapping-keyinfra] 1914 Pritikin, M., Behringer, M., and S. Bjarnason, 1915 "Bootstrapping Key Infrastructures", draft-pritikin-anima- 1916 bootstrapping-keyinfra-01 (work in progress), February 1917 2015. 1919 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1920 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1921 Functional Specification", RFC 2205, September 1997. 1923 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 1924 "Service Location Protocol, Version 2", RFC 2608, June 1925 1999. 1927 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1928 June 1999. 1930 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1931 "Remote Authentication Dial In User Service (RADIUS)", RFC 1932 2865, June 2000. 1934 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1935 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1936 Tunnels", RFC 3209, December 2001. 1938 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1939 and M. Carney, "Dynamic Host Configuration Protocol for 1940 IPv6 (DHCPv6)", RFC 3315, July 2003. 1942 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1943 Simple Network Management Protocol (SNMP)", STD 62, RFC 1944 3416, December 2002. 1946 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 1947 Hashes in Internet Protocols", RFC 4270, November 2005. 1949 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1950 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1951 September 2007. 1953 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1954 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1955 May 2008. 1957 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1958 Time Protocol Version 4: Protocol and Algorithms 1959 Specification", RFC 5905, June 2010. 1961 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1962 Signalling Transport", RFC 5971, October 2010. 1964 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1965 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1966 6241, June 2011. 1968 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1969 "Diameter Base Protocol", RFC 6733, October 2012. 1971 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1972 February 2013. 1974 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1975 Discovery", RFC 6763, February 2013. 1977 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1978 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1979 2013. 1981 Appendix A. Capability Analysis of Current Protocols 1983 This appendix discusses various existing protocols with properties 1984 related to the above negotiation and synchronisation requirements. 1985 The purpose is to evaluate whether any existing protocol, or a simple 1986 combination of existing protocols, can meet those requirements. 1988 Numerous protocols include some form of discovery, but these all 1989 appear to be very specific in their applicability. Service Location 1990 Protocol (SLP) [RFC2608] provides service discovery for managed 1991 networks, but requires configuration of its own servers. DNS-SD 1992 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 1993 small networks with a single link layer. 1994 [I-D.ietf-dnssd-requirements] aims to extend this to larger 1995 autonomous networks. However, both SLP and DNS-SD appear to target 1996 primarily application layer services, not the layer 2 and 3 1997 objectives relevant to basic network configuration. 1999 Routing protocols are mainly one-way information announcements. The 2000 receiver makes independent decisions based on the received 2001 information and there is no direct feedback information to the 2002 announcing peer. This remains true even though the protocol is used 2003 in both directions between peer routers; there is state 2004 synchronization, but no negotiation, and each peer runs its route 2005 calculations independently. 2007 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 2008 response model not well suited for peer negotiation. Network 2009 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 2010 does allow positive or negative responses from the target system, but 2011 this is still not adequate for negotiation. 2013 There are various existing protocols that have elementary negotiation 2014 abilities, such as Dynamic Host Configuration Protocol for IPv6 2015 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 2016 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 2017 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 2018 configuration or management protocols. However, they either provide 2019 only a simple request/response model in a master/slave context or 2020 very limited negotiation abilities. 2022 There are also signalling protocols with an element of negotiation. 2023 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 2024 designed for negotiating quality of service parameters along the path 2025 of a unicast or multicast flow. RSVP is a very specialised protocol 2026 aimed at end-to-end flows. However, it has some flexibility, having 2027 been extended for MPLS label distribution [RFC3209]. A more generic 2028 design is General Internet Signalling Transport (GIST) [RFC5971], but 2029 it is complex, tries to solve many problems, and is also aimed at 2030 per-flow signalling across many hops rather than at device-to-device 2031 signalling. However, we cannot completely exclude extended RSVP or 2032 GIST as a synchronization and negotiation protocol. They do not 2033 appear to be directly useable for peer discovery. 2035 We now consider two protocols that are works in progress at the time 2036 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 2037 protocol intended to convey NETCONF information expressed in the YANG 2038 language via HTTP, including the ability to transit HTML 2039 intermediaries. While this is a powerful approach in the context of 2040 centralised configuration of a complex network, it is not well 2041 adapted to efficient interactive negotiation between peer devices, 2042 especially simple ones that are unlikely to include YANG processing 2043 already. 2045 Secondly, we consider Distributed Node Consensus Protocol (DNCP) 2046 [I-D.ietf-homenet-dncp]. This is defined as a generic form of state 2047 synchronization protocol, with a proposed usage profile being the 2048 Home Networking Control Protocol (HNCP) [I-D.ietf-homenet-hncp] for 2049 configuring Homenet routers. 2051 Specific features of DNCP include: 2053 o Every participating node has a unique node identifier. 2055 o DNCP messages are encoded as a sequence of TLV objects, sent over 2056 unicast UDP or TCP, with or without (D)TLS security. 2058 o Multicast, if available, is used only for discovery of DNCP 2059 neighbors when lower security is acceptable. 2061 o Synchronization of state is maintained by the Trickle algorithm. 2062 There is no negotiation capability. 2064 o The HNCP profile of DNCP is designed to operate between directly 2065 connected neighbors on a shared link using UDP and link-local IPv6 2066 addresses. 2068 Clearly DNCP does not meet the needs of a general negotiation 2069 protocol, especially in its HNCP profile due to the limitation to 2070 link-local messages and its strict dependency on IPv6. However, at 2071 the minimum it is a very interesting test case for this style of 2072 interaction between devices without needing a central authority. 2074 A proposal was made some years ago for an IP based Generic Control 2075 Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at 2076 information exchange and negotiation but not directly at peer 2077 discovery. However, it has many points in common with the present 2078 work. 2080 None of the above solutions appears to completely meet the needs of 2081 generic discovery, state synchronization and negotiation in a single 2082 solution. Neither is there an obvious combination of protocols that 2083 does so. Therefore, this document proposes the design of a protocol 2084 that does meet those needs. However, this proposal needs to be 2085 compared with alternatives such as extension and adaptation of GIST 2086 or DNCP, or combination with IGCP. 2088 Authors' Addresses 2089 Brian Carpenter 2090 Department of Computer Science 2091 University of Auckland 2092 PB 92019 2093 Auckland 1142 2094 New Zealand 2096 Email: brian.e.carpenter@gmail.com 2098 Bing Liu 2099 Huawei Technologies Co., Ltd 2100 Q14, Huawei Campus 2101 No.156 Beiqing Road 2102 Hai-Dian District, Beijing 100095 2103 P.R. China 2105 Email: leo.liubing@huawei.com