Network Working Group Ram Gopal.L INTERNET DRAFT Senthil Sengodan Nokia Expires January, 2002 July 10, 2001 End Name Resolution Protocol Candidate (ENRP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. 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. Abstract The goal is to develop a Reliable server pooling protocols for the management and operation of server pools supporting highly reliable applications,and for client access mechanisms to a server pool. This document describes the ENRP protocol and details the how it is used in conjunction with ASAP protocol. Table of Contents 1. Introduction..............................................3 1.1 Terminology...............................................4 1.2. Architectural view .......................................5 2 Protocol Overview.........................................7 2.1 Name Server pool..........................................7 2.2 Choosing the Name Server address for registration.........7 2.2.1 ENRP Name server Registration............ ...............7 2.2.2 Name Server List download.................................8 2.2.2.1 Choosing Name Server ID ................................8 Ram & Senthil [Page 1] Internet Draft End Name Resolution Protocol July 2001 2.2.2.2 Choosing Care Taker Name Server...........................8 2.2.2.3 Avoiding NS-ID Collision..................................9 2.3 ENRP Name Server and PE list download ...................9 2.4 Name Server Updates .....................................9 2.4.1 Name Server Status notification..........................10 2.4.2. PE Status notification...................................10 2.5 NS deRegistration and NS update..........................10 2.6 ENRP Health check........................................10 3 Message Overview.........................................10 4 Request..................................................12 4.1 Request-Line.............................................12 4.2 Method...................................................12 4.2.1 NS-REGISTRATION..........................................13 4.2.2 HEARTBEAT................................................13 4.2.3 UPDATE...................................................13 4.2.4 NS-DOWNLOAD..............................................14 4.2.5 PE-DOWNLOAD..............................................14 5 Response Header..........................................14 5.1 Status-Line..............................................14 5.1.2 Status Codes and Reason Phrases..........................15 6 Header Field Definitions.................................16 6.1 Allow....................................................16 6.2 NS-Parameters ...........................................17 6.3 Policy...................................................17 6.4 Periodic-Update..........................................18 6.5 NS-ID....................................................18 6.6 Server-Type..............................................18 6.7 Transaction-ID...........................................19 6.8 Expires..................................................19 6.9 Security Related Headers.................................19 6.9.1 WWW-Authenticate ........................................19 6.9.2 Authorization............................................20 6.9.3 Authentication-Info......................................20 6.9.4 Encryption...............................................21 6.9.5 Require .................................................21 6.9.6 Response-Key.............................................21 7 Status Code Definitions..................................21 7.1 Successful 2xx...........................................21 7.1.1 200 OK...................................................21 7.2 Request Failure 4xx......................................22 7.2.1 400 Bad Request..........................................22 7.2.2 401 Unauthorized.........................................23 7.2.3 403 Method Not Allowed...................................22 7.2.4 404 Not Found............................................23 7.2.5 409 Request Entity Too Large.............................23 7.3 Server Failure 5xx.......................................23 7.3.1 500 Server Internal Error................................23 7.3.2 501 Not Implemented......................................23 7.3.3 502 Service Unavailable..................................23 7.3.5 503 Version Not Supported................................24 8. Behavior of Name Server..................................24 Ram & Senthil [Page 2] Internet Draft End Name Resolution Protocol July 2001 8.1 NS - Startup and Shutdown interaction message ..........24 8.1.1 Registering Entity Resolves the Name Server with which to Register........................................24 8.1.2 Joining Name Server needs to be registered with an NS....25. ................................................... 8.1.3 Name ServerDe-Registering itself from the Pool.......... 25 8.1.4 Download of ASAP/ENRP pool element information on to NS.......................................... 26 8.1.4.1 Name ServerRequests list of Name Servers in NS-pool......26 8.1.4.2 Response to ENRP-DOWNLOAD message requesting Name Server list ....................................... 26 8.1.4.3 NS requests PE list from caretaker NS................... 27 8.1.4.4 Response to NS-DOWNLOAD message requesting PE list.......27 8.2 Interaction between a pair of NS.........................28 8.2.1 NS Updates NS status to PEs and other NS in the NS-Pool..28 8.2.1.1 New NS Registration Notification ........................29 8.2.1.2 NS Registration Update...................................29 8.2.1.3 NS Heart beat Failure or NS de-Registration Notification Update .....................................29 8.2.2 Name Server updating an PE Status to all NS .............30 8.2.2.1 PE registration notification ............................30 8.2.2.2 PE registration update ..................................31 8.2.2.3 PE de-registration or interface heartbeat failure notification ....................................31 8.2.3 Caretaker NS sends a Heartbeat Request to other NSs in to NS-pool...............................................32 8.2.4 NS sends Heartbeat Response to Care-Taker NS.............33 8.2.5 NS notifies all other NSs in NS-pool of a change in caretaker NS ................................33 9 Security Considerations..................................34 9.1 Confidentiality and Privacy: Encryption..................34 9.1.1 Application-Level Encryption............... ..........34 9.1.2 Lower-Layer Encryption...................................34 9.2 Message Integrity and Access Control: Authentication.....34 9.2.1 Illustration of Digest Scheme ...........................34 A. Implementation Issues....................................35 B. Summary of Augmented BNF........................ ........35 C. Acknowledgements.........................................35 D Author's Contact Address.................................36 E Reference................................................36 1 Introduction [Req] discusses requirements for the management and operation of reliable server pools which may be needed for certain applications, and for the client access mechanism to a server pool. [Arch] describes an architecture for achieving such reliable server pools.Two protocols - ASAP and ENRP - are proposed within this architecture.In this document, we give a description of the ASAP protocol. Ram & Senthil [Page 3] Internet Draft End Name Resolution Protocol July 2001 1.1. Terminology In addition to the terminology defined in [Req][Arch], the following terms are defined here: Reliability: As stated in [Papoulis], the reliability of a system is defined as the probability that the system functions at a certain time 't'. In mathematical terms, we have R(t) = P{x>t} where R(t) = system reliability P{.} = Probability of occurrence of the specified event x = Random Variable (RV) denoting "time to failure" of a system t = time A typical metric for determining the reliability of a system is the mean time to failure. The larger this value, the more reliable the system is. Availability: As stated in [Mullender], the availability of a system is defined as the probability that the system provides correct service delivery at a certain time 't'. It is a measure of correct service delivery with respect to the alternation of correct and incorrect service, measured by the probability A(t) that the system is ready to provide the service at a point in time t. ENRP Server: Identical to Name Server [Arch][Req] Proxy PE (PPE): Proxy PE refers to a PE which acts on behalf of application servers, specifically legacy application servers. Proxy PU (PPU): Proxy PU refers to a PU which acts on behalf of a user of a server pool, specifically a legacy user of a server pool. Name Server Pool (NS-Pool) : Refers to ENRP Name Server pool Application Server Pool (AS-Pool): This term refers to "Pool" in [Arch], but is introduced here to distinguish from NS-Pool. Care Taker Name Server: Associated with each Name Server there is one care taker Name Server in the same pool and is responsible for health check. Name Server ID: A unique identifier assigned to each Name Server after registration in an NS-Pool. NS Handle: Refers to transport addresses) of a Name Server. Ram & Senthil [Page 4] Internet Draft End Name Resolution Protocol July 2001 1.2 Architectural view Figure 1 represents the architectural view of ENRP in a Rserpool. Communication of the different elements in this architecture is as follows: - ENRP Name Server (say NS 1 and NS 2 ) communicates with each other using ENRP protocol. There may be more than one Name Server in a Rserpool. - ENRP Name server uses its ASAP layer to communicate to its PU or PE. - Name Server keeps information regarding legacy servers but does not communicate to them. +---------------------+ +-----------+ +-----------+ | Application Server | |Legacy | |Legacy | | (A1) | |Server (S1)| |Server (S2)| +---------------------+ +-----------+ +-----------+ | ASAP | || || | | +---------------------+ +---------------------+ | ASAP - PPE (A2) | | Transport Layer | +---------------------+ | | | Transport Layer | +---------------------+ +---------------------+ || || || || =//===================//===============================//=== || +---------------------+ || +-------------------+ | Name Server (NS 1) | || | Pool User (P1) | | | || | | +----------+----------+ || | | | ENRP | ASAP | // +-------------------+ +----------+----------+ || | | | Transport Layer | || | ASAP | +----------+----------+ || +-------------------+ || || | Transport Layer | ||=====//=========|| +-------------------+ || || ||=====//======= || +---------------------+ || +--------+ +--------+ | Name Server (NS 2) | || |Legacy | |Legacy | | | || |Client | |Client | +---------------------+ || | (U1) | | (U2) | | ENRP | ASAP | // +--------+ +--------+ +----------+----------+ || || || | Transport Layer | || || || +---------------------+ || +-------------------+ || || | ASAP - PPU (P2) | ||=======//=======|| +-------------------+ || | Transport Layer | || +-------------------+ Ram & Senthil [Page 5] Internet Draft End Name Resolution Protocol July 2001 || || ||====//========= // Figure 2: Architectural view of ENRP Name servers Based on the requirements in [Req], some of the functionality that is provided within the protocol are: - The Name Server discovery mechanism does not rely on multicast technologies. Instead, a set of mechanisms are described, any of which may be used. (Refer 2.1) - The use of Expires header for initial registration, registration modification or deletion of PE with Name Server, permits automatic cache invalidation at the PU. This implies that the PU does not have to initiate queries to a PE to determine whether the PE is active, if it already knows that the PE is not active because its registration has expired. - Separate Registration mechanism are provided for Name Server which is different from PE registration. This will form a pool of ENRP Name server in a RSerPool scope. Apart from this each Name Server discovers its care taker server just after the registration process. (Refer Section 2.2.1 ) Some key characteristics of the architecture of Figure 1 are: - It does not assume any underlying transport protocols, and may use UDP, TCP, SCTP, RDP etc. - All communication between any two entities in the Rserpool is secured - it provides confidentiality, data origin authenticity and replay attack prevention. - The protocol does not rely on multicast, and works both in a unicast and multicast environment. - Each ENRP name server keeps all state information about each PE in the AS-Pool and about other Name Servers and this information is always synchronized between them with minimal message exchange. - Use of an ASCII based message exchange (similar to HTTP, SIP) makes the protocol simpler and easy to implement in low- processing device. Ram & Senthil [Page 6] Internet Draft End Name Resolution Protocol July 2001 - Load balancing is provided at three levels: - Across Name Servers for PU Queries - Across PEs for PU Queries - Across Name Servers for PE heartbeat 2 Protocol Overview 2.1 Name Server Pool A pool of ENRP Name servers cooperate (and are synchronized) with one another using ENRP, and are said to operate within an operational scope. There may be more than one Name server in an operation scope to form Name server pool. i.e. this is needed for availability and all the Name server cooperate and synchronize themselves. The reasons for having a cooperating/synchronized Name Serverpool include: o to handle the case of Name server failures o distribute load among the Name servers: Load sharing on heartbeat monitoring function (of PE) can be done. (a) When an existing Name Server leaves a pool, then the PEs that are handled by this Name Server need to be distributed among the other Name Servers in the pool. Similarly, when a new Name Server enters a pool, one may wish to redistribute the load among the various Name Servers. (b) It is uncertain if load sharing can be done for PU queries to Name servers. PUs cannot know the list of active Name servers in the operational scope. Their only source of info is from the DNS (which may not be up-to-date). A possibility is that the first time a PU contacts a Name server, that server could download a list of then currently active Name servers, so that the PU can use say a RR policy for subsequent queries to Name servers. 2.2 Choosing the Name server address for registration The Name Server that wants to be a part of a NS-pool obtains the list of Name servers from the DNS, or possibly some local configuration setting. This list may not be up-to-date, and some entries in the list may not be in the NS-pool, while there may be other Name servers in the pool that are not listed in this entry. The joining Name Server (Say A ) picks one Name server (Say B) (could be arbitrary) and sends its registration to this Name server B. 2.2.1 ENRP Name Server Registration The joining Name Server (say A) after choosing the Name server from the list ( Refer Section 2.2 ) sends the NS-REGISTRATION message to the Ram & Senthil [Page 7] Internet Draft End Name Resolution Protocol July 2001 Name server(say B). The Name server does the initial authentication (depending upon the security protocol) and sends back the NS-REGISTRATION response with the appropriate status code. A typical NS- REGISTRATION request contains, Expire time, service policy and other server specific information. 2.2.2 Name Server List download After NS-REGISTRATION is completed successfully, the newly joined Name Server (Say A) then requests for the Name server list by sending an NS-DOWNLOAD Request to the Name server with which it completed its registration (Say B) . 2.2.2.1 Choosing Name Server ID Requesting Name server after receiving Name Server list, computes the NS-ID (Name Server ID) that it assigns itself, and chooses its Care taker Name Server. The new Name server scans through the all Name server ID's in the list and chooses the NS-ID which is one greater than the highest value in the list. i.e, for example if we have five Name Servers and their NS id are 1,4,5,6 and 15, then the new Name Server that joins the pool will assign itself an NS-ID of 16 and its care taker Name Server will have an NS-ID 15. Name Server NS-ID Server-1 1 ;Care taker for Name Server 4 Server-2 4 ;Care taker for Name Server 5 Server-3 5 ;Care taker for Name Server 6 Server-4 6 ;Care taker for Name Server 15 Server-5 15 ;Care taker for Name Server 1 Server-6 16 ; Comment Newly joined Name server Note: The gaps in the Name server ID represents that those servers have left the NS-pool either normally or abnormally. Figure 4 Name Server ID Selection. 2.2.2.2 Choosing Care Taker ENRP Name Server After computing the Name server ID, the newly registered ENRP Name server chooses its care taker ENRP Name server whose NS-ID is one lesser than its value. Refer Figure 4, the Care Taker Server for Name Server 16 will be 15. Name Server NS-ID Server-1 1 ;Care taker for Name Server 4 Server-2 4 ;Care taker for Name Server 5 Ram & Senthil [Page 8] Internet Draft End Name Resolution Protocol July 2001 Server-3 5 ;Care taker for Name Server 6 Server-4 6 ;Care taker for Name Server 15 Server-5 15 ;Care taker for Name Server 16 Server-6 16 ; Comment Newly joined Name server ; Care taker for Name Server1 Figure 5 Name Server Care taker Selection/Reassignment. 2.2.2.3 Avoiding NS-ID Collision One needs to avoid the case where two or more Name servers (say, A, B, C) wishing to join a Name server pool at reasonably close points in time, obtain identical Name server lists, thereby computing an identical NS-ID (say, 16 as in Figure 5) for itself. When the first ENRP server (A) contacts its caretaker Name server (with NS-ID 15, which is say D), then a flag at D is set. When Name Server, say B, subsequently contacts its caretaker Name server, which is again D, D responds with an indication that the flag is set. This implies that Name server B needs to retry its initialization after a certain random amount of time. The same happens to Name server C. After Name server A has successfully updated all other Name Servers in the pool of its joining the pool, the flag at Name Server D is reset. A timer associated with this flag resets the flag if the update does not occur within a certain pre-specified amount of time. 2.3 ENRP Name Server and PE list download After determining the name server ID and Caretaker Name Server, the newly registered Name Server requests its Caretaker Name Server for PE list by sending PE-DOWNLOAD request. 2.4 Name Server Updates 2.4.1 Name Server Status notification Name Server sends the UPDATE message to other Name Servers in the NS- Pool and other PEs in the AS-Pool. This message is generated due to the following reasons: o After the Name Server registration, successful download of Name Server list and PE data, new Name server sends the Name Server update list to other Servers and to the list of PE in the pool. The Update message contains the NS-Parameters of the newly joined Name Server. o Care taker Name Server sends the ENRP update message due to Health check failure or normal shutdown of Name server. The update message contains the NS-Parameter of the failed Name Server. Ram & Senthil [Page 9] Internet Draft End Name Resolution Protocol July 2001 o Name Server can extend/update its registration with the NS-pool by sending UPDATE message, the typical update could be as follows 1. wants to extend the expiry time 2. wants to change the policy and control parameters 2.4.2. PE Status notification A Name Server sends PE updates only to other Name Servers in the NS- Pool. These messages are generated due to the following reasons: o PE health check failure o PE added to the AS-pool o PE does a registration update 2.5 NS deRegistration and NS update An NS can deRegister itself from the NS-pool, by sending NS_REGISTRATION message with Expires header of value 0, to care taker NS-server. NS can also de-Register one of its transport addresses if it is multi homed by setting the corresponding expire value to 0. 2.6 ENRP Health check Care taker NS (Say A) will periodically check the heartbeat of each transport address (in case of multi homing) of NS (say B) that it takes care of. NS B upon receiving this request, responds thereby indicating to A that it is alive. 3 Message Overview ENRP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279). Senders MUST terminate lines with a CRLF, but receivers MUST also interpret CR and LF by themselves as line terminators. An ENRP message is either a request from a client to a server, or a response from a server to a client. ENRP-message = Request | Response Both Request (section 4) and Response (section 5) messages use the generic-message format of RFC 822 [2] for transferring Ram & Senthil [Page 10] Internet Draft End Name Resolution Protocol July 2001 entities (the body of the message). Both types of messages consist of a start-line, one or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the carriage-return line-feed (CRLF)) indicating the end of the header fields, and an optional message-body. ENRP-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line | ;Section 4.1 Status-Line ;Section 5.1 Table 2 provides a snapshot of the various headers within ENRP. message-header = Allow ; Section 6.1 | Expires ; Section 6.8 | NS-Parameter ; Section 6.2 | PE-Parameter ; Refer ASAP Draft | Policy ; Section 6.3 | Periodic-Update ; Section 6.4 | Pool-Handle ; Refer ASAP Draft | NS-ID ; Section 6.5 | Transaction-ID ; Section 6.7 | Server-Type ; Section 6.6 | WWW-Authenticate ; Section 6.9.1 | Authorization ; Section 6.9.2 | Authorization-Info ; Section 6.9.3 | Encryption ; Section 6.9.4 | Require ; Section 6.9.5 | Response-Key ; Section 6.9.6 Table 3: ENRP headers The message syntax proposed for ASAP/ENRP satisfies the following requirements: - The message structure is based on well-known structures that have been used in protocols that have widespread deployment. - Ease of extensibility of the message structures - Facilitate code reuse where possible, when other protocol Ram & Senthil [Page 11] Internet Draft End Name Resolution Protocol July 2001 parsers use similar message structures - Efficient parsing of the message structures - Limited processing power requirements, facilitating use of the protocol in small devices. 4 Request The syntax of request messages is as follows: Request = Request-Line *message-header CRLF [message-body] 4.1 Request-Line The Request-Line contains a method token, followed by the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are allowed except in the final CRLF sequence. Request-Line = Method SP Protocol-Version CRLF When the ENRP protocol is being considered, the Request-Line is: Request-Line = Method SP ENRP-Version CRLF Implementations adhering to this document MUST use ENRP/1.0 for their ASAP-Version. 4.2 Method The methods are defined below. The Method token is case-sensitive. Method = "NS-REGISTRATION" | "PE-DOWNLOAD" | |"NS-DOWNLOAD" |"HEARTBEAT" |"UPDATE" Ram & Senthil [Page 12] Internet Draft End Name Resolution Protocol July 2001 4.2.1 NS-REGISTRAION The NS-REGISTRATION method is used within a Request message that is sent by a Name Server to another Name Server which is already a member of a pool to indicate one of the following: (a) Name Server wishes to join an NS-pool (b) Name Server, which has already registered itself with an ENRP server pool and is currently a member of an Name Server pool, extends/modifies the duration of registration. (c) Name Server, which has already registered itself with an Name Server pool deletes its registration. An NS cancels an existing registration by sending a NS- REGISTRATION request with an expiration time (Expires header) of zero seconds for a NS handle or the wildcard Endpoint Addr designated by a "*" for all registrations. If a Name Server handle is already found to exist, then the NS-Parameters associated with it are updated. 4.2.2 HEARTBEAT Heartbeat message are sent between an NS and its caretaker NS, in order to check whether the NS is alive. 4.2.3 UPDATE Name Server updates its database and sends the UPDATE to other servers. UPDATE message can be classified into two categories according to the type of updates. 1) The following update messages are sent by Name Servers to (1) other Name Servers within the same Name Server pool, as well as (2) to PE that are registered with this ENRP server pool: (Refer ASAP Draft for description of these messages) (a) New Registration: Name Server wishes to join the server pool (b) Registration Update: Name Server, which has already registered itself with an ENRP pool and is currently a member of the pool, wants to extend/modify the registration attributes (such as duration, policy etc.). (c) De-Registration: Name Server, which has already registered itself with an Name Server pool, deletes its registration. (c) Heartbeat Failure Notification: Name Server, which is currently a member of an ENRP pool, notifies to one/more ENRP servers within the pool of the heartbeat failure of another Name Server within the same pool. Ram & Senthil [Page 13] Internet Draft End Name Resolution Protocol July 2001 2) The following update messages are sent by Name Servers to other Name Servers: (a) PE registration notification: Notifying a newly added PE to the AS-pool. (b) PE registration update: PE , which has already registered itself with an AS-pool and is currently a member of the pool, wants to extend/modify the registration attributes (such as duration, policy etc.). (c) PE de-registration: PE, which has already registered itself with an AS-pool, deletes its registration. (c) PE heartbeat failure notification: Name Server, detects the failure of a PE during heartbeat check, and notifies the other Name Servers within the NS-pool. 4.2.4 NS-DOWNLOAD An NS after joining (registering) with the NS-pool, request the Name Server list. 4.2.5 PE-DOWNLOAD An NS after computing its NS-ID and identifying the caretaker NS, requests PE-DOWNLOAD from its caretaker NS. 5 Response Header After receiving and interpreting a request message, the recipient responds with an ENRP response message. The response message format is shown below: Response = Status-Line *message-header CRLF [ message-body ] 5.1 Status-Line The first line of a Response message is the Status-Line,consisting of the protocol version (Section 8.1.2 ) followed by a numeric Status-Code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Ram & Senthil [Page 14] Internet Draft End Name Resolution Protocol July 2001 Status-Line = Protocol-version SP Status-Code SP Reason- Phrase CRLF When ENRP is used, the Staus-Line is: Status-Line = ENRP-version SP Status-Code SP Reason- Phrase CRLF Implementations adhering to this document MUST use ENRP/1.0 for their ENRP-Version. 5.1.2 Status Codes and Reason Phrases The Status-Code is a 3-digit integer result code that indicates the outcome of the attempt to understand and satisfy the request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase. Status-Code = Success ;Fig. 3 | Client-Error ;Fig. 4 | Server-Error ;Fig. 5 | extension-code extension-code = 3DIGIT Reason-Phrase = * We provide an overview of the Status-Code below, and provide full definitions in Section 7. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. ASAP/ENRP/1.0 allows 4 values for the first digit: 2xx: Success -- the action was successfully received, understood, and accepted; 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error -- the server failed to fulfill an apparently valid request; Ram & Senthil [Page 15] Internet Draft End Name Resolution Protocol July 2001 Figures 3 through 5 present the individual values of the numeric response codes. Success = "200" ; OK Figure 3: Success status codes Client-Error = "400" ; Bad Request | "401" ; Unauthorized | "403" ; Method Not Allowed | "404" ; Not Found | "409" ; Request Entity Too Large Figure 4: Client error status codes Server-Error = "500" ; Internal Server Error | "501" ; Not Implemented | "503" ; ASAP/ENRP Version not supported Figure 5: Server error status codes 6 Header Field Definitions ENRP header fields are similar to SIP or HTTP header fields in both syntax and semantics. Some of these headers may be present in both request and response messages, while others may be present in only either a request or a response message. The subsections below describing each of the headers, also mentions their applicability within a request/response message. 6.1 Allow The Allow header field is used to indicate the list of methods that are supported by the responding server. Allow = ("Allow" | "l") ":" *("NS-REGISTRATION" | "NS-HEARTBEAT" |"UPDATE" | "NS-DOWNLOAD"|"PE-DOWNLOAD"| | quoted-string) An example of the Allow header is as follows: Allow= "NS-REGISTRATION" "PE-DOWNLOAD" Ram & Senthil [Page 16] Internet Draft End Name Resolution Protocol July 2001 6.2 NS-Parameters The NS-Parameter header is defined as follows: NS-Parameter = ( "NS-Parameter" | "e" ) ":" NS-ID; Handle NS-ID = ("NS-ID" | "i") ":" Digit Handle = 1*("(" transport-addr ")" [*(";"contact-params )] [comment ]) transport-addr = IPv4|IPv6 IPv4 = digit "." digit "." digit "." digit *(":" port-number) IPv6 = ( (digit ":" digit ":" digit ":" digit ":" digit ":" digit ":" digit ":" digit) |(":" digit ":" digit ":" digit ":" digit ":" digit ":" digit ":" digit) |(":" ":" digit ":" digit ":" digit ":" digit ":" digit ":" digit) |(":" ":" ":" digit ":" digit ":" digit ":" digit ":" digit)) *(":" port-number) port-number = digit contact-params = "q" "=" qvalue | "Expires" "=" delta-seconds | "Policy" "=" ("LRU"|"RR"|token) comment = quoted-string The NS-Parameter has one or more transport addresses, each of which may optionally have contact parameters and comments associated with them. q: The "qvalue" indicates the relative preference among the locations given. "qvalue" values are decimal numbers from 0 to 1, with higher values indicating higher preference. This could be used for the case of a multi-homed host where the same service may be available at different transport addresses, and a preference exists for certain transport addresses. 6.3 Policy The Policy header field is used to indicate the preferred load policy of the Name Server. It is used during registration of an NS-server, or when the policy associated with a registration needs to be updated. Policy = ("Policy" | "p") ":" ("LRU"|"RR"|token) Usually, when the policy header is specified, then an Expires header is included as well. This indicates the expiration time associated with the policy. Ram & Senthil [Page 17] Internet Draft End Name Resolution Protocol July 2001 An example of the Policy header is as follows: Policy="RR" 6.4 Periodic-Update The Periodic-Update header may be used within a HEARTBEAT Request as well as Response message. It is used within a HEARTBEAT request when an Name Server requests the NS for which it is a caretaker, to declare its presence to the it periodically. It is used within a response to a HEARTBEAT Request when the NS indicates whether it supports the periodic presence notification feature or not. For example, Care taker NS (Say A) requests a periodic-update heartbeat by generating the HEARTBEAT request message and including the Periodic-Update header with a value "Yes" to NS (Say B). If the Name Server B can report its presence periodically without getting any further request from the care taker NS (A) , then the Name Server B can respond to the HEARTBEAT Request by including a Periodic-Update header with value of "Yes". Periodic-Update = ("Periodic-Update" | "u") ":" "Yes" ";" An example of the Periodic-Update header is as follows: Periodic-Update="Yes" 6.5 NS-ID The NS-ID header field is used to convey the unique identification (ID) of an NS within an NS-pool. The syntax is as follows: NS-ID = ("NS-ID" | "i") ":" Digit Example: NS-ID=2 6.6 Server-Type The Server-Type header field is used to convey the type of server that is being referred to. Currently defined server types are: NS and PE. Server-Type = ("Server-Type" | "r") ":" ("NS"|"PE") Ram & Senthil [Page 18] Internet Draft End Name Resolution Protocol July 2001 Example: Server-Type=NS 6.7 Transaction-ID The Transaction-ID header field is used to associate a set of messages to the same transaction. Initial request messages MUST carry a locally unique transaction-ID. Responses and subsequent requests that are related to this request, MUST use the same Transaction-ID. Transaction-ID = ("Transaction-ID" | "t") ":" UUID Example: Transaction-ID= "124F-AB12-874-2344-2344-1234-2345-9EDE" 6.8 Expires The "Expires" parameter indicates how long the Name server handle is valid. The parameter is a number indicating seconds. When not present, the default value is taken to be the maximum, which is 2**32-1. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. Expires =("Expires" | "x") ":" delta-seconds Example: Expires = 1000 6.9 Security Related Headers 6.9.1 WWW-Authenticate The WWW-Authenticate header, typically included within a 401 Response message, is used to indicate that the Requesting entity needs to be authenticated. WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge Based on RFC2617, when Digest Authentication is used, the challenge is as follows: challenge = "Digest" digest-challenge digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] ) Ram & Senthil [Page 19] Internet Draft End Name Resolution Protocol July 2001 domain = "domain" "=" <"> quoted-string <"> nonce = "nonce" "=" nonce-value nonce-value = quoted-string opaque = "opaque" "=" quoted-string stale = "stale" "=" ( "true" | "false" ) algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | token ) qop-options = "qop" "=" <"> 1#qop-value <"> qop-value = "auth" | "auth-int" | token 6.9.2 Authorization The Authorization header is included within a Request message, so that the Requesting entity may authenticate itself to the receiver. Authorization = "Authorization" ":" credentials Based on RFC2617, when Digest authentication is used, the Authorization header is as follows: credentials = "Digest" digest-response digest-response = 1#( username | realm | nonce | response | [ algorithm ] | [cnonce] | [opaque] | [message-qop] | [nonce-count] | [auth-param] ) username = "username" "=" username-value username-value = quoted-string message-qop = "qop" "=" qop-value cnonce = "cnonce" "=" cnonce-value cnonce-value = nonce-value nonce-count = "nc" "=" nc-value nc-value = 8LHEX response = "response" "=" request-digest request-digest = <"> 32LHEX <"> LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" 6.9.3 Authentication-Info The Authentication-Info, typically included in a 200 Response message, conveys any optional information following successful authentication. The Authentication-Info based on RFC2617 is modified by appending a token field to carry the authorization token: AuthenticationInfo = "Authentication-Info" ":" auth-info auth-info = 1#(nextnonce | [ message-qop ] | [ response-auth ] | [ cnonce ] | [nonce-count] ) Ram & Senthil [Page 20] Internet Draft End Name Resolution Protocol July 2001 nextnonce = "nextnonce" "=" nonce-value response-auth = "rspauth" "=" response-digest response-digest = <"> *LHEX <"> 6.9.4 Encryption The Encryption header is used in Requests and Responses, when encryption is employed. The message body and all headers following a blank line are encrypted. As specified in RFC2543bis3: Encryption = "Encryption" ":" encryption-scheme 1*SP #encryption-params encryption-scheme = token encryption-params = generic-param 6.9.5 Require The Require header is used to indicate that the recipient needs to support the specified option. As specified in RFC2543: Require = "Require" ":" 1#option-tag When an entity requires the recipient to encrypt the messages, it includes the Require header with the following option-tag: Require: org.ietf.asap.encrypt-response 6.9.6 Response-Key The Response-Key header is used within a Request to indicate that the responder SHOULD use the enclosed key to encrypt responses. As specified in RFC2543: Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param key-scheme = token key-param = generic-param 7 Status Code Definitions 7.1 Successful 2xx The request was successful and MUST terminate a search. 7.1.1 200 OK The request has succeeded. The information returned with the response Ram & Senthil [Page 21] Internet Draft End Name Resolution Protocol July 2001 depends on the method used in the request, for example: o ENRP_REGISTRATION: The registration has succeeded, and the ENRP Server treats the message body of the Response message according to Content o ENRP_REGISTER (Update ): The registration update has succeeded and the Name Server end point treats the message body of the Response message according to its Content o ENRP_HEARTBEAT: The heartbeat has succeed, the Name Server treats the message body according to its Content. 7.2 Request Failure 4xx 4xx responses are definite failure responses from a particular server. The Name Server SHOULDNOT retry the same request without modification (e.g., adding appropriate authorization). However,the same request to a different server might be successful. 7.2.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, e.g., "Missing Handle name". 7.2.2 401 Unauthorized The request requires user authentication. This could occur either when the request did not contain an Authorization header (non- compliant client), or when the Authorization header is invalid. This response is issued by (1) Name Server when the PE does registration/update/deregistration ,or (2) When PU tries to exchange data with PE, or (3) When PU tries to NAME-RESOLUTION request with Name Server 7.2.3 403 Method Not Allowed The method specified in the Request-Line is not allowed for the receipt. The response MUST include an Allow header field containing a list of valid methods supported by the recipient. 7.2.4 404 Not Found Ram & Senthil [Page 22] Internet Draft End Name Resolution Protocol July 2001 The server has definitive information that the resource does not exist. For instance, when a PU sends a NAME-RESOLUTION Request to the Name Server and the Pool Handle contained therein does not exist, then the Name Server returns a 404 Response. 7.2.5 409 Request Entity Too Large The PE or Name Server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. The requesting entity may retry the request at a later time. 7.3 Server Failure 5xx 5xx responses are failure responses given when a server itself has errored. They are not definitive failures, and the requesting entity MUST NOT terminate a search if other possible locations remain untried. 7.3.1 500 Server Internal Error The Name Server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition, and MAY retry the request after several seconds. The client may retry the request at a later time. 7.3.2 501 Not Implemented The Name Server does not support the functionality required to fulfill the request. This is the appropriate response when it does not recognize the request method and is not capable of supporting it. 7.3.3 502 Service Unavailable The ENRP Name server or PE is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. Note: The existence of the 502 status code does not imply that a server has to use it when becoming overloaded. Some servers MAY wish to simply refuse the connection. Ram & Senthil [Page 23] Internet Draft End Name Resolution Protocol July 2001 7.3.4 503 Version Not Supported The Name Server does not support, or refuses to support, the ASAP/ENRP protocol version that was used in the request message. The PE is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. 8. Behavior of Name Server 8.1 NS - Startup and Shutdown interaction Messages This section describes the rules for Name Servers for generating and processing requests and responses during startup. 8.1.1 Registering Entity Resolves the Name Server with which to Register Prior to registering an Name Server with an NS-pool, the registering entity needs to resolve the IP address of an Name Server(s) with which it registers. Several mechanisms are possible, whereby the registering entity can determine the IP address of an Name Server to register with. For instance, (1) a registering entity may be manually configured with a set of IP addresses of Name Servers that it may register with, or (2) a registering entity may be configured with the DNS address of a Name Server(s) that it may register with following which it uses a DNS query and local policy to determine the specific IP address of the Name Server to register with, or (3) the Service Location Protocol (SLP) may be used to discover a suitable Name Server. We briefly describe a possible operation procedure when DNS is used. The registering entity is configured with the DNS address of an Name Server(s)that it may register with. It performs a DNS query which returns a set of IP addresses corresponding to the queried DNS address. Based on this returned list of IP addresses and any local policies, the registering entity selects an IP address for registration. While the selection of IP address is implementation specific, a sample procedure for selection of IP address is indicated below: (a) Selection criterion is based on the order of returned IP addresses. In other words, the first IP address in the list could be used for registration. If the registration fails, the next IP address in the list is tried, and so on. (b) Selection criterion is based on a random selection of returned IP addresses from the DNS query. Ram & Senthil [Page 24] Internet Draft End Name Resolution Protocol July 2001 It may be noted that the above specified mechanisms are outside the scope of the ASAP/ENRP protocol itself, and that the above specified mechanisms are possible ways of resolving the IP address of the Name Server. 8.1.2 Joining Name Server needs to be registered with an NS An Name Server may register with an NS-pool by contacting one of the NS in the pool. The registering Name Server resolves the IP address of the Name Server to register with, as specified in Section 8.1.1. In order to register with the selected IP address, the Name Server sends a Request message to the selected IP address with method set to NS-REGISTRATION. Implementations adhering to this document MUST set the ENRP-version field to ENRP/1.0. Hence, the Request- line is as follows: NS-REGISTRATION ENRP/1.0 For instance, a typical Register-Request message may look like this: NS-REGISTRATION ENRP/1.0 Transaction-ID=0xde34682a Expires: 7200 Authorization: An Name Server MUST be authenticated before it can register with an Name Server. In order to handle such authentication, the ENRP Registration Request message can optionally include an Authorization header. Security procedures are described Section 9. 8.1.3 Name Server De-Registering itself from the Pool An Name Server that wishes to withdraw its services from an NS-pool, does so by issuing a suitable de-register message to the Name Server(s) and also to the PE. An explicit de- register message is not provided for the purpose. Instead, de- registration is inferred by the use of a NS-REGISTRATION message with an Expires header field of value 0. For instance, a typical Register-Request message that is used for De-Registration purposes may look like this: Ram & Senthil [Page 25] Internet Draft End Name Resolution Protocol July 2001 NS-REGISTRATION ENRP/1.0 Transaction-ID=0x34ae78d Expires: 0 Authorization: NS-ID: 3 8.1.4 Download of ASAP/ENRP pool element information on to NS 8.1.4.1 Name Server Requests list of Name Servers in NS-pool After NS (say A) has successfully registered itself with an NS-pool by sending an NS-REGISTRATION request message to an NS (say B) in the NS-pool, it needs to obtain the list of ENRP servers in the pool. This is obtained by the NS A sending an NS-DOWNLOAD request message to NS B (which is the NS server that it got the registration response from.) The format of the Request-Line of an NS-DOWNLOAD request message is as follows NS-DOWNLOAD ENRP/1.0 A typical message is as follows: NS-DOWNLOAD ENRP/1.0 Transaction-ID=0x34ae78d Authorization: 8.1.4.2 Response to NS-DOWNLOAD message requesting Name Server list After an NS (say A) has successfully registered itself with an NS-pool by sending an NS-REGISTRATION request message to an NS (say B) in the NS-pool, it needs to obtain the list of NS servers in the pool. This is obtained by the NS A sending an NS-DOWNLOAD request message to NS B (which is the NS that it got the registration response from.) When NS B receives such an NS-REGISTRATION request message, it responds by sending a sequence of NS-Parameters. The NS-Parameter provides information on parameters such as IP addresses), policy, timers, NS-ID etc. An example of a successful response to an NS-DOWNLOAD message is as follows. Here, three Name Servers (with IDs 1,2 and 3) are present in the NS-pool. Name Server with NS-ID 1 is a multi- homed server with two interfaces - one with transport address 172.19.134.20:568 and the other with transport address 172.19.134.21:568. On the other hand, Name Server with NS-ID of 2 and 3, each have a single interface. Ram & Senthil [Page 26] Internet Draft End Name Resolution Protocol July 2001 200 ENRP/1.0 Transaction-ID=0x34ae78d NS-Parameter:1; 172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000; NS-Parameter:2;172.19.45.4:40;Expires:65000 NS-Parameter:3;172.20.65.45:568;Expires:42000 Policy: RR Authorization: After the requesting NS receives the list of NS-Parameters based on a successful NS-DOWNLOAD request, it computes its NS-ID by suitable navigation of the existing NS-IDs in the NS-ID list. (see Sec 2.2.2). Determination of the caretaker Name Server is also made by the NS at this point (see Sec 2.2.2). 8.1.4.3 NS requests PE list from caretaker NS An NS queries its caretaker NS for a list of PE, by sending an NS- DOWNLOAD message. The Server-Type header is set to PE to denote that the list of PE is queried for. An example of an NS-DOWNLOAD message is as follows: NS-DOWNLOAD ENRP/1.0 Transaction-ID=0x34ae78d Server-Type: PE Authorization: 8.1.4.4 Response to NS-DOWNLOAD message requesting PE list Upon receiving an NS-DOWLOAD request message with Server-Type set to PE, the caretaker NS responds with a list of PE-Parameters. The PE- Parameter includes information such as the IP addresses), policy, timers, and NS-ID of Name Server which is responsible for performing health check. An example usage of this message is as follows. Here, Name Server with NS-ID of 1 is the caretaker NS for two PEs within the AS-pool www.foo.com. The first PE is multi-homed with two interfaces - transport address of 172.19.134.20:568 and 172.19.134.21:568. The second PE has a single interface with transport address of 172.19.45.4:40. Also, illustrated in the message below is the usage of proxies. The NS with NS-ID of 2 is the caretaker Name Server for a legacy application server with transport address of 172.20.65.45:568, and the proxy PE that is responsible for handling the legacy application server has an transport address of 145.45.65.30:657. Ram & Senthil [Page 27] Internet Draft End Name Resolution Protocol July 2001 200 ENRP/1.0 Transaction-ID=0x34ae78d Server-Type: PE Pool-Handle: www.foo.com NS-ID:1 PE-Parameter: 172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000 NS-ID:1 PE-Parameter: 172.19.45.4:40;Expires:65000 NS-ID:2 PE-Parameter: 172.20.65.45:568;Expires:42000;Proxy- Addr:145.45.65.30:657 Policy: RR Authorization: 8.2 Interaction between a pair of NS The following messages are generated by Name Server in the NS-pool to other Name Servers and to PE to notify changes of NS in the NS-pool. 8.2.1 NS Updates NS status to PEs and other NS in the NS-Pool The following update messages are sent by Name Servers to (1) all other Name Servers within the same NS-pool, as well as (2) to all PE that are registered with this NS-pool: (a) New NS Registration Notification: When an NS (say, A) wishes to join the NS-pool, it registers itself with an NS (say, B) that is already in the NS-pool. NS B then uploads suitable information (including the current list of NS in the pool as well as the current list of PE that are managed by this NS-pool) to Name Server A. Name Server A then notifies all Name Servers and PE about its new registration. (Sec 8.2.1.1) (b) NS Registration Update: Name Server, which has already registered itself with an NS-pool and is currently a member of the pool, wants to extend/modify the registration attributes (such as duration, policy etc.). (Sec 8.2.1.2) (c) NS De-Registration Notification: Name Server, which has already registered itself with an NS-pool, deletes its registration by notifying its caretaker Name Server. After receiving such de-registration message from an NS, the caretaker NS-server notifies all other NS in the NS-pool of this de-registration. (Sec 8.2.1.3 ) (d) Heartbeat Failure Notification: Name Server, which is currently Ram & Senthil [Page 28] Internet Draft End Name Resolution Protocol July 2001 a member of an NS-pool, notifies to one/more Name Servers within the pool of the heartbeat failure of another NS within the same pool. (Sec 8.2.1.3 ) 8.2.1.1 New NS Registration Notification Newly added Name Server sends its update message to the other NS and PE. This informs that the new NS is part of the NS-pool. NS-UPDATE with Server-Type = ENRP and NS-ID refers to the Name Server ID which has joined the pool. For instance, NS-UPDATE message may look like this: NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d Expires: 10000 Server-Type:ENRP NS-Parameter: NS-ID:2;172.20.65.45:568;Expires:42000; Authorization: 8.2.1.2 NS Registration Update An Name Server that is already in an NS-pool may update its registration. Such update could include modification of registration attributes (e.g. expiration time of the registration, policy associated with the registration etc.). Registration updates are performed using a Request message with the NS-UPDATE method. NS-UPDATE with Server-Type = ENRP and NS-ID refers to the NS which has updated its registration attributes. For instance, when an NS wishes to increase its registration expiration to a new value of 10000 seconds, then a Request message as follows is sent: NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d Server-Type:ENRP NS-Parameter: NS-ID:2;172.20.65.45:568;Expires:10000; Authorization: 8.2.1.3 NS Heart beat Failure or NS de-Registration Notification Updates Ram & Senthil [Page 29] Internet Draft End Name Resolution Protocol July 2001 Caretaker Name Server updates all the other Name Servers and PE in the event of Name Server heartbeat failures or de-Registration. Note that the NS-ID represents the Name Server which has to be removed from the NS-pool.Expires value is set to 0. NS-UPDATE with Server-Type = ENRP and NS-ID refers to the NS which is no more part of the NS-pool. For instance, an NS-UPDATE may look like: NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d Expires: 0 Server-Type:ENRP NS-ID: 3 Authorization: 8.2.2 Name Server updating a PE Status to all NS The following update messages, dealing with the update of PE, are sent by an NS to other NS in the NS-pool: (a) PE registration notification: Notifying a newly added PE to the server pool. (b) PE registration update: PE , which has already registered itself with an AS-pool and is currently a member of the pool, wants to extend/modify the registration attributes (such as duration, policy etc.). (c) PE de-registration notification: PE , which has already registered itself with an AS-pool, deletes its registration. (d) PE heartbeat failure notification: NS, detects the failure of a PE during heartbeat check, and notifies the other NSs within the NS-pool. 8.2.2.1 PE registration notification NS updates other NS(s) regarding newly registered PE .Name Server which has received the PE-REGISTRATION request chooses Caretaker NS for that PE. NS-ID denotes the Caretaker NS for that PE. The caretaker NS is responsible for health check of the PE. An example is as follows: NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d PE-Parameter:172.19.146.54:675 Ram & Senthil [Page 30] Internet Draft End Name Resolution Protocol July 2001 Policy:LRU Expires: 10000 NS-ID: 3 Authorization: This implies that the PE with PE-Parameter "172.19.146.54:675" has been assigned a caretaker NS with NS-ID of 3. Alternatively, the application server may be a legacy application server that does not support ASAP/ENRP protocols. Such an application server may rely on proxy PE to act on its behalf. In this case, the proxy PE would register the application server with the NS. When the NS performs a registration notification to other NSs, it then needs to include both the transport address of the legacy application server, as well as the transport address of the proxy PE. The transport address of the legacy application server is needed in order to respond to a query by a PU (i.e., a NAME- RESOLUTION REQUEST message). The transport address of the proxy PE is needed for heartbeat check. An example is as follows: NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d PE-Parameter:172.19.146.54:675;Proxy: 172.20.43.45:45 Policy:LRU Expires: 10000 Authorization: NS-ID: 3 This implies that the PE with PE-Parameter "172.19.146.54:675;Proxy: 172.20.43.45:45" has been assigned a caretaker NS with NS-ID of 3. 8.2.2.2 PE registration update Caretaker NS updates other NS(s) regarding a registration update to an already registered PE. This is invoked when the caretaker NS has received the PE-REGISTRATION request message indicating the update. An example of an NS-UPDATE request message is as follows: NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d PE-Parameter:172.19.146.54:675 Policy:LRU Expires: 10000 Authorization: 8.2.2.3 PE de-registration or interface heartbeat failure notification Ram & Senthil [Page 31] Internet Draft End Name Resolution Protocol July 2001 An PE may have multiple interfaces by which it may be reached. This is the case of a multi-homed PE . In such a case, the NS needs to be aware of the availability of each interface associated with the PE . Thus, heartbeat check is done for each interface, and any failure of such an interface heartbeat check is notified to all the NSs. A multi-homed PE may de-register one/more/all of its interfaces associated with it. The caretaker NS that receives such a de-registration request message, also sends an NS-UPDATE message to all the NSs notifying them of such de-registration. The caretaker NS updates its ENRP database and sends an NS-UPDATE message with the Expires field set to zero, to other NSs. For instance, an NS-UPDATE may be as follows: NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d PE-Parameter:172.19.146.54:675 Expires: 0 Authorization: In the above example, the de-registration applies to the transport address indicated in the PE-Parameter header. Alternatively, the Expires field within the PE-Parameter header may be set to zero in order to indicate de-registration. For instance, an example of the usage of this would be: NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d PE-Parameter:172.19.146.54:675;expires=0 Policy:LRU Authorization: 8.2.3 Caretaker NS sends a Heartbeat Request to other NSs in NS-Pool Associated with each NS is a caretaker NS. The caretaker NS is responsible for heartbeat check of the NS under its care. A caretaker NS will send the HEARTBEAT request to the NS under its care, to examine whether the NS is alive. The format of the Request-Line of a HEARTBEAT request message is as follows: HEARTBEAT ENRP/1.0 An example of a heartbeat request is as follow s: Ram & Senthil [Page 32] Internet Draft End Name Resolution Protocol July 2001 HEARTBEAT ENRP/1.0 Transaction-ID=0x34ae78d Periodic-Update: Yes;600 Authorization: The heartbeat check that a caretaker NS performs is done on a per-interface basis for the NS under its care. If an ENRP server is multi-homed and has several interfaces by which the ENRP server may be reached, then the caretaker NS may need to poll (send HEARTBEAT request to) each interface associated with the NS under its care. 8.2.4 NS sends Heartbeat Response to Care-Taker NS Upon receiving a Heartbeat Request from its caretaker NS, an NS responds back to its caretaker NS with a Heartbeat Response message. The response indicates whether a Periodic- Update is supported or not. The format of HEARTBEAT response message is as follows: 200 ENRP/1.0 Transaction-ID=0x34ae78d Periodic-Update: Yes Authorization: The interface from which the response to the heartbeat request message is received, is the interface that corresponds to the heartbeat response. 8.2.5 NS notifies all other NSs in NS-pool of a change in caretaker NS This is the case of a change of caretaker NS notification. When the caretaker NS of a PE changes, then such a change needs to be notified to all NSs in the NS-pool. NS-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d NS-ID:1; PE-Parameter: 172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000 NS-ID:2; PE-Parameter: 172.19.45.4:40;Expires:65000 Policy:LRU Expires: 10000 Authorization: This implies that the PE with PE-Parameter of "172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000" is Ram & Senthil [Page 33] Internet Draft End Name Resolution Protocol July 2001 assigned a caretaker NS with NS-ID of 1. Similarly, the PE with PE- Parameter of "172.19.45.4:40;Expires:65000" has been assigned a caretaker NS with NS-ID of 2. 9 Security Considerations 9.1 Confidentiality and Privacy: Encryption 9.1.1 Application-Level Encryption Using public-key or shared-key based mechanisms, some or all headers as well as the message body within a Request and/or Response may be encrypted. The Encryption header is included to indicate the encryption mechanism employed. A blank line is used to indicate the start of encryption, and all headers following the blank line and the message body are encrypted. The mechanism follows that in RFC2543. 9.1.2 Lower-Layer Encryption In addition or instead of application layer encryption techniques, lower layer encryption techniques (e.g.IPSec, TLS, or link layer) may be employed. Such encryption may provide certain benefits, such as better protection against traffic analysis attacks (e.g. using link layer encryption). 9.2 Message Integrity and Access Control: Authentication The ENRP protocol utilizes mechanisms provided within HTTP and SIP for message integrity and/or authentication purposes. The Basic and Digest authentication schemes may be used for authentication. In addition, public-key based mechanisms may also be used. Irrespective of the type of authentication mechanism, the following procedure is adopted: - The WWW-Authenticate header is used within a 401 Response message, by the authenticator in order to indicate the authenticating mechanism and possibly the challenge. - The Authorization header is used within a re-issued Request message, in order to pass the authenticating information to the Authenticator. - The Authentication-Info header is used within a 200 Response message, by the authenticator in order to pass any token that may be needed by the entity that sent the Request message. Typically, all communication needs to be authenticated. 9.2.1 Illustration of Digest Scheme While we illustrate the use of the Digest authentication scheme here, Ram & Senthil [Page 34] Internet Draft End Name Resolution Protocol July 2001 a similar approach may be followed for other authentication schemes - Basic authentication, public-key based authentication etc. When an NS first registers with an NS in an NS-pool: - An NS (say, A) first registers with an NS (say B) in an NS-pool by sending a NS-REGISTRATION Request message without the Authorization header. - The NS B in the NS-pool returns a 401 Response message with a WWW-Authenticate header indicating that Digest authentication is needed. - The NS A sends a new NS-REGISTRATION Request message with an Authorization header included, in order to authenticate itself. - Upon successful authentication, the NS B returns a 200 Response message. An Authentication-Info header is included, and this contains a session key that all the NSs in the NS-pool share. For subsequent interactions between a pair of NS in the NS-pool: - All messages include an Authenticating Code within the Authorization header. The Authenticating Code is based on the session key shared by all the NS in the NS-pool. Appendix A. Implementation Issues For Implementation issues Refer ASAP draft Appendix A for more detail. B. Summary of Augmented BNF Please refer to [RFC2543] for a summary. C. Acknowledgement We wish to thank the Maureen Stillman and John Loughney for providing valuable comments and suggestions. Ram & Senthil [Page 35] Internet Draft End Name Resolution Protocol July 2001 D. Author's Contact Address Ram Gopal.L Senthil Sengodan Nokia Research Center 5 Wayside Road Burlington, MA 01803 USA email: ram.gopal@nokia.com senthil.sengodan@nokia.com E. Reference [RFC 822 ] D. Crocker, "Standard for the format of ARPA Internet text messages," Request for Comments 822, Internet Engineering Task Force,Aug. 1982. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC 2234] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF," Request for Comments 2234, Internet Engineering Task Force, Nov. 1997 [RFC 2279 ] F. Yergeau, "UTF-8, a transformation format of ISO 10646," Request for Comments 2279, Internet Engineering Task Force, Jan. 1998. [RFC2616] R. Fielding et al. Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, Internet Engineering Task Force, June 1999 [RFC 2617] J. Franks et al, HTTP Authentication: Basic and Digest Access Authentication, RFC 2617 Internet Engineering Task Force, June 1999 [RFC2960] R. R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960, November 2000 [ASAP-Draft] Ram Gopal and Senthil Sengodan , "Aggregate Server Access Protocol Candidate ",draft-gopal-asap-candidate-00.txt, July, 2001. Ram & Senthil [Page 36] Internet Draft End Name Resolution Protocol July 2001 [Papoulis] A.Papoulis, Probability, Random Variables, and Stochastic Processes, 3rd Edition, McGraw Hill Publication. [Mullender] Sape Mullender , Distributed Systems, 2nd Edition, Addison-Wesley [Rser-Arch] M. Tuexen, "Architecture for Reliable Server Pooling", Internet Draft,draft-ietf-rserpool-arch-00.txt, April, 2001. [Rser-Comp] J. Loughney, "Comparison of Protocols for Reliable Server Pooling", Internet draft,draft-ietf-rserpool-comp-00.txt, May 1,2001 [Rser-req] M. Tuexen,"Requirements for Reliable Server Pooling", Internet draft,draft-ietf-rserpool-reqts-03.txt,May 9 2001 [SIP Draft] Handley, "Session Initiation Protocol",Internet draft, draft-ietf-sip-rfc2543bis-02.txt, Nov 2000. [Stevens] W. R. Stevens, TCP/IP illustrated: the protocols , Vol. 1. Reading, Massachusetts: Addison-Wesley, 1994.