idnits 2.17.1 draft-carpenter-anima-gdn-protocol-01.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 (January 6, 2015) is 3391 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 (-10) exists of draft-ietf-homenet-hncp-02 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-03 == 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-00 -- 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 (~~), 10 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: July 10, 2015 Huawei Technologies Co., Ltd 6 January 6, 2015 8 A Generic Discovery and Negotiation Protocol for Autonomic Networking 9 draft-carpenter-anima-gdn-protocol-01 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 mutual configurations 16 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 as 20 possible alternatives. 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 July 10, 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 . . . . . . . . . . . . . 6 63 3. GDNP Protocol Overview . . . . . . . . . . . . . . . . . . . 7 64 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 9 66 3.3. GDNP Protocol Basic Properties and Mechanisms . . . . . . 12 67 3.3.1. Discovery Mechanism and Procedures . . . . . . . . . 12 68 3.3.2. Certificate-based Security Mechanism . . . . . . . . 14 69 3.3.3. Negotiation Procedures . . . . . . . . . . . . . . . 17 70 3.3.4. Synchronization Procedure . . . . . . . . . . . . . . 18 71 3.4. GDNP Constants . . . . . . . . . . . . . . . . . . . . . 19 72 3.5. Device Identifier and Certificate Tag . . . . . . . . . . 19 73 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 20 74 3.7. GDNP Messages . . . . . . . . . . . . . . . . . . . . . . 20 75 3.7.1. GDNP Message Format . . . . . . . . . . . . . . . . . 20 76 3.7.2. Discovery Message . . . . . . . . . . . . . . . . . . 21 77 3.7.3. Response Message . . . . . . . . . . . . . . . . . . 21 78 3.7.4. Request Message . . . . . . . . . . . . . . . . . . . 22 79 3.7.5. Negotiation Message . . . . . . . . . . . . . . . . . 22 80 3.7.6. Negotiation-ending Message . . . . . . . . . . . . . 22 81 3.7.7. Confirm-waiting Message . . . . . . . . . . . . . . . 22 82 3.8. GDNP General Options . . . . . . . . . . . . . . . . . . 23 83 3.8.1. Format of GDNP Options . . . . . . . . . . . . . . . 23 84 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 23 85 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 24 86 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 24 87 3.8.5. Waiting Time Option . . . . . . . . . . . . . . . . . 25 88 3.8.6. Certificate Option . . . . . . . . . . . . . . . . . 26 89 3.8.7. Signature Option . . . . . . . . . . . . . . . . . . 26 90 3.8.8. Locator Options . . . . . . . . . . . . . . . . . . . 27 91 3.9. Discovery Objective Option . . . . . . . . . . . . . . . 29 92 3.10. Negotiation and Synchronization Objective Options and 93 Considerations . . . . . . . . . . . . . . . . . . . . . 29 94 3.10.1. Organizing of GDNP Options . . . . . . . . . . . . . 30 95 3.10.2. Vendor Specific Options . . . . . . . . . . . . . . 30 96 3.10.3. Experimental Options . . . . . . . . . . . . . . . . 31 98 3.11. Items for Future Work . . . . . . . . . . . . . . . . . . 31 99 4. Security Considerations . . . . . . . . . . . . . . . . . . . 33 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 101 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 102 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 36 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 105 8.2. Informative References . . . . . . . . . . . . . . . . . 37 106 Appendix A. Capability Analysis of Current Protocols . . . . . . 39 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 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 effected as a special case 132 of negotiation. Section 3.2 describes a behavior model for a 133 protocol intended to support discovery, synchronization and 134 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 bootstrap 150 itself without making any prior assumptions about network structure. 152 Because GDNP can be used to perform a decision process among 153 distributed devices or between networks, it adopts a tight 154 certificate-based security mechanism, which needs a Public Key 155 Infrastructure (PKI) [RFC5280] system. The PKI may be managed by an 156 operator or be autonomic. 158 It is understood that in realistic deployments, not all devices will 159 support GDNP. Such mixed scenarios are not discussed in this 160 specification. 162 2. Requirement Analysis of Discovery, Synchronization and Negotiation 164 This section discusses the requirements for discovery, negotiation 165 and synchronization capabilities. 167 2.1. Requirements for Discovery 169 In an autonomic network we must assume that when a device starts up 170 it has no information about any peer devices. In some cases, when a 171 new user session starts up, the device concerned may again lack 172 information about relevant peer devices. It might be necessary to 173 set up resources on multiple other devices, coordinated and matched 174 to each other so that there is no wasted resource. Security settings 175 might also need updating to allow for the new device or user. 176 Therefore a basic requirement is that there must be a mechanism by 177 which a device can separately discover peer devices for each of the 178 technical objectives that it needs to manage or configure. Some 179 objectives may only be significant on the local link, but others may 180 be significant across the routed network and require off-link 181 operations. Thus, the relevant peer devices might be immediate 182 neighbors on the same layer 2 link or they might be more distant and 183 only accessible via layer 3. The mechanism must therefore support 184 both on-link discovery and off-link discovery of peers that support 185 specific technical objectives. 187 The relevant peer devices may be different for different technical 188 objectives. Therefore discovery needs to be repeated as often as 189 necessary to find peers capable of acting as counterparts for each 190 objective that a discovery initiator needs to handle. In many 191 scenarios, the discovery process may be followed by a synchronization 192 or negotiation process. Therefore, a discovery objective may be 193 associated with one or more synchronization or negotiation 194 objectives. 196 When a device first starts up, it has no knowledge of the network 197 structure. Therefore the discovery process must be able to support 198 any network scenario, assuming only that the device concerned is 199 bootstrapped from factory condition. 201 In some networks, as mentioned above, there will be some hierarchical 202 structure, at least for certain synchronization or negotiation 203 objectives. A special case of discovery is that each device must be 204 able to discover its hierarchical superior for each such objective 205 that it is capable of handling. This is part of the more general 206 requirement to discover off-link devices. 208 During initialisation, a device must be able to discover the 209 appropriate trust anchor, i.e. the appropriate PKI authority. 210 Logically, this is just a specific case of discovery. However, it 211 might be a special case requiring its own solution. In any case, the 212 trust anchor must be discovered before the security environment is 213 completely established. This question requires further study and is 214 the subject of [I-D.pritikin-anima-bootstrapping-keyinfra]. In 215 addition, depending on the type of network involved, discovery of 216 other central functions might be needed, such as the Network 217 Operations Center (NOC) [I-D.eckert-anima-stable-connectivity]. 219 2.2. Requirements for Synchronization and Negotiation Capability 221 We start by considering routing protocols, the closest approximation 222 to autonomic networking in widespread use. Routing protocols use a 223 largely autonomic model based on distributed devices that communicate 224 iteratively with each other. However, routing is mainly based on 225 one-way information synchronization (in either direction), rather 226 than on bi-directional negotiation. The focus is reachability, so 227 current routing protocols only consider simple link status, i.e., up 228 or down. More information, such as latency, congestion, capacity, 229 and particularly unused capacity, would be helpful to get better path 230 selection and utilization rate. Also, autonomic networks need to be 231 able to manage many more dimensions, such as security settings, power 232 saving, load balancing, etc. A basic requirement for the protocol is 233 therefore the ability to represent, discover, synchronize and 234 negotiate almost any kind of network parameter. 236 Human intervention in complex situations is costly and error-prone. 237 Therefore, synchronization or negotiation of parameters without human 238 intervention is desirable whenever the coordination of multiple 239 devices can improve overall network performance. It follows that a 240 requirement for the protocol is to be capable of being installed in 241 any device that would otherwise need human intervention. 243 Human intervention in large networks is often replaced by use of a 244 top-down network management system (NMS). It therefore follows that 245 a requirement for the protocol is to be capable of being installed in 246 any device that would otherwise be managed by an NMS, and that it can 247 co-exist with an NMS. 249 Since the goal is to minimize human intervention, it is necessary 250 that the network can in effect "think ahead" before changing its 251 parameters. In other words there must be a possibility of 252 forecasting the effect of a change. Stated differently, the protocol 253 must be capable of supporting a "dry run" of a changed configuration 254 before actually installing the change. 256 Status information and traffic metrics need to be shared between 257 nodes for dynamic adjustment of resources and for monitoring 258 purposes. While this might be achieved by existing protocols when 259 they are available, the new protocol needs to be able to support 260 parameter exchange, including mutual synchronization, even when no 261 negotiation as such is required. 263 Recovery from faults and identification of faulty devices should be 264 as automatic as possible. The protocol needs to be capable of 265 detecting unexpected events such a negotiation counterpart failing, 266 so that all devices concerned can initiate a recovery process. 268 The protocol needs to be able to deal with a wide variety of 269 technical objectives, covering any type of network parameter. 270 Therefore the protocol will need either an explicit information model 271 describing its messages, or at least a flexible and extensible 272 message format. One design consideration is whether to adopt an 273 existing information model or to design a new one. Another 274 consideration is whether to be able to carry some or all of the 275 message formats used by existing configuration protocols. 277 2.3. Specific Technical Requirements 279 To be a generic platform, the protocol should be IP version 280 independent. In other words, it should be able to run over IPv6 and 281 IPv4. Its messages and general options should be neutral with 282 respect to the IP version. However, some functions, such as 283 multicasting or broadcasting on a link, might need to be IP version 284 dependent. In case of doubt, IPv6 should be preferred. 286 The protocol must be able to access off-link counterparts, i.e., must 287 not be restricted to link-local operation. 289 The negotiation process must be guaranteed to terminate (with success 290 or failure) and if necessary it must contain tie-breaking rules for 291 each technical objective that requires them. 293 Dependencies: In order to decide a configuration on a given device, 294 the device may need information from neighbors. This can be 295 established through the negotiation procedure, or through 296 synchronization if that is sufficient. However, a given item in a 297 neighbor may depend on other information from its own neighbors, 298 which may need another negotiation or synchronization procedure to 299 obtain or decide. Therefore, there are potential dependencies among 300 negotiation or synchronization procedures. Thus, there need to be 301 clear boundaries and convergence mechanisms for these negotiation 302 dependencies. Also some mechanisms are needed to avoid loop 303 dependencies. 305 Policy constraints: There must be provision for general policy intent 306 rules to be applied by all devices in the network (e.g., security 307 rules, prefix length, resource sharing rules). However, policy 308 intent distribution might not use the negotiation protocol itself. 310 Management monitoring, alerts and intervention: Devices should be 311 able to report to a monitoring system. Some events must be able to 312 generate operator alerts and some provision for emergency 313 intervention must be possible (e.g. to freeze synchronization or 314 negotiation in a mis-behaving device). These features may not use 315 the negotiation protocol itself. 317 The protocol needs to be fully secure against forged messages and 318 man-in-the middle attacks, and as secure as reasonably possible 319 against denial of service attacks. It needs to be capable of 320 encryption in order to resist unwanted monitoring, although this 321 capability may not be required in all deployments. 323 3. GDNP Protocol Overview 325 3.1. Terminology 327 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 328 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 329 "OPTIONAL" in this document are to be interpreted as described in 330 [RFC2119] when they appear in ALL CAPS. When these words are not in 331 ALL CAPS (such as "should" or "Should"), they have their usual 332 English meanings, and are not to be interpreted as [RFC2119] key 333 words. 335 The following terms are used throughout this document: 337 o Discovery: a process by which a device discovers peer devices 338 according to a specific discovery objective. The discovery 339 results may be different according to the different discovery 340 objectives. The discovered peer devices may later be used as 341 negotiation counterparts or as sources of synchronization data. 343 o Negotiation: a process by which two (or more) devices interact 344 iteratively to agree on parameter settings that best satisfy the 345 objectives of one or more devices. 347 o State Synchronization: a process by which two (or more) devices 348 interact to agree on the current state of parameter values stored 349 in each device. This is a special case of negotiation in which 350 information is exchanged but the devices do not request their 351 peers to change parameter settings. All other definitions apply 352 to both negotiation and synchronization. 354 o Discovery Objective: a specific network functionality, network 355 element role or type of autonomic service agent (TBD) which the 356 discovery initiator intends to discover. One device may support 357 multiple discovery objectives. A discovery objective may be in 358 one-to-one correspondence with a synchronization objective or a 359 negotiation objective, or it may correspond to a certain group of 360 such objectives. 362 o Discovery Initiator: a device that spontaneously starts discovery 363 by sending a discovery message referring to a specific discovery 364 objective. 366 o Discovery Responder: a peer device which responds to the discovery 367 objective initiated by the discovery initiator. 369 o Synchronization Objective: specific technical content, which needs 370 to be synchronized among a number of devices. It is naturally 371 based on a specific service or function or action. It could be a 372 logical, numeric, or string value or a more complex data 373 structure. 375 o Synchronization Initiator: a device that spontaneously starts 376 synchronization by sending a request message referring to a 377 specific synchronization objective. 379 o Synchronization Responder: a peer device which responds with the 380 value of a synchronization objective. 382 o Negotiation Objective: specific technical content, which needs to 383 be decided in coordination with another network device. It is 384 naturally based on a specific service or function or action. It 385 could be a logical, numeric, or string value or a more complex 386 data structure. 388 o Negotiation Initiator: a device that spontaneously starts 389 negotiation by sending a request message referring to a specific 390 negotiation objective. 392 o Negotiation Counterpart: a peer device with which the Negotiation 393 Initiator negotiates a specific negotiation objective. 395 o Device Identifier: a public key, which identifies the device in 396 GDNP messages. It is assumed that its associated private key is 397 maintained in the device only. 399 o Device Certificate: A certificate for a single device, also the 400 identifier of the device, further described in Section 3.5. 402 o Device Certificate Tag: a tag, which is bound to the device 403 identifier. It is used to present a Device Certificate in short 404 form. 406 3.2. High-Level Design Choices 408 This section describes a behavior model and some considerations for 409 designing a generic discovery, synchronization and negotiation 410 protocol, which can act as a platform for different technical 411 objectives. 413 NOTE: This protocol is described here in a stand-alone fashion as a 414 proof of concept. An elementary version has been prototyped by 415 Huawei and the Beijing University of Posts and Telecommunications. 416 However, this is not yet a definitive proposal for IETF adoption. In 417 particular, adaptation and extension of one of the protocols 418 discussed in Appendix A might be an option. Also, the security model 419 outlined below would in practice be part of a general security 420 mechanism in an autonomic control plane 421 [I-D.behringer-anima-autonomic-control-plane]. This whole 422 specification is subject to change as a result. 424 o A generic platform 426 The protocol is designed as a generic platform, which is 427 independent from the synchronization or negotiation contents. It 428 takes care of the general intercommunication between counterparts. 429 The technical contents will vary according to the various 430 synchronization or negotiation objectives and the different pairs 431 of counterparts. 433 o Security infrastructure and trust relationship 435 Because this negotiation protocol may directly cause changes to 436 device configurations and bring significant impacts to a running 437 network, this protocol is based on a restrictive security 438 infrastructure, allowing it to be trusted and monitored so that 439 every device in this negotiation system behaves well and remains 440 well protected. 442 On the other hand, a limited negotiation model might be deployed 443 based on a limited trust relationship. For example, between two 444 administrative domains, devices might also exchange limited 445 information and negotiate some particular configurations based on 446 a limited conventional or contractual trust relationship. 448 o Discovery, synchronization and negotiation designed together 450 The discovery method and the synchronization and negotiation 451 methods are designed in the same way and can be combined when this 452 is useful. These processes can also be performed independently 453 when appropriate. 455 o A uniform pattern for technical contents 457 The synchronization and negotiation contents are defined according 458 to a uniform pattern. They could be carried either in TLV (Type, 459 Length and Value) format or in payloads described by a flexible 460 language. The initial protocol design uses the TLV approach. The 461 format is extensible for unknown future requirements. 463 o A conservative model for synchronization 465 Synchronization across a number of nodes is not a new problem and 466 the Trickle model that is already known to be effective and 467 efficient is adopted. 469 o A simple initiator/responder model for negotiation 471 Multi-party negotiations are too complicated to be modeled and 472 there might be too many dependencies among the parties to converge 473 efficiently. A simple initiator/responder model is more feasible 474 and can complete multiple-party negotiations by indirect steps. 476 o Organizing of synchronization or negotiation content 478 Naturally, the technical content will be organized according to 479 the relevant function or service. The content from different 480 functions or services is kept independent from each other. They 481 are not combined into a single option or single session because 482 these contents may be negotiated or synchronized with different 483 counterparts or may be different in response time. 485 o Self aware network device 487 Every network device will be pre-loaded with various functions and 488 be aware of its own capabilities, typically decided by the 489 hardware, firmware or pre-installed software. Its exact role may 490 depend on the surrounding network behaviors, which may include 491 forwarding behaviors, aggregation properties, topology location, 492 bandwidth, tunnel or translation properties, etc. The surrounding 493 topology will depend on the network planning. Following an 494 initial discovery phase, the device properties and those of its 495 neighbors are the foundation of the synchronization or negotiation 496 behavior of a specific device. A device has no pre-configuration 497 for the particular network in which it is installed. 499 o Requests and responses in negotiation procedures 501 The initiator can negotiate with its relevant negotiation 502 counterpart devices, which may be different according to the 503 specific negotiation objective. It can request relevant 504 information from the negotiation counterpart so that it can decide 505 its local configuration to give the most coordinated performance. 506 It can request the negotiation counterpart to make a matching 507 configuration in order to set up a successful communication with 508 it. It can request certain simulation or forecast results by 509 sending some dry run conditions. 511 Beyond the traditional yes/no answer, the responder can reply with 512 a suggested alternative if its answer is 'no'. This would start a 513 bi-directional negotiation ending in a compromise between the two 514 devices. 516 o Convergence of negotiation procedures 518 To enable convergence, when a responder makes a suggestion of a 519 changed condition in a negative reply, it should be as close as 520 possible to the original request or previous suggestion. The 521 suggested value of the third or later negotiation steps should be 522 chosen between the suggested values from the last two negotiation 523 steps. In any case there must be a mechanism to guarantee 524 convergence (or failure) in a small number of steps, such as a 525 timeout or maximum number of iterations. 527 * End of negotiation 529 A limited number of rounds, for example three, or a timeout, is 530 needed on each device for each negotiation objective. It may 531 be an implementation choice, a pre-configurable parameter, or a 532 network-wide policy intent. These choices might vary between 533 different types of autonomic service agent. Therefore, the 534 definition of each negotiation objective MUST clearly specify 535 this, so that the negotiation can always be terminated 536 properly. 538 * Failed negotiation 540 There must be a well-defined procedure for concluding that a 541 negotiation cannot succeed, and if so deciding what happens 542 next (deadlock resolution, tie-breaking, or revert to best- 543 effort service). Again, this MUST be specified for individual 544 negotiation objectives, as an implementation choice, a pre- 545 configurable parameter, or a network-wide policy intent. 547 3.3. GDNP Protocol Basic Properties and Mechanisms 549 3.3.1. Discovery Mechanism and Procedures 551 o Separated discovery and negotiation mechanisms 553 Although discovery and negotiation or synchronization are 554 defined together in the GDNP, they are separated mechanisms. 555 The discovery process could run independently from the 556 negotiation or synchronization process. Upon receiving a 557 discovery (Section 3.7.2) or request (Section 3.7.4) message, 558 the recipient device should return a message in which it either 559 indicates itself as a discovery responder or diverts the 560 initiator towards another more suitable device. 562 The discovery objective could be network functionalities, role- 563 based network elements or service agents (TBD). The discovery 564 results could be utilized by the negotiation protocol to decide 565 which device the initiator will negotiate with. 567 o Discovery Procedures 569 Discovery starts as on-link operation. The Divert option can 570 tell the discovery initiator to contact an off-link discovery 571 objective device. Every DISCOVERY message is sent by a 572 discovery initiator to the ALL_GDNP_NEIGHBOR multicast address 573 (Section 3.4). Every network device that supports the GDNP 574 always listens to a well-known transport port to capture the 575 discovery messages. 577 If the neighbor device supports the requested discovery 578 objective, it MAY respond with a Response message 579 (Section 3.7.3) with locator option(s). Otherwise, if the 580 neigbor device has cached information about a device that 581 supports the requested discovery objective (usually because it 582 discovered the same objective before), it SHOULD respond with a 583 Response message with a Divert option pointing to the 584 appropriate Discovery Responder. 586 After a GDNP device successfully discovers a Discovery 587 Responder supporting a specific objective, it MUST cache this 588 information. This cache record MAY be used for future 589 negotiation or synchronization, and SHOULD be passed on when 590 appropriate as a Divert option to another Discovery Initiator. 592 A GDNP device with multiple link-layer interfaces (typically a 593 router) MUST support discovery on all interfaces. If it 594 receives a DISCOVERY message on a given interface for a 595 specific objective that it does not support and for which it 596 has not previously discovered a Discovery Responder, it MUST 597 relay the query by re-issuing the same DISCOVERY message on its 598 other interfaces. Togther with the caching mechanism, this 599 should be sufficient to support most network bootstrapping 600 scenarios. 602 o A complete discovery process will start with multicast on the 603 local link; a neighbor might divert it to an off-link destination, 604 which could be a default higher-level gateway in a hierarchical 605 network. Then discovery would continue with a unicast to that 606 gateway; if that gateway is still not the right counterpart, it 607 should divert to another device, which is in principle closer to 608 the right counterpart. Finally the right counterpart responds to 609 start the negotiation or synchronization process. 611 o Rapid Mode (Discovery/Negotiation binding) 613 A Discovery message MAY include one or more Negotiation 614 Objective option(s). This allows a rapid mode of negotiation 615 described in Section 3.3.3. A similar mechanism is defined for 616 synchronization. 618 3.3.2. Certificate-based Security Mechanism 620 A certificate-based security mechanism provides security properties 621 for GDNP: 623 o the identity of a GDNP message sender can be verified by a 624 recipient. 626 o the integrity of a GDNP message can be checked by the recipient of 627 the message. 629 o anti-replay protection can be assured by the GDNP message 630 recipient. 632 The authority of the GDNP message sender depends on a Public Key 633 Infrastructure (PKI) system with a Certification Authority (CA), 634 which should normally be run by the network operator. In the case of 635 a network with no operator, such as a small office or home network, 636 the PKI itself needs to be established by an autonomic process, which 637 is out of scope for this specification. 639 A Request message MUST carry a Certificate option, defined in 640 Section 3.8.6. The first Negotiation Message, responding to a 641 Request message, SHOULD also carry a Certificate option. Using these 642 messages, recipients build their certificate stores, indexed by the 643 Device Certificate Tags included in every GDNP message. This process 644 is described in more detail below. 646 Every message MUST carry a signature option (Section 3.8.7). 648 For now, the authors do not think packet size is a problem. In this 649 GDNP specification, there SHOULD NOT be multiple certificates in a 650 single message. The current most used public keys are 1024/2048 651 bits; some may reach 4096. With overhead included, a single 652 certificate is less than 500 bytes. Messages are expected to be far 653 shorter than the normal packet MTU within a modern network. 655 3.3.2.1. Support for algorithm agility 657 Hash functions are used to provide message integrity checks. In 658 order to provide a means of addressing problems that may emerge in 659 the future with existing hash algorithms, as recommended in 660 [RFC4270], a mechanism for negotiating the use of more secure hashes 661 in the future is provided. 663 In addition to hash algorithm agility, a mechanism for signature 664 algorithm agility is also provided. 666 The support for algorithm agility in this document is mainly a 667 unilateral notification mechanism from sender to recipient. If the 668 recipient does not support the algorithm used by the sender, it 669 cannot authenticate the message. Senders in a single administrative 670 domain are not required to upgrade to a new algorithm simultaneously. 672 So far, the algorithm agility is supported by one-way notification, 673 rather than negotiation mode. As defined in Section 3.8.7, the 674 sender notifies the recipient what hash/signature algorithms it uses. 675 If the responder doesn't know a new algorithm used by the sender, the 676 negotiation request would fail. In order to establish a negotiation 677 session, the sender MAY fall back to an older, less preferred 678 algorithm. Certificates and network policy intent SHOULD limit the 679 choice of algorithms. 681 3.3.2.2. Message validation on reception 683 When receiving a GDNP message, a recipient MUST discard the GDNP 684 message if the Signature option is absent, or the Certificate option 685 is in a Request Message. 687 For the Request message and the Response message with a Certification 688 Option, the recipient MUST first check the authority of this sender 689 following the rules defined in [RFC5280]. After successful authority 690 validation, an implementation MUST add the sender's certification 691 into the local trust certificate record indexed by the associated 692 Device Certificate Tag (Section 3.5). 694 The recipient MUST now authenticate the sender by verifying the 695 Signature and checking a timestamp, as specified in Section 3.3.2.3. 696 The order of two procedures is left as an implementation decision. 697 It is RECOMMENDED to check timestamp first, because signature 698 verification is much more computationally expensive. 700 The signature field verification MUST show that the signature has 701 been calculated as specified in Section 3.8.7. The public key used 702 for signature validation is obtained from the certificate either 703 carried by the message or found from a local trust certificate record 704 by searching the message-carried Device Certificate Tag. 706 Only the messages that get through both the signature verifications 707 and timestamp check are accepted and continue to be handled for their 708 contained GDNP options. Messages that do not pass the above tests 709 MUST be discarded as insecure messages. 711 3.3.2.3. TimeStamp checking 713 Recipients SHOULD be configured with an allowed timestamp Delta 714 value, a "fuzz factor" for comparisons, and an allowed clock drift 715 parameter. The recommended default value for the allowed Delta is 716 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 717 drift, 0.01 second. 719 The timestamp is defined in the Signature Option, Section 3.8.7. To 720 facilitate timestamp checking, each recipient SHOULD store the 721 following information for each sender: 723 o The receive time of the last received and accepted GDNP message. 724 This is called RDlast. 726 o The time stamp in the last received and accepted GDNP message. 727 This is called TSlast. 729 An accepted GDNP message is any successfully verified (for both 730 timestamp check and signature verification) GDNP message from the 731 given peer. It initiates the update of the above variables. 732 Recipients MUST then check the Timestamp field as follows: 734 o When a message is received from a new peer (i.e., one that is not 735 stored in the cache), the received timestamp, TSnew, is checked, 736 and the message is accepted if the timestamp is recent enough to 737 the reception time of the packet, RDnew: 739 -Delta < (RDnew - TSnew) < +Delta 741 The RDnew and TSnew values SHOULD be stored in the cache as RDlast 742 and TSlast. 744 o When a message is received from a known peer (i.e., one that 745 already has an entry in the cache), the timestamp is checked 746 against the previously received GDNP message: 748 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 750 If this inequality does not hold, the recipient SHOULD silently 751 discard the message. If, on the other hand, the inequality holds, 752 the recipient SHOULD process the message. 754 Moreover, if the above inequality holds and TSnew > TSlast, the 755 recipient SHOULD update RDlast and TSlast. Otherwise, the 756 recipient MUST NOT update RDlast or TSlast. 758 An implementation MAY use some mechanism such as a timestamp cache to 759 strengthen resistance to replay attacks. When there is a very large 760 number of nodes on the same link, or when a cache filling attack is 761 in progress, it is possible that the cache holding the most recent 762 timestamp per sender will become full. In this case, the node MUST 763 remove some entries from the cache or refuse some new requested 764 entries. The specific policy as to which entries are preferred over 765 others is left as an implementation decision. 767 3.3.3. Negotiation Procedures 769 A negotiation initiator sends a negotiation request to counterpart 770 devices, which may be different according to different negotiation 771 objectives. It may request relevant information from the negotiation 772 counterpart so that it can decide its local configuration to give the 773 most coordinated performance. This would be sufficient in a case 774 where the required function is limited to state synchronization. It 775 may additionally request the negotiation counterpart to make a 776 matching configuration in order to set up a successful communication 777 with it. It may request a certain simulation or forecast result by 778 sending some dry run conditions. The details, including the 779 distinction between dry run and an actual configuration change, will 780 be defined separately for each type of negotiation objective. 782 If the counterpart can immediately apply the requested configuration, 783 it will give an immediate positive (accept) answer. This will end 784 the negotiation phase immediately. Otherwise, it will negotiate. It 785 will reply with a proposed alternative configuration that it can 786 apply (typically, a configuration that uses fewer resources than 787 requested by the negotiation initiator). This will start a bi- 788 directional negotiation to reach a compromise between the two network 789 devices. 791 The negotiation procedure is ended when one of the negotiation peers 792 sends a Negotiation Ending message, which contains an accept or 793 decline option and does not need a response from the negotiation 794 peer. 796 A negotiation procedure concerns one objective and one counterpart. 797 Both the initiator and the counterpart may take part in simultaneous 798 negotiations with various other devices, or in simultaneous 799 negotiations about different objectives. Thus, GDNP is expected to 800 be used in a multi-threaded mode. Certain negotiation objectives may 801 have restrictions on multi-threading, for example to avoid over- 802 allocating resources. 804 Rapid Mode (Discovery/Negotiation linkage) 805 A Discovery message MAY include one or more Negotiation Objective 806 option(s). In this case the Discovery message also acts as a 807 Request message to indicate to the Discovery Responder that it 808 could directly reply to the Discovery Initiator with a Negotiation 809 message for rapid processing, if the discovery objective could act 810 as the corresponding negotiation counterpart. However, the 811 indication is only advisory not prescriptive. 813 This rapid mode could reduce the interactions between nodes so 814 that a higher efficiency could be achieved. This rapid 815 negotiation function SHOULD be configured off by default and MAY 816 be configured on or off by policy intent. 818 3.3.4. Synchronization Procedure 820 A synchronization initiator sends a synchronization request to 821 counterpart devices, which may be different according to different 822 synchronization objectives. The counterpart responds with a Response 823 message containing the current value(s) of the requested 824 synchronization objective. No further messages are needed, but 825 otherwise the procedure operates as a subset of the negotiation 826 procedure. If no Response message is received, the synchronization 827 request MAY be repeated after a suitable timeout. 829 A synchronization responder MAY send an unsolicited Response message 830 containing a synchronization objective, if and only if the 831 specification of this objective permits it. This MAY be sent as a 832 multicast message to the ALL_GDNP_NEIGHBOR multicast address 833 (Section 3.4). In this case the Trickle algorithm [RFC6206] MUST be 834 used to avoid excessive multicast traffic. The parameters Imin, Imax 835 and k of the Trickle algorithm will be specified as part of the 836 specification of the synchronization objective concerned. 838 Rapid Mode (Discovery/Synchronization linkage) 840 A Discovery message MAY include one or more Synchronization 841 Objective option(s). In this case the Discovery message also acts 842 as a Request message to indicate to the Discovery Responder that 843 it could directly reply to the Discovery Initiator with a Response 844 message with synchronization data for rapid processing, if the 845 discovery target supports the corresponding synchronization 846 objective. However, the indication is only advisory not 847 prescriptive. 849 This rapid mode could reduce the interactions between nodes so 850 that a higher efficiency could be achieved. This rapid 851 synchronization function SHOULD be configured off by default and 852 MAY be configured on or off by policy intent. 854 3.4. GDNP Constants 856 o ALL_GDNP_NEIGHBOR (TBD1) 858 A link-local scope multicast address used by a GDNP-enabled device 859 to discover GDNP-enabled neighbor (i.e., on-link) devices . All 860 devices that support GDNP are members of this multicast group. 862 * IPv6 multicast address: TBD1 864 * IPv4 multicast address: TBD2 866 o GDNP Listen Port (TBD3) 868 A UDP port that every GDNP-enabled network device always listens 869 to. 871 3.5. Device Identifier and Certificate Tag 873 A GDNP-enabled Device MUST generate a stable public/private key pair 874 before it participates in GDNP. There MUST NOT be any way of 875 accessing the private key via the network or an operator interface. 876 The device then uses the public key as its identifier, which is 877 cryptographic in nature. It is a GDNP unique identifier for a GDNP 878 participant. 880 It then gets a certificate for this public key, signed by a 881 Certificate Authority that is trusted by other network devices. The 882 Certificate Authority SHOULD be managed within the local 883 administrative domain, to avoid needing to trust a third party. The 884 signed certificate would be used for authentication of the message 885 sender. In a managed network, this certification process could be 886 performed at a central location before the device is physically 887 installed at its intended location. In an unmanaged network, this 888 process must be autonomic, including the bootstrap phase. 890 A 128-bit Device Certifcate Tag, which is generated by taking a 891 cryptographic hash over the device certificate, is a short 892 presentation for GDNP messages. It is the index key to find the 893 device certificate in a recipient's local trusted certificate record. 895 The tag value is formed by taking a SHA-1 hash algorithm [RFC3174] 896 over the corresponding device certificate and taking the leftmost 128 897 bits of the hash result. 899 3.6. Session Identifier (Session ID) 901 A 24-bit opaque value used to distinguish multiple sessions between 902 the same two devices. A new Session ID MUST be generated for every 903 new Discovery or Request message, and for every unsolicited Response 904 message. All follow-up messages in the same discovery, 905 synchronization or negotiation procedure, which is initiated by the 906 request message, MUST carry the same Session ID. 908 The Session ID SHOULD have a very low collision rate locally. It is 909 RECOMMENDED to be generated by a pseudo-random algorithm using a seed 910 which is unlikely to be used by any other device in the same network 911 [RFC4086]. 913 3.7. GDNP Messages 915 This document defines the following GDNP message format and types. 916 Message types not listed here are reserved for future use. The 917 numeric encoding for each message type is shown in parentheses. 919 3.7.1. GDNP Message Format 921 All GDNP messages share an identical fixed format header and a 922 variable format area for options. Every Message carries the Device 923 Certificate Tag of its sender and a Session ID. Options are 924 presented serially in the options field, with no padding between the 925 options. Options are byte-aligned. 927 The following diagram illustrates the format of GDNP messages: 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | MESSAGE_TYPE | Session ID | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | | 935 | Device Certificate Tag | 936 | | 937 | | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Options (variable length) | 940 . . 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 MESSAGE_TYPE: Identifies the GDNP message type. 8-bit. 945 Session ID: Identifies this negotiation session, as defined in 946 Section 3.6. 24-bit. 948 Device Certificate Tag: Represents the Device Certificate, which 949 identifies the negotiation devices, as defined in Section 3.5. 950 The Device Certificate Tag is 128 bit, also defined in 951 Section 3.5. It is used as index key to find the device 952 certificate. 954 Options: GDNP Options carried in this message. Options are defined 955 starting at Section 3.8. 957 3.7.2. Discovery Message 959 DISCOVERY (MESSAGE_TYPE = 1): 961 A discovery initiator sends a DISCOVERY message to initiate a 962 discovery process. 964 The discovery initiator sends the DISCOVERY messages to the link- 965 local ALL_GDNP_NEIGHBOR multicast address for discovery, and stores 966 the discovery results (including responding discovery objectives and 967 corresponding unicast addresses or FQDNs). 969 A DISCOVERY message MUST include a discovery objective option 970 (Section 3.9). 972 A DISCOVERY message MAY include one or more negotiation objective 973 option(s) (Section 3.10) to indicate to the discovery objective that 974 it could directly return to the discovery initiatior with a 975 Negotiation message for rapid processing, if the discovery objective 976 could act as the corresponding negotiation counterpart, and similarly 977 for synchronization. 979 3.7.3. Response Message 981 RESPONSE (MESSAGE_TYPE = 2): 983 A node which receives a DISCOVERY message sends a Response message to 984 respond to a discovery. It MUST contain the same Session ID as the 985 DISCOVERY message. It MAY include a copy of the discovery objective 986 from the DISCOVERY message. 988 If the responding node supports the discovery objective of the 989 discovery, it MUST include at least one kind of locator option 990 (Section 3.8.8) to indicate its own location. A combination of 991 multiple kinds of locator options (e.g. IP address option + FQDN 992 option) is also valid. 994 If the responding node itself does not support the discovery 995 objective, but it knows the locator of the discovery objective, then 996 it SHOULD respond to the discovery message with a divert option 997 (Section 3.8.2) embedding a locator option or a combination of 998 multiple kinds of locator options which indicate the locator(s) of 999 the discovery objective. 1001 A node which receives a synchronization request sends a Response 1002 message with the synchronization data. A node MAY send an 1003 unsolicited Response Message with synchronization data and this MAY 1004 be sent to the link-local ALL_GDNP_NEIGHBOR multicast address. 1006 If the response contains synchronization data, this will be in the 1007 form of a GDNP Option for the specific synchronization objective. 1009 3.7.4. Request Message 1011 REQUEST (MESSAGE_TYPE = 3): 1013 A negotiation or synchronization requesting node sends the REQUEST 1014 message to the unicast address (directly stored or resolved from the 1015 FQDN) of the negotiation or synchronization counterpart (selected 1016 from the discovery results). 1018 A request message MUST include the relevant objective option, with 1019 the requested value in the case of negotiation. 1021 3.7.5. Negotiation Message 1023 NEGOTIATION (MESSAGE_TYPE = 4): 1025 A negotiation counterpart sends a NEGOTIATION message in response to 1026 a REQUEST message, a NEGOTIATION message, or a DISCOVERY message in 1027 Rapid Mode. A negotiation process MAY include multiple steps. 1029 3.7.6. Negotiation-ending Message 1031 NEGOTIATION-ENDING (MESSAGE_TYPE = 5): 1033 A negotiation counterpart sends an NEGOTIATION-ENDING message to 1034 close the negotiation. It MUST contain one, but only one of accept/ 1035 decline option, defined in Section 3.8.3 and Section 3.8.4. It could 1036 be sent either by the requesting node or the responding node. 1038 3.7.7. Confirm-waiting Message 1040 CONFIRM-WAITING (MESSAGE_TYPE = 6): 1042 A responding node sends a CONFIRM-WAITING message to indicate the 1043 requesting node to wait for a further negotiation response. It might 1044 be that the local process needs more time or that the negotiation 1045 depends on another triggered negotiation. This message MUST NOT 1046 include any other options than the Waiting Time Option 1047 (Section 3.8.5). 1049 3.8. GDNP General Options 1051 This section defines the GDNP general option for the negotiation and 1052 synchronization protocol signalling. Option types 10~63 are reserved 1053 for GDNP general options defined in the future. 1055 3.8.1. Format of GDNP Options 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | option-code | option-len | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | option-data | 1063 | (option-len octets) | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 Option-code: An unsigned integer identifying the specific option 1067 type carried in this option. 1069 Option-len: An unsigned integer giving the length of the option-data 1070 field in this option in octets. 1072 Option-data: The data for the option; the format of this data 1073 depends on the definition of the option. 1075 GDNP options are scoped by using encapsulation. If an option 1076 contains other options, the outer Option-len includes the total size 1077 of the encapsulated options, and the latter apply only to the outer 1078 option. 1080 3.8.2. Divert Option 1082 The divert option is used to redirect a GDNP request to another node, 1083 which may be more appropriate for the intended negotiation or 1084 synchronization. It may redirect to an entity that is known as a 1085 specific negotiation or synchronization counterpart (on-link or off- 1086 link) or a default gateway. The divert option MUST only be 1087 encapsulated in Response messages. If found elsewhere, it SHOULD be 1088 silently ignored. 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | OPTION_DIVERT | option-len | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Locator Option(s) of Diversion Device(s) | 1096 . . 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 Option-code: OPTION_DIVERT (1). 1101 Option-len: The total length of diverted destination sub-option(s) 1102 in octets. 1104 Locator Option(s) of Diversion Device(s): Embedded Locator Option(s) 1105 (Section 3.8.8) that point to diverted destination device(s). 1107 3.8.3. Accept Option 1109 The accept option is used to indicate to the negotiation counterpart 1110 that the proposed negotiation content is accepted. 1112 The accept option MUST only be encapsulated in Negotiation-ending 1113 messages. If found elsewhere, it SHOULD be silently ignored. 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | OPTION_ACCEPT | option-len | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 Option-code: OPTION_ACCEPT (2) 1123 Option-len: 0 1125 3.8.4. Decline Option 1127 The decline option is used to indicate to the negotiation counterpart 1128 the proposed negotiation content is declined and end the negotiation 1129 process. 1131 The decline option MUST only be encapsulated in Negotiation-ending 1132 messages. If found elsewhere, it SHOULD be silently ignored. 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_DECLINE | option-len | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 Option-code: OPTION_DECLINE (3) 1142 Option-len: 0 1144 Notes: there are scenarios where a negotiation counterpart wants to 1145 decline the proposed negotiation content and continue the negotiation 1146 process. For these scenarios, the negotiation counterpart SHOULD use 1147 a Response message, with either an objective option that contains at 1148 least one data field with all bits set to 1 to indicate a meaningless 1149 initial value, or a specific objective option that provides further 1150 conditions for convergence. 1152 3.8.5. Waiting Time Option 1154 The waiting time option is used to indicate that the negotiation 1155 counterpart needs to wait for a further negotiation response, since 1156 the processing might need more time than usual or it might depend on 1157 another triggered negotiation. 1159 The waiting time option MUST only be encapsulated in Confirm-waiting 1160 messages. If found elsewhere, it SHOULD be silently ignored. 1162 The counterpart SHOULD send a Response message or another Confirm- 1163 waiting message before the current waiting time expires. If not, the 1164 initiator SHOULD abandon or restart the negotiation procedure, to 1165 avoid an indefinite wait. 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_WAITING | option-len | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Time | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 Option-code: OPTION_WAITING (4) 1177 Option-len: 4, in octets 1179 Time: Time in milliseconds 1181 3.8.6. Certificate Option 1183 The Certificate option carries the certificate of the sender. The 1184 format of the Certificate option is as follows: 1186 0 1 2 3 1187 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 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | OPTION Certificate | option-len | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | | 1192 . Certificate (variable length) . 1193 . . 1194 | | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Option-code: OPTION_CERT_PARAMETER (5) 1199 Option-len: Length of certificate in octets 1201 Public key: A variable-length field containing a certificate 1203 3.8.7. Signature Option 1205 The Signature option allows public key-based signatures to be 1206 attached to a GDNP message. The Signature option is REQUIRED in 1207 every GDNP message and could be any place within the GDNP message. 1208 It protects the entire GDNP header and options. A TimeStamp has been 1209 integrated in the Signature Option for anti-replay protection. The 1210 format of the Signature option is described as follows: 1212 0 1 2 3 1213 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 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | OPTION_SIGNATURE | option-len | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | HA-id | SA-id | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Timestamp (64-bit) | 1220 | | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | | 1223 . Signature (variable length) . 1224 . . 1225 | | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 Option-code: OPTION_SIGNATURE (6) 1229 Option-len: 12 + Length of Signature field in octets. 1231 HA-id: Hash Algorithm id. The hash algorithm is used for computing 1232 the signature result. This design is adopted in order to provide 1233 hash algorithm agility. The value is from the Hash Algorithm for 1234 GDNP registry in IANA. The initial value assigned for SHA-1 is 1235 0x0001. 1237 SA-id: Signature Algorithm id. The signature algorithm is used for 1238 computing the signature result. This design is adopted in order 1239 to provide signature algorithm agility. The value is from the 1240 Signature Algorithm for GDNP registry in IANA. The initial value 1241 assigned for RSASSA-PKCS1-v1_5 is 0x0001. 1243 Timestamp: The current time of day (NTP-format timestamp [RFC5905] 1244 in UTC (Coordinated Universal Time), a 64-bit unsigned fixed-point 1245 number, in seconds relative to 0h on 1 January 1900.). It can 1246 reduce the danger of replay attacks. 1248 Signature: A variable-length field containing a digital signature. 1249 The signature value is computed with the hash algorithm and the 1250 signature algorithm, as described in HA-id and SA-id. The 1251 signature constructed by using the sender's private key protects 1252 the following sequence of octets: 1254 1. The GDNP message header. 1256 2. All GDNP options including the Signature option (fill the 1257 signature field with zeroes). 1259 The signature field MUST be padded, with all 0, to the next 16 bit 1260 boundary if its size is not an even multiple of 8 bits. The 1261 padding length depends on the signature algorithm, which is 1262 indicated in the SA-id field. 1264 3.8.8. Locator Options 1266 These locator options are used to present a device's or interface's 1267 reachability information. They are Locator IPv4 Address Option, 1268 Locator IPv6 Address Option and Locator FQDN (Fully Qualified Domain 1269 Name) Option. 1271 3.8.8.1. Locator IPv4 address option 1272 0 1 2 3 1273 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 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | OPTION_LOCATOR_IPV4ADDR | option-len | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | IPv4-Address | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 Option-code: OPTION_LOCATOR_IPV4ADDR (7) 1282 Option-len: 4, in octets 1284 IPv4-Address: The IPv4 address locator of the device/interface 1286 3.8.8.2. Locator IPv6 address option 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | OPTION_LOCATOR_IPV6ADDR | option-len | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | | 1294 | IPv6-Address | 1295 | | 1296 | | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 Option-code: OPTION_LOCATOR_IPV6ADDR (8) 1301 Option-len: 16, in octets 1303 IPv6-Address: The IPv6 address locator of the device/interface 1305 Note: A link-local IPv6 address MUST NOT be used when this option is 1306 used within the Divert option. 1308 3.8.8.3. Locator FQDN option 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | OPTION_FQDN | option-len | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Fully Qualified Domain Name | 1316 | (variable length) | 1317 . . 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 Option-code: OPTION_FQDN (9) 1321 Option-len: Length of Fully Qualified Domain Name in octets 1323 Domain-Name: The Fully Qualified Domain Name of the entity 1325 3.9. Discovery Objective Option 1327 The discovery objective option is to express the discovery objectives 1328 that the initiating node wants to discover and to confirm them in a 1329 Response message. 1331 0 1 2 3 1332 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 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | OPTION_DISOBJ | option-len | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Expression of Discovery Objectives (TBD) | 1337 . . 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 Option-code: OPTION_DISOBJ (TBD) 1342 Option-len: The total length in octets 1344 Expression of Discovery Objectives (TBD): This field is to express 1345 the discovery objectives that the initiating node wants to 1346 discover. It might be network functionality, role-based network 1347 element or service agent. 1349 3.10. Negotiation and Synchronization Objective Options and 1350 Considerations 1352 Negotiation and Synchronization Objective Options MUST be assigned an 1353 option type greater than 64 in the GDNP option table. 1355 The Negotiation Objective Options contain negotiation objectives, 1356 which are various according to different functions/services. They 1357 MUST be carried by Discovery, Request or Negotiation Messages only. 1359 For most scenarios, there SHOULD be initial values in the negotiation 1360 requests. Consequently, the Negotiation Objective options SHOULD 1361 always be completely presented in a Request message,or in a Discovery 1362 message in rapid mode. If there is no initial value, the bits in the 1363 value field SHOULD all be set to 1 to indicate a meaningless value, 1364 unless this is inappropriate for the specific negotiation objective. 1366 Synchronization Objective Options are similar, but MUST be carried by 1367 Discovery, Request or Response messages only. They include value 1368 fields only in Response messages. 1370 3.10.1. Organizing of GDNP Options 1372 Naturally, a negotiation objective, which is based on a specific 1373 service or function or action, SHOULD be organized as a single GDNP 1374 option. It is NOT RECOMMENDED to organize multiple negotiation 1375 objectives into a single option. 1377 A negotiation objective may have multiple parameters. Parameters can 1378 be categorized into two class: the obligatory ones presented as fixed 1379 fields; and the optional ones presented in TLV sub-options. It is 1380 NOT RECOMMENDED to split parameters in a single objective into 1381 multiple options, unless they have different response periods. An 1382 exception scenario may also be described by split objectives. 1384 3.10.2. Vendor Specific Options 1386 Option codes 128~159 have been reserved for vendor specific options. 1387 Multiple option codes have been assigned because a single vendor 1388 might use multiple options simultaneously. These vendor specific 1389 options are highly likely to have different meanings when used by 1390 different vendors. Therefore, they SHOULD NOT be used without an 1391 explicit human decision and SHOULD NOT be used in unmanaged networks 1392 such as home networks. 1394 There is one general requirement that applies to all vendor specific 1395 options. They MUST start with a field that uniquely identifies the 1396 enterprise that defines the option, in the form of a registered 32 1397 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen]. There is 1398 no default value for this field. 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | OPTION_vendor | option-len | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Private Enterprise Number | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Option Contents | 1408 . (variable length) . 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 Option-code: OPTION_vendor (128~159) 1413 Option-len: Length of PEN plus option contents in octets 1415 3.10.3. Experimental Options 1417 Option code 176~191 have been reserved for experimental options. 1418 Multiple option codes have been assigned because a single experiment 1419 may use multiple options simultaneously. These experimental options 1420 are highly likely to have different meanings when used for different 1421 experiments. Therefore, they SHOULD NOT be used without an explicit 1422 human decision and SHOULD NOT be used in unmanaged networks such as 1423 home networks. 1425 These option codes are also RECOMMENDED for use in documentation 1426 examples. 1428 3.11. Items for Future Work 1430 There are various design questions that are worthy of more work in 1431 the near future, as listed below: 1433 o UDP vs TCP: For now, this specification has chosen UDP as message 1434 transport mechanism. However, this is not closed yet. UDP is 1435 good for short conversations, fitting the discovery and divert 1436 scenarios well. However, it may have issues with large packets. 1437 TCP is good for stable and long sessions, with a little bit of 1438 time consumption during the session establishment stage. If 1439 messages exceed a reasonable MTU, a TCP mode may be necessary. 1441 o Message encryption: should GDNP messages be (optionally) encrypted 1442 as well as signed, to protect against internal eavesdropping or 1443 monitoring within the network? 1445 o DTLS or TLS vs built-in security mechanism. For now, this 1446 specification has chosen a PKI based built-in security mechanism 1447 based on asymmetric cryptography. However, (D)TLS might be chosen 1448 as security solution to avoid duplication of effort. It also 1449 allows essentially similar security for short messages over UDP 1450 and longer ones over TCP. The implementation trade-offs are 1451 different. The current approach requires expensive asymmetric 1452 cryptographic calculations for every message. (D)TLS has startup 1453 overheads but cheaper crypto per message. 1455 o Should discuss lifetime of discovery cache, and what to do when 1456 discovery fails (timeout and repeat?). 1458 o Timeout for lost Negotiation Ending and other messages to be 1459 added. 1461 o We mention convergence mechanisms and say "Also some mechanisms 1462 are needed to avoid loop dependencies." These issues need more 1463 work. 1465 o For replay protection, GDNP currently requires every participant 1466 to have an NTP-synchronized clock. Is this OK for low-end 1467 devices, and how does it work during device bootstrapping? We 1468 could take the Timestamp out of signature option, to become an 1469 independent and OPTIONAL (or RECOMMENDED) option. 1471 o Would use of MDNS have any impact on the Locator FQDN option? 1473 o Need to add a section describing the minimum requirements for the 1474 specification of an individual discovery, synchronization or 1475 negotiation objective. Maybe a formal information model is 1476 needed. 1478 o Is it reasonable to consider that a Discovery Objective is really 1479 just a set of specific Negotiation and/or Synchronization 1480 Objectives? In other words, if a GDNP node supports Negotiation 1481 and/or Synchronization Objectives A, B and C, then its 1482 corresponding Discovery Objective is a shorthand for "A+B+C". 1484 o Would a DISCOVERY(ANY) mechanism be useful during bootstrapping, 1485 i.e. used by all GDNP-capable routers to find all their neighbours 1486 that support any GDNP discovery objective?. 1488 o Would it be reasonable to allow an unsolicited Response message 1489 with Discovery Objective content, to speed up discovery during 1490 bootstrapping? 1492 o Is there a risk that the relaying of discovery messages 1493 (Section 3.3.1) will lead to loops or multicast storms? At least 1494 we should consider throttling discovery relays to a maximum rate. 1495 Or is there a better method for zeroconf discovery with no 1496 predefined hierarchy? 1498 o Should we consider a distributed or centralised DNS-like approach 1499 to discovery (after the initial discovery needed for 1500 bootstrapping)? 1502 o Need to discuss automatic recovery mechanism as required by 1503 Section 2.2 and management monitoring, alerts and intervention in 1504 general. 1506 o The Decline Option (Section 3.8.4) includes a note that a 1507 counterpart could use a Response message to indicate "Decline but 1508 try again". That seems strange - why not use a Negotiation 1509 message for this case? 1511 o The Signature Option (Section 3.8.7) states that this option could 1512 be any place in a message. Wouldn't it be better to specify a 1513 position (such as the end)? That would be much simpler to 1514 implement. 1516 o DoS Attack Protection needs work. 1518 o Use case and protocol walkthrough. A description of how a node 1519 starts up, performs discovery, and conducts negotiation and 1520 synchronisation for a sample use case would help readers to 1521 understand the applicability of this specification. Maybe it 1522 should be an artificial use case or maybe a simple real one. 1523 However, the authors have not yet decided whether to have a 1524 separate document or have it in this document. 1526 o We currently assume that there is only one counterpart for each 1527 discovery action. If this is false or one negotiation request 1528 receives multiple different responses, how does the initiator 1529 choose between them? Could it split them into multiple follow-up 1530 negotiations? 1532 o Alternatives to TLV format. It may be useful to provide a generic 1533 method of carrying negotiation objectives in a high-level format 1534 such as YANG or XML schema. It may also be useful to provide a 1535 generic method of carrying existing configuration information such 1536 as DHCP(v6) or IPv6 RA messages. These features could be provided 1537 by encapsulating such messages in their own TLVs, but large 1538 messages would definitely need a TCP mode instead of UDP. 1540 4. Security Considerations 1542 It is obvious that a successful attack on negotiation-enabled nodes 1543 would be extremely harmful, as such nodes might end up with a 1544 completely undesirable configuration that would also adversely affect 1545 their peers. GDNP nodes and messages therefore require full 1546 protection. 1548 - Authentication 1550 A cryptographically authenticated identity for each device is 1551 needed in an autonomic network. It is not safe to assume that a 1552 large network is physically secured against interference or that 1553 all personnel are trustworthy. Each autonomic device should be 1554 capable of proving its identity and authenticating its messages. 1556 GDNP proposes a certificate-based security mechanism to provide 1557 authentication and data integrity protection. 1559 The timestamp mechanism provides an anti-replay function. 1561 Since GDNP is intended to be deployed in a single administrative 1562 domain operating its own trust anchor and CA, there is no need for 1563 a trusted public third party. 1565 - Privacy 1567 Generally speaking, no personal information is expected to be 1568 involved in the negotiation protocol, so there should be no direct 1569 impact on personal privacy. Nevertheless, traffic flow paths, 1570 VPNs, etc. may be negotiated, which could be of interest for 1571 traffic analysis. Also, carriers generally want to conceal 1572 details of their network topology and traffic density from 1573 outsiders. Therefore, since insider attacks cannot be prevented 1574 in a large carrier network, the security mechanism for the 1575 negotiation protocol needs to provide message confidentiality. 1577 - DoS Attack Protection 1579 TBD. 1581 5. IANA Considerations 1583 Section 3.4 defines the following multicast addresses, which have 1584 been assigned by IANA for use by GDNP: 1586 ALL_GDNP_NEIGHBOR multicast address (IPv6): (TBD1) 1588 ALL_GDNP_NEIGHBOR multicast address (IPv4): (TBD2) 1590 Section 3.4 defines the following UDP port, which has been assigned 1591 by IANA for use by GDNP: 1593 GDNP Listen Port: (TBD3) 1595 This document defined a new General Discovery and Negotiation 1596 Protocol. The IANA is requested to create a new GDNP registry. The 1597 IANA is also requested to add two new registry tables to the newly- 1598 created GDNP registry. The two tables are the GDNP Messages table 1599 and GDNP Options table. 1601 Initial values for these registries are given below. Future 1602 assignments are to be made through Standards Action or Specification 1603 Required [RFC5226]. Assignments for each registry consist of a type 1604 code value, a name and a document where the usage is defined. 1606 GDNP Messages table. The values in this table are 16-bit unsigned 1607 integers. The following initial values are assigned in Section 3.7 1608 in this document: 1610 Type | Name | RFCs 1611 ---------+-----------------------------+------------ 1612 0 |Reserved | this document 1613 1 |Discovery | this document 1614 2 |Response | this document 1615 3 |Request Message | this document 1616 4 |Negotiation Message | this document 1617 5 |Negotiation-end Message | this document 1618 6 |Confirm-waiting Message | this document 1620 GDNP Options table. The values in this table are 16-bit unsigned 1621 integers. The following initial values are assigned in Section 3.8 1622 and Section 3.10 in this document: 1624 Type | Name | RFCs 1625 ---------+-----------------------------+------------ 1626 0 |Reserved | this document 1627 1 |Divert Option | this document 1628 2 |Accept Option | this document 1629 3 |Decline Option | this document 1630 4 |Waiting Time Option | this document 1631 5 |Certificate Option | this document 1632 6 |Signature Option | this document 1633 7 |Device IPv4 Address Option | this document 1634 8 |Device IPv6 Address Option | this document 1635 9 |Device FQDN Option | this document 1636 10~63 |Reserved for future GDNP | this document 1637 |General Options | 1638 128~159 |Vendor Specific Options | this document 1639 176~191 |Experimental Options | this document 1641 The IANA is also requested to create two new registry tables in the 1642 GDNP Parameters registry. The two tables are the Hash Algorithm for 1643 GDNP table and the Signature Algorithm for GDNP table. 1645 Initial values for these registries are given below. Future 1646 assignments are to be made through Standards Action or Specification 1647 Required [RFC5226]. Assignments for each registry consist of a name, 1648 a value and a document where the algorithm is defined. 1650 Hash Algorithm for GDNP. The values in this table are 16-bit 1651 unsigned integers. The following initial values are assigned for 1652 Hash Algorithm for GDNP in this document: 1654 Name | Value | RFCs 1655 ---------------------+-----------+------------ 1656 Reserved | 0x0000 | this document 1657 SHA-1 | 0x0001 | this document 1658 SHA-256 | 0x0002 | this document 1660 Signature Algorithm for GDNP. The values in this table are 16-bit 1661 unsigned integers. The following initial values are assigned for 1662 Signature Algorithm for GDNP in this document: 1664 Name | Value | RFCs 1665 ---------------------+-----------+------------ 1666 Reserved | 0x0000 | this document 1667 RSASSA-PKCS1-v1_5 | 0x0001 | this document 1669 6. Acknowledgements 1671 A major contribution to the original version of this document was 1672 made by Sheng Jiang. 1674 Valuable comments were received from Zhenbin Li, Dimitri 1675 Papadimitriou, Michael Richardson, Rene Struik, Dacheng Zhang, and 1676 other participants in the NMRG research group and the ANIMA working 1677 group. 1679 This document was produced using the xml2rfc tool [RFC2629]. 1681 7. Change log [RFC Editor: Please remove] 1683 draft-carpenter-anima-discovery-negotiation-protocol-01, restructured 1684 the logical flow of the document, updated to describe synchronization 1685 completely, add unsolicited responses, numerous corrections and 1686 clarifications, expanded future work list, 2015-01-06. 1688 draft-carpenter-anima-discovery-negotiation-protocol-00, combination 1689 of draft-jiang-config-negotiation-ps-03 and draft-jiang-config- 1690 negotiation-protocol-02, 2014-10-08. 1692 8. References 1693 8.1. Normative References 1695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1696 Requirement Levels", BCP 14, RFC 2119, March 1997. 1698 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1699 (SHA1)", RFC 3174, September 2001. 1701 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1702 Requirements for Security", BCP 106, RFC 4086, June 2005. 1704 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1705 Housley, R., and W. Polk, "Internet X.509 Public Key 1706 Infrastructure Certificate and Certificate Revocation List 1707 (CRL) Profile", RFC 5280, May 2008. 1709 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1710 "The Trickle Algorithm", RFC 6206, March 2011. 1712 8.2. Informative References 1714 [I-D.behringer-anima-autonomic-control-plane] 1715 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 1716 Autonomic Control Plane", draft-behringer-anima-autonomic- 1717 control-plane-00 (work in progress), October 2014. 1719 [I-D.chaparadza-intarea-igcp] 1720 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 1721 Mahkonen, "IP based Generic Control Protocol (IGCP)", 1722 draft-chaparadza-intarea-igcp-00 (work in progress), July 1723 2011. 1725 [I-D.eckert-anima-stable-connectivity] 1726 Eckert, T. and M. Behringer, "Autonomic Network Stable 1727 Connectivity", draft-eckert-anima-stable-connectivity-00 1728 (work in progress), October 2014. 1730 [I-D.ietf-dnssd-requirements] 1731 Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 1732 "Requirements for Scalable DNS-SD/mDNS Extensions", draft- 1733 ietf-dnssd-requirements-04 (work in progress), October 1734 2014. 1736 [I-D.ietf-homenet-hncp] 1737 Stenberg, M. and S. Barth, "Home Networking Control 1738 Protocol", draft-ietf-homenet-hncp-02 (work in progress), 1739 October 2014. 1741 [I-D.ietf-netconf-restconf] 1742 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1743 Protocol", draft-ietf-netconf-restconf-03 (work in 1744 progress), October 2014. 1746 [I-D.irtf-nmrg-an-gap-analysis] 1747 Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis 1748 for Autonomic Networking", draft-irtf-nmrg-an-gap- 1749 analysis-03 (work in progress), December 2014. 1751 [I-D.irtf-nmrg-autonomic-network-definitions] 1752 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1753 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1754 Networking - Definitions and Design Goals", draft-irtf- 1755 nmrg-autonomic-network-definitions-05 (work in progress), 1756 December 2014. 1758 [I-D.liang-iana-pen] 1759 Liang, P., Melnikov, A., and D. Conrad, "Private 1760 Enterprise Number (PEN) practices and Internet Assigned 1761 Numbers Authority (IANA) registration considerations", 1762 draft-liang-iana-pen-04 (work in progress), July 2014. 1764 [I-D.pritikin-anima-bootstrapping-keyinfra] 1765 Pritikin, M., Behringer, M., and S. Bjarnason, 1766 "Bootstrapping Key Infrastructures", draft-pritikin-anima- 1767 bootstrapping-keyinfra-00 (work in progress), November 1768 2014. 1770 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1771 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1772 Functional Specification", RFC 2205, September 1997. 1774 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 1775 "Service Location Protocol, Version 2", RFC 2608, June 1776 1999. 1778 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1779 June 1999. 1781 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1782 "Remote Authentication Dial In User Service (RADIUS)", RFC 1783 2865, June 2000. 1785 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1786 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1787 Tunnels", RFC 3209, December 2001. 1789 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1790 and M. Carney, "Dynamic Host Configuration Protocol for 1791 IPv6 (DHCPv6)", RFC 3315, July 2003. 1793 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1794 Simple Network Management Protocol (SNMP)", STD 62, RFC 1795 3416, December 2002. 1797 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 1798 Hashes in Internet Protocols", RFC 4270, November 2005. 1800 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1801 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1802 September 2007. 1804 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1805 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1806 May 2008. 1808 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1809 Time Protocol Version 4: Protocol and Algorithms 1810 Specification", RFC 5905, June 2010. 1812 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1813 Signalling Transport", RFC 5971, October 2010. 1815 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1816 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1817 6241, June 2011. 1819 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1820 "Diameter Base Protocol", RFC 6733, October 2012. 1822 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1823 February 2013. 1825 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1826 Discovery", RFC 6763, February 2013. 1828 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1829 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1830 2013. 1832 Appendix A. Capability Analysis of Current Protocols 1834 This section discusses various existing protocols with properties 1835 related to the above negotiation and synchronisation requirements. 1837 The purpose is to evaluate whether any existing protocol, or a simple 1838 combination of existing protocols, can meet those requirements. 1840 Numerous protocols include some form of discovery, but these all 1841 appear to be very specific in their applicability. Service Location 1842 Protocol (SLP) [RFC2608] provides service discovery for managed 1843 networks, but requires configuration of its own servers. DNS-SD 1844 [RFC6763] combined with mDNS [RFC6762] provides service discovery for 1845 small networks with a single link layer. 1846 [I-D.ietf-dnssd-requirements] aims to extend this to larger 1847 autonomous networks. However, both SLP and DNS-SD appear to target 1848 primarily application layer services, not the layer 2 and 3 1849 objectives relevant to basic network configuration. 1851 Routing protocols are mainly one-way information announcements. The 1852 receiver makes independent decisions based on the received 1853 information and there is no direct feedback information to the 1854 announcing peer. This remains true even though the protocol is used 1855 in both directions between peer routers; there is state 1856 synchronization, but no negotiation, and each peer runs its route 1857 calculations independently. 1859 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 1860 response model not well suited for peer negotiation. Network 1861 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 1862 does allow positive or negative responses from the target system, but 1863 this is still not adequate for negotiation. 1865 There are various existing protocols that have elementary negotiation 1866 abilities, such as Dynamic Host Configuration Protocol for IPv6 1867 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 1868 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 1869 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 1870 configuration or management protocols. However, they either provide 1871 only a simple request/response model in a master/slave context or 1872 very limited negotiation abilities. 1874 There are also signalling protocols with an element of negotiation. 1875 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 1876 designed for negotiating quality of service parameters along the path 1877 of a unicast or multicast flow. RSVP is a very specialised protocol 1878 aimed at end-to-end flows. However, it has some flexibility, having 1879 been extended for MPLS label distribution [RFC3209]. A more generic 1880 design is General Internet Signalling Transport (GIST) [RFC5971], but 1881 it is complex, tries to solve many problems, and is also aimed at 1882 per-flow signalling across many hops rather than at device-to-device 1883 signalling. However, we cannot completely exclude extended RSVP or 1884 GIST as a synchronization and negotiation protocol. They do not 1885 appear to be directly useable for peer discovery. 1887 We now consider two protocols that are works in progress at the time 1888 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 1889 protocol intended to convey NETCONF information expressed in the YANG 1890 language via HTTP, including the ability to transit HTML 1891 intermediaries. While this is a powerful approach in the context of 1892 centralised configuration of a complex network, it is not well 1893 adapted to efficient interactive negotiation between peer devices, 1894 especially simple ones that are unlikely to include YANG processing 1895 already. 1897 Secondly, we consider HomeNet Control Protocol (HNCP) 1898 [I-D.ietf-homenet-hncp]. This is defined as "a minimalist state 1899 synchronization protocol for Homenet routers." 1901 NOTE: HNCP is under revision at the time of this writing, so the 1902 following comments will soon be out of date. 1904 Specific features are: 1906 o Every participating node has a unique node identifier. 1908 o "HNCP is designed to operate between directly connected neighbors 1909 on a shared link using link-local IPv6 addresses." 1911 o Currency of state is maintained by spontaneous link-local 1912 multicast messages. 1914 o HNCP discovers and tracks link-local neighbours. 1916 o HNCP messages are encoded as a sequence of TLV objects, sent over 1917 UDP. 1919 o Authentication depends on a signature TLV (assuming public keys 1920 are associated with node identifiers). 1922 o The functionality covered initially includes: site border 1923 discovery, prefix assignment, DNS namespace discovery, and routing 1924 protocol selection. 1926 Clearly HNCP does not completely meet the needs of a general 1927 negotiation protocol, especially due to its limitation to link-local 1928 messages and its strict dependency on IPv6, but at the minimum it is 1929 a very interesting test case for this style of interaction between 1930 devices without needing a central authority. 1932 A proposal has been made for an IP based Generic Control Protocol 1933 (IGCP) [I-D.chaparadza-intarea-igcp]. This is aimed at information 1934 exchange and negotiation but not directly at peer discovery. 1935 However, it has many points in common with the present work. 1937 None of the above solutions appears to completely meet the needs of 1938 discovery, state synchronization and negotiation in the general case. 1939 Neither is there an obvious combination of protocols that does so. 1940 Therefore, this document proposes the design of a protocol that does 1941 meet those needs. However, this proposal needs to be confronted with 1942 alternatives such as extension and adaptation of GIST or HNCP, or 1943 combination with IGCP. 1945 Authors' Addresses 1947 Brian Carpenter 1948 Department of Computer Science 1949 University of Auckland 1950 PB 92019 1951 Auckland 1142 1952 New Zealand 1954 Email: brian.e.carpenter@gmail.com 1956 Bing Liu 1957 Huawei Technologies Co., Ltd 1958 Q14, Huawei Campus 1959 No.156 Beiqing Road 1960 Hai-Dian District, Beijing 100095 1961 P.R. China 1963 Email: leo.liubing@huawei.com