idnits 2.17.1 draft-jiang-config-negotiation-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2014) is 3585 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 (-06) exists of draft-irtf-nmrg-an-gap-analysis-00 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track B. Carpenter 5 Expires: December 28, 2014 Univ. of Auckland 6 B. Liu 7 Huawei Technologies Co., Ltd 8 June 26, 2014 10 Configuration Discovery and Negotiation Protocol for Network Devices 11 draft-jiang-config-negotiation-protocol-02 13 Abstract 15 This document defines a new protocol that enables intelligent devices 16 to dynamically discover and negotiate their configuration with 17 counterpart devices. This document only defines a general protocol 18 as a negotiation platform while the negotiation objectives for 19 specific scenarios are to be described in 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 December 28, 2014. 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. CDNP Protocol Overview . . . . . . . . . . . . . . . . . . . 4 58 3.1. IP Version Independent . . . . . . . . . . . . . . . . . 5 59 3.2. Objective Oriented Discovery Mechanism . . . . . . . . . 5 60 3.3. Neighbor Diverting Discovery Mechanism . . . . . . . . . 5 61 3.4. Certificate-based Security Mechanism . . . . . . . . . . 6 62 3.4.1. Support for algorithm agility . . . . . . . . . . . . 7 63 3.4.2. Message validation on reception . . . . . . . . . . . 7 64 3.4.3. TimeStamp checking . . . . . . . . . . . . . . . . . 8 65 3.5. Negotiation Procedures . . . . . . . . . . . . . . . . . 9 66 4. CDNP Constants . . . . . . . . . . . . . . . . . . . . . . . 10 67 5. Device Identifier and Certificate Tag . . . . . . . . . . . . 10 68 6. Session Identifier . . . . . . . . . . . . . . . . . . . . . 11 69 7. CDNP Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. CDNP Messsage Format . . . . . . . . . . . . . . . . . . 11 71 7.2. Request Message . . . . . . . . . . . . . . . . . . . . . 12 72 7.3. Negotiation Message . . . . . . . . . . . . . . . . . . . 12 73 7.4. Negotiation-ending Message . . . . . . . . . . . . . . . 13 74 7.5. Confirm-waiting Message . . . . . . . . . . . . . . . . . 13 75 8. CDNP General Options . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Format of CDNP Options . . . . . . . . . . . . . . . . . 13 77 8.2. Divert Option . . . . . . . . . . . . . . . . . . . . . . 14 78 8.3. Accept Option . . . . . . . . . . . . . . . . . . . . . . 15 79 8.4. Decline Option . . . . . . . . . . . . . . . . . . . . . 15 80 8.5. Waiting Time Option . . . . . . . . . . . . . . . . . . . 16 81 8.6. Certificate Option . . . . . . . . . . . . . . . . . . . 17 82 8.7. Signature Option . . . . . . . . . . . . . . . . . . . . 17 83 8.8. Locator Options . . . . . . . . . . . . . . . . . . . . . 18 84 8.8.1. Locator IPv4 address option . . . . . . . . . . . . . 19 85 8.8.2. Locator IPv6 address option . . . . . . . . . . . . . 19 86 8.8.3. Locator FQDN option . . . . . . . . . . . . . . . . . 19 87 9. Objective Options and Considerations . . . . . . . . . . . . 20 88 9.1. Organizing of CDNP Options . . . . . . . . . . . . . . . 20 89 9.2. Vendor Specific Options . . . . . . . . . . . . . . . . . 21 90 9.3. Experimental Options . . . . . . . . . . . . . . . . . . 21 91 10. Items for Future Work . . . . . . . . . . . . . . . . . . . . 21 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 95 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 24 96 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 15.1. Normative References . . . . . . . . . . . . . . . . . . 25 98 15.2. Informative References . . . . . . . . . . . . . . . . . 25 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 The success of the Internet has made IP-based networks bigger and 104 more complicated. Large-scale ISP networks have become more and more 105 problematic for human based management. Also operational costs are 106 growing quickly. Consequently, there are therefore increased 107 requirements for autonomy in the networks. General aspects of 108 autonomic networks are discussed in 109 [I-D.irtf-nmrg-autonomic-network-definitions] and 110 [I-D.irtf-nmrg-an-gap-analysis]. In order to fulfil autonomy, 111 devices that are more intelligent need to be able to negotiate 112 directly with each other. [I-D.jiang-config-negotiation-ps] 113 describes the requirements and application scenarios for network 114 device negotiation. It also describes a behavior model of a generic 115 negotiation protocol. Prior to negotiation, devices must discover 116 each other. The design of Configuration Discovery and Negotiation 117 Protocol (CDNP) in this document is mainly based on this behavior 118 model. 120 Although many negotiations may happen between distributed horizontal 121 peers, the main target scenarios are still hierarchical networks, 122 which is the major structure of current large-scale networks. Thus, 123 where necessary, we assume that each network element has a 124 hierarchical superior. Of course, the protocol itself is capable of 125 being used in a small and/or flat network structure such as a small 126 office or home network, too. 128 This document defines a generic discovery and negotiation protocol, 129 named Configuration Discovery and Negotiation Protocol (CDNP), that 130 can be used to control decision process among distributed devices or 131 between networks. The newly defined CDNP in this document adapts a 132 tight certificate-based mechanism, which needs a Public Key 133 Infrastracture (PKI, [RFC5280]) system. The PKI may be managed by an 134 operator or be autonomic. The document also introduces a new 135 discovery mechanism, which is based on a neighbor learning process 136 and is oriented towards negotiation objectives. 138 It is understood that in realistic deployments, not all devices will 139 support CDNP. Such mixed scenarios are not discussed in this 140 specification. 142 2. Requirements Language and Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 [RFC2119] when they appear in ALL CAPS. When these words are not in 148 ALL CAPS (such as "should" or "Should"), they have their usual 149 English meanings, and are not to be interpreted as [RFC2119] key 150 words. 152 o Negotiation Objective: specific negotiation content, which needs 153 to be decided in coordination with another network device. It is 154 naturally based on a specific service or function or action. It 155 could be a logical, numeric, or string value or a more complex 156 data structure. 158 o Negotiation Initiator: a device that spontaneously starts 159 discovery or negotiation by sending a request message referring to 160 a specific negotiation objective. 162 o Negotiation Counterpart: a peer device with which the Negotiation 163 Initiator negotiates a specific negotiation objective. 165 o Device Identifier: a public key, which identifies the device in 166 CDNP messages. It is assumed that its associated private key is 167 maintained in the device only. 169 o Device Certificate: A certificate for a single device, also the 170 identitier of the device, further described in Section 5. 172 o Device Certificate Tag: a tag, which is bound to the device 173 identitier. It is used to present Device Certificate in short 174 form. 176 3. CDNP Protocol Overview 178 The Configuration Discovery and Negotiation protocol is designed to 179 be a generic platform, which is independent from the negotiation 180 contents. It only takes care of the general intercommunication 181 between negotiation counterparts. The negotiation contents vary, 182 giving the various negotiation objectives and the different pairs of 183 negotiating counterparts. CDNP runs over UDP. 185 The CDNP has been designed based on simple initiator/responder model, 186 while multiple-party negotiations could be completed by indirect 187 steps. The initiator requests a particular objective and the 188 counterpart responds accordingly. 190 3.1. IP Version Independent 192 To be a generic platform, CDNP should be IP version independent. In 193 other words, it should be able to run over IPv6 and IPv4. Its 194 messages and general options are neutral with respect to the IP 195 version. 197 However, some functions, such as multicasting or broadcasting on a 198 link, might need to be IP version dependent. For these parts, the 199 document defines support for both IP versions separately. 201 3.2. Objective Oriented Discovery Mechanism 203 Typically, one network device has multiple functions. It may be 204 involved in different negotiation processes for different negotiation 205 objectives. Therefore, the traditional topology-oriented device 206 discovery mechanisms are not sufficient for CDNP. A new discovery 207 mechanism is needed to find negotiation counterparts based on a 208 specific negotiation objective. As a result, an objective-based 209 discovery mechanism is described in this document. 211 For every new negotiation objective, the negotiation initiator needs 212 to start a new discovery process in order to find the proper 213 negotiation counterpart. Because a listening CDNP-enabled device has 214 to know the requested negotiation objective to decide whether it is a 215 proper negotiation counterpart and make a response, the discovery 216 process needs to be tightly coupled with the request process. 217 Therefore, in this document, the discovery process is merged into the 218 request process. There is no need for an independent discovery 219 message and process. 221 3.3. Neighbor Diverting Discovery Mechanism 223 We now discuss the general flow of Request, Negotiation, and 224 Negotiation-Ending messages, and Accept, Decline and Divert options. 225 Details of the options are given later. 227 Discovery starts as on-link operation. However, negotiation may 228 continue either on-link or off-link. The Divert option can tell the 229 negotiation initiator to contact an off-link counterpart. 231 Every Request message is sent by a negotiation initiator to the 232 ALL_CDNP_NEIGHBOR multicast address (Section 4). 234 If the neighbor device is a proper negotiation counterpart, it MAY 235 respond with a Negotiation message to start a negotiation process, or 236 with a Negotiation-Ending message in the case of a clear Accept or 237 Decline. 239 If the neigbor device is not a proper negotiation counterpart for the 240 objective given in the Request message, but knows a proper 241 negotiation counterpart, for example because it negotiated the same 242 objective with that other negotiation counterpart before, it SHOULD 243 respond with a Negotiation-Ending message with a Divert option 244 pointed to the proper negotiation counterpart. If the neigbor device 245 is not a proper negotiation counterpart, but does not know a proper 246 negotiation counterpart, it SHOULD respond with a Negotiation-Ending 247 message with a Divert option pointed to its hierachical upstream 248 device. 250 After a CDNP device successfully negotiated a specific objective with 251 a negotiation counterpart, it SHOULD record this negotiation 252 counterpart with this objective type locally. This record may be 253 used for future negotiation or to pass to another neighbor as a 254 Divert option. This learning mechanism should be able to support 255 most network establishment scenarios. 257 3.4. Certificate-based Security Mechanism 259 A certification based security mechanism provides security properties 260 for CDNP: 262 o the identity of a CDNP message sender can be verified by a 263 recipient. 265 o the integrity of CDNP message can be checked by the recipient of 266 the message. 268 o anti-replay protection on the CDNP message recipient. 270 The authority of the CDNP message sender depends on a Public Key 271 Infrastructure (PKI) system with a Certification Authority (CA), 272 which should normally be run by the network operator. In the case of 273 a network with no operator, such as a small office or home network, 274 the PKI itself needs to be established by an autonomic process, which 275 is out of scope for this specification. 277 A Request message MUST carry a Certificate option, defined in 278 Section 8.6. The first Negotiation Message, responding to a Request 279 message, SHOULD also carry a Certificate option. Using these 280 messages, recipients build their certificate stores, indexed by the 281 Device Certificate Tags included in every CDNP message. This process 282 is described in more detail below. 284 Every message MUST carry a signature option, defined in Section 8.7. 286 For now, the authors do not think packet size is a problem. In this 287 CDNP specification, there SHOULD NOT be multiple certificates in a 288 single message. The current most used public keys are 1024/2048 289 bits, some may reach 4096. With overhead included, a single 290 certificate is less than 500 bytes. Messages should be far shorter 291 than the normal packet MTU within a modern network. 293 3.4.1. Support for algorithm agility 295 Hash functions are used to provide message integrity checks. In 296 order to provide a means of addressing problems that may emerge in 297 the future with existing hash algorithms, as recommended in 298 [RFC4270], a mechanism for negotiating the use of more secure hashes 299 in the future is provided. 301 In addition to hash algorithm agility, a mechanism for signature 302 algorithm agility is also provided. 304 The support for algorithm agility in this document is mainly a 305 unilateral notification mechanism from sender to recipient. If the 306 recipient does not support the algorithm used by the sender, it 307 cannot authenticate the message. Senders in a single administrative 308 domain are not required to upgrade to a new algorithm simultaneously. 310 So far, the algorithm agility is supported by one-way notification, 311 rather than negotiation mode. As defined in Section 8.7, the sender 312 notifies the recipient what hash/signature algorithms it uses. If 313 the responder doesn't know a new algorithm used by the sender, the 314 negotiation request would fail. In order to establish a negotiation 315 session, the sender MAY fall back to an older, less preferred 316 algorithm. To avoid downgrade attacks it MUST NOT fall back to an 317 algorithm considered weak. 319 3.4.2. Message validation on reception 321 When receiving a CDNP message, a recipient MUST discard the CDNP 322 message if the Signature option is absent, or the Certificate option 323 is in a Request Message. 325 For the Request message and the Response message with a Certification 326 Option, the recipient MUST first check the authority of this sender 327 following the rules defined in [RFC5280]. After successful authority 328 validation, an implementation MUST add the sender's certification 329 into the local trust certificate record indexed by the associated 330 Device Certificate Tag, defined in Section 5. 332 The recipient MUST now authenticate the sender by verifying the 333 Signature and checking a timestamp, as specified in Section 3.4.3. 335 The order of two procedures is left as an implementation decision. 336 It is RECOMMENDED to check timestamp first, because signature 337 verification is much more computationally expensive. 339 The signature field verification MUST show that the signature has 340 been calculated as specified in Section 8.7. The public key used for 341 signature validation is obtained from the certificate either carried 342 by the message or found from a local trust certificate record by 343 searching the message-carried Device Certicate Tag. 345 Only the messages that get through both the signature verifications 346 and timestamp check are accepted and continue to be handled for their 347 contained CDNP options. Messages that do not pass the above tests 348 MUST be discarded as insecure messages. 350 3.4.3. TimeStamp checking 352 Recipients SHOULD be configured with an allowed timestamp Delta 353 value, a "fuzz factor" for comparisons, and an allowed clock drift 354 parameter. The recommended default value for the allowed Delta is 355 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 356 drift, 0.01 second. 358 The timestamp is defined in the Signature Option, Section 8.7. To 359 facilitate timestamp checking, each recipient SHOULD store the 360 following information for each sender: 362 o The receive time of the last received and accepted CDNP message. 363 This is called RDlast. 365 o The time stamp in the last received and accepted CDNP message. 366 This is called TSlast. 368 An accepted CDNP message is any successfully verified (for both 369 timestamp check and signature verification) CDNP message from the 370 given peer. It initiates the update of the above variables. 371 Recipients MUST then check the Timestamp field as follows: 373 o When a message is received from a new peer (i.e., one that is not 374 stored in the cache), the received timestamp, TSnew, is checked, 375 and the message is accepted if the timestamp is recent enough to 376 the reception time of the packet, RDnew: 378 -Delta < (RDnew - TSnew) < +Delta 380 The RDnew and TSnew values SHOULD be stored in the cache as RDlast 381 and TSlast. 383 o When a message is received from a known peer (i.e., one that 384 already has an entry in the cache), the timestamp is checked 385 against the previously received CDNP message: 387 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 389 If this inequality does not hold, the recipient SHOULD silently 390 discard the message. If, on the other hand, the inequality holds, 391 the recipient SHOULD process the message. 393 Moreover, if the above inequality holds and TSnew > TSlast, the 394 recipient SHOULD update RDlast and TSlast. Otherwise, the 395 recipient MUST NOT update RDlast or TSlast. 397 An implementation MAY use some mechanism such as a timestamp cache to 398 strengthen resistance to replay attacks. When there is a very large 399 number of nodes on the same link, or when a cache filling attack is 400 in progress, it is possible that the cache holding the most recent 401 timestamp per sender will become full. In this case, the node MUST 402 remove some entries from the cache or refuse some new requested 403 entries. The specific policy as to which entries are preferred over 404 others is left as an implementation decision. 406 3.5. Negotiation Procedures 408 A negotiation initiator sends a negotiation request to discovered 409 negotiation counterpart devices, which may be different according to 410 different negotiation objectives. It may request relevant 411 information from the negotiation counterpart so that it can decide 412 its local configuration to give the most coordinated performance. It 413 may request the negotiation counterpart to make a matching 414 configuration in order to set up a successful communication with it. 415 It may request certain simulation or forecast result by sending some 416 dry run conditions. The details will be defined separately for each 417 type of negotiation objective. 419 If the counterpart can immediately apply the requested confguration, 420 it will give a positive (yes) answer. This will normally end the 421 negotiation phase immediately. Otherwise it will give a negative 422 (no) answer. Normally, this will not end the negotiation phase. 424 In the negative (no) case, the negotiation counterpart should be able 425 to reply with a proposed alternative configuration that it can apply 426 (typically, a configuration that uses fewer resources than requested 427 by the negotiation initiator). This will start a bi-directional 428 negotiation to reach a compromise between the two network devices. 430 The negotiation procedure is ended when one of the negotiation peers 431 sends a Negotiation Ending message, which contains an accept or 432 decline option and does not need a response from the negotiation 433 peer. 435 A negotiation procedure concerns one objective and one counterpart. 436 Both the initiator and the counterpart may take part in simultaneous 437 negotiations with various other devices, or in simultaneous 438 negotiations about different objectives. Thus, CDNP is expected to 439 be used in a multi-threaded mode. Certain negotiation objectives may 440 have restrictions on multi-threading, for example to avoid over- 441 allocating resources. 443 4. CDNP Constants 445 o ALL_CDNP_NEIGHBOR (TBD1) 447 A link-local scope multicast address used by a CDNP-enabled router 448 to discover CDNP-enabled neighbor (i.e., on-link) devices . All 449 routers that support CDNP are members of this multicast group. 451 * IPv6 multicast address: TBD1 453 * IPv4 multicast address: TBD2 455 o CDNP Listen Port (TBD3) 457 A UDP port that every CDNP-enabled network device always listens 458 to. 460 5. Device Identifier and Certificate Tag 462 A CDNP-enabled Device MUST generate a stable public/private key pair 463 before it participates in CDNP. There MUST NOT be any way of 464 accessing the private key via the network or an operator interface. 465 The device then uses the public key as its identifier, which is 466 cryptographic in nature. It is a CDNP unique identifier for a CDNP 467 participant. 469 It then gets a certificate for this public key, signed by a 470 Certificate Authority that is trusted by other network devices. The 471 Certificate Authority SHOULD be managed by the network administrator, 472 to avoid needing to trust a third party. The signed certificate 473 would be used for authentication of the message sender. In a managed 474 network, this certification process could be performed at a central 475 location before the device is physically installed at its intended 476 location. In an unmanaged network, this process must be autonomic, 477 including the bootstrap phase. 479 A 128-bit Device Certifcate Tag, which is generated by taking a 480 cryptographic hash over the device certificate, is a short 481 presentation for CDNP messages. It is the index key to find the 482 device certificate in a recipient's local trusted certificate record. 484 The tag value is formed by taking a SHA-1 hash algorithm over the 485 corresponding device certificate and taking the leftmost 128 bits of 486 the hash result. 488 6. Session Identifier 490 A 24-bit opaque value used to distinguish multiple sessions between 491 the same two devices. A new Session ID SHOULD be generated for every 492 new Request message. All followup messages in the same negotiation 493 procedure, which is initiated by the request message, SHOULD carry 494 the same Session ID. 496 The Session ID SHOULD have a very low collision rate locally. It is 497 RECOMMENDED to be generated by a pseudo-random algorithm using a seed 498 which is unlikely to be used by any other device in the same network. 500 7. CDNP Messages 502 This document defines the following CDNP message format and types. 503 Message types not listed here are reserved for future use. The 504 numeric encoding for each message type is shown in parentheses. 506 7.1. CDNP Messsage Format 508 All CDNP messages share an identical fixed format header and a 509 vaiable format area for options. Every Message carries the Device 510 Certificate Tag of its sender and a Session ID. Options are 511 presented serially in the options field, with no padding between the 512 options. Options are byte-aligned. 514 The following diagram illustrates the format of CDNP messages: 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | MESSAGE_TYPE | Session ID | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | | 522 | Device Certificate Tag | 523 | | 524 | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Options (variable length) | 527 . . 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 MESSAGE_TYPE Identifies the CDNP message type. 8-bit. 532 Session ID Identifies this negotiation session, as defined in 533 Section 6. 24-bit. 535 Device Certificate Tag 536 Present the Device Certificate, which identifies 537 the negotiation deviceas, as defined in Section 5. 538 The Device Certificate Tag is 128 bit, also defined 539 in Section 5. It is used as index key to find the 540 device certificate. 542 Options CDNP Options carried in this message. Options are 543 definded in Section 8. 545 7.2. Request Message 547 REQUEST (1) A negotiation requesting node sends a REQUEST message 548 to initiate a negotiation. 550 If the requesting node does not know any negotiation 551 counterpart, it sends the REQUEST messages to the 552 link-local ALL_CDNP_NEIGHBOR multicast address. 554 If the requesting node re-contacts a known negotiation 555 counterpart, it sends the REQUEST message to the 556 unicast address of the negotiation counterpart 557 directly. 559 7.3. Negotiation Message 560 NEGOTIATION (2)A negotiation counterpart sends an NEGOTIATION 561 message in response to a REQUEST message or a 562 Negotiation message in a negotiation process which 563 may need multiple steps. 565 7.4. Negotiation-ending Message 567 NEGOTIATION-ENDING (3) 568 A negotiation counterpart sends an NEGOTIATION-EDNING 569 message to close the negotiation. It MUST contain 570 one, but only one of accept/decline/divert option, 571 defined in Section 8. It could be sent either by the 572 requesting node or the responding node. 574 7.5. Confirm-waiting Message 576 CONFIRM-WAITING (4) 577 A responding node sends a CONFIRM-WAITING message to 578 indicate the requesting node to wait for a further 579 negotiation response. It might be that the local 580 process needs more time or that the negotiation 581 depends on another triggered negotiation. This 582 message MUST NOT include any other options than the 583 WAITING option defined in Section 8.5. 585 8. CDNP General Options 587 This section defines the CDNP general option for the negotiation 588 protocol signalling. Option type 10~64 is reserved for CDNP general 589 options defined in the future. 591 8.1. Format of CDNP Options 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | option-code | option-len | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | option-data | 598 | (option-len octets) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Option-code An unsigned integer identifying the specific option 602 type carried in this option. 604 Option-len An unsigned integer giving the length of the 605 option-data field in this option in octets. 607 Option-data The data for the option; the format of this data 608 depends on the definition of the option. 610 CDNP options are scoped by using encapsulation. If an option 611 contains other options, the outer Option-len includes the total size 612 of the encapsulated options, and the latter apply only to the outer 613 option. 615 8.2. Divert Option 617 The divert option is used to redirect a CDNP request to another node, 618 which may be more appropriate for the intended negotiation. It may 619 redirect to an entity that is known as a specific negotiation 620 counterpart or a default gateway or a hierarchically upstream 621 devices. The divert option MUST only be encapsulated in Negotiation- 622 ending messages. If found elsewhere it SHOULD be silently ignored. 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | OPTION_DIVERT | option-len | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Locator Option (s) of Diversion Device(s) | 630 . . 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Option-code OPTION_DIVERT (1). 635 Option-len The total length of diverted destination 636 sub-option(s) in octets. 638 Locator Option (s) of Diverted Device 639 Emedded Locator Option(s), defined in Section 8.8, 640 that point to diverted destination device(s). 642 8.3. Accept Option 644 The accept option is used to indicate the negotiation counterpart 645 that the proposed negotiation content is accepted. 647 The accept option MUST only be encapsulated in Negotiation-ending 648 messages. If found elsewhere it SHOULD be silently ignored. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | OPTION_ACCEPT | option-len | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Option-code OPTION_ACCEPT (2). 658 Option-len 0. 660 8.4. Decline Option 662 The decline option is used to indicate the negotiation counterpart 663 the proposed negotiation content is declined and end the negotiation 664 process. 666 The decline option MUST only be encapsulated in Negotiation-ending 667 messages. If found elsewhere it SHOULD be silently ignored. 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | OPTION_DECLINE | option-len | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 Option-code OPTION_DECLINE (3). 677 Option-len 0. 679 Notes: there are scenarios where a negotiation counterpart wants to 680 decline the proposed negotiation content and continue the negotiation 681 process. For these scenarios, the negotiation counterpart SHOULD use 682 a Response message, with either an objective option that contains at 683 least one data field with all bits set to 1 to indicate a meaningless 684 initial value, or a specific objective option that provides further 685 conditions for convergence. 687 8.5. Waiting Time Option 689 The waiting time option is used to indicate that the negotiation 690 counterpart needs to wait for a further negotiation response, since 691 the processing might need more time than usual or it might depend on 692 another triggered negotiation. 694 The waiting time option MUST only be encapsulated in Confirm-waiting 695 messages. If found elsewhere it SHOULD be silently ignored. 697 The counterpart SHOULD send a Response message or another Confirm- 698 waiting message before the current waiting time expires. If not, the 699 initiator SHOULD abandon or restart the negotiation procedure, to 700 avoid an indefinite wait. 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | OPTION_WAITING | option-len | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Time | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Option-code OPTION_WAITING (4). 712 Option-len 4, in octets. 714 Time The time is counted in millisecond as a unit. 716 8.6. Certificate Option 718 The Certificate option carries the certificate of the sender. The 719 format of the Certificate option is as follows: 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | OPTION Certificate | option-len | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | | 727 . Certificate (variable length) . 728 . . 729 | | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 Option-code OPTION_CERT_PARAMETER (5) 734 Option-len Length of certificate in octets 736 Public key A variable-length field containing a certificate 738 8.7. Signature Option 740 The Signature option allows public key-based signatures to be 741 attached to a CDNP message. The Signature option is REQUIRED in 742 every CDNP message and could be any place within the CDNP message. 743 It protects the entire CDNP header and options. A TimeStamp has been 744 integrated in the Signature Option for anti-replay protection. The 745 format of the Signature option is described as follows: 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | OPTION_SIGNATURE | option-len | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | HA-id | SA-id | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Timestamp (64-bit) | 755 | | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | | 758 . Signature (variable length) . 759 . . 760 | | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Option-code OPTION_SIGNATURE (6) 764 Option-len 12 + Length of Signature field in octets. 766 HA-id Hash Algorithm id. The hash algorithm is used for 767 computing the signature result. This design is 768 adopted in order to provide hash algorithm agility. 769 The value is from the Hash Algorithm for CDNP 770 registry in IANA. The initial value assigned 771 for SHA-1 is 0x0001. 773 SA-id Signature Algorithm id. The signature algorithm is 774 used for computing the signature result. This 775 design is adopted in order to provide signature 776 algorithm agility. The value is from the Signature 777 Algorithm for CDNP registry in IANA. The initial 778 value assigned for RSASSA-PKCS1-v1_5 is 779 0x0001. 781 Timestamp The current time of day (NTP-format timestamp 782 [RFC5905] in UTC (Coordinated Universal Time), a 783 64-bit unsigned fixed-point number, in seconds 784 relative to 0h on 1 January 1900.). It can reduce 785 the danger of replay attacks. 787 Signature A variable-length field containing a digital 788 signature. The signature value is computed with 789 the hash algorithm and the signature algorithm, as 790 described in HA-id and SA-id. The signature 791 constructed by using the sender's private key 792 protects the following sequence of octets: 794 1. The CDNP message header. 796 2. All CDNP options including the Signature option 797 (fill the signature field with zeroes). 799 The signature field MUST be padded, with all 0, to 800 the next 16 bit boundary if its size is not an even 801 multiple of 8 bits. The padding length depends on 802 the signature algorithm, which is indicated in the 803 SA-id field. 805 8.8. Locator Options 807 These locator options are used to present a device's or interface's 808 reachability information. They are Locator IPv4 Address Option, 809 Locator IPv6 Address Option and Locator FQDN (Fully Qualified Domain 810 Name) Option. 812 8.8.1. Locator IPv4 address option 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | OPTION_LOCATOR_IPV4ADDR | option-len | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | IPv4-Address | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Option-code OPTION_LOCATOR_IPV4ADDR (7) 824 Option-len 4, in octets. 826 IPv4-Address The IPv4 address locator of the device/interface. 828 8.8.2. Locator IPv6 address option 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | OPTION_LOCATOR_IPV6ADDR | option-len | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | | 836 | IPv6-Address | 837 | | 838 | | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 Option-code OPTION_LOCATOR_IPV6ADDR (8). 843 Option-len 16, in octets. 845 IPv6-Address The IPv6 address locator of the device/interface. 847 Note: link-local IPv6 address SHOULD be avoided when this option is 848 used in the Divert option. It may create a connection problem. 850 8.8.3. Locator FQDN option 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | OPTION_FQDN | option-len | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Fully Qualified Domain Name | 857 | (variable length) | 858 . . 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Option-code OPTION_FQDN (9). 863 Option-len Length of Fully Qualified Domain Name in octets. 865 Domain-Name The Fully Qualified Domain Name of the entity. 867 9. Objective Options and Considerations 869 The Objective options contains negotiation objectives, which are 870 various according to different functions/services. They MUST be 871 carried by Request or Negotiation Messages only. Objective options 872 SHOULD be assigned an option type greater than 64 in the CDNP option 873 table. 875 For most scenarios, there SHOULD be initial values in the negotiation 876 requests. Consequently, the Objective options SHOULD always be 877 completely presented in a Request message. If there is no initial 878 value, the bits in the value field SHOULD all be set to 1 to indicate 879 a meaningless value, unless this is inappropriate for the specific 880 negotiation objective. 882 9.1. Organizing of CDNP Options 884 Naturally, a negotiation objective, which is based on a specific 885 service or function or action, SHOULD be organized as a single CDNP 886 option. It is NOT RECOMMENDED to organize multiple negotiation 887 objectives into a single option. 889 A negotiation objective may have multiple parameters. Parameters can 890 be categorized into two class: the obligatory ones presented as fixed 891 fields; and the optional ones presented in TLV sub-options. It is 892 NOT RECOMMENDED to split parameters in a single objective into 893 multiple options, unless they have different response periods. An 894 exception scenario may also be described by split objectives. 896 9.2. Vendor Specific Options 898 Option codes 128~159 have been reserved for vendor specific options. 899 Multiple option codes have been assigned because a single vendor may 900 use multiple options simultaneously. These vendor specific options 901 are highly likely to have different meanings when used by different 902 vendors. Therefore, they SHOULD NOT be used without an explicit 903 human decision. They are not suitable for unmanaged networks such as 904 home networks. 906 9.3. Experimental Options 908 Option code 176~191 have been reserved for experimental options. 909 Multiple option codes have been assigned because a single experiment 910 may use multiple options simultaneously. These experimental options 911 are highly likely to have different meanings when used for different 912 experiments. Therefore, they SHOULD NOT be used without an explicit 913 human decision. They are not suitable for unmanaged networks such as 914 home networks. 916 10. Items for Future Work 918 There are a few open design questions that are worthy of more work in 919 the near future, as listed below: 921 o UDP vs TCP: For now, this specification has chosen UDP as message 922 transport mechanism. However, this is not closed yet. UDP is 923 good for short conversations, fitting the divert scenarios well. 924 However, it may have issues with large packets. TCP is good for 925 stable and long sessions, with a little bit of time comsumption 926 during the session establishment stage. If messages exceed a 927 reasonable MTU, a TCP mode may be necessary. 929 o Message encryption: should CDNP messages be encrypted as well as 930 signed, to protect against internal eavesdropping within the 931 network? 933 o TLS or DTLS vs built-in security mechanism. For now, this 934 specifcation has chosen a PKI based build-in security mechanism. 935 However, TLS or DTLS might be chosen as security infrastructure 936 for simplification reasons. 938 o Timeout for lost Negotiation Ending and other messages to be 939 added. 941 o CDNP currently requires every participant to have an NTP- 942 synchronized clock. Is this OK for low-end devices? 944 o Would use of MDNS have any impact on the Locator FQDN option? 946 o Use case. A use case may help readers to understand the 947 applicability of this specification. However, the authors have 948 not yet decided whether to have a separate document or have it in 949 this document. General uses cases for AN have been developed, but 950 they are not specific enough for this purpose. 952 o Rules about how data items are defined in a negotiation objective. 953 Maybe a formal information model is needed. 955 o We currently assume that there is only one counterpart for each 956 discovery action. If this is false or one negotiation request 957 receives multiple different responses, how does the initator 958 choose between them? Could it split them into multiple follow-up 959 negotiations? 961 o Alternatives to TLV format. It may be useful to provide a generic 962 method of carrying negotiation objectives in a high-level format 963 such as YANG or an XML schema. It may also be useful to provide a 964 generic method of carrying existing configuration information such 965 as DHCP(v6) or IPv6 RA messages. These features could be provided 966 by encapsulating such messages in their own TLVs. 968 11. Security Considerations 970 Using certificate-based security mechanism and its verification 971 mechanism in CDNP message exchanging provides the authentication and 972 data integrity protection. The timestamp mechanism provides an anti- 973 replay function. 975 Since CDNP is intended to be deployed in a single administrative 976 domain recommended to operate its own CA, there is no need for a 977 trusted third party. 979 12. IANA Considerations 981 Section 4 defines the following mtwpulticast addresses, which have 982 been assigned by IANA for use by CDNP: 984 ALL_CDNP_NEIGHBOR multicast address (IPv6): (TBD1) 986 ALL_CDNP_NEIGHBOR multicast address (IPv4): (TBD2) 988 Section 4 defines the following UDP port, which have been assigned by 989 IANA for use by CDNP: 991 CDNP Listen Port: (TBD3) 992 This document defined a new Configuration Discovery and Negotiation 993 Protocol. The IANA is requested to create a new CDNP registry. The 994 IANA is also requested to add two new registry tables to the newly- 995 created CDNP registry. The two tables are the CDNP Messages table 996 and CDNP Options table. 998 Initial values for these registries are given below. Future 999 assignments are to be made through Standards Action or Specification 1000 Required [RFC5226]. Assignments for each registry consist of a type 1001 code value, a name and a document where the usage is defined. 1003 CDNP Messages table. The values in this table are 16-bit unsigned 1004 integers. The following initial values are assigned in Section 7 in 1005 this document: 1007 Type | Name | RFCs 1008 ---------+-----------------------------+------------ 1009 0 |Reserved | this document 1010 1 |Request Message | this document 1011 2 |Negotiation Message | this document 1012 3 |Negotiation-end Message | this document 1013 4 |Confirm-waiting Message | this document 1015 CDNP Options table. The values in this table are 16-bit unsigned 1016 integers. The following initial values are assigned in Section 8 and 1017 Section 9 in this document: 1019 Type | Name | RFCs 1020 ---------+-----------------------------+------------ 1021 0 |Reserved | this document 1022 1 |Divert Option | this document 1023 2 |Accept Option | this document 1024 3 |Decline Option | this document 1025 4 |Waiting Time Option | this document 1026 5 |Certificate Option | this document 1027 6 |Sigature Option | this document 1028 7 |Device IPv4 Address Option | this document 1029 8 |Device IPv6 Address Option | this document 1030 9 |Device FQDN Option | this document 1031 10~64 |Reserved for future CDNP | this document 1032 |General Options | 1033 128~159 |Vendor Specific Options | this document 1034 176~191 |Experimental Options | this document 1036 The IANA is also requested to create two new registry tables in the 1037 CDNP Parameters registry. The two tables are the Hash Algorithm for 1038 CDNP table and the Signature Algorithm for CDNP table. 1040 Initial values for these registries are given below. Future 1041 assignments are to be made through Standards Action or Specification 1042 Required [RFC5226]. Assignments for each registry consist of a name, 1043 a value and a document where the algorithm is defined. 1045 Hash Algorithm for CDNP. The values in this table are 16-bit 1046 unsigned integers. The following initial values are assigned for 1047 Hash Algorithm for CDNP in this document: 1049 Name | Value | RFCs 1050 ---------------------+-----------+------------ 1051 Reserved | 0x0000 | this document 1052 SHA-1 | 0x0001 | this document 1053 SHA-256 | 0x0002 | this document 1055 Signature Algorithm for CDNP. The values in this table are 16-bit 1056 unsigned integers. The following initial values are assigned for 1057 Signature Algorithm for CDNP in this document: 1059 Name | Value | RFCs 1060 ---------------------+-----------+------------ 1061 Reserved | 0x0000 | this document 1062 RSASSA-PKCS1-v1_5 | 0x0001 | this document 1064 13. Acknowledgements 1066 Valuable comments were received from Zhenbin Li and Dacheng Zhang, 1067 and other participants in the xxx working group. 1069 This document was produced using the xml2rfc tool [RFC2629]. 1071 14. Change log [RFC Editor: Please remove] 1073 draft-jiang-config-negotiation-protocol-02: adapted scope to include 1074 discovery, multiple threads, mentioned YANG etc. encapsulation, 1075 2013-06-26. 1077 draft-jiang-config-negotiation-protocol-01: corrections and 1078 additions, 2014-04-21. 1080 draft-jiang-config-negotiation-protocol-00: original version, 1081 2013-10-19. 1083 15. References 1084 15.1. Normative References 1086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1087 Requirement Levels", BCP 14, RFC 2119, March 1997. 1089 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1090 Housley, R., and W. Polk, "Internet X.509 Public Key 1091 Infrastructure Certificate and Certificate Revocation List 1092 (CRL) Profile", RFC 5280, May 2008. 1094 15.2. Informative References 1096 [I-D.irtf-nmrg-an-gap-analysis] 1097 Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis 1098 for Autonomic Networking", draft-irtf-nmrg-an-gap- 1099 analysis-00 (work in progress), April 2014. 1101 [I-D.irtf-nmrg-autonomic-network-definitions] 1102 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1103 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1104 Networking - Definitions and Design Goals", draft-irtf- 1105 nmrg-autonomic-network-definitions-00 (work in progress), 1106 December 2013. 1108 [I-D.jiang-config-negotiation-ps] 1109 Jiang, S., Yin, Y., and B. Carpenter, "Network 1110 Configuration Negotiation Problem Statement and 1111 Requirements", draft-jiang-config-negotiation-ps-03 (work 1112 in progress), May 2014. 1114 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1115 June 1999. 1117 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 1118 Hashes in Internet Protocols", RFC 4270, November 2005. 1120 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1121 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1122 May 2008. 1124 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1125 Time Protocol Version 4: Protocol and Algorithms 1126 Specification", RFC 5905, June 2010. 1128 Authors' Addresses 1130 Sheng Jiang 1131 Huawei Technologies Co., Ltd 1132 Q14, Huawei Campus 1133 No.156 Beiqing Road 1134 Hai-Dian District, Beijing 100095 1135 P.R. China 1137 Email: jiangsheng@huawei.com 1139 Brian Carpenter 1140 Department of Computer Science 1141 University of Auckland 1142 PB 92019 1143 Auckland 1142 1144 New Zealand 1146 Email: brian.e.carpenter@gmail.com 1148 Bing Liu 1149 Huawei Technologies Co., Ltd 1150 Q14, Huawei Campus 1151 No.156 Beiqing Road 1152 Hai-Dian District, Beijing 100095 1153 P.R. China 1155 Email: leo.liubing@huawei.com