Network Working Group Q. Xie Internet-Draft Motorola Intended status: Experimental R. Stewart Expires: January 10, 2008 Cisco Systems, Inc. M. Stillman Nokia M. Tuexen Muenster Univ. of Applied Sciences A. Silverton Motorola, Inc. July 9, 2007 Endpoint Handlespace Redundancy Protocol (ENRP) draft-ietf-rserpool-enrp-16.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Xie, et al. Expires January 10, 2008 [Page 1] Internet-Draft Endpoint Handlespace Redundancy July 2007 Abstract The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . . 6 2.1. ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6 2.2. ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8 2.3. ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8 2.4. ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10 2.5. ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 16 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . . 17 3.1. Methods for Communicating amongst ENRP Servers . . . . . . 17 3.2. ENRP Server Initialization . . . . . . . . . . . . . . . . 18 3.2.1. Generate a Server Identifier . . . . . . . . . . . . . 18 3.2.2. Acquire Peer Server List . . . . . . . . . . . . . . . 19 3.2.3. Download ENRP Handlespace Data from Mentor Peer . . . 21 3.3. Handle PE Registration . . . . . . . . . . . . . . . . . . 23 3.3.1. Rules on PE Re-registration . . . . . . . . . . . . . 24 3.4. Handle PE De-registration . . . . . . . . . . . . . . . . 25 3.5. Pool Handle Translation . . . . . . . . . . . . . . . . . 26 3.6. Server Handlespace Update . . . . . . . . . . . . . . . . 27 3.6.1. Announcing Addition or Update of PE . . . . . . . . . 27 3.6.2. Announcing Removal of PE . . . . . . . . . . . . . . . 28 3.7. Detecting and Removing Unreachable PE . . . . . . . . . . 28 3.8. Helping PE and PU to Discover Home ENRP Server . . . . . . 29 3.9. Maintaining Peer List and Monitoring Peer Status . . . . . 29 3.9.1. Discovering New Peer . . . . . . . . . . . . . . . . . 30 3.9.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 30 3.9.3. Detecting Peer Server Failure . . . . . . . . . . . . 30 3.10. Taking-over a Failed Peer Server . . . . . . . . . . . . . 30 Xie, et al. Expires January 10, 2008 [Page 2] Internet-Draft Endpoint Handlespace Redundancy July 2007 3.10.1. Initiating Server Take-over Arbitration . . . . . . . 31 3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32 3.11. Handlespace Data Auditing and Re-synchronization . . . . . 32 3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33 3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 33 3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34 3.12. Handling Unrecognized Message or Unrecognized Parameter . 35 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 37 5.2. A New Table for Update Action Types . . . . . . . . . . . 37 5.3. Multicast Addresses . . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 39 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 40 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 41 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.1. Normative References . . . . . . . . . . . . . . . . . . . 44 8.2. Informative References . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 48 Xie, et al. Expires January 10, 2008 [Page 3] Internet-Draft Endpoint Handlespace Redundancy July 2007 1. Introduction ENRP is designed to work in conjunction with ASAP [1] to accomplish the functionality of RSerPool as defined by its requirements [2] and architecture [3]. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. Whenever appropriate, in the rest of this document we will refer to this RSerPool registry service as ENRP handlespace, or simply handlespace because it manages all pool handles. 1.1. Definitions This document uses the following terms: Operational scope: See [3]; Pool (or server pool): See [3]; Pool handle: See [3]; Pool element (PE): See [3]; Pool user (PU): See [3]; Pool element handle: See [3]; ENRP handlespace (or handlespace): See [3]; ENRP client channel: The communication channel through which an ASAP User (either a PE or PU) requests ENRP handlespace service. The client channel is usually defined by the transport address of the home server and a well-known port number. The channel MAY make use of multi-cast or a named list of ENRP servers. ENRP server channel: Defined by a well-known multicast IP address and a well known port number. All ENRP servers in an operational scope can send multicast messages to other servers through this channel. PEs are also allowed to multicast on this channel occasionally; Xie, et al. Expires January 10, 2008 [Page 4] Internet-Draft Endpoint Handlespace Redundancy July 2007 Home ENRP server: The ENRP server to which a PE or PU currently belongs. A PE MUST only have one home ENRP server at any given time and both the PE and its home ENRP server MUST keep track of this master/slave relationship between them. A PU SHOULD select one of the available ENRP servers as its home ENRP server, but the ENRP server does not need to know, nor does it need to keep track of this relationship. 1.2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [6]. Xie, et al. Expires January 10, 2008 [Page 5] Internet-Draft Endpoint Handlespace Redundancy July 2007 2. ENRP Message Definitions In this section, we define the format of all ENRP messages. These are messages sent and received amongst ENRP servers in an operational scope. Messages sent and received between a PE/PU and an ENRP server are part of ASAP and are defined in [1]. A common format, that is defined in [12], is used for all ENRP and ASAP messages. Most ENRP messages contains a combination of fixed fields and TLV parameters. The TLV (Type-Length_value) parameters are also defined in [12]. All messages, as well as their fields/parameters described below, MUST be transmitted in network byte order (a.k.a. Big Endian, meaning the most significant byte is transmitted first). For ENRP, the following message types are defined in this section: Type Message Name ----- ------------------------- 0x00 - (reserved by IETF) 0x01 - ENRP_PRESENCE 0x02 - ENRP_HANDLE_TABLE_REQUEST 0x03 - ENRP_HANDLE_TABLE_RESPONSE 0x04 - ENRP_HANDLE_UPDATE 0x05 - ENRP_LIST_REQUEST 0x06 - ENRP_LIST_RESPONSE 0x07 - ENRP_INIT_TAKEOVER 0x08 - ENRP_INIT_TAKEOVER_ACK 0x09 - ENRP_TAKEOVER_SERVER 0x0a - ENRP_ERROR 0x0b-0xff - (reserved by IETF) Figure 1 Except for the ENRP_PRESENCE message, the usage of the ENRP server channel is for further study. The usage of point-to-point communications is assumed in this specification. 2.1. ENRP_PRESENCE message This ENRP message is used to announce (periodically) the presence of an ENRP server, or to probe the status of a peer ENRP server. This message is either send on the ENRP server channel or point-to-point to another ENRP server. Xie, et al. Expires January 10, 2008 [Page 6] Internet-Draft Endpoint Handlespace Redundancy July 2007 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Checksum Param : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Server Information Param (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R (reply_required) flag: 1 bit Set to '1' if the sender requires a response to this message, otherwise set to '0'. If sent to the ENRP server channel this field MUST be set to '0'. Sending Server's ID: 32 bit (unsigned integer) This is the ID of the ENRP server which sent this message. Receiving Server's ID: 32 bit (unsigned integer) This is the ID of the ENRP server to which this message is intended. If the message is not intended for an individual server (e.g., the message is multicasted to a group of servers), this field MUST be sent with all 0's. If the message is send point-to-point this field MAY be sent with all 0's. PE Checksum Parameter: This is a TLV that contains the latest PE checksum of the ENRP server who sends the ENRP_PRESENCE. This parameter SHOULD be included for handlespace consistency auditing. See Section 3.11.1 for details. Server Information Parameter: If this parameter is present, it contains the server information of the sender of this message (Server Information Parameter is defined in [12]). This parameter is optional. However, if this message is sent in response to a received "reply required" ENRP_PRESENCE from a peer, the sender then Xie, et al. Expires January 10, 2008 [Page 7] Internet-Draft Endpoint Handlespace Redundancy July 2007 MUST include its server information. Note, at startup an ENRP server MUST pick a randomly generated, non- zero 32-bit unsigned integer as its ID and MUST use this same ID until the ENRP server is rebooted. 2.2. ENRP_HANDLE_TABLE_REQUEST message An ENRP server sends this message to one of its peers to request a copy of the handlespace data. This message is normally used during server initialization or handlespace re-synchronization. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ W (oWn-children-only) flag: 1 bit Set to '1' if the sender of this message is only requesting information about the PEs owned by the message receiver. Otherwise, set to '0'. Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. 2.3. ENRP_HANDLE_TABLE_RESPONSE message The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in response to a received PEER_NAME_TABLE_REQUEST message to assist peer server initialization or handle-space synchronization. Xie, et al. Expires January 10, 2008 [Page 8] Internet-Draft Endpoint Handlespace Redundancy July 2007 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Pool entry #1 (optional) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Pool entry #n (optional) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M (More_to_send) flag: 1 bit Set to '1' if the sender of this message has more pool entries to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages. Otherwise, set to '0'. R (Reject) flag: 1 bit MUST be set to '1' if the sender of this message is rejecting a handlespace request. In this case, pool entries MUST not be included. This might happen if the sender of this message is in the middle of initializing its database or it is under high load. Message Length: 16 bits (unsigned integer) Indicates the entire length of the message including the header in number of octets. Note, the value in Message Length field will NOT cover any padding at the end of this message. Xie, et al. Expires January 10, 2008 [Page 9] Internet-Draft Endpoint Handlespace Redundancy July 2007 Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. Pool entry #1-#n: If the R flag is set to '0', at least one pool entry SHOULD be present in this message. Each pool entry MUST start with a Pool Handle parameter as defined in section 3.1.7, and is followed by one or more Pool Element parameters in TLV format, as shown below: +---------------------------+ : Pool handle : +---------------------------+ : PE #1 : +---------------------------+ : PE #2 : +---------------------------+ : ... : +---------------------------+ : PE #n : +---------------------------+ 2.4. ENRP_HANDLE_UPDATE message The PEER_NAME_UPDATE message is sent by the home ENRP server of a PE to all peer servers to announce registration, reregistration, or deregistration of the PE in the handle-space. Xie, et al. Expires January 10, 2008 [Page 10] Internet-Draft Endpoint Handlespace Redundancy July 2007 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Update Action | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Length: 16 bits (unsigned integer) Indicates the entire length of the message including the header in number of octets. Note, the value in Message Length field will NOT cover any padding at the end of this message. Update Action: 16 bits (unsigned integer) This field indicates the requested action of the specified PE. The field MUST be set to one of the following values: 0x0000 - ADD_PE: Add or update the specified PE in the ENRP handlespace 0x0001 - DEL_PE: Delete the specified PE from the ENRP handlespace. 0x0002 - 0xFFFF: Reserved by IETF. Other values are reserved by IETF and MUST not be used. Reserved: 16 bits This field MUST be set to all 0's by sender and ignored by the receiver. Xie, et al. Expires January 10, 2008 [Page 11] Internet-Draft Endpoint Handlespace Redundancy July 2007 Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. Pool handle: Specifies to which the PE belongs. Pool Element: Specifies the PE. 2.5. ENRP_LIST_REQUEST message The PEER_LIST_REQUEST message is sent to request a current copy of the ENRP server list. This message is normally sent from a newly activated ENRP server to an established ENRP server as part of the initialization process. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. Xie, et al. Expires January 10, 2008 [Page 12] Internet-Draft Endpoint Handlespace Redundancy July 2007 2.6. ENRP_LIST_RESPONSE message The PEER_LIST_RESPONSE message is sent in response from an ENRP server that receives a PEER_LIST_REQUEST message to return information about known ENRP servers. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x06 |0|0|0|0|0|0|0|R| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Server Information Parameter of Peer #1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Server Information Parameter of Peer #n : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R (Reject) flag: 1 bit This flag MUST be set to '1' if the sender of this message is rejecting a PEER_LIST_REQUEST message. If this case occurs, the message MUST NOT include any Server Information Parameters. Message Length: 16 bits (unsigned integer) Indicates the entire length of the message in number of octets. Note, the value in Message Length field will NOT cover any padding at the end of this message. Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. Xie, et al. Expires January 10, 2008 [Page 13] Internet-Draft Endpoint Handlespace Redundancy July 2007 Server Information Parameter of Peer #1-#n: Each contains a Server Information Parameter of a peer known to the sender. The Server Information Parameter is defined in [12]. 2.7. ENRP_INIT_TAKEOVER message The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the takeover initiator) to announce its intention of taking over a specific peer ENRP server. It is send to all its peers. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Targeting Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. Targeting Server's ID: 32-bit (unsigned integer) This is the ID of the peer ENRP that is the target of this takeover attempt. 2.8. ENRP_INIT_TAKEOVER_ACK message The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover initiator to acknowledge the reception of the PEER_INIT_TAKEROVER message and that it does not object to the takeover. Xie, et al. Expires January 10, 2008 [Page 14] Internet-Draft Endpoint Handlespace Redundancy July 2007 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Targeting Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. Targeting Server's ID: This is the ID of the peer ENRP that is the target of this takeover attempt. 2.9. ENRP_TAKEOVER_SERVER message The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator to declare the enforcement of a takeover to all active peer ENRP servers. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Targeting Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xie, et al. Expires January 10, 2008 [Page 15] Internet-Draft Endpoint Handlespace Redundancy July 2007 Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. Targeting Server's ID: This is the ID of the peer ENRP that is the target of this takeover operation. 2.10. ENRP_ERROR message The ENRP_ERROR message is sent by a registrar to report an operational error to a peer ENRP server. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operational Error Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sending Server's ID: See Section 2.1. Receiving Server's ID: See Section 2.1. Operational Error Parameter: This parameter, defined in [12], indicates the type of error(s) being reported. Xie, et al. Expires January 10, 2008 [Page 16] Internet-Draft Endpoint Handlespace Redundancy July 2007 3. ENRP Operation Procedures In this section, we discuss the operation procedures defined by ENRP. An ENRP server MUST follow these procedures when sending, receiving, or processing ENRP messages. Many of the RSerPool events call for both server-to-server and PU/ PE-to-server message exchanges. Only the message exchanges and activities between an ENRP server and its peer(s) are considered within the ENRP scope and are defined in this document. Procedures for exchanging messages between a PE/PU and ENRP servers are defined in [1]. 3.1. Methods for Communicating amongst ENRP Servers Within an RSerPool operational scope, ENRP servers need to communicate with each other in order to exchange information such as the pool membership changes, handlespace data synchronization, etc. Two types of communications are used amongst ENRP servers: o point-to-point message exchange from one ENPR server to a specific peer server, and o announcements from one server to all its peer servers in the operational scope. Point-to-point communication is always carried out over an SCTP association between the sending server and the receiving server. Announcements are communicated out with one of the following two approaches: 1. The sending server sends the announcement message to the ENRP server channel. This must also handle the relation between the ENRP server channel and the operational scope. The usage of the ENRP server channel is for further study. 2. The sending server sends multiple copies of the announcement, one to each of its peer servers, over a set of point-to-point SCTP associations between the sending server and the peers. In order to maximize inter-operability of ENRP servers, the following rules MUST be followed: 1. At the startup time, a new ENRP server SHOULD make a decision on whether it will enable IP multicast for ENRP announcements. This Xie, et al. Expires January 10, 2008 [Page 17] Internet-Draft Endpoint Handlespace Redundancy July 2007 decision should be based on preconfigured information such as the availability of IP multicast and the security requirements from the user of RSerPool. 2. If an ENRP server disables multicast, it then: A. MUST NOT subscribe to the well-known server multicast channel, i.e., it only receives peer announcements over SCTP associations, and B. MUST transmit all its out-going announcements over point-to- point SCTP associations with its peers. 3. If an ENRP server enables itself to use multicast, it then: A. MUST subscribe to the well-known server multicast channel to ready itself for receiving peers' multicast announcements, B. MUST also be prepared to receive peer announcements over point-to-point SCTP associations from peers. C. MUST track internally which peers are multicast-enabled and which are not. Note: A peer is always assumed to be multicast-disabled until/unless an ENRP message of any type is received from that peer over the well-known server multicast channel. D. when sending out an announcement, MUST send a copy to the ENRP server channel AND a copy to each of the peers that are marked as multicast-disabled over a point-to-point SCTP association. 3.2. ENRP Server Initialization This section describes the steps a new ENRP server needs to take in order to join the other existing ENRP servers, or to initiate the handlespace service if it is the first ENRP server started in the operational scope. 3.2.1. Generate a Server Identifier A new ENRP server MUST generate a non-zero, 32-bit server Id that is as unique as possible in the operational scope and this server Id MUST remain unchanged for the lifetime of the server. Normally, a good 32-bit random number will be good enough as the server Id ([15] provides some information on randomness guidelines). Note, there is a very remote chance (about 1 in about 4 billion) that Xie, et al. Expires January 10, 2008 [Page 18] Internet-Draft Endpoint Handlespace Redundancy July 2007 two ENRP servers in an operational scope will generate the same server Id and hence cause a server Id conflict in the pool. However, no severe consequence of such a conflict has been identified. 3.2.2. Acquire Peer Server List At startup, the ENRP server (initiating server) will first attempt to learn all existing peer ENRP servers in the same operational scope, or to determine that it is alone in the scope. The initiating server uses an existing peer server to bootstrap itself into service. We call this peer server the mentor server. 3.2.2.1. Finding the mentor server If the initiating server is told about an existing peer server through some administrative means (such as DNS query, configuration database, startup scripts, etc), the initiating server SHOULD then use this peer server as its mentor server and SHOULD skip the remaining steps in this subsection. If multiple existing peer servers are specified, the initiating server SHOULD pick one of them as its mentor server, keep the others as its backup mentor servers, and skip the remaining steps in this subsection. If no existing peer server is specified to the initiating server AND if multicast is available in the operational scope, the following mentor server discovery procedures SHOULD be followed: 1. The initiating server SHOULD first join the ENRP server channel. 2. When the first ENRP_PRESENCE message arrives, the server SHOULD take the sender of this received response as its mentor server. This completes the discovery of the mentor server. If ENRP_PRESENCE messages are also received from other peers (a likely event when multiple peers exist in the operational scope at the time the new server started), the initiating server SHOULD keep a list of those responded as its backup mentor servers (see below). 3. If no response to its ENRP_PRESENCE message are received after TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After that, if there is still no response, the initiating server MUST assume that it is alone in the operational scope. Xie, et al. Expires January 10, 2008 [Page 19] Internet-Draft Endpoint Handlespace Redundancy July 2007 4. If the initiating server determined that it is alone in the scope, it MUST skip the procedures in Section 3.2.2.2 and Section 3.2.3 and MUST consider its initialization completed and start offering ENRP services. Note, if multicast is not available (or not allowed for reasons such as security concerns) in the operational scope, at least one peer server MUST be specified to the initiating server through administrative means, unless the initiation server is the first server to start in the operational scope. Note, if the administratively specified mentor peer(s) fails and the ENRP server channel is available, the initiating server SHOULD use the auto-discover procedure defined in steps 1-5 above. 3.2.2.2. Request complete server list from mentor peer Once the initiating server finds its mentor peer server (by either discovery or administrative means), the initiating server MUST send an ENRP_LIST_REQUEST message to the mentor peer server to request a copy of the complete server list maintained by the mentor peer (see Section 3.9 for maintaining server list). The initiating server SHOULD start a MAX-TIME-NO-RESPONSE timer every time it finishes sending an ENRP_LIST_REQUEST message. If the timer expires before receiving a response from the mentor peer, the initiating server SHOULD abort and send a new server list request to a backup mentor peer, if one is available. Upon the reception of this request, the mentor peer server SHOULD reply with an ENRP_LIST_RESPONSE message and include in the message body all existing ENRP servers known by the mentor peer. Upon the reception of the ENRP_LIST_RESPONSE message from the mentor peer, the initiating server MUST use the server information carried in the message to initialize its own peer list. However, if the mentor itself is in the process of startup and not ready to provide a peer server list (for example, the mentor peer is waiting for a response to its own ENRP_LIST_REQUEST to another server), it MUST reject the request by the initiating server and respond with an ENRP_LIST_RESPONSE message with the R flag set to '1', and with no server information included in the response. In the case where its ENRP_LIST_REQUEST is rejected by the mentor peer, the initiating server SHOULD either wait for a few seconds and re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a backup mentor peer available, select another mentor peer server and Xie, et al. Expires January 10, 2008 [Page 20] Internet-Draft Endpoint Handlespace Redundancy July 2007 send the ENRP_LIST_REQUEST to the new mentor server. 3.2.3. Download ENRP Handlespace Data from Mentor Peer After a peer list download is completed, the initiating server MUST request a copy of the current handlespace data from its mentor peer server, by taking the following steps: 1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST message to the mentor peer, with W flag set to '0', indicating that the entire handlespace is requested. 2. Upon the reception of this message, the mentor peer MUST start a download session in which a copy of the current handlespace data maintained by the mentor peer is sent to the initiating server in one or more ENRP_HANDLE_TABLE_RESPONSE messages (Note, the mentor server may find it particularly desirable to use multiple ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when the handlespace is large, especially when forming and sending out a single response containing a large handlespace may interrupt its other services). If more than one ENRP_HANDLE_TABLE_RESPONSE message are used during the download, the mentor peer MUST use the M flag in each ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this message is the last one for the download session. In particular, the mentor peer MUST set the M flag to '1' in the outbound ENRP_HANDLE_TABLE_RESPONSE if there is more data to be transferred and MUST keep track of the progress of the current download session. The mentor peer MUST set the M flag to '0' in the last ENRP_HANDLE_TABLE_RESPONSE for the download session and close the download session (i.e., removing any internal record of the session) after sending out the last message. 3. During the downloading, every time the initiating server receives an ENRP_HANDLE_TABLE_RESPONSE message, it MUST transfer the data entries carried in the message into its local handlespace database, and then check whether or not this message is the last one for the download session. If the M flag is set to '1' in the just processed ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer to request for the next ENRP_HANDLE_TABLE_RESPONSE message. 4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE message into its local handlespace database, the initiating server MUST handle each pool entry carried in the message using Xie, et al. Expires January 10, 2008 [Page 21] Internet-Draft Endpoint Handlespace Redundancy July 2007 the following rules: A. If the pool does not exist in the local handlespace, the initiating server MUST create the pool in the local handlespace and add the PE(s) in the pool entry to the pool. When creating the pool, the initiation server MUST set the overall member selection policy type of the pool to the policy type indicated in the first PE. B. If the pool already exists in the local handlespace, but the PE(s) in the pool entry is not currently a member of the pool, the initiating server MUST add the PE(s) to the pool. C. If the pool already exists in the local handlespace AND the PE(s) in the Pool entry is already a member of the pool, the initiating server SHOULD replace the attributes of the existing PE(s) with the new information. ENRP will make sure that the information keeps up to date. 5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from the mentor peer and unpacked into the local handlespace, the initialization process is completed and the initiating server SHOULD start to provide ENRP services. Under certain circumstances, the mentor peer itself may not be able to provide a handlespace download to the initiating server. For example, the mentor peer is in the middle of initializing its own handlespace database, or it has currently too many download sessions open to other servers. In such a case, the mentor peer MUST reject the request by the initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE message with the R flag set to '1', and with no pool entries included in the response. In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the mentor peer, the initiating server SHOULD either wait for a few seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor server, or if there is a backup mentor peer available, select another mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new mentor server. A handlespace download session that has been started may get interrupted for some reason. To cope with this, the initiating server SHOULD start a timer every time it finishes sending an ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires without receiving a response from the mentor peer, the initiating Xie, et al. Expires January 10, 2008 [Page 22] Internet-Draft Endpoint Handlespace Redundancy July 2007 server SHOULD abort the current download session and re-start a new handlespace download with a backup mentor peer, if one is available. Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the mentor peer set the M-bit to 1 to indicate that it has more data to send, it SHOULD start a session timer. If this timer expires without receiving another request from the initiating server, the mentor peer SHOULD abort the session, cleaning out any resource and record of the session. 3.3. Handle PE Registration To register itself with the handlespace, a PE sends an ASAP_REGISTRATION message to its home ENRP server. The format of ASAP_REGISTRATION message and rules of sending it are defined in [1]. In the ASAP_REGISTRATION message, the PE indicates the handle of the pool it wishes to join in a pool handle parameter, and its complete transport information and any load control information in a PE parameter. The ENRP server handles the ASAP_REGISTRATION message according to the following rules: 1. If the named pool does not exist in the handlespace, the ENRP server MUST creates a new pool with that handle in the handlespace and add the PE to the pool as its first PE; When a new pool is created, the overall member selection policy of the pool MUST be set to the policy type indicated by the first PE, the overall pool transport type MUST be set to the transport type indicated by the PE, and the overall pool data/control channel configuration MUST be set to what is indicated in the Transport Use field of the User Transport parameter by the registering PE. 2. If the named pool already exists in the handlespace, but the requesting PE is not currently a member of the pool, the ENRP server will add the PE as a new member to the pool; However, before adding the PE to the pool, the server MUST check if the policy type, transport type, and transport usage indicated by the registering PE is consistent with those of the pool. If different, the ENRP server MUST reject the registration. 3. If the named pool already exists in the handlespace AND the requesting PE is already a member of the pool, the ENRP server SHOULD consider this as a re-registration case. The ENRP server Xie, et al. Expires January 10, 2008 [Page 23] Internet-Draft Endpoint Handlespace Redundancy July 2007 MUST perform the same tests on policy, transport type, transport use, as described above. If the re-registration is accepted after the test, the ENRP Server SHOULD replace the attributes of the existing PE with the information carried in the received ASAP_REGISTRATION message. 4. After accepting the registration, the ENRP server MUST assign itself the owner of this PE. If this is a re-registration, the ENRP server MUST take over ownership of this PE regardless of whether the PE was previously owned by this server or by another server. The ENRP server MUST also record the SCTP transport address from which it received the ASAP_REGISTRATION in the ASAP Transport parameter TLV inside the PE parameter of this PE. 5. The ENRP server may reject the registration due to other reasons such as invalid values, lack of resource, authentication failure, etc. In all above cases, the ENRP server MUST reply to the requesting PE with an ASAP_REGISTRATION_RESPONSE message. If the registration is accepted, the ENRP server MUST set the 'R' flag in the ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, the ENRP server MUST indicate the rejection by setting the 'R' flag in the ASAP_REGISTRATION_RESPONSE to '1'. If the registration is rejected, the ENRP server SHOULD include the proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. If the registration is granted (either a new registration or a re- registration case), the ENRP server MUST assign itself to be the home ENRP server of the PE, i.e., to "own" the PE. Implementation note: for better performance, the ENRP server may find it both efficient and convenient to internally maintain two separate PE lists or tables - one is for the PEs that are "owned" by the ENRP server and the other for all the PEs owned by its peer(s). Moreover, if the registration is granted, the ENRP server MUST take the handlespace update action as described in Section 3.6 to inform its peers about the change just made. If the registration is denied, no message will be sent to its peers. 3.3.1. Rules on PE Re-registration A PE may re-register itself to the handlespace with a new set of attributes in order to, for example, extend its registration life, change its load factor value, etc. as described in the ASAP Xie, et al. Expires January 10, 2008 [Page 24] Internet-Draft Endpoint Handlespace Redundancy July 2007 specification. A PE may modify its load factor value at any time via re- registration. Based on the number of PEs in the pool and the pool's overall policy type, this operation allows the PE to dynamically control its share of inbound messages received by the pool (also see Section ???? in [1] for more on load control). Moreover, when re-registering, the PE MUST NOT change its policy type. The server MUST reject the re-registration if the PE attempt to change its policy type. In the rejection, the server SHOULD attach an error code "Pooling Policy Inconsistent". Regardless whether it is the current owner of the PE, if the re- registration is granted to the PE, the ENRP server MUST assign itself to be the new home ENRP server of the PE. Moreover, if the re-registration is granted, the ENRP server MUST take the handlespace update action as described in Section 3.6 to inform its peers about the change just made. If the re-registration is denied, no message will be sent to its peers. 3.4. Handle PE De-registration To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION message to its home ENRP server. The complete format of ASAP_DEREGISTRATION message and rules of sending it are defined in [1]. In the ASAP_DEREGISTRATION message the PE indicates the handle of the pool it belongs to in a pool handle parameter and provides its PE identifier. Upon receiving the message, the ENRP server SHALL remove the PE from its handlespace. Moreover, if the PE is the last one of the named pool, the ENRP server will remove the pool from the handlespace as well. If the ENRP server fails to find any record of the PE in its handlespace, it SHOULD consider the de-registration granted and completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the PE. The ENRP server may reject the de-registration request for various reasons, such as invalid parameters, authentication failure, etc. In response, the ENRP server MUST send an ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de- Xie, et al. Expires January 10, 2008 [Page 25] Internet-Draft Endpoint Handlespace Redundancy July 2007 registration is rejected, the ENRP server MUST indicate the rejection by including the proper Operational Error parameter. It should be noted that de-registration does not stop the PE from sending or receiving application messages. Once the de-registration request is granted AND the PE removed from its local copy of the handlespace, the ENRP server MUST take the handlespace update action described in Section 3.6 to inform its peers about the change just made. Otherwise, the ENRP server MUST NOT inform its peers. 3.5. Pool Handle Translation A PU uses the pool handle translation service of an ENRP server to resolve a pool handle to a list of accessible transport addresses of the member PEs of the pool. This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify the pool handle to be translated in a Pool Handle parameter. Complete definition of the ASAP_HANDLE_RESOLUTION message and the rules of sending it are defined in [1]. An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION requests from PUs either over an SCTP association on the well-know SCTP port, or over a TCP connection on the well-know TCP port. Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server MUST first look up the pool handle in its handlespace. If the pool exits, the home ENRP server MUST compose and send back an ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. In the response message, the ENRP server SHOULD list all the PEs currently registered in this pool, in a list of PE parameters. The ENRP server MUST also include a pool member selection policy parameter to indicate the overall member selection policy for the pool, if the current pool member selection policy is not round-robin. If the named pool does not exist in the handlespace, the ENRP server MUST reject the handle resolution request by responding with an ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor Handle error. The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and the rules of receiving it are defined in [1]. Xie, et al. Expires January 10, 2008 [Page 26] Internet-Draft Endpoint Handlespace Redundancy July 2007 3.6. Server Handlespace Update This includes a set of update operations used by an ENRP server to inform its peers when its local handlespace is modified, e.g., addition of a new PE, removal of an existing PE, change of pool or PE properties. 3.6.1. Announcing Addition or Update of PE When a new PE is granted registration to the handlespace or an existing PE is granted a re-registration, the home ENRP server uses this procedure to inform all its peers. This is an ENRP announcement and is sent to all the peer of the home ENRP server. See Section 3.1 on how announcements are sent. An ENRP server MUST announce this update to all its peers in a ENRP_HANDLE_UPDATE message with the Update Action field set to ADD_PE, indicating the addition of a new PE or the modification of an existing PE. The complete new information of the PE and the pool its belongs to MUST be indicated in the message with a PE parameter and a Pool Handle parameter, respectively. The home ENRP server SHOULD fill in its server Id in the Sending Server's ID field and leave the Receiving Server's ID blank (i.e., all 0's). When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take the following actions: 1. If the named pool indicated by the pool handle does not exist in its local copy of the handlespace, the peer MUST create the named pool in its local handlespace and add the PE to the pool as the first PE. It MUST then copy in all other attributes of the PE carried in the message. When the new pool is created, the overall member selection policy of the pool MUST be set to the policy type indicated by the PE. 2. If the named pool already exists in the peer's local copy of the handlespace AND the PE does not exist, the peer MUST add the PE to the pool as a new PE and copy in all attributes of the PE carried in the message. 3. If the named pool exists AND the PE is already a member of the pool, the peer MUST replace the attributes of the PE with the new information carried in the message. Xie, et al. Expires January 10, 2008 [Page 27] Internet-Draft Endpoint Handlespace Redundancy July 2007 3.6.2. Announcing Removal of PE When an existing PE is granted de-registration or is removed from its handlespace for some other reasons (e.g., purging an unreachable PE, see Section 3.7), the ENRP server MUST uses this procedure to inform all its peers about the change just made. This is an ENRP announcement and is sent to all the peer of the home ENRP server. See Section 3.1 on how announcements are sent. An ENRP server MUST announce the PE removal to all its peers in an ENRP_HANDLE_UPDATE message with the Update Action field set to DEL_PE, indicating the removal of an existing PE. The complete information of the PE and the pool its belongs to MUST be indicated in the message with a PE parameter and a Pool Handle parameter, respectively. The sending server MUST fill in its server ID in the Sending Server's ID field and leave the Receiving Server's ID blank (i.e., set to all 0's). When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first find pool and the PE in its own handlespace, and then remove the PE from its local handlespace. If the removed PE is the last one in the pool, the peer MUST also delete the pool from its local handlespace. If the peer fails to find the PE or the pool in its handlespace, it SHOULD take no further actions. 3.7. Detecting and Removing Unreachable PE Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE Notification, see section 10.2 of [9]), the PU SHOULD send an ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The message SHOULD contain the pool handle and the PE Id of the unreachable PE. Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message to the PE in question (the 'H' flag in the message SHOULD be set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP server MUST consider the PE as truly unreachable and MUST remove the PE from its handlespace and take actions described in Section 3.6.2. If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully to the PE, the ENRP server MUST retain the PE in its handlespace. Moreover, the server SHOULD keep a counter to record how many Xie, et al. Expires January 10, 2008 [Page 28] Internet-Draft Endpoint Handlespace Redundancy July 2007 ASAP_ENDPOINT_UNREACHABLE messages it has received reporting reachability problem relating to this PE. If the counter exceeds the protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE from its handlespace and take actions described in Section 3.6.2. Optionally, an ENRP server may also periodically send point-to-point ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each of the PEs owned by the ENRP server in order to check their reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the PE as unreachable and MUST remove the PE from its handlespace and take actions described in Section 3.6.2. Note, if an ENRP server owns a large number of PEs, the implementation should pay attention not to flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period. The complete definition and rules of sending ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE messages are described in [1]. 3.8. Helping PE and PU to Discover Home ENRP Server At its startup time, or whenever its current home ENRP server is not providing services, a PE or PU will attempt to find a new home server. For this reason, the PE or PU will need to maintain a list of currently available ENRP servers in its scope. To help the PE or PU maintaining this list, an ENRP server, if it is enabled for multicast, SHOULD periodically send out an ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP multicast channel. And in the ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the transport addresses available for ASAP communications. If the ENRP server only supports SCTP for ASAP communications, the transport information MAY be omitted in the ASAP_SERVER_ANNOUNCE message. For the complete procedure of this, see Section 3.6?? in [1]. 3.9. Maintaining Peer List and Monitoring Peer Status An ENRP server MUST keep an internal record on the status of each of its known peers. This record is referred to as the server's "peer list" Xie, et al. Expires January 10, 2008 [Page 29] Internet-Draft Endpoint Handlespace Redundancy July 2007 3.9.1. Discovering New Peer If a message of any type is received from a previously unknown peer, the ENRP server MUST consider this peer a new peer in the operational scope and add it to the peer list. The ENRP server MUST send an ENRP_PRESENCE message with the Reply- required flag set to '1' to the source address found in the arrived message. This will force the new peer to reply with its own ENRP_PRESENCE containing its full server information (see Section 2.1). 3.9.2. Server Sending Heartbeat Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its continued presence to all its peer with a ENRP_PRESENCE message. In the ENRP_PRESENCE message, the ENRP server MUST set the 'Replay_required' flag to '0', indicating that no response is required. The arrival of this periodic ENRP_PRESENCE message will cause all its peers to update their internal variable "peer.last.heard" for the sending server (see Section 3.9.3 for more details). 3.9.3. Detecting Peer Server Failure An ENRP server MUST keep an internal variable "peer.last.heard" for each of its known peers and the value of this variable MUST be updated to the current local time every time a message of any type (point-to-point or announcement) is received from the corresponding peer. If a peer has not been heard for more than MAX-TIME-LAST-HEARD seconds, the ENRP server MUST immediately send a point-to-point ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. If the send fails or the peer does not reply after MAX-TIME-NO- RESPONSE seconds, the ENRP server MUST consider the peer server dead and SHOULD initiate the takeover procedure defined in Section 3.10. 3.10. Taking-over a Failed Peer Server In the following descriptions, we call the ENRP server that detects the failed peer server and initiates the take-over the "initiating server" and the failed peer server the "target server." This allows PE to continue to operate in case of a failure of their Home ENRP server. Xie, et al. Expires January 10, 2008 [Page 30] Internet-Draft Endpoint Handlespace Redundancy July 2007 3.10.1. Initiating Server Take-over Arbitration The initiating server SHOULD first start the take-over arbitration process by sending a ENRP_INIT_TAKEOVER message to all its peer servers. See Section 3.1 on how announcements are sent. In the message, the initiating server MUST fill in the Sending Server's ID and Targeting Server's ID. The goal is that only one ENRP server takes over the PE from the target. After announcing the ENRP_INIT_TAKEOVER message, the initiating server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of its known peers, except of the target server. Each peer receiving a ENRP_INIT_TAKEOVER message from the initiating server SHOULD take the following actions: 1. If the peer server determines that itself is the target server indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately announce an ENRP_PRESENCE message to all its peer ENRP servers in an attempt to stop this take-over process. This indicates a false failure detection case by the initiating server. The initiating server MUST stop the takeover operation. 2. If the peer server finds that it has already started its own take-over arbitration process on the same target server, it MUST perform the following arbitration: A. If the peer's server ID is smaller in value than the Sending Server's ID in the arrived ENRP_INIT_TAKEOVER message, the peer server SHOULD immediately abort its own take-over attempt. Moreover, the peer SHOULD mark the target server as "not active" on its internal peer list so that its status will no longer be monitored by the peer, and reply the initiating server with an ENRP_INIT_TAKEOVER_ACK message. B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER message and take no action. 3. If the peer finds that it is neither the target server nor is in its own take-over process, the peer SHOULD: a) mark the target server as "not active" on its internal peer list so that its status will no longer be monitored by this peer, and b) reply to the initiating server with an ENRP_INIT_TAKEOVER_ACK message. Once the initiating server has received ENRP_INIT_TAKEOVER_ACK message from _all_ of its currently known peers (except for the target server), it SHOULD consider that it has won the arbitration and SHOULD proceed to complete the take-over, following the steps Xie, et al. Expires January 10, 2008 [Page 31] Internet-Draft Endpoint Handlespace Redundancy July 2007 described in Section 3.10.2. However, if it receives an ENRP_PRESENCE from the target server at any point in the arbitration process, the initiating server MUST immediately abort the take-over process and mark the status of the target server as "active". 3.10.2. Take-over Target Peer Server The initiating ENRP server SHOULD first send, via an announcement, a ENRP_TAKEOVER_SERVER message to inform all its active peers that the take-over is enforced. The target server's ID MUST be filled in the message. The initiating server SHOULD then remove the target server from its internal peer list. Then it SHOULD examine its local copy of the handlespace and claim ownership of each of the PEs originally owned by the target server, by following these steps: 1. mark itself as the home ENRP server of each of the PEs originally owned by the target server; 2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the 'H' flag set to '1', to each of the PEs. This will trigger the PE to adopt the initiating sever as its new home ENRP server; When a peer receives the ENRP_TAKEOVER_SERVER message from the initiating server, it SHOULD update its local peer list and PE cache by following these steps: 1. remove the target server from its internal peer list; 2. update the home ENRP server of each PE in its local copy of the handlespace to be the sender of the message, i.e., the initiating server. 3.11. Handlespace Data Auditing and Re-synchronization Message losses or certain temporary breaks in network connectivity may result in data inconsistency in the local handlespace copy of some of the ENRP servers in an operational scope. Therefore, each ENRP server in the operational scope SHOULD periodically verify that its local copy of handlespace data is still in sync with that of its peers. This section defines the auditing and re-synchronization procedures for an ENRP server to maintain its handlespace data consistency. Xie, et al. Expires January 10, 2008 [Page 32] Internet-Draft Endpoint Handlespace Redundancy July 2007 3.11.1. Auditing Procedures A checksum covering the data which should be the same is exchanged to figure out if the data is the same or not. The auditing of handlespace consistency is based on the following procedures: 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit integer internal variable) for each of its known peers and for itself. For an ENRP server with 'k' known peers, we denote these internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE checksum. The list of what these checksums cover and a detailed algorithm for calculating them is given in Section 3.11.2. 2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST include in the message its current PE checksum (i.e., "pe.checksum.pr0"). 3. When an ENRP server (server A) receives a PE checksum (carried in an arrived ENRP_PRESENCE) from a peer ENRP server (server B), server A SHOULD compare the PE checksum found in the ENRP_PRESENCE with its own internal PE checksum of server B (i.e., "pe.checksum.prB"). 4. If the two values match, server A will consider that there is no handlespace inconsistency between itself and server B and should take no further actions. 5. If the two values do NOT match, server A SHOULD consider that there is a handlespace inconsistency between itself and server B and a re-synchronization process SHOULD be carried out immediately with server B (see Section 3.11.3). 3.11.2. PE Checksum Calculation Algorithm When an ENRP server (server A) calculate an internal PE checksum for a peer (server B), it MUST use the following algorithm. Let us assume that in server A's internal handlespace there are currently 'M' PEs that are owned by server B. Each of the 'M' PEs will then contribute to the checksum calculation with the following byte block: Xie, et al. Expires January 10, 2008 [Page 33] Internet-Draft Endpoint Handlespace Redundancy July 2007 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool handle string of the pool the PE belongs (padded with : : zeros to next 32-bit word boundary if needed) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE Id (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note, these are not TLVs. This byte block gives each PE a unique byte pattern in the scope. The 16-bit PE checksum for server B "pe.checksum.prB" is then calculated over the byte blocks contributed by the 'M' PEs one by one. The PE checksum calculation MUST use the Internet algorithm described in [4]. Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") in the same fashion, using the byte blocks of all the PEs owned by itself. Note, whenever an ENRP finds that its internal handlespace has changed (e.g., due to PE registration/deregistration, receiving peer updates, removing failed PEs, downloading handlespace pieces from a peer, etc.), it MUST immediately update all its internal PE checksums that are affected by the change. Implementation Note: when the internal handlespace changes (e.g., a new PE added or an existing PE removed), an implementation needs not to re-calculate the affected PE checksum; it can instead simply update the checksum by adding or subtracting the byte block of the corresponding PE from the previous checksum value. 3.11.3. Re-synchronization Procedures If an ENRP server determines that there is inconsistency between its local handlespace data and a peer's handlespace data with regarding to the PEs owned by that peer, it MUST perform the following steps to re-synchronize the data: 1. The ENRP server SHOULD first "mark" every PE it knows about that is owned by the peer in its local handlespace database; 2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST message with W flag set to '1' to the peer to request a complete list of PEs owned by the peer; 3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with W flag set to '1', the peer server SHOULD immediately respond with an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently Xie, et al. Expires January 10, 2008 [Page 34] Internet-Draft Endpoint Handlespace Redundancy July 2007 owned by the peer. 4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the ENRP server SHOULD transfer the PE entries carried in the message into its local handlespace database. If an PE entry being transferred already exists in its local database, the ENRP server MUST replace the entry with the copy found in the message and remove the "mark" from the entry. 5. After transferring all the PE entries from the received ENRP_HANDLE_TABLE_RESPONSE message into its local database, the ENRP server SHOULD check whether there are still PE entries that remain "marked" in its local handlespace. If so, the ENRP server SHOULD silently remove those "marked" entries. Note, similar to what is described in Section 3.2.3, the peer may reject the ENRP_HANDLE_TABLE_REQUEST or use more than one ENRP_HANDLE_TABLE_RESPONSE message to respond. 3.12. Handling Unrecognized Message or Unrecognized Parameter When an ENRP server receives an ENRP message with an unknown message type or a message of known type that contains an unknown parameter, it SHOULD handle the unknown message or the unknown parameter according to the unrecognized message and parameter handling rules defined in Sections 3 and 4 in [12]. According to the rules, if an error report to the message sender is needed, the ENRP server that discovered the error SHOULD send back an ENRP_ERROR message with proper error cause code. Xie, et al. Expires January 10, 2008 [Page 35] Internet-Draft Endpoint Handlespace Redundancy July 2007 4. Variables and Thresholds 4.1. Variables peer.last.heard - the local time that a peer server was last heard (via receiving either a multicast or point-to-point message from the peer). pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server keeps for a peer. A separate PE checksum is kept for each of its known peers as well as for itself. 4.2. Thresholds MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will make to contact an ENRP server (Default=3 times). TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will wait for a response from an ENRP server (Default=5 seconds). PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a heartbeat message to all its known peers. (Default=30 secs.) SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server will wait before considering a silent peer server potentially dead. (Default=61 secs.) MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message sender will wait for a response after sending out a message. (Default=5 secs.) MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a PE that an ENRP server will allow before purging this PE from the handlespace. (Default=3) Xie, et al. Expires January 10, 2008 [Page 36] Internet-Draft Endpoint Handlespace Redundancy July 2007 5. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] This document (RFCXXX) is the reference for all registrations described in this section. All registrations need to be listed on an RSerPool specific page. 5.1. A New Table for ENRP Message Types ENRP Message Types have to be maintained by IANA. Ten initial values should be assigned by IANA as described in Figure 1. This requires a new table "ENRP Message Types": Type Message Name Reference ----- ------------------------- --------- 0x00 (reserved by IETF) RFCXXXX 0x01 ENRP_PRESENCE RFCXXXX 0x02 ENRP_HANDLE_TABLE_REQUEST RFCXXXX 0x03 ENRP_HANDLE_TABLE_RESPONSE RFCXXXX 0x04 ENRP_HANDLE_UPDATE RFCXXXX 0x05 ENRP_LIST_REQUEST RFCXXXX 0x06 ENRP_LIST_RESPONSE RFCXXXX 0x07 ENRP_INIT_TAKEOVER RFCXXXX 0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX 0x09 ENRP_TAKEOVER_SERVER RFCXXXX 0x0a ENRP_ERROR RFCXXXX 0x0b-0xff (reserved by IETF) RFCXXXX For registering at IANA an ENRP Message Type in this table a request has to be made to assign such a number. This number must be unique. The "Specification Required" policy of RFC2434 [8] MUST be applied. 5.2. A New Table for Update Action Types Update Types have to be maintained by IANA. Two initial values should be assigned by IANA. This requires a new table "Update Action Types": Type Update Action Reference ------------- -------------------- --------- 0x0000 ADD_PE RFCXXXX 0x0001 DEL_PE RFCXXXX Xie, et al. Expires January 10, 2008 [Page 37] Internet-Draft Endpoint Handlespace Redundancy July 2007 0x0002-0xffff (reserved by IETF) RFCXXXX For registering at IANA an Update Action Type in this table a request has to be made to assign such a number. This number must be unique. The "Specification Required" policy of RFC2434 [8] MUST be applied. 5.3. Multicast Addresses IANA should assign one multicast address for the ENRP server channel and another one for the ENRP client channel. Xie, et al. Expires January 10, 2008 [Page 38] Internet-Draft Endpoint Handlespace Redundancy July 2007 6. Security Considerations We present a summary of the threats to the RSerPool architecture and describe security requirements in response to mitigate the threats.ENext we present the security mechanisms, based on TLS, that are implementation requirements in response to the threats.E Finally, we present a chain of trust argument that examines critical data paths in RSerPool and shows how these paths are protected by the TLS implementation. 6.1. Summary of Rserpool Security Threats Threats Introduced by RSerPool and Requirements for Security in Response to Threats [13] describes the threats to the RSerPool architecture in detail lists the security requirements in response to each threat.E From the threats described in this document, the security services required for the RSerPool protocol are enumerated below. Threat 1) PE registration/deregistration flooding or spoofing ----------- Security mechanism in response: ENRP server authenticates the PE Threat 2) PE registers with a malicious ENRP server ----------- Security mechanism in response: PE authenticates the ENRP server Threat 1 and 2 taken together results in mutual authentication of the ENRP server and the PE. Threat 3) Malicious ENRP server joins the ENRP server pool ----------- Security mechanism in response: ENRP servers mutually authenticate Threat 4) A PU communicates with a malicious ENRP server for handle resolution ----------- Security mechanism in response: The PU authenticates the ENRP server Threat 5) Replay attack ----------- Security mechanism in response: Security protocol which has protection from replay attacks Threat 6) Corrupted data which causes a PU to have misinformation concerning a pool handle resolution ----------- Security mechanism in response: Security protocol which supports Xie, et al. Expires January 10, 2008 [Page 39] Internet-Draft Endpoint Handlespace Redundancy July 2007 integrity protection Threat 7) Eavesdropper snooping on handlespace information ----------- Security mechanism in response: Security protocol which supports data confidentiality Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to ENRP server ----------- Security mechanism in response: ASAP must control the number of ASAP endpoint unreachable messages transmitted from the PU to the ENRP server. Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from the ENRP server ----------- Security mechanism in response: ENRP server must control the number of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE To summarize the threats 1-7 require security mechanisms which support authentication, integrity, data confidentiality, protection from replay attacks. For RSerPool we need to authenticate the following: PU <---- ENRP Server (PU authenticates the ENRP server) PE <----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication) 6.2. Implementing Security Mechanisms We do not define any new security mechanisms specifically for EE responding to threats 1-7.E Rather we use an existing IETF security EE protocol, specifically [2], to provide the security services required.ETLS supports all these requirements and MUST be implemented.EThe TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a minimum by implementors of TLS for RSerPool.E For purposes of backwards compatibility, ENRP SHOULD support EE TLS_RSA_WITH_3DES_EDE_CBC_SHA.EImplementers MAY also support any EE other IETF approved ciphersuites. ENRP servers, PEs, PUs MUST implement TLS.E ENRP servers and PEs must support mutual authentication.E ENRP servers must support mutual authentication among themselves.E PUs MUST authenticate ENRP servers. ENRP servers and PEs SHOULD possess a site certificate whose subject corresponds to their canonical hostname.E PUs MAY have certificates Xie, et al. Expires January 10, 2008 [Page 40] Internet-Draft Endpoint Handlespace Redundancy July 2007 of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use.E All RSerPool elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers). Implementations MUST support TLS with SCTP as described in [10] or TLS over TCP as described in [7].EWhen using TLS/SCTP we must ensure that RSerPool does not use any features of SCTP that are not available to an TLS/SCTP user.E This is not a difficult technical problem, but simply a requirement.E When describing an API of the RSerPool lower layer we have also to take into account the differences between TLS and SCTP. Threat 8 requires the ASAP protocol to limit the number of ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [1]) to the ENRP server. Threat 9 requires the ENRP protocol to limit the number of ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see section Section 3.7). 6.3. Chain of trust Security is mandatory to implement in RSerPool and is based on TLS implementation in all three architecture components that comprise RSerPool -- namely PU, PE and ENRP server. We define an ENRP server that uses TLS for all communication and authenticates ENRP peers and PE registrants to be a secured ENRP server. Here is a description of all possible data paths and a description of the security. PU <---> secured ENRP Server (authentication of ENRP server; queries over TLS) PE <---> secured ENRP server (mutual authentication; registration/deregistration over TLS) secured ENRP server <---> secured ENRP server (mutual authentication; database updates using TLS) If all components of the system authenticate and communicate using TLS, the chain of trust is sound. The root of the trust chain is the ENRP server. If that is secured using TLS, then security will be enforced for all ENRP and PE components that try to connect to it. Summary of interaction between secured and unsecured components: If Xie, et al. Expires January 10, 2008 [Page 41] Internet-Draft Endpoint Handlespace Redundancy July 2007 the PE does not use TLS and tries to register with a secure ENRP server, it will receive an error message response indicated as error due to security considerations and the registration will be rejected. If an ENRP server which does not use TLS tries to update the database of a secure ENRP server, then the update will be rejected. If an PU does not use TLS and communicates with a secure ENRP server, it will get a response with the understanding that the response is not secure as the response can be tampered with in transit even if the ENRP database is secured. The final case is the PU sending a secure request to ENRP. It might be that ENRP and PEs are not secured and this is an allowable configuration. The intent is to secure the communication over the Internet between the PU and the ENRP server. Summary: RSerPool architecture components can communicate with each other to establish a chain of trust. Secured PE and ENRP servers reject any communications with unsecured ENRP or PE servers. If the above is enforced, then a chain of trust is established for the RSerPool user. Xie, et al. Expires January 10, 2008 [Page 42] Internet-Draft Endpoint Handlespace Redundancy July 2007 7. Acknowledgements The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, Thomas Dreibholz, and many others for their invaluable comments and feedback. Xie, et al. Expires January 10, 2008 [Page 43] Internet-Draft Endpoint Handlespace Redundancy July 2007 8. References 8.1. Normative References [1] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12 (work in progress), July 2005. [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002. [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and A. Silverton, "Architecture for Reliable Server Pooling", draft-ietf-rserpool-arch-10 (work in progress), July 2005. [4] Braden, R., Borman, D., and C. Partridge, "Computing the Internet Checksum", RFC 1071, September 1988. [5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [10] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP", RFC 3436, December 2002. [11] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003. [12] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-09 (work in progress), Xie, et al. Expires January 10, 2008 [Page 44] Internet-Draft Endpoint Handlespace Redundancy July 2007 July 2005. [13] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M. Holdrege, "Threats Introduced by Rserpool and Requirements for Security in Response to Threats", draft-ietf-rserpool-threats-05 (work in progress), July 2005. [14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 8.2. Informative References [15] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. Xie, et al. Expires January 10, 2008 [Page 45] Internet-Draft Endpoint Handlespace Redundancy July 2007 Authors' Addresses Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 US Phone: Email: qxie1@email.mot.com Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA Phone: Email: rrs@cisco.com Maureen Stillman Nokia 127 W. State Street Ithaca, NY 14850 US Phone: Email: maureen.stillman@nokia.com Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany Email: tuexen@fh-muenster.de Xie, et al. Expires January 10, 2008 [Page 46] Internet-Draft Endpoint Handlespace Redundancy July 2007 Aron J. Silverton Motorola, Inc. 1301 E. Algonquin Road Room 2246 Schaumburg, IL 60196 USA Phone: +1 847-576-8747 Email: aron.j.silverton@motorola.com Xie, et al. Expires January 10, 2008 [Page 47] Internet-Draft Endpoint Handlespace Redundancy July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Xie, et al. Expires January 10, 2008 [Page 48]