idnits 2.17.1 draft-wendt-modern-drip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2849 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) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Bellur 3 Internet-Draft C. Wendt, Ed. 4 Intended status: Standards Track Comcast 5 Expires: January 9, 2017 July 8, 2016 7 Distributed Registry Protocol 8 draft-wendt-modern-drip-01 10 Abstract 12 This document describes a protocol for allowing a distributed set of 13 nodes to synchronize a set of information in real-time with minimal 14 amount of delay. This is useful for registry types of information 15 like identity and telephone numbers with associated routing and 16 ownership information and could be extended to support other 17 distributed real-time information updates as well. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. DRiP Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Distributed MESH Architecture . . . . . . . . . . . . . . . . 3 57 4. DRiP procedures . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Distributed Registry Rules . . . . . . . . . . . . . . . 4 59 4.2. Node State . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2.1. API - POST /node/:nodeid/active . . . . . . . . . . . 5 61 4.2.2. API - POST /node/:nodeid/inactive . . . . . . . . . . 5 62 4.2.3. API - GET /state . . . . . . . . . . . . . . . . . . 5 63 4.3. Custom HTTP header fields . . . . . . . . . . . . . . . . 6 64 4.4. Key-Value Data Propagation Rules . . . . . . . . . . . . 8 65 4.5. Key-Value Data Update . . . . . . . . . . . . . . . . . . 8 66 4.5.1. Voting Phase . . . . . . . . . . . . . . . . . . . . 9 67 4.5.1.1. API - POST /voting . . . . . . . . . . . . . . . 10 68 4.5.1.2. POST /votingphase/node/:nodeid/response/:response 11 69 4.5.2. Commit Phase . . . . . . . . . . . . . . . . . . . . 11 70 4.5.2.1. API - POST /commit . . . . . . . . . . . . . . . 12 71 4.6. Node Sync Operation . . . . . . . . . . . . . . . . . . . 13 72 4.6.1. API - PUT /sync/node/:nodeid . . . . . . . . . . . . 13 73 4.7. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.7.1. API - POST /heartbeat/node/:nodeid . . . . . . . . . 14 75 4.8. Key-Value Data Update Entitlement Verification . . . . . 15 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 5.1. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 79 5.3. Payload Validation . . . . . . . . . . . . . . . . . . . 15 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 This document describes the Distributed Registry Protocol (DRiP). 86 DRiP defines a set of peer protocols for how an arbitrary number of 87 nodes arranged in a distributed mesh architecture can be used to 88 synchronize data in real-time across a network. 90 1.1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 Initiator Node: 97 A node that initiates data propagation. 99 Receiver Node: 100 A node that forwards the propagated key-value data. 102 2. DRiP Overview 104 DRiP uses a mix of a gossip protocol with update counters for 105 distribution of key-value data with the addition of a voting system 106 to avoid race conditions on writing of key-value data. 108 3. Distributed MESH Architecture 110 The DRiP architecture is based on a peer-to-peer communication model 111 where a given node associated with a data store is not necessarily 112 aware of the total number of nodes in the entire network. Minimally, 113 every node should reachable by at least one multi-node path from 114 every other node. Each node in the DRiP network maintains a list of 115 peer nodes from which it receives and transmits updates. Information 116 is propagated by forwarding to it's peer nodes until the information 117 received by a node has already been received. 119 ___ ___ ___ ___ 120 |DB |_________|DB | |DB |_________|DB | 121 |___| |___| |___| |___| 122 | Data | | Data | 123 | Store | | Store | 124 _|_ Cluster _|_ _|_ Cluster _|_ 125 |DB |_________|DB | |DB |_________|DB | 126 |___| |___| |___| |___| 127 \ / 128 \ / 129 _\___ DRIP _ /__ 130 |Node |------------|Node | 131 | A | HTTPS | C | 132 |_____| |_____| 133 \H H/ 134 D\T T/D 135 R\T P/R 136 I\P P/I 137 P\S S/P 138 __\__ / DRIP _____ 139 |Node |------------|Node | 140 | B | HTTPS | D | 141 |_____| |_____| 142 / / 143 ___ ___ / __/_ ___ 144 |DB |_________|DB | |DB |_________|DB | 145 |___| |___| |___| |___| 146 | Data | | Data | 147 | Store | | Store | 148 _|_ Cluster _|_ _|_ Cluster _|_ 149 |DB |_________|DB | |DB |_________|DB | 150 |___| |___| |___| |___| 152 Distributed Mesh Architecture 154 4. DRiP procedures 156 4.1. Distributed Registry Rules 158 All nodes in the distributed mesh MUST agree upon a specific key- 159 value data model. The choice of data store is implementation 160 specific. 162 All nodes MUST be configured with at least one peer node before 163 propagation. 165 A node MUST ignore any updates or commands it receives from other 166 nodes that are not configured as peer nodes. 168 All nodes MUST send a periodic heartbeat or keep-alive message via 169 HTTPS to the respective peer nodes. If a heartbeat is not received 170 the peer node is removed from the list of active peer nodes. 172 4.2. Node State 174 The peer node should maintain a state that defines whether it is 175 active, inactive, or synchronizing key-value data with a peer node. 177 The node should proactively tell it's peer nodes its state by sending 178 the following POST messages. The GET query is available for nodes to 179 query the state of peer nodes. 181 4.2.1. API - POST /node/:nodeid/active 183 Example (using cURL) 185 Request 187 $ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..." 188 -X POST https://nodearegistry.com/node/nodeA/active 190 Response 192 HTTP/1.1 200 OK 194 4.2.2. API - POST /node/:nodeid/inactive 196 Example (using cURL) 198 Request 200 $ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..." 201 -X POST https://nodearegistry.com/node/nodeA/inactive 203 Response 205 HTTP/1.1 200 OK 207 4.2.3. API - GET /state 209 Description: 211 A node should query the state of its peer node before it initiates a 212 sync operation. This request responds with either "active" or "sync" 213 or no response, if in "inactive" state. 215 Example (using cURL) 216 Request 218 $ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..." 219 -X GET https://nodearegistry.com/state 221 Response 223 HTTP/1.1 200 OK with the following JSON object. 225 +---------------+----------------------------------+ 226 | Property | Description | 227 +---------------+----------------------------------+ 228 | state | "active" or "inactive" or "sync" | 229 +---------------+----------------------------------+ 231 4.3. Custom HTTP header fields 233 Custom HTTP header fields will be used to carry node specific 234 information. 236 +---------------+---------------------------------------------------+ 237 | Field Name | Description | 238 +---------------+---------------------------------------------------+ 239 | DRiP-Node-ID | Each node in the mesh MUST have a unique | 240 | | identifier. An Initiator node MUST set its own | 241 | | node ID as the field value. A Receiver Node MUST | 242 | | NOT change the DRiP-Node-ID field value as it | 243 | | forward the HTTPS request to its peer nodes. | 244 +---------------+---------------------------------------------------+ 246 Example: 247 DRiP-Node-ID: xyz 249 +-------------------+-----------------------------------------------+ 250 | Field Name | Description | 251 +-------------------+-----------------------------------------------+ 252 | DRiP-Node-Counter | Every node maintains a count of the number of | 253 | | times it initiates key-value data | 254 | | propagation. This counter MUST be an unsigned | 255 | | type, typically, a 64 bit integer. The | 256 | | Initiator node MUST set this count as the | 257 | | field value. A Receiver Node MUST NOT change | 258 | | the DRiP-Node-Counter field value as it | 259 | | forward the HTTPS request to its peer nodes. | 260 +-------------------+-----------------------------------------------+ 262 Example: 263 DRiP-Node-Counter: 123 265 +-------------------------+-----------------------------------------+ 266 | Field Name | Description | 267 +-------------------------+-----------------------------------------+ 268 | DRiP-Node-Counter-reset | A node can reset the count (to zero) of | 269 | | the number of times it initiates key- | 270 | | value data propagation. If the counter | 271 | | value is reset, prior to initiating | 272 | | data propagation, then this field value | 273 | | MUST be set to true. Otherwise, it MUST | 274 | | be set to false, at all times. A | 275 | | typical use case to reset the counter | 276 | | value is when the counter (of unsigned | 277 | | type) value wraps around. The Initiator | 278 | | node MUST set this field value to | 279 | | either true or false. A Receiver Node | 280 | | MUST NOT change the DRiP-Node-Counter- | 281 | | reset field value as it forward the | 282 | | HTTPS request to its peer nodes. | 283 +-------------------------+-----------------------------------------+ 285 Example: 286 DRiP-Node-Counter-reset: false 288 +-----------------------+-------------------------------------------+ 289 | Field Name | Description | 290 +-----------------------+-------------------------------------------+ 291 | DRiP-Transaction-Type | The Initiator node MUST set this field | 292 | | value to be either "update" or "sync". A | 293 | | Receiver Node MUST NOT change the DRiP- | 294 | | Transaction-Type field value as it | 295 | | forward the HTTPS request to its peer | 296 | | nodes. | 297 +-----------------------+-------------------------------------------+ 299 Example: 300 DRiP-Transaction-Type: update 302 +--------------------+----------------------------------------------+ 303 | Field Name | Description | 304 +--------------------+----------------------------------------------+ 305 | DRiP-Sync-Complete | For sync transaction type, the Initiator | 306 | | node MUST set this field value to be true, | 307 | | if synchronization is complete. Otherwise, | 308 | | this field value MUST be set to false. | 309 +--------------------+----------------------------------------------+ 311 Example: 312 DRiP-Sync-Complete: false 314 4.4. Key-Value Data Propagation Rules 316 A node propagates key-value data to all its peer nodes except the the 317 node from which it received data. For example, in Figure 1, when 318 node B receives key-value data from node A, it will propagate the 319 data received to nodes C and D but not back to node A. 321 For each transaction type (Update or Sync), the following set of 322 actions MUST take place when a node receives a HTTPS request with 323 propagated key-value data: 325 o If DRiP-Node-ID field value (in the HTTP header) contains 326 Initiator node ID that has never been seen, both DRiP-Node-ID and 327 DRiP-Node-Counter field values MUST be stored for future reference 328 and the key-value data is propagated to all peer nodes. 330 o If DRiP-Node-ID field value (in the HTTP header) matches with a 331 stored node ID and DRiP-Node-Counter-reset field value is false. 333 * The received key-value data MUST be propagated to the peer 334 nodes if DRiP-Node-Counter field value is greater than the 335 saved counter value. The DRiP-Node-Counter field value MUST be 336 saved as the new counter for the stored node ID. 338 * If DRiP-Node-Counter field value is less than or equal to saved 339 counter value, then the key-value data has already been 340 received and MUST NOT be propagated to peer nodes. This 341 ensures that propagation stops when all nodes have received the 342 key-value data from the Initiator node. 344 o If DRiP-Node-ID field value matches with a stored node ID and 345 DRiP-Node-Counter-reset field value is true: 347 * The received key-value data MUST be propagated to the peer 348 nodes. The DRiP-Node-Counter field value MUST be saved as the 349 new counter for the stored node ID. 351 4.5. Key-Value Data Update 353 When an Initiator node has new data it wants to propagate to the 354 distributed mesh, it initiates an Update. The Update consists of a 355 two-phase commit (2PC) procedure in order to guarantee there are no 356 race conditions for updating the same key's data, as well as for any 357 error conditions in the distributed mesh that would cause the update 358 to not complete for all nodes in the network. 360 The two phases are called the "voting" phase and the "commit" phase. 362 _________ 363 ----------------------->| | 364 | | Waiting | 365 | | For | 366 | ---------------------| Events | 367 | | (Update, |_________| 368 | | Start Timer) 369 | | -------------------------------- 370 | | | Received Update From Peer Node | 371 | | | | 372 | | ______________|_ If key matches an | 373 | | | | in-progress update | 374 | ----------->| | vote "no". | 375 | | Waiting For | Otherwise, vote "yes". | 376 | | Response From | | 377 | | Peer Nodes |<----------------------------- 378 | | | 379 | ----| |---- 380 | Timer | |________________| | 381 | Expired | | Received Votes 382 | | | From All Peer 383 | | | Nodes 384 | | _______________ | 385 | | | | | 386 | | | | | 387 | --->| |<--- 388 | | Validating | 389 | (If all Votes | Votes | 390 | are "YES", | | 391 | propagate | | 392 | commit) | | 393 ---------------|________________| 395 Update State Diagram 397 4.5.1. Voting Phase 399 The voting phase is the phase where all nodes are queried to "vote" 400 whether they are aware of any potential conflict that would cause the 401 transaction not to complete. 403 The Initiator node MUST set a timeout period to get response from its 404 peer nodes. 406 The peer nodes known to the initiator node will continue propagate 407 the information to their peer nodes and so on. However, these peer 408 nodes beyond the initiator node will no longer need to keep track of 409 the time interval for responses. A node will stop continuing to 410 propagate information when it determines it has received the same 411 information again. This can be determined by keeping track of the 412 counter and originating node id. 414 If all peer nodes vote "yes", then the second phase or commit phase 415 in the local node is initiated. If any node in the distributed mesh 416 votes "no" or if the timeout period expires and all peer nodes have 417 not responded, then the commit of the information MUST NOT be 418 completed. No action is taken for responses received after the 419 timeout period. 421 Note: The voting procedure is intentionally split into two separate 422 full HTTP transactions for reliability. 424 ___ ___ ___ ___ ___ ___ 425 |DB |_________|DB | |DB |_________|DB | |DB |_________|DB | 426 |___| |___| |___| |___| |___| |___| 427 | Data | | Data | | Data | 428 | Store | | Store | | Store | 429 _|_ Cluster _|_ _|_ Cluster _|_ _|_ Cluster _|_ 430 |DB |_________|DB | |DB |_________|DB | |DB |_________|DB | 431 |___| |___| |___| |___| |___| |___| 432 \ \ | 433 \ \ | 434 _\___ Vote(HTTPS) _\___ Vote(HTTPS) |____ 435 |Node | <---------- |Node | ----------> |Node | 436 | B |---------------| A |---------------| C | 437 |_____| ----------> |_____| <---------- |_____| 438 Yes/No Yes/No 440 Voting Phase 442 4.5.1.1. API - POST /voting 444 Request: 446 POST /voting 448 Description: 450 A post from either Initiator node or subsequent peer nodes to request 451 a vote of "yes" or "no" whether the key-value data could be committed 452 without error or conflict. 454 Example (using cURL) 456 Request 457 $ curl -i -H "Content-Type: application/json" -H "DRiP-Node-ID: 458 nodeA" -H "DRiP-Node-Counter: 1234" -H 459 "DRiP-Node-Counter-reset: false" -X POST -d '{}' https://nodebregistry.com/voting 462 Response 464 HTTP/1.1 200 OK 466 4.5.1.2. POST /votingphase/node/:nodeid/response/:response 468 Request: 470 POST /voting/peernode/:nodeid/response/:response 472 Description: 474 A POST from peer node back to node with response of vote. 476 Example (using cURL) 478 Request 480 $ curl -i -X POST http://nodearegistry.com/node/nodeA/response/yes 482 Response 484 HTTP/1.1 200 OK 486 4.5.2. Commit Phase 488 The Initiator node, that originated the gossip, upon receiving a 489 successful aggregated "yes" vote from all the peer nodes should start 490 the commit phase. This node MUST commit the data to its data store. 491 Subsequently, this information is propagated to all the nodes so that 492 each node in the mesh will commit the same information in their 493 respective data stores. 495 ___ ___ ___ ___ 496 |DB |_________|DB | |DB |_________|DB | 497 |___| |___| |___| |___| 498 | Data | | Data | 499 | Store | | Store | 500 _|_ Cluster _|_ _|_ Cluster _|_ 501 |DB |_________|DB | |DB |_________|DB | 502 |___| |___| |___| |___| 503 \ / 504 \COMMIT /COMMIT 505 _\___ COMMIT _ /__ 506 |Node |------------|Node | 507 | A | HTTPS | C | 508 |_____| |_____| 509 \H H/ 510 \T T/ 511 COMMIT\T P/COMMIT 512 \P P/ 513 \S S/ 514 __\__ / COMMIT _____ 515 |Node |------------|Node | 516 | B | HTTPS | D | 517 |_____| |_____| 518 / / 519 /COMMIT /COMMIT 520 ___ ___/ _/__ ___ 521 |DB |_________|DB | |DB |_________|DB | 522 |___| |___| |___| |___| 523 | Data | | Data | 524 | Store | | Store | 525 _|_ Cluster _|_ _|_ Cluster _|_ 526 |DB |_________|DB | |DB |_________|DB | 527 |___| |___| |___| |___| 529 Commit Phase 531 4.5.2.1. API - POST /commit 533 Request: 535 POST /commit 537 Description: 539 A commit message is sent from Initiator or subsequent peer nodes to 540 signal the Receiver node to commit the data to its data store. 542 Example (using cURL) 544 Request 546 $ curl -i -H "Content-Type: application/json" -H "DRiP-Node-ID: 547 nodeA" -H "DRiP-Node-Counter: 1234" -H 548 "DRiP-Node-Counter-reset: false" -X POST -d 549 '' https://nodebregistry.com/commit 551 Response 553 HTTP/1.1 200 OK 555 4.6. Node Sync Operation 557 A node, either newly added to the distributed mesh or put back into 558 service after being inactive, will get the state of a peer node to 559 determine if it is in "active" state. If so, the node can 560 immediately initiate a Sync transaction. The peer node MUST start 561 propagating a comprehensive and complete set of key-value data from 562 its data store. 564 The two phase commit does NOT apply here as the contents of the 565 initiating node's data store is either outdated or empty. During 566 this phase (HTTPS requests received will have DRiP-Sync-Complete 567 field value set to false), this node SHOULD NOT become an Initiator 568 node to provision data. While this transaction is going on, this 569 node MUST vote "yes" to all real-time updates. The commits 570 corresponding to the Updates should also be completed and reflected 571 in the data store. 573 4.6.1. API - PUT /sync/node/:nodeid 575 Request: 577 PUT /sync/node/:nodeid 579 Description: 581 API call for initiating a full registry synchronization from node to 582 peer-node. 584 Example (using cURL) 586 Request 588 $ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..." 589 -X POST https://peernode.com/sync/node/nodeA 591 Response 593 HTTP/1.1 200 OK 595 4.7. Heartbeat 597 Periodic heartbeats are required for a node to determine it's 598 visibility to the rest of it's peer nodes and whether it should put 599 itself in "inactive" mode. The proceedure for heartbeats is as 600 follows. 602 A node sends periodic heartbeat requests to its peer nodes with an 603 indication of its state. These heartbeat requests are not to be 604 propagated beyond the peer nodes. 606 If all of its peer nodes cannot be reached or do not respond with 200 607 OK, then the node that sent the heartbeat request will set its own 608 state to "inactive". This is based on the reasonable assumption that 609 none of the peer nodes are able to communicate with this node until a 610 new heartbeat request is sucessful. Once in the inactive state, the 611 node will 613 o not propagate any incoming key-value data 615 o not update any incoming key-value data 617 o continue to send the periodic heartbeat requests to its peer 618 nodes. If any one responds with 200 OK, then the node will move 619 its state to "synchronizing" and will re-synchronize its data with 620 any active peer node as detailed in section 4.6 622 In addition, any one or more peer nodes that cannot be reached or did 623 not respond with 200 OK should not be used to propagate key-value 624 data until it responds (with 200 OK) to the heartbeat request. 626 4.7.1. API - POST /heartbeat/node/:nodeid 628 Example (using cURL) 630 Request 632 $ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..." 633 -X POST -d '' https://peernode.com/heartbeat/node/nodeA 635 Response 637 HTTP/1.1 200 OK 639 4.8. Key-Value Data Update Entitlement Verification 641 When a node owner would like to create or modify particular key-value 642 data, generally in the context of a registry, there MAY be a 643 verification procedure that key-value data write or modification can 644 be performed. This could include validating whether key-value data 645 is entitled to be written, modified or subsequently propagated based 646 on application policy. For example, identity or telephone number 647 ownership or porting. The exact mechanics of this are out of scope 648 of this document and are generally application specific. 650 5. Security Considerations 652 5.1. HTTPS 654 All nodes MUST perform HTTP transactions using TLS as defined in 655 [RFC7230]. 657 5.2. Authorization 659 All nodes MUST validate their authority to consume the HTTP APIs of a 660 peer node by adding a JSON Web Token (JWT) value [RFC7519] in the 661 Authorization request-header field. 663 The creation and verification of the JWT should be based on a digital 664 signature. For most distributed registry scenerios where the owner 665 of a node may not have a direct relationship with another node owner, 666 a PKI based certificate approach is highly suggested. For protection 667 against replay attacks, the claim set SHOULD contain an "iat" claim 668 and the signature should be verified to be signed by the expected 669 owner of the peer node. The "iat" claim identifies the time at which 670 the JWT was issued and can be used to validate when the time of the 671 transaction occurred. 673 5.3. Payload Validation 675 In addition to the DRiP level protocol protection, it is highly 676 suggested to sign and validate part or all of the JSON update 677 payloads to the originator of the update. DRiP does not define 678 anything regarding the contents of the payload, so this document does 679 not address this in any way. 681 6. References 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, 685 DOI 10.17487/RFC2119, March 1997, 686 . 688 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 689 Protocol (HTTP/1.1): Message Syntax and Routing", 690 RFC 7230, DOI 10.17487/RFC7230, June 2014, 691 . 693 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 694 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 695 . 697 Authors' Addresses 699 Harsha Bellur 700 Comcast 701 One Comcast Center 702 Philadelphia, PA 19103 703 USA 705 Email: Harsha_Bellur@cable.comcast.com 707 Chris Wendt (editor) 708 Comcast 709 One Comcast Center 710 Philadelphia, PA 19103 711 USA 713 Email: chris-ietf@chriswendt.net