idnits 2.17.1 draft-ietf-rserpool-enrp-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1727. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2008) is 5740 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-17 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-20 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-16 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Xie 3 Internet-Draft R. Stewart 4 Intended status: Experimental 5 Expires: January 12, 2009 M. Stillman 6 Nokia 7 M. Tuexen 8 Muenster Univ. of Applied Sciences 9 A. Silverton 10 Motorola, Inc. 11 July 11, 2008 13 Endpoint Handlespace Redundancy Protocol (ENRP) 14 draft-ietf-rserpool-enrp-21.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 12, 2009. 41 Abstract 43 The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to 44 work in conjunction with the Aggregate Server Access Protocol (ASAP) 45 to accomplish the functionality of the Reliable Server Pooling 46 (RSerPool) requirements and architecture. Within the operational 47 scope of RSerPool, ENRP defines the procedures and message formats of 48 a distributed, fault-tolerant registry service for storing, 49 bookkeeping, retrieving, and distributing pool operation and 50 membership information. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . . 6 58 2.1. ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6 59 2.2. ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8 60 2.3. ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8 61 2.4. ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10 62 2.5. ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 63 2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 64 2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 65 2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 66 2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 67 2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 16 68 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . . 17 69 3.1. Methods for Communicating amongst ENRP Servers . . . . . . 17 70 3.2. ENRP Server Initialization . . . . . . . . . . . . . . . . 17 71 3.2.1. Generate a Server Identifier . . . . . . . . . . . . . 17 72 3.2.2. Acquire Peer Server List . . . . . . . . . . . . . . . 18 73 3.2.3. Download ENRP Handlespace Data from Mentor Peer . . . 19 74 3.3. Server Handlespace Update . . . . . . . . . . . . . . . . 21 75 3.3.1. Announcing Addition or Update of PE . . . . . . . . . 21 76 3.3.2. Announcing Removal of PE . . . . . . . . . . . . . . . 22 77 3.4. Maintaining Peer List and Monitoring Peer Status . . . . . 23 78 3.4.1. Discovering New Peer . . . . . . . . . . . . . . . . . 23 79 3.4.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 23 80 3.4.3. Detecting Peer Server Failure . . . . . . . . . . . . 23 81 3.5. Taking-over a Failed Peer Server . . . . . . . . . . . . . 24 82 3.5.1. Initiating Server Take-over Arbitration . . . . . . . 24 83 3.5.2. Take-over Target Peer Server . . . . . . . . . . . . . 25 84 3.6. Handlespace Data Auditing and Re-synchronization . . . . . 26 85 3.6.1. Auditing Procedures . . . . . . . . . . . . . . . . . 26 86 3.6.2. PE Checksum Calculation Algorithm . . . . . . . . . . 27 87 3.6.3. Re-synchronization Procedures . . . . . . . . . . . . 28 89 3.7. Handling Unrecognized Message or Unrecognized Parameter . 28 90 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 29 91 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 29 92 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 29 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 94 5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 30 95 5.2. A New Table for Update Action Types . . . . . . . . . . . 30 96 5.3. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 31 97 5.4. SCTP payload protocol identifier . . . . . . . . . . . . . 31 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 99 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32 100 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33 101 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 36 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 104 8.1. Normative References . . . . . . . . . . . . . . . . . . . 39 105 8.2. Informative References . . . . . . . . . . . . . . . . . . 40 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 107 Intellectual Property and Copyright Statements . . . . . . . . . . 42 109 1. Introduction 111 ENRP is designed to work in conjunction with ASAP 112 [I-D.ietf-rserpool-asap] to accomplish the functionality of RSerPool 113 as defined by its requirements [RFC3237]. 115 Within the operational scope of RSerPool, ENRP defines the procedures 116 and message formats of a distributed fault-tolerant registry service 117 for storing, bookkeeping, retrieving, and distributing pool operation 118 and membership information. 120 Whenever appropriate, in the rest of this document we will refer to 121 this RSerPool registry service as ENRP handlespace, or simply 122 handlespace because it manages all pool handles. 124 1.1. Definitions 126 This document uses the following terms: 128 Operational scope: The part of the network visible to pool users by 129 a specific instance of the reliable server pooling protocols. 131 Pool (or server pool): A collection of servers providing the same 132 application functionality. 134 Pool handle: A logical pointer to a pool. Each server pool will be 135 identifiable in the operational scope of the system by a unique 136 pool handle. 138 Pool element: A server entity having registered to a pool. 140 Pool user: A server pool user. 142 Pool element handle (or endpoint handle): A logical pointer to a 143 particular pool element in a pool, consisting of the pool handle 144 and a destination transport address of the pool element. 146 Handle space: A cohesive structure of pool handles and relations 147 that may be queried by an internal or external agent. 149 ENRP client channel: The communication channel through which an ASAP 150 User (either a PE or PU) requests ENRP handlespace service. The 151 client channel is usually defined by the transport address of the 152 home server and a well-known port number. 154 ENRP server channel: Defined by a list of IP addresses (one for each 155 ENRP servers in an operational scope) and a well known port 156 number. All ENRP servers in an operational scope can send "group- 157 cast" messages to other servers through this channel. In a 158 "group-cast", the sending server sends multiple copies of the 159 message, one to each of its peer servers, over a set of point-to- 160 point SCTP associations between the sending server and the peers. 161 The "group-cast" may be conveniently implemented with the use of 162 the "SCTP_SENDALL" option on an one-to-many style SCTP socket 163 [I-D.ietf-tsvwg-sctpsocket]. 165 Home ENRP server: The ENRP server to which a PE or PU currently 166 belongs. A PE MUST only have one home ENRP server at any given 167 time and both the PE and its home ENRP server MUST keep track of 168 this master/slave relationship between them. A PU SHOULD select 169 one of the available ENRP servers as its home ENRP server, but the 170 ENRP server does not need to know, nor does it need to keep track 171 of this relationship. 173 1.2. Conventions 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 2. ENRP Message Definitions 181 In this section, we define the format of all ENRP messages. These 182 are messages sent and received amongst ENRP servers in an operational 183 scope. Messages sent and received between a PE/PU and an ENRP server 184 are part of ASAP and are defined in [I-D.ietf-rserpool-asap]. A 185 common format, that is defined in [I-D.ietf-rserpool-common-param], 186 is used for all ENRP and ASAP messages. 188 Most ENRP messages contains a combination of fixed fields and TLV 189 parameters. The TLV (Type-Length_value) parameters are also defined 190 in [I-D.ietf-rserpool-common-param]. If a nested TLV parameter is 191 not ended on a 32-bit word boundary, it will be padded with all '0' 192 octets to the next 32-bit word boundary. 194 All messages, as well as their fields/parameters described below, 195 MUST be transmitted in network byte order (a.k.a. Big Endian, 196 meaning the most significant byte is transmitted first). 198 For ENRP, the following message types are defined in this section: 200 Type Message Name 201 ----- ------------------------- 202 0x00 - (reserved by IETF) 203 0x01 - ENRP_PRESENCE 204 0x02 - ENRP_HANDLE_TABLE_REQUEST 205 0x03 - ENRP_HANDLE_TABLE_RESPONSE 206 0x04 - ENRP_HANDLE_UPDATE 207 0x05 - ENRP_LIST_REQUEST 208 0x06 - ENRP_LIST_RESPONSE 209 0x07 - ENRP_INIT_TAKEOVER 210 0x08 - ENRP_INIT_TAKEOVER_ACK 211 0x09 - ENRP_TAKEOVER_SERVER 212 0x0a - ENRP_ERROR 213 0x0b-0xff - (reserved by IETF) 215 Figure 1 217 2.1. ENRP_PRESENCE message 219 This ENRP message is used to announce (periodically) the presence of 220 an ENRP server, or to probe the status of a peer ENRP server. This 221 message is either send on the ENRP server channel or point-to-point 222 to another ENRP server. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Sending Server's ID | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Receiving Server's ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 : PE Checksum Param : 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 : Server Information Param (optional) : 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Sending Server's ID: 32 bit (unsigned integer) 240 This is the ID of the ENRP server which sent this message. 242 Receiving Server's ID: 32 bit (unsigned integer) 244 This is the ID of the ENRP server to which this message is 245 intended. If the message is not intended for an individual 246 server (e.g., the message is group-casted to a group of 247 servers), this field MUST be sent with all 0's. If the message 248 is send point-to-point this field MAY be sent with all 0's. 250 PE Checksum Parameter: 252 This is a TLV that contains the latest PE checksum of the ENRP 253 server who sends the ENRP_PRESENCE. This parameter SHOULD be 254 included for handlespace consistency auditing. See 255 Section 3.6.1 for details. 257 Server Information Parameter: 259 If this parameter is present, it contains the server 260 information of the sender of this message (Server Information 261 Parameter is defined in [I-D.ietf-rserpool-common-param]). 262 This parameter is optional. However, if this message is sent 263 in response to a received "reply required" ENRP_PRESENCE from a 264 peer, the sender then MUST include its server information. 266 Note, at startup an ENRP server MUST pick a randomly generated, non- 267 zero 32-bit unsigned integer as its ID and MUST use this same ID 268 until the ENRP server is rebooted. 270 2.2. ENRP_HANDLE_TABLE_REQUEST message 272 An ENRP server sends this message to one of its peers to request a 273 copy of the handlespace data. This message is normally used during 274 server initialization or handlespace re-synchronization. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Sending Server's ID | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Receiving Server's ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 W (oWn-children-only) flag: 1 bit 288 Set to '1' if the sender of this message is only requesting 289 information about the PEs owned by the message receiver. 290 Otherwise, set to '0'. 292 Sending Server's ID: 294 See Section 2.1. 296 Receiving Server's ID: 298 See Section 2.1. 300 2.3. ENRP_HANDLE_TABLE_RESPONSE message 302 The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in 303 response to a received PEER_NAME_TABLE_REQUEST message to assist peer 304 server initialization or handle-space synchronization. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Sending Server's ID | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Receiving Server's ID | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 : : 316 : Pool entry #1 (optional) : 317 : : 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 : : 320 : ... : 321 : : 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 : : 324 : Pool entry #n (optional) : 325 : : 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 M (More_to_send) flag: 1 bit 330 Set to '1' if the sender of this message has more pool entries 331 to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages. 332 Otherwise, set to '0'. 334 R (Reject) flag: 1 bit 336 MUST be set to '1' if the sender of this message is rejecting a 337 handlespace request. In this case, pool entries MUST NOT be 338 included. This might happen if the sender of this message is 339 in the middle of initializing its database or it is under high 340 load. 342 Message Length: 16 bits (unsigned integer) 344 Indicates the entire length of the message including the header 345 in number of octets. 347 Note, the value in Message Length field will NOT cover any 348 padding at the end of this message. 350 Sending Server's ID: 352 See Section 2.1. 354 Receiving Server's ID: 356 See Section 2.1. 358 Pool entry #1-#n: 360 If the R flag is set to '0', at least one pool entry SHOULD be 361 present in this message. Each pool entry MUST start with a 362 Pool Handle parameter as defined in section 3.9 of 363 [I-D.ietf-rserpool-common-param], and is followed by one or 364 more Pool Element parameters in TLV format, as shown below: 366 +---------------------------+ 367 : Pool handle : 368 +---------------------------+ 369 : PE #1 : 370 +---------------------------+ 371 : PE #2 : 372 +---------------------------+ 373 : ... : 374 +---------------------------+ 375 : PE #n : 376 +---------------------------+ 378 2.4. ENRP_HANDLE_UPDATE message 380 The PEER_NAME_UPDATE message is sent by the home ENRP server of a PE 381 to all peer servers to announce registration, re-registration, or de- 382 registration of the PE in the handle-space. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Sending Server's ID | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Receiving Server's ID | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Update Action | (reserved) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 : Pool Handle Parameter : 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 : Pool Element Parameter : 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Message Length: 16 bits (unsigned integer) 402 Indicates the entire length of the message including the header 403 in number of octets. 405 Note, the value in Message Length field will NOT cover any 406 padding at the end of this message. 408 Update Action: 16 bits (unsigned integer) 410 This field indicates the requested action of the specified PE. 411 The field MUST be set to one of the following values: 413 0x0000 - ADD_PE: Add or update the specified PE in the ENRP 414 handlespace 416 0x0001 - DEL_PE: Delete the specified PE from the ENRP 417 handlespace. 419 0x0002 - 0xFFFF: Reserved by IETF. 421 Other values are reserved by IETF and MUST NOT be used. 423 Reserved: 16 bits 425 This field MUST be set to all 0's by sender and ignored by the 426 receiver. 428 Sending Server's ID: 430 See Section 2.1. 432 Receiving Server's ID: 434 See Section 2.1. 436 Pool handle: 438 Specifies to which the PE belongs. 440 Pool Element: 442 Specifies the PE. 444 2.5. ENRP_LIST_REQUEST message 446 The PEER_LIST_REQUEST message is sent to request a current copy of 447 the ENRP server list. This message is normally sent from a newly 448 activated ENRP server to an established ENRP server as part of the 449 initialization process. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Sending Server's ID | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Receiving Server's ID | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Sending Server's ID: 463 See Section 2.1. 465 Receiving Server's ID: 467 See Section 2.1. 469 2.6. ENRP_LIST_RESPONSE message 471 The PEER_LIST_RESPONSE message is sent in response from an ENRP 472 server that receives a PEER_LIST_REQUEST message to return 473 information about known ENRP servers. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type = 0x06 |0|0|0|0|0|0|0|R| Message Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Sending Server's ID | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Receiving Server's ID | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 : Server Information Parameter of Peer #1 : 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 : ... : 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 : Server Information Parameter of Peer #n : 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 R (Reject) flag: 1 bit 493 This flag MUST be set to '1' if the sender of this message is 494 rejecting a PEER_LIST_REQUEST message. If this case occurs, 495 the message MUST NOT include any Server Information Parameters. 497 Message Length: 16 bits (unsigned integer) 499 Indicates the entire length of the message in number of octets. 501 Note, the value in Message Length field will NOT cover any 502 padding at the end of this message. 504 Sending Server's ID: 506 See Section 2.1. 508 Receiving Server's ID: 510 See Section 2.1. 512 Server Information Parameter of Peer #1-#n: 514 Each contains a Server Information Parameter of a peer known to 515 the sender. The Server Information Parameter is defined in 516 [I-D.ietf-rserpool-common-param]. 518 2.7. ENRP_INIT_TAKEOVER message 520 The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the 521 takeover initiator) to announce its intention of taking over a 522 specific peer ENRP server. It is send to all its peers. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Sending Server's ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Receiving Server's ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Targeting Server's ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Sending Server's ID: 538 See Section 2.1. 540 Receiving Server's ID: 542 See Section 2.1. 544 Targeting Server's ID: 32-bit (unsigned integer) 546 This is the ID of the peer ENRP that is the target of this 547 takeover attempt. 549 2.8. ENRP_INIT_TAKEOVER_ACK message 551 The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover 552 initiator to acknowledge the reception of the PEER_INIT_TAKEOVER 553 message and that it does not object to the takeover. 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Sending Server's ID | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Receiving Server's ID | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Targeting Server's ID | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Sending Server's ID: 569 See Section 2.1. 571 Receiving Server's ID: 573 See Section 2.1. 575 Targeting Server's ID: 577 This is the ID of the peer ENRP that is the target of this 578 takeover attempt. 580 2.9. ENRP_TAKEOVER_SERVER message 582 The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator 583 to declare the enforcement of a takeover to all active peer ENRP 584 servers. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Sending Server's ID | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Receiving Server's ID | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Targeting Server's ID | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Sending Server's ID: 599 See Section 2.1. 601 Receiving Server's ID: 603 See Section 2.1. 605 Targeting Server's ID: 607 This is the ID of the peer ENRP that is the target of this 608 takeover operation. 610 2.10. ENRP_ERROR message 612 The ENRP_ERROR message is sent by a registrar to report an 613 operational error to a peer ENRP server. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Sending Server's ID | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Receiving Server's ID | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 : Operational Error Parameter : 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Sending Server's ID: 629 See Section 2.1. 631 Receiving Server's ID: 633 See Section 2.1. 635 Operational Error Parameter: 637 This parameter, defined in [I-D.ietf-rserpool-common-param], 638 indicates the type of error(s) being reported. 640 3. ENRP Operation Procedures 642 In this section, we discuss the operation procedures defined by ENRP. 643 An ENRP server MUST follow these procedures when sending, receiving, 644 or processing ENRP messages. 646 Many of the RSerPool events call for both server-to-server and PU/ 647 PE-to-server message exchanges. Only the message exchanges and 648 activities between an ENRP server and its peer(s) are considered 649 within the ENRP scope and are defined in this document. 651 Procedures for exchanging messages between a PE/PU and ENRP servers 652 are defined in [I-D.ietf-rserpool-asap]. 654 3.1. Methods for Communicating amongst ENRP Servers 656 Within an RSerPool operational scope, ENRP servers need to 657 communicate with each other in order to exchange information such as 658 the pool membership changes, handlespace data synchronization, etc. 660 Two types of communications are used amongst ENRP servers: 662 o point-to-point message exchange from one ENPR server to a specific 663 peer server, and 665 o announcements from one server to all its peer servers in the 666 operational scope. 668 Point-to-point communication is always carried out over an SCTP 669 association between the sending server and the receiving server. 670 Announcements are sent out via "group-casts" over the ENRP server 671 channel. 673 3.2. ENRP Server Initialization 675 This section describes the steps a new ENRP server needs to take in 676 order to join the other existing ENRP servers, or to initiate the 677 handlespace service if it is the first ENRP server started in the 678 operational scope. 680 3.2.1. Generate a Server Identifier 682 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 683 as unique as possible among all the ENRP servers in the operational 684 scope and this server Id MUST remain unchanged for the lifetime of 685 the server. Normally, a good 32-bit random number will be good 686 enough as the server Id ([RFC4086] provides some information on 687 randomness guidelines). 689 Note, there is a very remote chance (about 1 in about 4 billion) that 690 two ENRP servers in an operational scope will generate the same 691 server Id and hence cause a server Id conflict in the pool. However, 692 no severe consequence of such a conflict has been identified. 694 Note, the ENRP server Id space is separate from the PE Id space 695 defined in [I-D.ietf-rserpool-asap]. 697 3.2.2. Acquire Peer Server List 699 At startup, the ENRP server (initiating server) will first attempt to 700 learn all existing peer ENRP servers in the same operational scope, 701 or to determine that it is alone in the scope. 703 The initiating server uses an existing peer server to bootstrap 704 itself into service. We call this peer server the mentor server. 706 3.2.2.1. Finding the mentor server 708 If the initiating server is told about one existing peer server 709 through some administrative means (such as DNS query, configuration 710 database, startup scripts, etc), the initiating server MUST then use 711 this peer server as its mentor server. 713 If multiple existing peer servers are specified, the initiating 714 server MUST pick one of them as its mentor server and keep the others 715 as its backup mentor servers. 717 If no existing peer server is specified, the initiating server MUST 718 assume that it is alone in the operational scope, and MUST skip the 719 procedures in Section 3.2.2.2 and Section 3.2.3 and MUST consider its 720 initialization completed and start offering ENRP services. 722 3.2.2.2. Request complete server list from mentor peer 724 Once the initiating server finds its mentor peer server (by either 725 discovery or administrative means), the initiating server MUST send 726 an ENRP_LIST_REQUEST message to the mentor peer server to request a 727 copy of the complete server list maintained by the mentor peer (see 728 Section 3.4 for maintaining server list). 730 The initiating server SHOULD start a MAX-TIME-NO-RESPONSE timer every 731 time it finishes sending an ENRP_LIST_REQUEST message. If the timer 732 expires before receiving a response from the mentor peer, the 733 initiating server SHOULD abandon the interaction with the current 734 mentor server and send a new server list request to a backup mentor 735 peer, if one is available. 737 Upon the reception of this request, the mentor peer server SHOULD 738 reply with an ENRP_LIST_RESPONSE message and include in the message 739 body all existing ENRP servers known by the mentor peer. 741 Upon the reception of the ENRP_LIST_RESPONSE message from the mentor 742 peer, the initiating server MUST use the server information carried 743 in the message to initialize its own peer list. 745 However, if the mentor itself is in the process of startup and not 746 ready to provide a peer server list (for example, the mentor peer is 747 waiting for a response to its own ENRP_LIST_REQUEST to another 748 server), it MUST reject the request by the initiating server and 749 respond with an ENRP_LIST_RESPONSE message with the R flag set to 750 '1', and with no server information included in the response. 752 In the case where its ENRP_LIST_REQUEST is rejected by the mentor 753 peer, the initiating server SHOULD either wait for a few seconds and 754 re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a 755 backup mentor peer available, select another mentor peer server and 756 send the ENRP_LIST_REQUEST to the new mentor server. 758 3.2.3. Download ENRP Handlespace Data from Mentor Peer 760 After a peer list download is completed, the initiating server MUST 761 request a copy of the current handlespace data from its mentor peer 762 server, by taking the following steps: 764 1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST 765 message to the mentor peer, with W flag set to '0', indicating 766 that the entire handlespace is requested. 768 2. Upon the reception of this message, the mentor peer MUST start a 769 download session in which a copy of the current handlespace data 770 maintained by the mentor peer is sent to the initiating server in 771 one or more ENRP_HANDLE_TABLE_RESPONSE messages (Note, the mentor 772 server may find it particularly desirable to use multiple 773 ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when 774 the handlespace is large, especially when forming and sending out 775 a single response containing a large handlespace may interrupt 776 its other services). 778 If more than one ENRP_HANDLE_TABLE_RESPONSE message are used 779 during the download, the mentor peer MUST use the M flag in each 780 ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this 781 message is the last one for the download session. In particular, 782 the mentor peer MUST set the M flag to '1' in the outbound 783 ENRP_HANDLE_TABLE_RESPONSE if there is more data to be 784 transferred and MUST keep track of the progress of the current 785 download session. The mentor peer MUST set the M flag to '0' in 786 the last ENRP_HANDLE_TABLE_RESPONSE for the download session and 787 close the download session (i.e., removing any internal record of 788 the session) after sending out the last message. 790 3. During the downloading, every time the initiating server receives 791 an ENRP_HANDLE_TABLE_RESPONSE message, it MUST transfer the data 792 entries carried in the message into its local handlespace 793 database, and then check whether or not this message is the last 794 one for the download session. 796 If the M flag is set to '1' in the just processed 797 ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST 798 send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer 799 to request for the next ENRP_HANDLE_TABLE_RESPONSE message. 801 4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE 802 message into its local handlespace database, the initiating 803 server MUST handle each pool entry carried in the message using 804 the following rules: 806 A. If the pool does not exist in the local handlespace, the 807 initiating server MUST create the pool in the local 808 handlespace and add the PE(s) in the pool entry to the pool. 810 When creating the pool, the initiation server MUST set the 811 overall member selection policy type of the pool to the 812 policy type indicated in the first PE. 814 B. If the pool already exists in the local handlespace, but the 815 PE(s) in the pool entry is not currently a member of the 816 pool, the initiating server MUST add the PE(s) to the pool. 818 C. If the pool already exists in the local handlespace AND the 819 PE(s) in the Pool entry is already a member of the pool, the 820 initiating server SHOULD replace the attributes of the 821 existing PE(s) with the new information. ENRP will make sure 822 that the information keeps up to date. 824 5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from 825 the mentor peer and unpacked into the local handlespace, the 826 initialization process is completed and the initiating server 827 SHOULD start to provide ENRP services. 829 Under certain circumstances, the mentor peer itself may not be able 830 to provide a handlespace download to the initiating server. For 831 example, the mentor peer is in the middle of initializing its own 832 handlespace database, or it has currently too many download sessions 833 open to other servers. 835 In such a case, the mentor peer MUST reject the request by the 836 initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE 837 message with the R flag set to '1', and with no pool entries included 838 in the response. 840 In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the 841 mentor peer, the initiating server SHOULD either wait for a few 842 seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor 843 server, or if there is a backup mentor peer available, select another 844 mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new 845 mentor server. 847 A handlespace download session that has been started may get 848 interrupted for some reason. To cope with this, the initiating 849 server SHOULD start a timer every time it finishes sending an 850 ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires 851 without receiving a response from the mentor peer, the initiating 852 server SHOULD abort the current download session and re-start a new 853 handlespace download with a backup mentor peer, if one is available. 855 Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the 856 mentor peer set the M-bit to 1 to indicate that it has more data to 857 send, it SHOULD start a session timer. If this timer expires without 858 receiving another request from the initiating server, the mentor peer 859 SHOULD abort the session, cleaning out any resource and record of the 860 session. 862 3.3. Server Handlespace Update 864 This includes a set of update operations used by an ENRP server to 865 inform its peers when its local handlespace is modified, e.g., 866 addition of a new PE, removal of an existing PE, change of pool or PE 867 properties. 869 3.3.1. Announcing Addition or Update of PE 871 When a new PE is granted registration to the handlespace or an 872 existing PE is granted a re-registration, the home ENRP server uses 873 this procedure to inform all its peers. 875 This is an ENRP announcement and is sent to all the peer of the home 876 ENRP server. See Section 3.1 on how announcements are sent. 878 An ENRP server MUST announce this update to all its peers in a 879 ENRP_HANDLE_UPDATE message with the Update Action field set to 880 ADD_PE, indicating the addition of a new PE or the modification of an 881 existing PE. The complete new information of the PE and the pool its 882 belongs to MUST be indicated in the message with a PE parameter and a 883 Pool Handle parameter, respectively. 885 The home ENRP server SHOULD fill in its server Id in the Sending 886 Server's ID field and leave the Receiving Server's ID blank (i.e., 887 all 0's). 889 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take 890 the following actions: 892 1. If the named pool indicated by the pool handle does not exist in 893 its local copy of the handlespace, the peer MUST create the named 894 pool in its local handlespace and add the PE to the pool as the 895 first PE. It MUST then copy in all other attributes of the PE 896 carried in the message. 898 When the new pool is created, the overall member selection policy 899 of the pool MUST be set to the policy type indicated by the PE. 901 2. If the named pool already exists in the peer's local copy of the 902 handlespace AND the PE does not exist, the peer MUST add the PE 903 to the pool as a new PE and copy in all attributes of the PE 904 carried in the message. 906 3. If the named pool exists AND the PE is already a member of the 907 pool, the peer MUST replace the attributes of the PE with the new 908 information carried in the message. 910 3.3.2. Announcing Removal of PE 912 When an existing PE is granted de-registration or is removed from its 913 handlespace for some other reasons (e.g., purging an unreachable PE, 914 see 3.5 in [I-D.ietf-rserpool-asap]), the ENRP server MUST uses this 915 procedure to inform all its peers about the change just made. 917 This is an ENRP announcement and is sent to all the peer of the home 918 ENRP server. See Section 3.1 on how announcements are sent. 920 An ENRP server MUST announce the PE removal to all its peers in an 921 ENRP_HANDLE_UPDATE message with the Update Action field set to 922 DEL_PE, indicating the removal of an existing PE. The complete 923 information of the PE and the pool its belongs to MUST be indicated 924 in the message with a PE parameter and a Pool Handle parameter, 925 respectively. 927 The sending server MUST fill in its server ID in the Sending Server's 928 ID field and leave the Receiving Server's ID blank (i.e., set to all 929 0's). 931 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first 932 find pool and the PE in its own handlespace, and then remove the PE 933 from its local handlespace. If the removed PE is the last one in the 934 pool, the peer MUST also delete the pool from its local handlespace. 936 If the peer fails to find the PE or the pool in its handlespace, it 937 SHOULD take no further actions. 939 3.4. Maintaining Peer List and Monitoring Peer Status 941 An ENRP server MUST keep an internal record on the status of each of 942 its known peers. This record is referred to as the server's "peer 943 list" 945 3.4.1. Discovering New Peer 947 If a message of any type is received from a previously unknown peer, 948 the ENRP server MUST consider this peer a new peer in the operational 949 scope and add it to the peer list. 951 The ENRP server MUST send an ENRP_PRESENCE message with the Reply- 952 required flag set to '1' to the source address found in the arrived 953 message. This will force the new peer to reply with its own 954 ENRP_PRESENCE containing its full server information (see 955 Section 2.1). 957 3.4.2. Server Sending Heartbeat 959 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 960 continued presence to all its peer with a ENRP_PRESENCE message. In 961 the ENRP_PRESENCE message, the ENRP server MUST set the 962 'Replay_required' flag to '0', indicating that no response is 963 required. 965 The arrival of this periodic ENRP_PRESENCE message will cause all its 966 peers to update their internal variable "peer_last_heard" for the 967 sending server (see Section 3.4.3 for more details). 969 3.4.3. Detecting Peer Server Failure 971 An ENRP server MUST keep an internal variable "peer_last_heard" for 972 each of its known peers and the value of this variable MUST be 973 updated to the current local time every time a message of any type 974 (point-to-point or announcement) is received from the corresponding 975 peer. 977 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 978 seconds, the ENRP server MUST immediately send a point-to-point 979 ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. 981 If the send fails or the peer does not reply after MAX-TIME-NO- 982 RESPONSE seconds, the ENRP server MUST consider the peer server dead 983 and SHOULD initiate the takeover procedure defined in Section 3.5. 985 3.5. Taking-over a Failed Peer Server 987 In the following descriptions, we call the ENRP server that detects 988 the failed peer server and initiates the take-over the "initiating 989 server" and the failed peer server the "target server." This allows 990 PE to continue to operate in case of a failure of their Home ENRP 991 server. 993 3.5.1. Initiating Server Take-over Arbitration 995 The initiating server SHOULD first start the take-over arbitration 996 process by sending a ENRP_INIT_TAKEOVER message to all its peer 997 servers. See Section 3.1 on how announcements are sent. In the 998 message, the initiating server MUST fill in the Sending Server's ID 999 and Targeting Server's ID. The goal is that only one ENRP server 1000 takes over the PE from the target. 1002 After announcing the ENRP_INIT_TAKEOVER message (group-casting to all 1003 known peers, including the target server), the initiating server 1004 SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of its 1005 known peers, except of the target server. 1007 Each peer receiving an ENRP_INIT_TAKEOVER message from the initiating 1008 server MUST take the following actions: 1010 1. If the peer server determines that itself is the target server 1011 indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately 1012 announce an ENRP_PRESENCE message to all its peer ENRP servers in 1013 an attempt to stop this take-over process. This indicates a 1014 false failure detection case by the initiating server. The 1015 initiating server MUST stop the takeover operation by marking the 1016 target server as "active" and taking no further takeover actions. 1018 2. If the peer server finds that it has already started its own 1019 take-over arbitration process on the same target server, it MUST 1020 perform the following arbitration: 1022 A. If the peer's server ID is smaller in value than the Sending 1023 Server's ID in the arrived ENRP_INIT_TAKEOVER message, the 1024 peer server MUST immediately abort its own take-over attempt 1025 by taking no further takeover actions of its own. Moreover, 1026 the peer MUST mark the target server as "not active" on its 1027 internal peer list so that its status will no longer be 1028 monitored by the peer, and reply the initiating server with 1029 an ENRP_INIT_TAKEOVER_ACK message. 1031 B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER 1032 message. 1034 3. If the peer finds that it is neither the target server nor is in 1035 its own take-over process, the peer MUST: a) mark the target 1036 server as "not active" on its internal peer list so that its 1037 status will no longer be monitored by this peer, and b) MUST 1038 reply to the initiating server with an ENRP_INIT_TAKEOVER_ACK 1039 message. 1041 Once the initiating server has received the ENRP_INIT_TAKEOVER_ACK 1042 message from all of its currently known peers (except for the target 1043 server), it MUST consider that it has won the arbitration and MUST 1044 proceed to complete the take-over, following the steps described in 1045 Section 3.5.2. 1047 However, if it receives an ENRP_PRESENCE from the target server at 1048 any point in the arbitration process, the initiating server MUST 1049 immediately stop the take-over process and mark the status of the 1050 target server as "active". 1052 3.5.2. Take-over Target Peer Server 1054 The initiating ENRP server MUST first send, via an announcement, an 1055 ENRP_TAKEOVER_SERVER message to inform all its active peers that the 1056 take-over is enforced. The target server's ID MUST be filled in the 1057 message. The initiating server SHOULD then remove the target server 1058 from its internal peer list. 1060 Then it SHOULD examine its local copy of the handlespace and claim 1061 ownership of each of the PEs originally owned by the target server, 1062 by following these steps: 1064 1. mark itself as the home ENRP server of each of the PEs originally 1065 owned by the target server; 1067 2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the 1068 'H' flag set to '1', to each of the PEs. This will trigger the 1069 PE to adopt the initiating sever as its new home ENRP server; 1071 When a peer receives the ENRP_TAKEOVER_SERVER message from the 1072 initiating server, it SHOULD update its local peer list and PE cache 1073 by following these steps: 1075 1. remove the target server from its internal peer list; 1077 2. update the home ENRP server of each PE in its local copy of the 1078 handlespace to be the sender of the message, i.e., the initiating 1079 server. 1081 3.6. Handlespace Data Auditing and Re-synchronization 1083 Message losses or certain temporary breaks in network connectivity 1084 may result in data inconsistency in the local handlespace copy of 1085 some of the ENRP servers in an operational scope. Therefore, each 1086 ENRP server in the operational scope SHOULD periodically verify that 1087 its local copy of handlespace data is still in sync with that of its 1088 peers. 1090 This section defines the auditing and re-synchronization procedures 1091 for an ENRP server to maintain its handlespace data consistency. 1093 3.6.1. Auditing Procedures 1095 A checksum covering the data which should be the same is exchanged to 1096 figure out if the data is the same or not. 1098 The auditing of handlespace consistency is based on the following 1099 procedures: 1101 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1102 integer internal variable) for each of its known peers and for 1103 itself. For an ENRP server with 'k' known peers, we denote these 1104 internal variables as "pe_checksum_pr0", "pe_checksum_pr1", ..., 1105 "pe_checksum_prk", where "pe_checksum_pr0" is the server's own PE 1106 checksum. The list of what these checksums cover and a detailed 1107 algorithm for calculating them is given in Section 3.6.2. 1109 2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST 1110 include in the message its current PE checksum (i.e., 1111 "pe_checksum_pr0"). 1113 3. When an ENRP server (server A) receives a PE checksum (carried in 1114 an arrived ENRP_PRESENCE) from a peer ENRP server (server B), 1115 server A SHOULD compare the PE checksum found in the 1116 ENRP_PRESENCE with its own internal PE checksum of server B 1117 (i.e., "pe_checksum_prB"). 1119 4. If the two values match, server A will consider that there is no 1120 handlespace inconsistency between itself and server B and should 1121 take no further actions. 1123 5. If the two values do NOT match, server A SHOULD consider that 1124 there is a handlespace inconsistency between itself and server B 1125 and a re-synchronization process SHOULD be carried out 1126 immediately with server B (see Section 3.6.3). 1128 3.6.2. PE Checksum Calculation Algorithm 1130 When an ENRP server (server A) calculate an internal PE checksum for 1131 a peer (server B), it MUST use the following algorithm. 1133 Let us assume that in server A's internal handlespace there are 1134 currently 'M' PEs that are owned by server B. Each of the 'M' PEs 1135 will then contribute to the checksum calculation with the following 1136 byte block: 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 : Pool handle string of the pool the PE belongs (padded with : 1142 : zeros to next 32-bit word boundary if needed) : 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | PE Id (4 octets) | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 Note, these are not TLVs. This byte block gives each PE a unique 1148 byte pattern in the scope. The 16-bit PE checksum for server B 1149 "pe_checksum_prB" is then calculated over the byte blocks contributed 1150 by the 'M' PEs one by one. The PE checksum calculation MUST use the 1151 Internet algorithm described in [RFC1071]. 1153 Server A MUST calculate its own PE checksum (i.e., "pe_checksum_pr0") 1154 in the same fashion, using the byte blocks of all the PEs owned by 1155 itself. 1157 Note, whenever an ENRP finds that its internal handlespace has 1158 changed (e.g., due to PE registration/deregistration, receiving peer 1159 updates, removing failed PEs, downloading handlespace pieces from a 1160 peer, etc.), it MUST immediately update all its internal PE checksums 1161 that are affected by the change. 1163 Implementation Note: when the internal handlespace changes (e.g., a 1164 new PE added or an existing PE removed), an implementation needs not 1165 to re-calculate the affected PE checksum; it can instead simply 1166 update the checksum by adding or subtracting the byte block of the 1167 corresponding PE from the previous checksum value. 1169 3.6.3. Re-synchronization Procedures 1171 If an ENRP server determines that there is inconsistency between its 1172 local handlespace data and a peer's handlespace data with regarding 1173 to the PEs owned by that peer, it MUST perform the following steps to 1174 re-synchronize the data: 1176 1. The ENRP server SHOULD first "mark" every PE it knows about that 1177 is owned by the peer in its local handlespace database; 1179 2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST 1180 message with W flag set to '1' to the peer to request a complete 1181 list of PEs owned by the peer; 1183 3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with W 1184 flag set to '1', the peer server SHOULD immediately respond with 1185 an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently 1186 owned by the peer. 1188 4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the 1189 ENRP server SHOULD transfer the PE entries carried in the message 1190 into its local handlespace database. If an PE entry being 1191 transferred already exists in its local database, the ENRP server 1192 MUST replace the entry with the copy found in the message and 1193 remove the "mark" from the entry. 1195 5. After transferring all the PE entries from the received 1196 ENRP_HANDLE_TABLE_RESPONSE message into its local database, the 1197 ENRP server SHOULD check whether there are still PE entries that 1198 remain "marked" in its local handlespace. If so, the ENRP server 1199 SHOULD silently remove those "marked" entries. 1201 Note, similar to what is described in Section 3.2.3, the peer may 1202 reject the ENRP_HANDLE_TABLE_REQUEST or use more than one 1203 ENRP_HANDLE_TABLE_RESPONSE message to respond. 1205 3.7. Handling Unrecognized Message or Unrecognized Parameter 1207 When an ENRP server receives an ENRP message with an unknown message 1208 type or a message of known type that contains an unknown parameter, 1209 it SHOULD handle the unknown message or the unknown parameter 1210 according to the unrecognized message and parameter handling rules 1211 defined in Sections 3 and 4 in [I-D.ietf-rserpool-common-param]. 1213 According to the rules, if an error report to the message sender is 1214 needed, the ENRP server that discovered the error SHOULD send back an 1215 ENRP_ERROR message with proper error cause code. 1217 4. Variables and Thresholds 1219 4.1. Variables 1221 peer_last_heard - the local time that a peer server was last heard 1222 (via receiving either a group-cast or point-to-point message from 1223 the peer). 1225 pe_checksum_pr - the internal 32-bit PE checksum that an ENRP server 1226 keeps for a peer. A separate PE checksum is kept for each of its 1227 known peers as well as for itself. 1229 4.2. Thresholds 1231 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1232 heartbeat message to all its known peers. (Default=30 secs.) 1234 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1235 will wait before considering a silent peer server potentially 1236 dead. (Default=61 secs.) 1238 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1239 sender will wait for a response after sending out a message. 1240 (Default=5 secs.) 1242 5. IANA Considerations 1244 [NOTE to RFC-Editor: 1246 "RFCXXXX" is to be replaced by the RFC number you assign this 1247 document. 1249 ] 1251 This document (RFCXXX) is the reference for all registrations 1252 described in this section. All registrations need to be listed on an 1253 RSerPool specific page. 1255 5.1. A New Table for ENRP Message Types 1257 ENRP Message Types have to be maintained by IANA. Ten initial values 1258 should be assigned by IANA as described in Figure 1. This requires a 1259 new table "ENRP Message Types": 1261 Type Message Name Reference 1262 ----- ------------------------- --------- 1263 0x00 (reserved by IETF) RFCXXXX 1264 0x01 ENRP_PRESENCE RFCXXXX 1265 0x02 ENRP_HANDLE_TABLE_REQUEST RFCXXXX 1266 0x03 ENRP_HANDLE_TABLE_RESPONSE RFCXXXX 1267 0x04 ENRP_HANDLE_UPDATE RFCXXXX 1268 0x05 ENRP_LIST_REQUEST RFCXXXX 1269 0x06 ENRP_LIST_RESPONSE RFCXXXX 1270 0x07 ENRP_INIT_TAKEOVER RFCXXXX 1271 0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX 1272 0x09 ENRP_TAKEOVER_SERVER RFCXXXX 1273 0x0a ENRP_ERROR RFCXXXX 1274 0x0b-0xff (reserved by IETF) RFCXXXX 1276 For registering at IANA an ENRP Message Type in this table a request 1277 has to be made to assign such a number. This number must be unique. 1278 The "Specification Required" policy of [RFC5226] MUST be applied. 1280 5.2. A New Table for Update Action Types 1282 Update Types have to be maintained by IANA. Two initial values 1283 should be assigned by IANA. This requires a new table "Update Action 1284 Types": 1286 Type Update Action Reference 1287 ------------- -------------------- --------- 1288 0x0000 ADD_PE RFCXXXX 1289 0x0001 DEL_PE RFCXXXX 1290 0x0002-0xffff (reserved by IETF) RFCXXXX 1292 For registering at IANA an Update Action Type in this table a request 1293 has to be made to assign such a number. This number must be unique. 1294 The "Specification Required" policy of [RFC5226] MUST be applied. 1296 5.3. Port numbers 1298 The references for the already assigned port numbers 1300 enrp-udp 9901/udp 1302 enrp-sctp 9901/sctp 1304 enrp-sctp-tls 9902/sctp 1306 should be updated to RFCXXXX. 1308 5.4. SCTP payload protocol identifier 1310 The reference for the already assigned ENRP payload protocol 1311 identifier 12 should be updated to RFCXXXX. 1313 6. Security Considerations 1315 We present a summary of the threats to the RSerPool architecture and 1316 describe security requirements in response to mitigate the threats. 1317 Next we present the security mechanisms, based on TLS, that are 1318 implementation requirements in response to the threats. Finally, we 1319 present a chain of trust argument that examines critical data paths 1320 in RSerPool and shows how these paths are protected by the TLS 1321 implementation. 1323 6.1. Summary of Rserpool Security Threats 1325 Threats Introduced by RSerPool and Requirements for Security in 1326 Response to Threats [I-D.ietf-rserpool-threats] describes the threats 1327 to the RSerPool architecture in detail lists the security 1328 requirements in response to each threat. From the threats described 1329 in this document, the security services required for the RSerPool 1330 protocol are enumerated below. 1332 Threat 1) PE registration/deregistration flooding or spoofing 1333 ----------- 1334 Security mechanism in response: ENRP server authenticates the PE 1336 Threat 2) PE registers with a malicious ENRP server 1337 ----------- 1338 Security mechanism in response: PE authenticates the ENRP server 1340 Threat 1 and 2 taken together results in mutual authentication of the 1341 ENRP server and the PE. 1343 Threat 3) Malicious ENRP server joins the ENRP server pool 1344 ----------- 1345 Security mechanism in response: ENRP servers mutually authenticate 1347 Threat 4) A PU communicates with a malicious ENRP server for handle 1348 resolution 1349 ----------- 1350 Security mechanism in response: The PU authenticates the ENRP server 1352 Threat 5) Replay attack 1353 ----------- 1354 Security mechanism in response: Security protocol which has 1355 protection from replay attacks 1357 Threat 6) Corrupted data which causes a PU to have misinformation 1358 concerning a pool handle resolution 1359 ----------- 1360 Security mechanism in response: Security protocol which supports 1361 integrity protection 1363 Threat 7) Eavesdropper snooping on handlespace information 1364 ----------- 1365 Security mechanism in response: Security protocol which supports data 1366 confidentiality 1368 Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to 1369 ENRP server 1370 ----------- 1371 Security mechanism in response: ASAP must control the number of ASAP 1372 endpoint unreachable messages transmitted from the PU to the ENRP 1373 server. 1375 Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from 1376 the ENRP server 1377 ----------- 1378 Security mechanism in response: ENRP server must control the number 1379 of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE 1381 To summarize the threats 1-7 require security mechanisms which 1382 support authentication, integrity, data confidentiality, protection 1383 from replay attacks. 1385 For RSerPool we need to authenticate the following: 1387 PU <---- ENRP Server (PU authenticates the ENRP server) 1388 PE <----> ENRP Server (mutual authentication) 1389 ENRP server <-----> ENRP Server (mutual authentication) 1391 6.2. Implementing Security Mechanisms 1393 We do not define any new security mechanisms specifically for 1394 responding to threats 1-7. Rather we use an existing IETF security 1395 protocol, specifically [RFC3237], to provide the security services 1396 required. TLS supports all these requirements and MUST be 1397 implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be 1398 supported at a minimum by implementors of TLS for Rserpool. For 1399 purposes of backwards compatibility, ENRP SHOULD support 1400 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1401 other IETF approved ciphersuites. 1403 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs MUST 1404 support mutual authentication using PSK. ENRP servers MUST support 1405 mutual authentication among themselves using PSK. PUs MUST 1406 authenticate ENRP servers using certificates. 1408 TLS with PSK is mandatory to implement as the authentication 1409 mechanism for ENRP to ENRP authentication and PE to ENRP 1410 authentication. For PSK, having a pre-shared-key constitutes 1411 authorization.The network administrators of a pool need to decide 1412 which nodes are authorized to participate in the pool. The 1413 justification for PSK is that we assume that one administrative 1414 domain will control and manage the server pool. This allows for PSK 1415 to be implemented and managed by a central security administrator. 1417 TLS with certificates is mandatory to implement as the authentication 1418 mechanism for PU to ENRP server. PUs MUST autnthenticate ENRP 1419 servers using certificates. ENRP servers MUST possess a site 1420 certificate whose subject corresponds to their canonical hostname. 1421 PUs MAY have certificates of their own for mutual authentication with 1422 TLS, but no provisions are set forth in this document for their use. 1423 All Rserpool elements that support TLS MUST have a mechanism for 1424 validating certificates received during TLS negotiation; this entails 1425 possession of one or more root certificates issued by certificate 1426 authorities (preferably well-known distributors of site certificates 1427 comparable to those that issue root certificates for web browsers). 1429 In order to prevent man-in-the-middle attacks, the client MUST verify 1430 the server's identity (as presented in the server's Certificate 1431 message). The client's understanding of the server's identity 1432 (typically the identity used to establish the transport connection) 1433 is called the "reference identity". The client determines the type 1434 (e.g., DNS name or IP address) of the reference identity and performs 1435 a comparison between the reference identity and each subjectAltName 1436 value of the corresponding type until a match is produced. Once a 1437 match is produced, the server's identity has been verified, and the 1438 server identity check is complete. Different subjectAltName types 1439 are matched in different ways. The client may map the reference 1440 identity to a different type prior to performing a comparison. 1441 Mappings may be performed for all available subjectAltName types to 1442 which the reference identity can be mapped; however, the reference 1443 identity should only be mapped to types for which the mapping is 1444 either inherently secure (e.g., extracting the DNS name from a URI to 1445 compare with a subjectAltName of type dNSName) or for which the 1446 mapping is performed in a secure manner (e.g., using DNSSEC, or using 1447 user- or admin-configured host- to-address/address-to-host lookup 1448 tables).. 1450 If the server identity check fails, user-oriented clients SHOULD 1451 either notify the user or close the transport connection and indicate 1452 that the server's identity is suspect. Automated clients SHOULD 1453 close the transport connection and then return or log an error 1454 indicating that the server's identity is suspect or both. Beyond the 1455 server identity check described in this section, clients should be 1456 prepared to do further checking to ensure that the server is 1457 authorized to provide the service it is requested to provide. The 1458 client may need to make use of local policy information in making 1459 this determination. 1461 If the reference identity is an internationalized domain name, 1462 conforming implementations MUST convert it to the ASCII Compatible 1463 Encoding (ACE) format as specified in Section 4 of [RFC3490] before 1464 comparison with subjectAltName values of type dNSName. Specifically, 1465 conforming implementations MUST perform the conversion operation 1466 specified in Section 4 of [RFC3490] as follows: * in step 1, the 1467 domain name SHALL be considered a "stored string"; * in step 3, set 1468 the flag called "UseSTD3ASCIIRules"; * in step 4, process each label 1469 with the "ToASCII" operation; and * in step 5, change all label 1470 separators to U+002E (full stop). 1472 After performing the "to-ASCII" conversion, the DNS labels and names 1473 MUST be compared for equality according to the rules specified in 1474 Section 3 of RFC3490. The '*' (ASCII 42) wildcard character is 1475 allowed in subjectAltName values of type dNSName, and then only as 1476 the left-most (least significant) DNS label in that value. This 1477 wildcard matches any left-most DNS label in the server name. That 1478 is, the subject *.example.com matches the server names a.example.com 1479 and b.example.com, but does not match example.com or a.b.example.com. 1481 When the reference identity is an IP address, the identity MUST be 1482 converted to the "network byte order" octet string representation RFC 1483 791[RFC0791][RFC2460][RFC2460]. For IP Version 4, as specified in 1484 RFC 791, the octet string will contain exactly four octets. For IP 1485 Version 6, as specified in RFC 2460, the octet string will contain 1486 exactly sixteen octets. This octet string is then compared against 1487 subjectAltName values of type iPAddress. A match occurs if the 1488 reference identity octet string and value octet strings are 1489 identical. 1491 After a TLS layer is established in an session, both parties are to 1492 each independently decide whether or not to continue based on local 1493 policy and the security level achieved. If either party decides that 1494 the security level is inadequate for it to continue, it SHOULD remove 1495 the TLS layer immediately after the TLS (re)negotiation has completed 1496 (see RFC4511)[RFC4511]. Implementations may reevaluate the security 1497 level at any time and, upon finding it inadequate, should remove the 1498 TLS layer. 1500 Implementations MUST support TLS with SCTP as described in [RFC3436] 1501 or TLS over TCP as described in [RFC4346]. When using TLS/SCTP we 1502 must ensure that RSerPool does not use any features of SCTP that are 1503 not available to an TLS/SCTP user. This is not a difficult technical 1504 problem, but simply a requirement. When describing an API of the 1505 RSerPool lower layer we have also to take into account the 1506 differences between TLS and SCTP. 1508 Threat 8 requires the ASAP protocol to limit the number of 1509 ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document) 1510 to the ENRP server. 1512 Threat 9 requires the ENRP protocol to limit the number of 1513 ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE. 1515 There is no security mechanism defined for the multicast 1516 announcements. Therefore a receiver of such an announcement can not 1517 consider the source address of such a message to be a trustworthy 1518 address of an ENRP server. A receiver must also be prepared to 1519 receive a large number of multicast announcements from attackers. 1521 6.3. Chain of trust 1523 Security is mandatory to implement in RSerPool and is based on TLS 1524 implementation in all three architecture components that comprise 1525 RSerPool -- namely PU, PE and ENRP server. We define an ENRP server 1526 that uses TLS for all communication and authenticates ENRP peers and 1527 PE registrants to be a secured ENRP server. 1529 Here is a description of all possible data paths and a description of 1530 the security. 1532 PU <---> secured ENRP Server (authentication of ENRP server; 1533 queries over TLS) 1534 PE <---> secured ENRP server (mutual authentication; 1535 registration/deregistration over TLS) 1536 secured ENRP server <---> secured ENRP server (mutual authentication; 1537 database updates using TLS) 1539 If all components of the system authenticate and communicate using 1540 TLS, the chain of trust is sound. The root of the trust chain is the 1541 ENRP server. If that is secured using TLS, then security will be 1542 enforced for all ENRP and PE components that try to connect to it. 1544 Summary of interaction between secured and unsecured components: If 1545 the PE does not use TLS and tries to register with a secure ENRP 1546 server, it will receive an error message response indicated as error 1547 due to security considerations and the registration will be rejected. 1548 If an ENRP server which does not use TLS tries to update the database 1549 of a secure ENRP server, then the update will be rejected. If an PU 1550 does not use TLS and communicates with a secure ENRP server, it will 1551 get a response with the understanding that the response is not secure 1552 as the response can be tampered with in transit even if the ENRP 1553 database is secured. 1555 The final case is the PU sending a secure request to ENRP. It might 1556 be that ENRP and PEs are not secured and this is an allowable 1557 configuration. The intent is to secure the communication over the 1558 Internet between the PU and the ENRP server. 1560 Summary: 1562 RSerPool architecture components can communicate with each other to 1563 establish a chain of trust. Secured PE and ENRP servers reject any 1564 communications with unsecured ENRP or PE servers. 1566 If the above is enforced, then a chain of trust is established for 1567 the RSerPool user. 1569 7. Acknowledgments 1571 The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, 1572 Thomas Dreibholz, Frank Volkmer, and many others for their invaluable 1573 comments and feedback. 1575 8. References 1577 8.1. Normative References 1579 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1580 September 1981. 1582 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1583 "Computing the Internet checksum", RFC 1071, 1584 September 1988. 1586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1587 Requirement Levels", BCP 14, RFC 2119, March 1997. 1589 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1590 (IPv6) Specification", RFC 2460, December 1998. 1592 [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 1593 Loughney, J., and M. Stillman, "Requirements for Reliable 1594 Server Pooling", RFC 3237, January 2002. 1596 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1597 Layer Security over Stream Control Transmission Protocol", 1598 RFC 3436, December 2002. 1600 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1601 "Internationalizing Domain Names in Applications (IDNA)", 1602 RFC 3490, March 2003. 1604 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1605 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1607 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 1608 (LDAP): The Protocol", RFC 4511, June 2006. 1610 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1611 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1612 May 2008. 1614 [I-D.ietf-rserpool-common-param] 1615 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 1616 "Aggregate Server Access Protocol (ASAP) and Endpoint 1617 Handlespace Redundancy Protocol (ENRP) Parameters", 1618 draft-ietf-rserpool-common-param-17 (work in progress), 1619 May 2008. 1621 [I-D.ietf-rserpool-asap] 1622 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 1623 "Aggregate Server Access Protocol (ASAP)", 1624 draft-ietf-rserpool-asap-20 (work in progress), May 2008. 1626 [I-D.ietf-rserpool-threats] 1627 Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. 1628 Sengodan, "Threats Introduced by RSerPool and Requirements 1629 for Security in Response to Threats", 1630 draft-ietf-rserpool-threats-15 (work in progress), 1631 July 2008. 1633 [I-D.ietf-tsvwg-sctpsocket] 1634 Stewart, R., Xie, Q., Corp, T., Poon, K., Tuexen, M., and 1635 V. Yasevich, "Sockets API Extensions for Stream Control 1636 Transmission Protocol (SCTP)", 1637 draft-ietf-tsvwg-sctpsocket-16 (work in progress), 1638 February 2008. 1640 8.2. Informative References 1642 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1643 Requirements for Security", BCP 106, RFC 4086, June 2005. 1645 Authors' Addresses 1647 Qiaobing Xie 1648 USA 1650 Phone: +1 224-465-5954 1651 Email: Qiaobing.Xie@gmail.org 1653 Randall R. Stewart 1654 4875 Forest Drive 1655 Suite 200 1656 Columbia, SC 29206 1657 USA 1659 Phone: 1660 Email: randall@lakerest.net 1662 Maureen Stillman 1663 Nokia 1664 127 W. State Street 1665 Ithaca, NY 14850 1666 US 1668 Phone: 1669 Email: maureen.stillman@nokia.com 1671 Michael Tuexen 1672 Muenster Univ. of Applied Sciences 1673 Stegerwaldstr. 39 1674 48565 Steinfurt 1675 Germany 1677 Email: tuexen@fh-muenster.de 1679 Aron J. Silverton 1680 Motorola, Inc. 1681 1301 E. Algonquin Road 1682 Room 2246 1683 Schaumburg, IL 60196 1684 USA 1686 Phone: +1 847-576-8747 1687 Email: aron.j.silverton@motorola.com 1689 Full Copyright Statement 1691 Copyright (C) The IETF Trust (2008). 1693 This document is subject to the rights, licenses and restrictions 1694 contained in BCP 78, and except as set forth therein, the authors 1695 retain all their rights. 1697 This document and the information contained herein are provided on an 1698 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1699 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1700 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1701 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1702 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1703 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1705 Intellectual Property 1707 The IETF takes no position regarding the validity or scope of any 1708 Intellectual Property Rights or other rights that might be claimed to 1709 pertain to the implementation or use of the technology described in 1710 this document or the extent to which any license under such rights 1711 might or might not be available; nor does it represent that it has 1712 made any independent effort to identify any such rights. Information 1713 on the procedures with respect to rights in RFC documents can be 1714 found in BCP 78 and BCP 79. 1716 Copies of IPR disclosures made to the IETF Secretariat and any 1717 assurances of licenses to be made available, or the result of an 1718 attempt made to obtain a general license or permission for the use of 1719 such proprietary rights by implementers or users of this 1720 specification can be obtained from the IETF on-line IPR repository at 1721 http://www.ietf.org/ipr. 1723 The IETF invites any interested party to bring to its attention any 1724 copyrights, patents or patent applications, or other proprietary 1725 rights that may cover technology that may be required to implement 1726 this standard. Please address the information to the IETF at 1727 ietf-ipr@ietf.org.