idnits 2.17.1 draft-carpenter-anima-gdn-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2014) is 3482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-01 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-02 == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-02 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-04 -- 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: 0 errors (**), 0 flaws (~~), 5 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 S. Jiang 5 Expires: April 16, 2015 B. Liu 6 Huawei Technologies Co., Ltd 7 October 13, 2014 9 A Generic Discovery and Negotiation Protocol for Autonomic Networking 10 draft-carpenter-anima-gdn-protocol-00 12 Abstract 14 This document defines a new protocol that enables intelligent devices 15 to dynamically discover peer devices, to synchronize state with them, 16 and to negotiate mutual configurations with them. This document only 17 defines a general protocol as a negotiation platform, while the 18 negotiation objectives for specific scenarios are to be described in 19 separate documents. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 16, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language and Terminology . . . . . . . . . . . . 4 57 3. Requirement Analysis of Discovery, Synchronization and 58 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Requirements for Discovery . . . . . . . . . . . . . . . 5 60 3.2. Requirements for Synchronization and Negotiation 61 Capability . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Negotiation Capability Analysis of Current Protocols . . . . 7 63 5. GDNP Protocol Overview . . . . . . . . . . . . . . . . . . . 9 64 5.1. High-Level Design Choices . . . . . . . . . . . . . . . . 9 65 5.2. GDNP Protocol Basic Properties and Mechanisms . . . . . . 13 66 5.2.1. IP Version Independent . . . . . . . . . . . . . . . 13 67 5.2.2. Discovery Mechanism and Procedures . . . . . . . . . 13 68 5.2.3. Certificate-based Security Mechanism . . . . . . . . 14 69 5.2.4. Negotiation Procedures . . . . . . . . . . . . . . . 17 70 5.3. GDNP Constants . . . . . . . . . . . . . . . . . . . . . 18 71 5.4. Device Identifier and Certificate Tag . . . . . . . . . . 18 72 5.5. Session Identifier . . . . . . . . . . . . . . . . . . . 19 73 5.6. GDNP Messages . . . . . . . . . . . . . . . . . . . . . . 19 74 5.6.1. GDNP Message Format . . . . . . . . . . . . . . . . . 19 75 5.6.2. Discovery Message . . . . . . . . . . . . . . . . . . 20 76 5.6.3. Response Message . . . . . . . . . . . . . . . . . . 21 77 5.6.4. Request Message . . . . . . . . . . . . . . . . . . . 21 78 5.6.5. Negotiation Message . . . . . . . . . . . . . . . . . 22 79 5.6.6. Negotiation-ending Message . . . . . . . . . . . . . 22 80 5.6.7. Confirm-waiting Message . . . . . . . . . . . . . . . 22 81 5.7. GDNP General Options . . . . . . . . . . . . . . . . . . 22 82 5.7.1. Format of GDNP Options . . . . . . . . . . . . . . . 22 83 5.7.2. Divert Option . . . . . . . . . . . . . . . . . . . . 23 84 5.7.3. Accept Option . . . . . . . . . . . . . . . . . . . . 24 85 5.7.4. Decline Option . . . . . . . . . . . . . . . . . . . 24 86 5.7.5. Waiting Time Option . . . . . . . . . . . . . . . . . 25 87 5.7.6. Certificate Option . . . . . . . . . . . . . . . . . 26 88 5.7.7. Signature Option . . . . . . . . . . . . . . . . . . 26 89 5.7.8. Locator Options . . . . . . . . . . . . . . . . . . . 27 90 5.8. Discovery Objective Option . . . . . . . . . . . . . . . 29 91 5.9. Negotiation Objective Options and Considerations . . . . 29 92 5.9.1. Organizing of GDNP Options . . . . . . . . . . . . . 30 93 5.9.2. Vendor Specific Options . . . . . . . . . . . . . . . 30 94 5.9.3. Experimental Options . . . . . . . . . . . . . . . . 30 95 5.10. Items for Future Work . . . . . . . . . . . . . . . . . . 30 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 99 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 35 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 101 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 102 10.2. Informative References . . . . . . . . . . . . . . . . . 35 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 105 1. Introduction 107 The success of the Internet has made IP-based networks bigger and 108 more complicated. Large-scale ISP networks have become more and more 109 problematic for human based management. Also operational costs are 110 growing quickly. Consequently, there are therefore increased 111 requirements for autonomy in the networks. General aspects of 112 autonomic networks are discussed in 113 [I-D.irtf-nmrg-autonomic-network-definitions] and 114 [I-D.irtf-nmrg-an-gap-analysis]. In order to fulfil autonomy, 115 devices that are more intelligent need to be able to discover each 116 other, to synchronize state with each other, and negotiate directly 117 with each other. 119 Following this Introduction and the definition of useful terminology, 120 Section 3 describes the requirements and application scenarios for 121 network device negotiation. Then the negotiation capabilities of 122 various existing protocols are reviewed in Section 4. State 123 synchronization, when needed, can be considered as a special case of 124 negotiation. Prior to negotiation or synchronization, devices must 125 discover each other. Section 5.1 describes a behavior model for a 126 protocol intended to support discovery, synchronization and 127 negotiation. The design of Generic Discovery and Negotiation 128 Protocol (GDNP) in Section 5 of this document is mainly based on this 129 behavior model. 131 Although many negotiations may happen between horizontally 132 distributed peers, the main target scenarios are still hierarchical 133 networks, which is the major structure of current large-scale 134 networks. Thus, where necessary, we assume that each network element 135 has a hierarchical superior. Of course, the protocol itself is 136 capable of being used in a small and/or flat network structure such 137 as a small office or home network, too. 139 This document defines a Generic Discovery and Negotiation Protocol 140 (GDNP), that can be used to perform decision process among 141 distributed devices or between networks. The newly defined GDNP in 142 this document adapts a tight certificate-based mechanism, which needs 143 a Public Key Infrastructure (PKI, [RFC5280]) system. The PKI may be 144 managed by an operator or be autonomic. The document also introduces 145 a new discovery mechanism, which is based on a neighbor learning 146 process and is oriented towards negotiation objectives. 148 It is understood that in realistic deployments, not all devices will 149 support GDNP. Such mixed scenarios are not discussed in this 150 specification. 152 2. Requirements Language and Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in 157 [RFC2119] when they appear in ALL CAPS. When these words are not in 158 ALL CAPS (such as "should" or "Should"), they have their usual 159 English meanings, and are not to be interpreted as [RFC2119] key 160 words. 162 o Discovery: a process by which a device discovers peer devices 163 according to a specific discovery objective. The discovery 164 results may be different according to the different discovery 165 objectives. The discovered peer devices may later be used as 166 negotiation counterparts. 168 o Negotiation: a process by which two (or more) devices interact 169 iteratively to agree on parameter settings that best satisfy the 170 objectives of one or more devices. 172 o State Synchronization: a process by which two (or more) devices 173 interact iteratively to agree on the current state of parameter 174 values stored in each device. This is a special case of 175 negotiation in which information is exchanged but the devices do 176 not request their peers to change parameter settings. All other 177 definitions apply to both negotiation and synchronization. 179 o Discovery Objective: a specific functionality, role-based network 180 element or service agent (TBD) which the discovery initiator 181 intends to discover. One device may support multiple discovery 182 objectives. 184 o Discovery Initiator: a device that spontaneously starts discovery 185 by sending a discovery message referring to a specific discovery 186 objective. 188 o Discovery Responder: a peer device which responds to the discovery 189 objective initiated by the discovery initiator. 191 o Negotiation Objective: specific negotiation content, which needs 192 to be decided in coordination with another network device. It is 193 naturally based on a specific service or function or action. It 194 could be a logical, numeric, or string value or a more complex 195 data structure. 197 o Negotiation Initiator: a device that spontaneously starts 198 negotiation by sending a request message referring to a specific 199 negotiation objective. 201 o Negotiation Counterpart: a peer device with which the Negotiation 202 Initiator negotiates a specific negotiation objective. 204 o Device Identifier: a public key, which identifies the device in 205 CDNP messages. It is assumed that its associated private key is 206 maintained in the device only. 208 o Device Certificate: A certificate for a single device, also the 209 identifier of the device, further described in Section 5.4. 211 o Device Certificate Tag: a tag, which is bound to the device 212 identifier. It is used to present Device Certificate in short 213 form. 215 3. Requirement Analysis of Discovery, Synchronization and Negotiation 217 This section discusses the requirements for discovery, negotiation 218 and synchronization capabilities. 220 3.1. Requirements for Discovery 222 In an autonomic network we must assume that when a device starts up 223 it has no information about any peer devices. In some cases, when a 224 new user session starts up, the device concerned may again lack 225 information about relevant peer devices. It might be necessary to 226 set up resources on multiple other devices, coordinated and matched 227 to each other so that there is no wasted resource. Security settings 228 might also need updating to allow for the new device or user. 229 Therefore a basic requirement is that there must be a mechanism by 230 which a device can discover peer devices. These devices might be 231 immediate neighbors on the same layer 2 link or they might be more 232 distant and only accessible via layer 3. 234 The relevant peer devices may be different for different discovery 235 objectives. Therefore discovery needs to be repeated as often as 236 necessary to find peers capable of acting as counterparts for each 237 objective that a discovery initiator needs to handle. In many 238 scenarios, discovery process may follow up by negotiation process. 239 Correspondently, the discovery objective may associate with the 240 negotiation objective. 242 In most networks, as mentioned above, there will be some hierarchical 243 structure. A special case of discovery is that each device must be 244 able to discover its hierarchical superior for each negotiation 245 objective that it is capable of handling. 247 During initialisation, a device must be able to discover the 248 appropriate trust anchor. Logically, this is just a specific case of 249 discovery. However, it might be a special case requiring its own 250 solution. This question requires further study. 252 3.2. Requirements for Synchronization and Negotiation Capability 254 We start by considering routing protocols, the closest approximation 255 to autonomic networking in widespread use. Routing protocols use a 256 largely autonomic model based on distributed devices that communicate 257 iteratively with each other. However, routing is mainly based on 258 one-way information announcements (in either direction), rather than 259 on bi-directional negotiation. The only focus is reachability, so 260 current routing protocols only consider simple link status, as up or 261 down. More information, such as latency, congestion, capacity, and 262 particularly unused capacity, would be helpful to get better path 263 selection and utilization rate. Also, autonomic networks need to be 264 able to manage many more dimensions, such as security settings, power 265 saving, load balancing, etc. A basic requirement for the protocol is 266 therefore the ability to represent, discover, synchronize and 267 negotiate almost any kind of network parameter. 269 Human intervention in complex situations is costly and error-prone. 270 Therefore, a negotiation model without human intervention is 271 desirable whenever the coordination of multiple devices can provide 272 better overall network performance. Therefore a requirement for the 273 protocol is to be capable of being installed in any device that would 274 otherwise need human intervention. 276 Human intervention in large networks is often replaced by use of a 277 top-down network management system (NMS). It follows that a 278 requirement for the protocol is to be capable of being installed in 279 any device that would otherwise be managed by an NMS, and that it can 280 co-exist with an NMS. 282 Since the goal is no human intervention, it is necessary that the 283 network can in effect "think ahead" before changing its parameters. 284 In other words there must be a possibility of forecasting the effect 285 of a change. Stated differently, the protocol must be capable of 286 supporting a "dry run" of a changed configuration before actually 287 installing the change. 289 Status information and traffic metrics need to be shared between 290 nodes for dynamic adjustment of resources and for monitoring 291 purposes. While this might be achieved by existing protocols when 292 they are available, the new protocol needs to be able to support 293 parameter exchange, including mutual synchronization, even when no 294 negotiation as such is required. 296 Recovery from faults and identification of faulty devices should be 297 as automatic as possible. The protocol needs to be capable of 298 detecting unexpected events such a negotiation counterpart failing, 299 so that all devices concerned can initiate a recovery process. 301 The protocol needs to be able to deal with a wide variety of 302 negotiation objectives, covering any type of network parameter. 303 Therefore the protocol will need either an explicit information model 304 describing its messages, or at least a flexible and extensible 305 message format. One design consideration is whether to adopt an 306 existing information model or to design a new one. Another 307 consideration is whether to be able to carry some or all of the 308 message formats used by existing configuration protocols. 310 The protocol needs to be fully secure against forged messages and 311 man-in-the middle attacks, and as secure as reasonably possible 312 against denial of service attacks. It needs to be capable of 313 encryption in order to resist unwanted monitoring, although this 314 capability may not be required in all deployments. 316 4. Negotiation Capability Analysis of Current Protocols 318 This section discusses various existing protocols with properties 319 related to the above negotiation and synchronisation requirements. 320 The purpose is to evaluate whether any existing protocol, or a simple 321 combination of existing protocols, can meet those requirements. 323 The analysis does not include discovery protocols. While numerous 324 protocols include some form of discovery, these all appear to be very 325 specific in their applicability. 327 Routing protocols are mainly one-way information announcements. The 328 receiver makes independent decisions based on the received 329 information and there is no direct feedback information to the 330 announcing peer. This remains true even though the protocol is used 331 in both directions between peer routers; there is state 332 synchronization, but no negotiation, and each peer runs its route 333 calculations independently. 335 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 336 response model not well suited for peer negotiation. Network 337 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 338 does allow positive or negative responses from the target system, but 339 this is still not adequate for negotiation. 341 There are various existing protocols that have elementary negotiation 342 abilities, such as Dynamic Host Configuration Protocol for IPv6 343 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control 344 Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service 345 (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are 346 configuration or management protocols. However, they either provide 347 only a simple request/response model in a master/slave context or 348 very limited negotiation abilities. 350 There are also signalling protocols with an element of negotiation. 351 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 352 designed for negotiating quality of service parameters along the path 353 of a unicast or multicast flow. RSVP is a very specialised protocol 354 aimed at end-to-end flows. However, it has some flexibility, having 355 been extended for MPLS label distribution [RFC3209]. A more generic 356 design is General Internet Signalling Transport (GIST) [RFC5971], but 357 it is complex, tries to solve many problems, and is also aimed at 358 per-flow signalling across many hops rather than at device-to-device 359 signalling. However, we cannot completely exclude extended RSVP or 360 GIST as a synchronization and negotiation protocol. They do not 361 appear to be directly useable for peer discovery. 363 We now consider two protocols that are works in progress at the time 364 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 365 protocol intended to convey NETCONF information expressed in the YANG 366 language via HTTP, including the ability to transit HTML 367 intermediaries. While this is a powerful approach in the context of 368 centralised configuration of a complex network, it is not well 369 adapted to efficient interactive negotiation between peer devices, 370 especially simple ones that are unlikely to include YANG processing 371 already. 373 Secondly, we consider HomeNet Control Protocol (HNCP) 374 [I-D.ietf-homenet-hncp]. This is defined as "a minimalist state 375 synchronization protocol for Homenet routers." Specific features 376 are: 378 o Every participating node has a unique node identifier. 380 o "HNCP is designed to operate between directly connected neighbors 381 on a shared link using link-local IPv6 addresses." 383 o Currency of state is maintained by spontaneous link-local 384 multicast messages. 386 o HNCP discovers and tracks link-local neighbours. 388 o HNCP messages are encoded as a sequence of TLV objects, sent over 389 UDP. 391 o Authentication depends on a signature TLV (assuming public keys 392 are associated with node identifiers). 394 o The functionality covered initially includes: site border 395 discovery, prefix assignment, DNS namespace discovery, and routing 396 protocol selection. 398 Clearly HNCP does not completely meet the needs of a general 399 negotiation protocol, especially due to its limitation to link-local 400 messages and its strict dependency on IPv6, but at the minimum it is 401 a very interesting test case for this style of interaction between 402 devices without needing a central authority. 404 A proposal has been made for an IP based Generic Control Protocol 405 (IGCP) [I-D.chaparadza-intarea-igcp]. This is aimed at information 406 exchange and negotiation but not directly at peer discovery. 407 However, it has many points in common with the present work. 409 None of the above solutions appears to completely meet the needs of 410 discovery, state synchronization and negotiation in the general case. 411 Neither is there an obvious combination of protocols that does so. 412 Therefore, the remainder of this document proposes the design of a 413 protocol that does meet those needs. However, this proposal needs to 414 be confronted with alternatives such as extension and adaptation of 415 GIST or HNCP, or combination with IGCP. 417 5. GDNP Protocol Overview 419 5.1. High-Level Design Choices 421 This section describes a behavior model and some considerations for 422 designing a generic discovery and negotiation protocol, which would 423 act as a platform for different negotiation objectives. 425 NOTE: This protocol is described here in a stand-alone fashion as a 426 proof of concept. An elementary version has been prototyped by 427 Huawei and the Beijing University of Posts and Telecommunications. 428 However, this is not yet a definitive proposal for IETF adoption. In 429 particular, adaptation and extension of one of the protocols 430 discussed in Section 4 might be an option. Also, the security model 431 outlined below would in practice be part of a general security 432 mechanism in an autonomic control plane. This whole specification is 433 subject to change as a result. 435 o A generic platform 437 The design of the network device protocol is desired to be a 438 generic platform, which is independent from the negotiation 439 contents. It should only take care of the general 440 intercommunication between negotiation counterparts. The 441 negotiation contents will vary according to the various 442 negotiation objectives and the different pairs of negotiating 443 counterparts. 445 o Security infrastructure and trust relationship 447 Because this negotiation protocol may directly cause changes to 448 device configurations and bring significant impacts to a running 449 network, this protocol must be based on a restrictive security 450 infrastructure. It should be carefully managed and monitored so 451 that every device in this negotiation system behaves well and 452 remains well protected. 454 On the other hand, a limited negotiation model might be deployed 455 based on a limited trust relationship. For example, between two 456 administrative domains, devices might also exchange limited 457 information and negotiate some particular configurations based on 458 a limited conventional or contractual trust relationship. 460 o Discovery and negotiation designed together 462 The discovery method and the negotiation method are designed in 463 the same way and can be combined when this is useful. 465 o A uniform pattern for negotiation contents 467 The negotiation contents should be defined according to a uniform 468 pattern. They could be carried either in TLV (Type, Length and 469 Value) format or in payloads described by a flexible language, 470 like XML. A protocol design should choose one of these two. The 471 format must be extensible for unknown future requirements. As 472 noted above, an existing information model and existing message 473 format(s) should be considered. 475 o A simple initiator/responder model 477 Multi-party negotiations are too complicated to be modeled and 478 there may be too many dependencies among the parties to converge 479 efficiently. A simple initiator/responder model is more feasible 480 and could actually complete multiple-party negotiations by 481 indirect steps. Naturally this process must be guaranteed to 482 terminate and must contain tie-breaking rules. 484 o Organizing of negotiation content 486 Naturally, the negotiation content should be organized according 487 to the relevant function or service. The content from different 488 functions or services should be kept independent from each other. 489 They should not be combined into a single option or single session 490 because these contents may be negotiated with different 491 counterparts or may be different in response time. 493 o Self aware network device 495 Every network device should be pre-configured with its role and 496 functions and be aware of its own capabilities. The roles may be 497 only distinguished because of network behaviors, which may include 498 forwarding behaviors, aggregation properties, topology location, 499 bandwidth, tunnel or translation properties, etc. The role and 500 functions may depend on the network planning. The capability is 501 typically decided by the hardware or firmware. These parameters 502 are the foundation of the negotiation behavior of a specific 503 device. 505 o Requests and responses in negotiation procedures 507 The initiator should be able to negotiate with its relevant 508 negotiation counterpart devices, which may be different according 509 to the negotiation objective. It may request relevant information 510 from the negotiation counterpart so that it can decide its local 511 configuration to give the most coordinated performance. It may 512 request the negotiation counterpart to make a matching 513 configuration in order to set up a successful communication with 514 it. It may request certain simulation or forecast results by 515 sending some dry run conditions. 517 Beyond the traditional yes/no answer, the responder should be able 518 to reply with a suggested alternative if its answer is 'no'. This 519 would start a bi-directional negotiation ending in a compromise 520 between the two devices. 522 o Convergence of negotiation procedures 523 The negotiation procedure should move towards convergent results. 524 It means that when a responder makes a suggestion of a changed 525 condition in a negative reply, it should be as close as possible 526 to the original request or previous suggestion. The suggested 527 value of the third or later negotiation steps should be chosen 528 between the suggested values from the last two negotiation steps. 529 In any case there must be a mechanism to guarantee rapid 530 convergence in a small number of steps. 532 o Dependencies of negotiation 534 In order to decide a configuration on a device, the device may 535 need information from neighbors. This can be established through 536 the above negotiation procedure. However, a given item in a 537 neighbor may depend on other information from its own neighbors, 538 which may need another negotiation procedure to obtain or decide. 539 Therefore, there are dependencies among negotiation procedures. 540 There need to be clear boundaries and convergence mechanisms for 541 these negotiation dependencies. Also some mechanisms are needed 542 to avoid loop dependencies. 544 o End of negotiation 546 A single negotiation procedure also needs ending conditions if it 547 does not converge. A limited number of rounds, for example three, 548 should be set on the devices. It may be an implementation choice 549 or a pre-configurable parameter. However, the protocol design 550 needs to clearly specify this, so that the negotiation can be 551 terminated properly. In some cases, a timeout might be needed to 552 end a negotiation. 554 o Failed negotiation 556 There must be a well-defined procedure for concluding that a 557 negotiation cannot succeed, and if so deciding what happens next 558 (deadlock resolution, tie-breaking, or revert to best-effort 559 service). 561 o Policy constraints 563 There must be provision for general policy rules to be applied by 564 all devices in the network (e.g., security rules, prefix length, 565 resource sharing rules). However, policy distribution might not 566 use the negotiation protocol itself. 568 o Management monitoring, alerts and intervention 570 Devices should be able to report to a monitoring system. Some 571 events must be able to generate operator alerts and some provision 572 for emergency intervention must be possible (e.g. to freeze 573 negotiation in a mis-behaving device). These features may not use 574 the negotiation protocol itself. 576 5.2. GDNP Protocol Basic Properties and Mechanisms 578 5.2.1. IP Version Independent 580 To be a generic platform, GDNP should be IP version independent. In 581 other words, it should be able to run over IPv6 and IPv4. Its 582 messages and general options are neutral with respect to the IP 583 version. 585 However, some functions, such as multicasting or broadcasting on a 586 link, might need to be IP version dependent. For these parts, the 587 document defines support for both IP versions separately. 589 5.2.2. Discovery Mechanism and Procedures 591 o Separated discovery and negotiation mechanisms 593 Although discovery and negotiation defined together in the 594 GDNP, they are separated mechanisms. The discovery process 595 could run independently from the negotiation process. Upon 596 receiving a discovery (defined in Section 5.6.2) or request 597 message (defined in Section 5.6.4) , the recipient device 598 should return a message in which it either indicates itself as 599 a discovery responder or diverts the initiator towards another 600 more suitable device. 602 The discovery objective could be network functionalities, role- 603 based network elements or service agents (TBD). The discovery 604 results could be utilized by the negotiation protocol to decide 605 which device the initiator will negotiate with. 607 o Discovery Procedures 609 Discovery starts as on-link operation. The Divert option can 610 tell the discovery initiator to contact an off-link discovery 611 objective device. Every DISCOVERY message is sent by a 612 discovery initiator to the ALL_GDNP_NEIGHBOR multicast address 613 (Section 5.3). Every network device that supports the GDNP 614 always listens to a well-known (UDP?) port to capture the 615 discovery messages. 617 If the neighbor device supports a proper discovery objective, 618 it MAY respond with a Response message (defined in 619 Section 5.6.3) with locator option(s). Otherwise, if the 620 neigbor device knows a device that supports the proper 621 discovery objective (for example because it discovered the same 622 objective before), it SHOULD respond with a Response message 623 with a Divert option pointed to the proper discovery objective. 625 After a GDNP device successfully discovered a device supporting 626 a specific objective, it MUST record this discovery objective. 627 This record may be used for future negotiation or to pass to 628 another neighbor as a Divert option. This learning mechanism 629 should be able to support most network establishment scenarios 631 o Rapid Mode (Discovery/Negotiation binding) 633 A DISCOVERY message MAY includes one or more negotiation 634 objective option(s) to indicate to the discovery objective that 635 it could directly reply to the discovery initiator with a 636 Negotiation message for rapid processing, if the discovery 637 objective could act as the corresponding negotiation 638 counterpart. However, the indication is only advisory not 639 prescriptive. 641 This rapid mode could reduce the interactions between nodes so 642 that a higher efficiency could be achieved. This rapid 643 negotiation function SHOULD be configured on or off by the 644 administrators. 646 5.2.3. Certificate-based Security Mechanism 648 A certification based security mechanism provides security properties 649 for CDNP: 651 o the identity of a GDNP message sender can be verified by a 652 recipient. 654 o the integrity of GDNP message can be checked by the recipient of 655 the message. 657 o anti-replay protection on the GDNP message recipient. 659 The authority of the GDNP message sender depends on a Public Key 660 Infrastructure (PKI) system with a Certification Authority (CA), 661 which should normally be run by the network operator. In the case of 662 a network with no operator, such as a small office or home network, 663 the PKI itself needs to be established by an autonomic process, which 664 is out of scope for this specification. 666 A Request message MUST carry a Certificate option, defined in 667 Section 5.7.6. The first Negotiation Message, responding to a 668 Request message, SHOULD also carry a Certificate option. Using these 669 messages, recipients build their certificate stores, indexed by the 670 Device Certificate Tags included in every GDNP message. This process 671 is described in more detail below. 673 Every message MUST carry a signature option, defined in 674 Section 5.7.7. 676 For now, the authors do not think packet size is a problem. In this 677 GDNP specification, there SHOULD NOT be multiple certificates in a 678 single message. The current most used public keys are 1024/2048 679 bits, some may reach 4096. With overhead included, a single 680 certificate is less than 500 bytes. Messages should be far shorter 681 than the normal packet MTU within a modern network. 683 5.2.3.1. Support for algorithm agility 685 Hash functions are used to provide message integrity checks. In 686 order to provide a means of addressing problems that may emerge in 687 the future with existing hash algorithms, as recommended in 688 [RFC4270], a mechanism for negotiating the use of more secure hashes 689 in the future is provided. 691 In addition to hash algorithm agility, a mechanism for signature 692 algorithm agility is also provided. 694 The support for algorithm agility in this document is mainly a 695 unilateral notification mechanism from sender to recipient. If the 696 recipient does not support the algorithm used by the sender, it 697 cannot authenticate the message. Senders in a single administrative 698 domain are not required to upgrade to a new algorithm simultaneously. 700 So far, the algorithm agility is supported by one-way notification, 701 rather than negotiation mode. As defined in Section 5.7.7, the 702 sender notifies the recipient what hash/signature algorithms it uses. 703 If the responder doesn't know a new algorithm used by the sender, the 704 negotiation request would fail. In order to establish a negotiation 705 session, the sender MAY fall back to an older, less preferred 706 algorithm. To avoid downgrade attacks it MUST NOT fall back to an 707 algorithm considered weak. 709 5.2.3.2. Message validation on reception 711 When receiving a GDNP message, a recipient MUST discard the GDNP 712 message if the Signature option is absent, or the Certificate option 713 is in a Request Message. 715 For the Request message and the Response message with a Certification 716 Option, the recipient MUST first check the authority of this sender 717 following the rules defined in [RFC5280]. After successful authority 718 validation, an implementation MUST add the sender's certification 719 into the local trust certificate record indexed by the associated 720 Device Certificate Tag, defined in Section 5.4. 722 The recipient MUST now authenticate the sender by verifying the 723 Signature and checking a timestamp, as specified in Section 5.2.3.3. 724 The order of two procedures is left as an implementation decision. 725 It is RECOMMENDED to check timestamp first, because signature 726 verification is much more computationally expensive. 728 The signature field verification MUST show that the signature has 729 been calculated as specified in Section 5.7.7. The public key used 730 for signature validation is obtained from the certificate either 731 carried by the message or found from a local trust certificate record 732 by searching the message-carried Device Certificate Tag. 734 Only the messages that get through both the signature verifications 735 and timestamp check are accepted and continue to be handled for their 736 contained CDNP options. Messages that do not pass the above tests 737 MUST be discarded as insecure messages. 739 5.2.3.3. TimeStamp checking 741 Recipients SHOULD be configured with an allowed timestamp Delta 742 value, a "fuzz factor" for comparisons, and an allowed clock drift 743 parameter. The recommended default value for the allowed Delta is 744 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 745 drift, 0.01 second. 747 The timestamp is defined in the Signature Option, Section 5.7.7. To 748 facilitate timestamp checking, each recipient SHOULD store the 749 following information for each sender: 751 o The receive time of the last received and accepted GDNP message. 752 This is called RDlast. 754 o The time stamp in the last received and accepted GDNP message. 755 This is called TSlast. 757 An accepted GDNP message is any successfully verified (for both 758 timestamp check and signature verification) GDNP message from the 759 given peer. It initiates the update of the above variables. 760 Recipients MUST then check the Timestamp field as follows: 762 o When a message is received from a new peer (i.e., one that is not 763 stored in the cache), the received timestamp, TSnew, is checked, 764 and the message is accepted if the timestamp is recent enough to 765 the reception time of the packet, RDnew: 767 -Delta < (RDnew - TSnew) < +Delta 769 The RDnew and TSnew values SHOULD be stored in the cache as RDlast 770 and TSlast. 772 o When a message is received from a known peer (i.e., one that 773 already has an entry in the cache), the timestamp is checked 774 against the previously received GDNP message: 776 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 778 If this inequality does not hold, the recipient SHOULD silently 779 discard the message. If, on the other hand, the inequality holds, 780 the recipient SHOULD process the message. 782 Moreover, if the above inequality holds and TSnew > TSlast, the 783 recipient SHOULD update RDlast and TSlast. Otherwise, the 784 recipient MUST NOT update RDlast or TSlast. 786 An implementation MAY use some mechanism such as a timestamp cache to 787 strengthen resistance to replay attacks. When there is a very large 788 number of nodes on the same link, or when a cache filling attack is 789 in progress, it is possible that the cache holding the most recent 790 timestamp per sender will become full. In this case, the node MUST 791 remove some entries from the cache or refuse some new requested 792 entries. The specific policy as to which entries are preferred over 793 others is left as an implementation decision. 795 5.2.4. Negotiation Procedures 797 A negotiation initiator sends a negotiation request to counterpart 798 devices, which may be different according to different negotiation 799 objectives. It may request relevant information from the negotiation 800 counterpart so that it can decide its local configuration to give the 801 most coordinated performance. This would be sufficient in a case 802 where the required function is limited to state synchronization. It 803 may additionally request the negotiation counterpart to make a 804 matching configuration in order to set up a successful communication 805 with it. It may request a certain simulation or forecast result by 806 sending some dry run conditions. The details will be defined 807 separately for each type of negotiation objective. 809 If the counterpart can immediately apply the requested configuration, 810 it will give a positive (yes) answer. This will normally end the 811 negotiation phase immediately. Otherwise it will give a negative 812 (no) answer. Normally, this will not end the negotiation phase. 814 In the negative (no) case, the negotiation counterpart should be able 815 to reply with a proposed alternative configuration that it can apply 816 (typically, a configuration that uses fewer resources than requested 817 by the negotiation initiator). This will start a bi-directional 818 negotiation to reach a compromise between the two network devices. 820 The negotiation procedure is ended when one of the negotiation peers 821 sends a Negotiation Ending message, which contains an accept or 822 decline option and does not need a response from the negotiation 823 peer. 825 A negotiation procedure concerns one objective and one counterpart. 826 Both the initiator and the counterpart may take part in simultaneous 827 negotiations with various other devices, or in simultaneous 828 negotiations about different objectives. Thus, GDNP is expected to 829 be used in a multi-threaded mode. Certain negotiation objectives may 830 have restrictions on multi-threading, for example to avoid over- 831 allocating resources. 833 5.3. GDNP Constants 835 o ALL_GDNP_NEIGHBOR (TBD1) 837 A link-local scope multicast address used by a GDNP-enabled router 838 to discover GDNP-enabled neighbor (i.e., on-link) devices . All 839 routers that support GDNP are members of this multicast group. 841 * IPv6 multicast address: TBD1 843 * IPv4 multicast address: TBD2 845 o GDNP Listen Port (TBD3) 847 A UDP port that every GDNP-enabled network device always listens 848 to. 850 5.4. Device Identifier and Certificate Tag 852 A GDNP-enabled Device MUST generate a stable public/private key pair 853 before it participates in GDNP. There MUST NOT be any way of 854 accessing the private key via the network or an operator interface. 855 The device then uses the public key as its identifier, which is 856 cryptographic in nature. It is a GDNP unique identifier for a GDNP 857 participant. 859 It then gets a certificate for this public key, signed by a 860 Certificate Authority that is trusted by other network devices. The 861 Certificate Authority SHOULD be managed by the network administrator, 862 to avoid needing to trust a third party. The signed certificate 863 would be used for authentication of the message sender. In a managed 864 network, this certification process could be performed at a central 865 location before the device is physically installed at its intended 866 location. In an unmanaged network, this process must be autonomic, 867 including the bootstrap phase. 869 A 128-bit Device Certifcate Tag, which is generated by taking a 870 cryptographic hash over the device certificate, is a short 871 presentation for GDNP messages. It is the index key to find the 872 device certificate in a recipient's local trusted certificate record. 874 The tag value is formed by taking a SHA-1 hash algorithm over the 875 corresponding device certificate and taking the leftmost 128 bits of 876 the hash result. 878 5.5. Session Identifier 880 A 24-bit opaque value used to distinguish multiple sessions between 881 the same two devices. A new Session ID SHOULD be generated for every 882 new Request message. All follow-up messages in the same negotiation 883 procedure, which is initiated by the request message, SHOULD carry 884 the same Session ID. 886 The Session ID SHOULD have a very low collision rate locally. It is 887 RECOMMENDED to be generated by a pseudo-random algorithm using a seed 888 which is unlikely to be used by any other device in the same network. 890 5.6. GDNP Messages 892 This document defines the following GDNP message format and types. 893 Message types not listed here are reserved for future use. The 894 numeric encoding for each message type is shown in parentheses. 896 5.6.1. GDNP Message Format 898 All GDNP messages share an identical fixed format header and a 899 vaiable format area for options. Every Message carries the Device 900 Certificate Tag of its sender and a Session ID. Options are 901 presented serially in the options field, with no padding between the 902 options. Options are byte-aligned. 904 The following diagram illustrates the format of GDNP messages: 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | MESSAGE_TYPE | Session ID | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | | 912 | Device Certificate Tag | 913 | | 914 | | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Options (variable length) | 917 . . 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 MESSAGE_TYPE Identifies the GDNP message type. 8-bit. 922 Session ID Identifies this negotiation session, as defined in 923 Section 6. 24-bit. 925 Device Certificate Tag 926 Present the Device Certificate, which identifies 927 the negotiation devices, as defined in Section 5.4. 928 The Device Certificate Tag is 128 bit, also defined 929 in Section 5. It is used as index key to find the 930 device certificate. 932 Options GDNP Options carried in this message. Options are 933 definded in Section 5.7, 5.8 and 5.9. 935 5.6.2. Discovery Message 936 DISCOVERY (1) A discovery initiator sends a DISCOVERY message 937 to initiate a discovery process. 939 The discovery initiator sends the DISCOVERY 940 messages to the link-local ALL_GDNP_NEIGHBOR multicast 941 address for discovery, and stores the discovery 942 results (including responding discovery objectives and 943 corresponding unicast addresses or FQDNs). 945 A DISCOVERY message MUST include a discovery objective 946 option defined in Section 5.8. 948 A DISCOVERY message MAY include one or more negotiation 949 objective option(s) (defined in Section 5.9) to indicate 950 the discovery objective that it could directly return to 951 the discovery initiatior with a Negotiation message for 952 rapid processing, if the discovery objective could act as 953 the corresponding negotiation counterpart. 955 5.6.3. Response Message 957 RESPONSE (2) A node which receives a DISCOVERY message sends a 958 Response message to respond to a discovery. 960 If the responding node itself is the discovery objective 961 of the discovery, it MUST include at least one kind of 962 locator option (defined in 5.7.8) to indicate its own 963 location. A combination of multiple kinds of locator 964 options (e.g. IP address option + FQDN option) is also 965 valid. 967 If the responding node itself is NOT the discovery 968 objective, but it knows the locator of the discovery 969 objective, then it SHOULD respond to the discovery with a 970 divert option (defined in 5.7.2) embedding a locator 971 option or a combination of multiple kinds of locator 972 options which indicate the locator(s) of the discovery 973 objective. 975 5.6.4. Request Message 977 REQUEST (3) A negotiation requesting node sends the REQUEST message 978 to the unicast address (directly stored or resolved 979 from the FQDN) of the negotiation counterpart (selected 980 from the discovery results). 982 5.6.5. Negotiation Message 984 NEGOTIATION (4)A negotiation counterpart sends a NEGOTIATION 985 message in response to a REQUEST message, a 986 Negotiation message, or a DISCOVERY message 987 in a negotiation process which may need 988 multiple steps. 990 5.6.6. Negotiation-ending Message 992 NEGOTIATION-ENDING (5) 993 A negotiation counterpart sends an NEGOTIATION-EDNING 994 message to close the negotiation. It MUST contain 995 one, but only one of accept/decline option, 996 defined in Section 8. It could be sent either by the 997 requesting node or the responding node. 999 5.6.7. Confirm-waiting Message 1001 CONFIRM-WAITING (6) 1002 A responding node sends a CONFIRM-WAITING message to 1003 indicate the requesting node to wait for a further 1004 negotiation response. It might be that the local 1005 process needs more time or that the negotiation 1006 depends on another triggered negotiation. This 1007 message MUST NOT include any other options than the 1008 WAITING option defined in Section 8.5. 1010 5.7. GDNP General Options 1012 This section defines the GDNP general option for the negotiation 1013 protocol signalling. Option type 10~64 is reserved for GDNP general 1014 options defined in the future. 1016 5.7.1. Format of GDNP Options 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | option-code | option-len | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | option-data | 1023 | (option-len octets) | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 Option-code An unsigned integer identifying the specific option 1027 type carried in this option. 1029 Option-len An unsigned integer giving the length of the 1030 option-data field in this option in octets. 1032 Option-data The data for the option; the format of this data 1033 depends on the definition of the option. 1035 GDNP options are scoped by using encapsulation. If an option 1036 contains other options, the outer Option-len includes the total size 1037 of the encapsulated options, and the latter apply only to the outer 1038 option. 1040 5.7.2. Divert Option 1042 The divert option is used to redirect a GDNP request to another node, 1043 which may be more appropriate for the intended negotiation. It may 1044 redirect to an entity that is known as a specific negotiation 1045 counterpart or a default gateway or a hierarchically upstream 1046 devices. The divert option MUST only be encapsulated in Negotiation- 1047 ending messages. If found elsewhere, it SHOULD be silently ignored. 1049 0 1 2 3 1050 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 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | OPTION_DIVERT | option-len | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Locator Option (s) of Diversion Device(s) | 1055 . . 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 Option-code OPTION_DIVERT (1). 1060 Option-len The total length of diverted destination 1061 sub-option(s) in octets. 1063 Locator Option (s) of Diverted Device(s) 1064 Embedded Locator Option(s), defined in Section 5.7.8, 1065 that point to diverted destination device(s). 1067 5.7.3. Accept Option 1069 The accept option is used to indicate the negotiation counterpart 1070 that the proposed negotiation content is accepted. 1072 The accept option MUST only be encapsulated in Negotiation-ending 1073 messages. If found elsewhere, it SHOULD be silently ignored. 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | OPTION_ACCEPT | option-len | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 Option-code OPTION_ACCEPT (2). 1083 Option-len 0. 1085 5.7.4. Decline Option 1087 The decline option is used to indicate the negotiation counterpart 1088 the proposed negotiation content is declined and end the negotiation 1089 process. 1091 The decline option MUST only be encapsulated in Negotiation-ending 1092 messages. If found elsewhere, it SHOULD be silently ignored. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | OPTION_DECLINE | option-len | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Option-code OPTION_DECLINE (3). 1102 Option-len 0. 1104 Notes: there are scenarios where a negotiation counterpart wants to 1105 decline the proposed negotiation content and continue the negotiation 1106 process. For these scenarios, the negotiation counterpart SHOULD use 1107 a Response message, with either an objective option that contains at 1108 least one data field with all bits set to 1 to indicate a meaningless 1109 initial value, or a specific objective option that provides further 1110 conditions for convergence. 1112 5.7.5. Waiting Time Option 1114 The waiting time option is used to indicate that the negotiation 1115 counterpart needs to wait for a further negotiation response, since 1116 the processing might need more time than usual or it might depend on 1117 another triggered negotiation. 1119 The waiting time option MUST only be encapsulated in Confirm-waiting 1120 messages. If found elsewhere, it SHOULD be silently ignored. 1122 The counterpart SHOULD send a Response message or another Confirm- 1123 waiting message before the current waiting time expires. If not, the 1124 initiator SHOULD abandon or restart the negotiation procedure, to 1125 avoid an indefinite wait. 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | OPTION_WAITING | option-len | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Time | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 Option-code OPTION_WAITING (4). 1137 Option-len 4, in octets. 1139 Time The time is counted in millisecond as a unit. 1141 5.7.6. Certificate Option 1143 The Certificate option carries the certificate of the sender. The 1144 format of the Certificate option is as follows: 1146 0 1 2 3 1147 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 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | OPTION Certificate | option-len | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | | 1152 . Certificate (variable length) . 1153 . . 1154 | | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Option-code OPTION_CERT_PARAMETER (5) 1159 Option-len Length of certificate in octets 1161 Public key A variable-length field containing a certificate 1163 5.7.7. Signature Option 1165 The Signature option allows public key-based signatures to be 1166 attached to a GDNP message. The Signature option is REQUIRED in 1167 every GDNP message and could be any place within the GDNP message. 1168 It protects the entire GDNP header and options. A TimeStamp has been 1169 integrated in the Signature Option for anti-replay protection. The 1170 format of the Signature option is described as follows: 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | OPTION_SIGNATURE | option-len | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | HA-id | SA-id | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Timestamp (64-bit) | 1180 | | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | | 1183 . Signature (variable length) . 1184 . . 1185 | | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 Option-code OPTION_SIGNATURE (6) 1189 Option-len 12 + Length of Signature field in octets. 1191 HA-id Hash Algorithm id. The hash algorithm is used for 1192 computing the signature result. This design is 1193 adopted in order to provide hash algorithm agility. 1194 The value is from the Hash Algorithm for GDNP 1195 registry in IANA. The initial value assigned 1196 for SHA-1 is 0x0001. 1198 SA-id Signature Algorithm id. The signature algorithm is 1199 used for computing the signature result. This 1200 design is adopted in order to provide signature 1201 algorithm agility. The value is from the Signature 1202 Algorithm for GDNP registry in IANA. The initial 1203 value assigned for RSASSA-PKCS1-v1_5 is 1204 0x0001. 1206 Timestamp The current time of day (NTP-format timestamp 1207 [RFC5905] in UTC (Coordinated Universal Time), a 1208 64-bit unsigned fixed-point number, in seconds 1209 relative to 0h on 1 January 1900.). It can reduce 1210 the danger of replay attacks. 1212 Signature A variable-length field containing a digital 1213 signature. The signature value is computed with 1214 the hash algorithm and the signature algorithm, as 1215 described in HA-id and SA-id. The signature 1216 constructed by using the sender's private key 1217 protects the following sequence of octets: 1219 1. The GDNP message header. 1221 2. All GDNP options including the Signature option 1222 (fill the signature field with zeroes). 1224 The signature field MUST be padded, with all 0, to 1225 the next 16 bit boundary if its size is not an even 1226 multiple of 8 bits. The padding length depends on 1227 the signature algorithm, which is indicated in the 1228 SA-id field. 1230 5.7.8. Locator Options 1232 These locator options are used to present a device's or interface's 1233 reachability information. They are Locator IPv4 Address Option, 1234 Locator IPv6 Address Option and Locator FQDN (Fully Qualified Domain 1235 Name) Option. 1237 5.7.8.1. Locator IPv4 address option 1239 0 1 2 3 1240 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 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | OPTION_LOCATOR_IPV4ADDR | option-len | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | IPv4-Address | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 Option-code OPTION_LOCATOR_IPV4ADDR (7) 1249 Option-len 4, in octets. 1251 IPv4-Address The IPv4 address locator of the device/interface. 1253 5.7.8.2. Locator IPv6 address option 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | OPTION_LOCATOR_IPV6ADDR | option-len | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | | 1261 | IPv6-Address | 1262 | | 1263 | | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 Option-code OPTION_LOCATOR_IPV6ADDR (8). 1268 Option-len 16, in octets. 1270 IPv6-Address The IPv6 address locator of the device/interface. 1272 Note: link-local IPv6 address SHOULD be avoided when this option is 1273 used in the Divert option. It may create a connection problem. 1275 5.7.8.3. Locator FQDN option 1276 0 1 2 3 1277 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 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | OPTION_FQDN | option-len | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Fully Qualified Domain Name | 1282 | (variable length) | 1283 . . 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 Option-code OPTION_FQDN (9). 1288 Option-len Length of Fully Qualified Domain Name in octets. 1290 Domain-Name The Fully Qualified Domain Name of the entity. 1292 5.8. Discovery Objective Option 1294 The discovery objective option is to express the discovery objectives 1295 that the initiating node wants to discover. 1297 0 1 2 3 1298 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 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | OPTION_DISOBJ | option-len | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Expression of Discovery Objectives (TBD) | 1303 . . 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 Option-code OPTION_DISOBJ (TBD). 1308 Option-len The total length in octets. 1310 Expression of Discovery Objectives (TBD) 1311 This field is to express the discovery objectives 1312 that the initiating node wants to discover. It might 1313 be network functionality, role-based network element 1314 or service agent. 1316 5.9. Negotiation Objective Options and Considerations 1318 The Negotiation Objective Options contain negotiation objectives, 1319 which are various according to different functions/services. They 1320 MUST be carried by Discovery, Request or Negotiation Messages only. 1321 Objective options SHOULD be assigned an option type greater than 64 1322 in the GDNP option table. 1324 For most scenarios, there SHOULD be initial values in the negotiation 1325 requests. Consequently, the Objective options SHOULD always be 1326 completely presented in a Request message. If there is no initial 1327 value, the bits in the value field SHOULD all be set to 1 to indicate 1328 a meaningless value, unless this is inappropriate for the specific 1329 negotiation objective. 1331 5.9.1. Organizing of GDNP Options 1333 Naturally, a negotiation objective, which is based on a specific 1334 service or function or action, SHOULD be organized as a single GDNP 1335 option. It is NOT RECOMMENDED to organize multiple negotiation 1336 objectives into a single option. 1338 A negotiation objective may have multiple parameters. Parameters can 1339 be categorized into two class: the obligatory ones presented as fixed 1340 fields; and the optional ones presented in TLV sub-options. It is 1341 NOT RECOMMENDED to split parameters in a single objective into 1342 multiple options, unless they have different response periods. An 1343 exception scenario may also be described by split objectives. 1345 5.9.2. Vendor Specific Options 1347 Option codes 128~159 have been reserved for vendor specific options. 1348 Multiple option codes have been assigned because a single vendor may 1349 use multiple options simultaneously. These vendor specific options 1350 are highly likely to have different meanings when used by different 1351 vendors. Therefore, they SHOULD NOT be used without an explicit 1352 human decision. They are not suitable for unmanaged networks such as 1353 home networks. 1355 5.9.3. Experimental Options 1357 Option code 176~191 have been reserved for experimental options. 1358 Multiple option codes have been assigned because a single experiment 1359 may use multiple options simultaneously. These experimental options 1360 are highly likely to have different meanings when used for different 1361 experiments. Therefore, they SHOULD NOT be used without an explicit 1362 human decision. They are not suitable for unmanaged networks such as 1363 home networks. 1365 5.10. Items for Future Work 1367 There are a few open design questions that are worthy of more work in 1368 the near future, as listed below: 1370 o UDP vs TCP: For now, this specification has chosen UDP as message 1371 transport mechanism. However, this is not closed yet. UDP is 1372 good for short conversations, fitting the divert scenarios well. 1373 However, it may have issues with large packets. TCP is good for 1374 stable and long sessions, with a little bit of time consumption 1375 during the session establishment stage. If messages exceed a 1376 reasonable MTU, a TCP mode may be necessary. 1378 o Message encryption: should GDNP messages be (optionally) encrypted 1379 as well as signed, to protect against internal eavesdropping or 1380 monitoring within the network? 1382 o TLS or DTLS vs built-in security mechanism. For now, this 1383 specification has chosen a PKI based build-in security mechanism. 1384 However, TLS or DTLS might be chosen as security infrastructure 1385 for simplification reasons. 1387 o Timeout for lost Negotiation Ending and other messages to be 1388 added. 1390 o GDNP currently requires every participant to have an NTP- 1391 synchronized clock. Is this OK for low-end devices? 1393 o Would use of MDNS have any impact on the Locator FQDN option? 1395 o Use case. A use case may help readers to understand the 1396 applicability of this specification. However, the authors have 1397 not yet decided whether to have a separate document or have it in 1398 this document. General uses cases for AN have been developed, but 1399 they are not specific enough for this purpose. 1401 o Rules about how data items are defined in a negotiation objective. 1402 Maybe a formal information model is needed. 1404 o We currently assume that there is only one counterpart for each 1405 discovery action. If this is false or one negotiation request 1406 receives multiple different responses, how does the initiator 1407 choose between them? Could it split them into multiple follow-up 1408 negotiations? 1410 o Alternatives to TLV format. It may be useful to provide a generic 1411 method of carrying negotiation objectives in a high-level format 1412 such as YANG or XML schema. It may also be useful to provide a 1413 generic method of carrying existing configuration information such 1414 as DHCP(v6) or IPv6 RA messages. These features could be provided 1415 by encapsulating such messages in their own TLVs. 1417 6. Security Considerations 1419 It is obvious that a successful attack on negotiation-enabled nodes 1420 would be extremely harmful, as such nodes might end up with a 1421 completely undesirable configuration. Security considerations are in 1422 the following aspects as the following. 1424 - Authentication 1426 A cryptographically authenticated identity for each device is 1427 needed in an autonomic network. It is not safe to assume that a 1428 large network is physically secured against interference or that 1429 all personnel are trustworthy. Each autonomic device should be 1430 capable of proving its identity and authenticating its messages. 1431 One approach for the negotiation protocol is using certificate- 1432 based security mechanism and its verification mechanism in GDNP 1433 message exchanging provides the authentication and data integrity 1434 protection. 1436 The timestamp mechanism provides an anti-replay function. 1438 Since GDNP is intended to be deployed in a single administrative 1439 domain recommended to operate its own trust anchor and CA, there 1440 is no need for a trusted public third party. 1442 - Privacy 1444 Generally speaking, no personal information is expected to be 1445 involved in the negotiation protocol, so there should be no direct 1446 impact on personal privacy. Nevertheless, traffic flow paths, 1447 VPNs, etc. may be negotiated, which could be of interest for 1448 traffic analysis. Also, carriers generally want to conceal 1449 details of their network topology and traffic density from 1450 outsiders. Therefore, since insider attacks cannot be prevented 1451 in a large carrier network, the security mechanism for the 1452 negotiation protocol needs to provide message confidentiality. 1454 - DoS Attack Protection 1456 TBD. 1458 7. IANA Considerations 1460 Section 5.3 defines the following multicast addresses, which have 1461 been assigned by IANA for use by GDNP: 1463 ALL_GDNP_NEIGHBOR multicast address (IPv6): (TBD1) 1464 ALL_GDNP_NEIGHBOR multicast address (IPv4): (TBD2) 1466 Section 5.3 defines the following UDP port, which have been assigned 1467 by IANA for use by GDNP: 1469 GDNP Listen Port: (TBD3) 1471 This document defined a new General Discovery and Negotiation 1472 Protocol. The IANA is requested to create a new GDNP registry. The 1473 IANA is also requested to add two new registry tables to the newly- 1474 created GDNP registry. The two tables are the GDNP Messages table 1475 and GDNP Options table. 1477 Initial values for these registries are given below. Future 1478 assignments are to be made through Standards Action or Specification 1479 Required [RFC5226]. Assignments for each registry consist of a type 1480 code value, a name and a document where the usage is defined. 1482 GDNP Messages table. The values in this table are 16-bit unsigned 1483 integers. The following initial values are assigned in Section 5.6 1484 in this document: 1486 Type | Name | RFCs 1487 ---------+-----------------------------+------------ 1488 0 |Reserved | this document 1489 1 |Request Message | this document 1490 2 |Negotiation Message | this document 1491 3 |Negotiation-end Message | this document 1492 4 |Confirm-waiting Message | this document 1494 GDNP Options table. The values in this table are 16-bit unsigned 1495 integers. The following initial values are assigned in Section 5.7 1496 and Section 5.9 in this document: 1498 Type | Name | RFCs 1499 ---------+-----------------------------+------------ 1500 0 |Reserved | this document 1501 1 |Divert Option | this document 1502 2 |Accept Option | this document 1503 3 |Decline Option | this document 1504 4 |Waiting Time Option | this document 1505 5 |Certificate Option | this document 1506 6 |Sigature Option | this document 1507 7 |Device IPv4 Address Option | this document 1508 8 |Device IPv6 Address Option | this document 1509 9 |Device FQDN Option | this document 1510 10~64 |Reserved for future CDNP | this document 1511 |General Options | 1512 128~159 |Vendor Specific Options | this document 1513 176~191 |Experimental Options | this document 1515 The IANA is also requested to create two new registry tables in the 1516 GDNP Parameters registry. The two tables are the Hash Algorithm for 1517 GDNP table and the Signature Algorithm for GDNP table. 1519 Initial values for these registries are given below. Future 1520 assignments are to be made through Standards Action or Specification 1521 Required [RFC5226]. Assignments for each registry consist of a name, 1522 a value and a document where the algorithm is defined. 1524 Hash Algorithm for GDNP. The values in this table are 16-bit 1525 unsigned integers. The following initial values are assigned for 1526 Hash Algorithm for GDNP in this document: 1528 Name | Value | RFCs 1529 ---------------------+-----------+------------ 1530 Reserved | 0x0000 | this document 1531 SHA-1 | 0x0001 | this document 1532 SHA-256 | 0x0002 | this document 1534 Signature Algorithm for GDNP. The values in this table are 16-bit 1535 unsigned integers. The following initial values are assigned for 1536 Signature Algorithm for GDNP in this document: 1538 Name | Value | RFCs 1539 ---------------------+-----------+------------ 1540 Reserved | 0x0000 | this document 1541 RSASSA-PKCS1-v1_5 | 0x0001 | this document 1543 8. Acknowledgements 1545 Valuable comments were received from Zhenbin Li, Dacheng Zhang, Rene 1546 Struik, Dimitri Papadimitriou, and other participants in the ANIMA 1547 and NMRG working group. 1549 This document was produced using the xml2rfc tool [RFC2629]. 1551 9. Change log [RFC Editor: Please remove] 1553 draft-carpenter-anima-discovery-negotiation-protocol-00, combination 1554 of draft-jiang-config-negotiation-ps-03 and draft-jiang-config- 1555 negotiation-protocol-02, 2014-10-08. 1557 10. References 1559 10.1. Normative References 1561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1562 Requirement Levels", BCP 14, RFC 2119, March 1997. 1564 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1565 Housley, R., and W. Polk, "Internet X.509 Public Key 1566 Infrastructure Certificate and Certificate Revocation List 1567 (CRL) Profile", RFC 5280, May 2008. 1569 10.2. Informative References 1571 [I-D.chaparadza-intarea-igcp] 1572 Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. 1573 Mahkonen, "IP based Generic Control Protocol (IGCP)", 1574 draft-chaparadza-intarea-igcp-00 (work in progress), July 1575 2011. 1577 [I-D.ietf-homenet-hncp] 1578 Stenberg, M. and S. Barth, "Home Networking Control 1579 Protocol", draft-ietf-homenet-hncp-01 (work in progress), 1580 June 2014. 1582 [I-D.ietf-netconf-restconf] 1583 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1584 Protocol", draft-ietf-netconf-restconf-02 (work in 1585 progress), October 2014. 1587 [I-D.irtf-nmrg-an-gap-analysis] 1588 Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis 1589 for Autonomic Networking", draft-irtf-nmrg-an-gap- 1590 analysis-02 (work in progress), October 2014. 1592 [I-D.irtf-nmrg-autonomic-network-definitions] 1593 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1594 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1595 Networking - Definitions and Design Goals", draft-irtf- 1596 nmrg-autonomic-network-definitions-04 (work in progress), 1597 October 2014. 1599 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1600 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1601 Functional Specification", RFC 2205, September 1997. 1603 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1604 June 1999. 1606 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1607 "Remote Authentication Dial In User Service (RADIUS)", RFC 1608 2865, June 2000. 1610 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1611 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1612 Tunnels", RFC 3209, December 2001. 1614 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1615 and M. Carney, "Dynamic Host Configuration Protocol for 1616 IPv6 (DHCPv6)", RFC 3315, July 2003. 1618 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1619 Simple Network Management Protocol (SNMP)", STD 62, RFC 1620 3416, December 2002. 1622 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 1623 Hashes in Internet Protocols", RFC 4270, November 2005. 1625 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1626 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1627 September 2007. 1629 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1630 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1631 May 2008. 1633 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1634 Time Protocol Version 4: Protocol and Algorithms 1635 Specification", RFC 5905, June 2010. 1637 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1638 Signalling Transport", RFC 5971, October 2010. 1640 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1641 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1642 6241, June 2011. 1644 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1645 "Diameter Base Protocol", RFC 6733, October 2012. 1647 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1648 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1649 2013. 1651 Authors' Addresses 1653 Brian Carpenter 1654 Department of Computer Science 1655 University of Auckland 1656 PB 92019 1657 Auckland 1142 1658 New Zealand 1660 Email: brian.e.carpenter@gmail.com 1662 Sheng Jiang 1663 Huawei Technologies Co., Ltd 1664 Q14, Huawei Campus 1665 No.156 Beiqing Road 1666 Hai-Dian District, Beijing 100095 1667 P.R. China 1669 Email: jiangsheng@huawei.com 1671 Bing Liu 1672 Huawei Technologies Co., Ltd 1673 Q14, Huawei Campus 1674 No.156 Beiqing Road 1675 Hai-Dian District, Beijing 100095 1676 P.R. China 1678 Email: leo.liubing@huawei.com