draft-ietf-rserpool-enrp-16.txt   draft-ietf-rserpool-enrp-17.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Intended status: Experimental R. Stewart Intended status: Experimental R. Stewart
Expires: January 10, 2008 Cisco Systems, Inc. Expires: March 25, 2008 Cisco Systems, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
A. Silverton A. Silverton
Motorola, Inc. Motorola, Inc.
July 9, 2007 September 22, 2007
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-16.txt draft-ietf-rserpool-enrp-17.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008. This Internet-Draft will expire on March 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to
work in conjunction with the Aggregate Server Access Protocol (ASAP) work in conjunction with the Aggregate Server Access Protocol (ASAP)
to accomplish the functionality of the Reliable Server Pooling to accomplish the functionality of the Reliable Server Pooling
skipping to change at page 3, line 25 skipping to change at page 3, line 25
5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 37 5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 37
5.2. A New Table for Update Action Types . . . . . . . . . . . 37 5.2. A New Table for Update Action Types . . . . . . . . . . . 37
5.3. Multicast Addresses . . . . . . . . . . . . . . . . . . . 38 5.3. Multicast Addresses . . . . . . . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39
6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 39 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 39
6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 40 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 40
6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 41 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 41
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References . . . . . . . . . . . . . . . . . . . 44 8.1. Normative References . . . . . . . . . . . . . . . . . . . 44
8.2. Informative References . . . . . . . . . . . . . . . . . . 45 8.2. Informative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP [1] to accomplish ENRP is designed to work in conjunction with ASAP [9] to accomplish
the functionality of RSerPool as defined by its requirements [2] and the functionality of RSerPool as defined by its requirements [5].
architecture [3].
Within the operational scope of RSerPool, ENRP defines the procedures Within the operational scope of RSerPool, ENRP defines the procedures
and message formats of a distributed fault-tolerant registry service and message formats of a distributed fault-tolerant registry service
for storing, bookkeeping, retrieving, and distributing pool operation for storing, bookkeeping, retrieving, and distributing pool operation
and membership information. and membership information.
Whenever appropriate, in the rest of this document we will refer to Whenever appropriate, in the rest of this document we will refer to
this RSerPool registry service as ENRP handlespace, or simply this RSerPool registry service as ENRP handlespace, or simply
handlespace because it manages all pool handles. handlespace because it manages all pool handles.
1.1. Definitions 1.1. Definitions
This document uses the following terms: This document uses the following terms:
Operational scope: See [3]; Operational scope: The part of the network visible to pool users by
a specific instance of the reliable server pooling protocols.
Pool (or server pool): See [3]; Pool (or server pool): A collection of servers providing the same
application functionality.
Pool handle: See [3]; Pool handle: A logical pointer to a pool. Each server pool will be
identifiable in the operational scope of the system by a unique
pool handle.
Pool element (PE): See [3]; Pool element: A server entity having registered to a pool.
Pool user (PU): See [3]; Pool user: A server pool user.
Pool element handle: See [3]; Pool element handle (or endpoint handle): A logical pointer to a
particular pool element in a pool, consisting of the pool handle
and a destination transport address of the pool element.
ENRP handlespace (or handlespace): See [3]; Handle space: A cohesive structure of pool handles and relations
that may be queried by an internal or external agent.
ENRP client channel: The communication channel through which an ASAP ENRP client channel: The communication channel through which an ASAP
User (either a PE or PU) requests ENRP handlespace service. The User (either a PE or PU) requests ENRP handlespace service. The
client channel is usually defined by the transport address of the client channel is usually defined by the transport address of the
home server and a well-known port number. The channel MAY make home server and a well-known port number. The channel MAY make
use of multi-cast or a named list of ENRP servers. use of multi-cast or a named list of ENRP servers.
ENRP server channel: Defined by a well-known multicast IP address ENRP server channel: Defined by a well-known multicast IP address
and a well known port number. All ENRP servers in an operational and a well known port number. All ENRP servers in an operational
scope can send multicast messages to other servers through this scope can send multicast messages to other servers through this
skipping to change at page 5, line 14 skipping to change at page 5, line 21
Home ENRP server: The ENRP server to which a PE or PU currently 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 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 time and both the PE and its home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its home ENRP server, but the 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 ENRP server does not need to know, nor does it need to keep track
of this relationship. of this relationship.
1.2. Conventions 1.2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
they appear in this document, are to be interpreted as described in document are to be interpreted as described in RFC2119 [2].
[6].
2. ENRP Message Definitions 2. ENRP Message Definitions
In this section, we define the format of all ENRP messages. These In this section, we define the format of all ENRP messages. These
are messages sent and received amongst ENRP servers in an operational are messages sent and received amongst ENRP servers in an operational
scope. Messages sent and received between a PE/PU and an ENRP server 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 are part of ASAP and are defined in [9]. A common format, that is
defined in [12], is used for all ENRP and ASAP messages. defined in [8], is used for all ENRP and ASAP messages.
Most ENRP messages contains a combination of fixed fields and TLV Most ENRP messages contains a combination of fixed fields and TLV
parameters. The TLV (Type-Length_value) parameters are also defined parameters. The TLV (Type-Length_value) parameters are also defined
in [12]. in [8].
All messages, as well as their fields/parameters described below, All messages, as well as their fields/parameters described below,
MUST be transmitted in network byte order (a.k.a. Big Endian, MUST be transmitted in network byte order (a.k.a. Big Endian,
meaning the most significant byte is transmitted first). meaning the most significant byte is transmitted first).
For ENRP, the following message types are defined in this section: For ENRP, the following message types are defined in this section:
Type Message Name Type Message Name
----- ------------------------- ----- -------------------------
0x00 - (reserved by IETF) 0x00 - (reserved by IETF)
skipping to change at page 7, line 48 skipping to change at page 7, line 48
This is a TLV that contains the latest PE checksum of the ENRP This is a TLV that contains the latest PE checksum of the ENRP
server who sends the ENRP_PRESENCE. This parameter SHOULD be server who sends the ENRP_PRESENCE. This parameter SHOULD be
included for handlespace consistency auditing. See included for handlespace consistency auditing. See
Section 3.11.1 for details. Section 3.11.1 for details.
Server Information Parameter: Server Information Parameter:
If this parameter is present, it contains the server If this parameter is present, it contains the server
information of the sender of this message (Server Information information of the sender of this message (Server Information
Parameter is defined in [12]). This parameter is optional. Parameter is defined in [8]). This parameter is optional.
However, if this message is sent in response to a received However, if this message is sent in response to a received
"reply required" ENRP_PRESENCE from a peer, the sender then "reply required" ENRP_PRESENCE from a peer, the sender then
MUST include its server information. MUST include its server information.
Note, at startup an ENRP server MUST pick a randomly generated, non- 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 zero 32-bit unsigned integer as its ID and MUST use this same ID
until the ENRP server is rebooted. until the ENRP server is rebooted.
2.2. ENRP_HANDLE_TABLE_REQUEST message 2.2. ENRP_HANDLE_TABLE_REQUEST message
skipping to change at page 14, line 9 skipping to change at page 14, line 9
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Server Information Parameter of Peer #1-#n: Server Information Parameter of Peer #1-#n:
Each contains a Server Information Parameter of a peer known to Each contains a Server Information Parameter of a peer known to
the sender. The Server Information Parameter is defined in the sender. The Server Information Parameter is defined in
[12]. [8].
2.7. ENRP_INIT_TAKEOVER message 2.7. ENRP_INIT_TAKEOVER message
The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the
takeover initiator) to announce its intention of taking over a takeover initiator) to announce its intention of taking over a
specific peer ENRP server. It is send to all its peers. specific peer ENRP server. It is send to all its peers.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 44 skipping to change at page 16, line 44
Sending Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Operational Error Parameter: Operational Error Parameter:
This parameter, defined in [12], indicates the type of error(s) This parameter, defined in [8], indicates the type of error(s)
being reported. being reported.
3. ENRP Operation Procedures 3. ENRP Operation Procedures
In this section, we discuss the operation procedures defined by ENRP. In this section, we discuss the operation procedures defined by ENRP.
An ENRP server MUST follow these procedures when sending, receiving, An ENRP server MUST follow these procedures when sending, receiving,
or processing ENRP messages. or processing ENRP messages.
Many of the RSerPool events call for both server-to-server and PU/ Many of the RSerPool events call for both server-to-server and PU/
PE-to-server message exchanges. Only the message exchanges and PE-to-server message exchanges. Only the message exchanges and
activities between an ENRP server and its peer(s) are considered activities between an ENRP server and its peer(s) are considered
within the ENRP scope and are defined in this document. within the ENRP scope and are defined in this document.
Procedures for exchanging messages between a PE/PU and ENRP servers Procedures for exchanging messages between a PE/PU and ENRP servers
are defined in [1]. are defined in [9].
3.1. Methods for Communicating amongst ENRP Servers 3.1. Methods for Communicating amongst ENRP Servers
Within an RSerPool operational scope, ENRP servers need to Within an RSerPool operational scope, ENRP servers need to
communicate with each other in order to exchange information such as communicate with each other in order to exchange information such as
the pool membership changes, handlespace data synchronization, etc. the pool membership changes, handlespace data synchronization, etc.
Two types of communications are used amongst ENRP servers: Two types of communications are used amongst ENRP servers:
o point-to-point message exchange from one ENPR server to a specific o point-to-point message exchange from one ENPR server to a specific
skipping to change at page 18, line 48 skipping to change at page 18, line 48
This section describes the steps a new ENRP server needs to take in 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 order to join the other existing ENRP servers, or to initiate the
handlespace service if it is the first ENRP server started in the handlespace service if it is the first ENRP server started in the
operational scope. operational scope.
3.2.1. Generate a Server Identifier 3.2.1. Generate a Server Identifier
A new ENRP server MUST generate a non-zero, 32-bit server Id that is 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 as unique as possible in the operational scope and this server Id
MUST remain unchanged for the lifetime of the server. Normally, a 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] good 32-bit random number will be good enough as the server Id
provides some information on randomness guidelines). (RFC4086 [11] provides some information on randomness guidelines).
Note, there is a very remote chance (about 1 in about 4 billion) that Note, there is a very remote chance (about 1 in about 4 billion) that
two ENRP servers in an operational scope will generate the same two ENRP servers in an operational scope will generate the same
server Id and hence cause a server Id conflict in the pool. However, server Id and hence cause a server Id conflict in the pool. However,
no severe consequence of such a conflict has been identified. no severe consequence of such a conflict has been identified.
3.2.2. Acquire Peer Server List 3.2.2. Acquire Peer Server List
At startup, the ENRP server (initiating server) will first attempt to At startup, the ENRP server (initiating server) will first attempt to
learn all existing peer ENRP servers in the same operational scope, learn all existing peer ENRP servers in the same operational scope,
skipping to change at page 23, line 18 skipping to change at page 23, line 18
mentor peer set the M-bit to 1 to indicate that it has more data to 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 send, it SHOULD start a session timer. If this timer expires without
receiving another request from the initiating server, the mentor peer receiving another request from the initiating server, the mentor peer
SHOULD abort the session, cleaning out any resource and record of the SHOULD abort the session, cleaning out any resource and record of the
session. session.
3.3. Handle PE Registration 3.3. Handle PE Registration
To register itself with the handlespace, a PE sends an To register itself with the handlespace, a PE sends an
ASAP_REGISTRATION message to its home ENRP server. The format of ASAP_REGISTRATION message to its home ENRP server. The format of
ASAP_REGISTRATION message and rules of sending it are defined in [1]. ASAP_REGISTRATION message and rules of sending it are defined in [9].
In the ASAP_REGISTRATION message, the PE indicates the handle of the 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 pool it wishes to join in a pool handle parameter, and its complete
transport information and any load control information in a PE transport information and any load control information in a PE
parameter. parameter.
The ENRP server handles the ASAP_REGISTRATION message according to The ENRP server handles the ASAP_REGISTRATION message according to
the following rules: the following rules:
1. If the named pool does not exist in the handlespace, the ENRP 1. If the named pool does not exist in the handlespace, the ENRP
skipping to change at page 25, line 10 skipping to change at page 25, line 10
A PE may re-register itself to the handlespace with a new set of A PE may re-register itself to the handlespace with a new set of
attributes in order to, for example, extend its registration life, attributes in order to, for example, extend its registration life,
change its load factor value, etc. as described in the ASAP change its load factor value, etc. as described in the ASAP
specification. specification.
A PE may modify its load factor value at any time via re- 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 registration. Based on the number of PEs in the pool and the pool's
overall policy type, this operation allows the PE to dynamically overall policy type, this operation allows the PE to dynamically
control its share of inbound messages received by the pool (also see control its share of inbound messages received by the pool (also see
Section ???? in [1] for more on load control). Section ???? in [9] for more on load control).
Moreover, when re-registering, the PE MUST NOT change its policy Moreover, when re-registering, the PE MUST NOT change its policy
type. The server MUST reject the re-registration if the PE attempt type. The server MUST reject the re-registration if the PE attempt
to change its policy type. In the rejection, the server SHOULD to change its policy type. In the rejection, the server SHOULD
attach an error code "Pooling Policy Inconsistent". attach an error code "Pooling Policy Inconsistent".
Regardless whether it is the current owner of the PE, if the re- 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 registration is granted to the PE, the ENRP server MUST assign itself
to be the new home ENRP server of the PE. to be the new home ENRP server of the PE.
Moreover, if the re-registration is granted, the ENRP server MUST Moreover, if the re-registration is granted, the ENRP server MUST
take the handlespace update action as described in Section 3.6 to take the handlespace update action as described in Section 3.6 to
inform its peers about the change just made. If the re-registration inform its peers about the change just made. If the re-registration
is denied, no message will be sent to its peers. is denied, no message will be sent to its peers.
3.4. Handle PE De-registration 3.4. Handle PE De-registration
To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION
message to its home ENRP server. The complete format of message to its home ENRP server. The complete format of
ASAP_DEREGISTRATION message and rules of sending it are defined in ASAP_DEREGISTRATION message and rules of sending it are defined in
[1]. [9].
In the ASAP_DEREGISTRATION message the PE indicates the handle of the 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 pool it belongs to in a pool handle parameter and provides its PE
identifier. identifier.
Upon receiving the message, the ENRP server SHALL remove the PE from 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 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 pool, the ENRP server will remove the pool from the handlespace as
well. well.
skipping to change at page 26, line 26 skipping to change at page 26, line 26
3.5. Pool Handle Translation 3.5. Pool Handle Translation
A PU uses the pool handle translation service of an ENRP server to 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 resolve a pool handle to a list of accessible transport addresses of
the member PEs of the pool. the member PEs of the pool.
This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its
home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify
the pool handle to be translated in a Pool Handle parameter. the pool handle to be translated in a Pool Handle parameter.
Complete definition of the ASAP_HANDLE_RESOLUTION message and the Complete definition of the ASAP_HANDLE_RESOLUTION message and the
rules of sending it are defined in [1]. rules of sending it are defined in [9].
An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION
requests from PUs either over an SCTP association on the well-know 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. SCTP port, or over a TCP connection on the well-know TCP port.
Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server
MUST first look up the pool handle in its handlespace. If the pool MUST first look up the pool handle in its handlespace. If the pool
exits, the home ENRP server MUST compose and send back an exits, the home ENRP server MUST compose and send back an
ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU.
skipping to change at page 26, line 49 skipping to change at page 26, line 49
ENRP server MUST also include a pool member selection policy ENRP server MUST also include a pool member selection policy
parameter to indicate the overall member selection policy for the parameter to indicate the overall member selection policy for the
pool, if the current pool member selection policy is not round-robin. 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 If the named pool does not exist in the handlespace, the ENRP server
MUST reject the handle resolution request by responding with an MUST reject the handle resolution request by responding with an
ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor
Handle error. Handle error.
The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and
the rules of receiving it are defined in [1]. the rules of receiving it are defined in [9].
3.6. Server Handlespace Update 3.6. Server Handlespace Update
This includes a set of update operations used by an ENRP server to This includes a set of update operations used by an ENRP server to
inform its peers when its local handlespace is modified, e.g., 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 addition of a new PE, removal of an existing PE, change of pool or PE
properties. properties.
3.6.1. Announcing Addition or Update of PE 3.6.1. Announcing Addition or Update of PE
skipping to change at page 28, line 37 skipping to change at page 28, line 37
find pool and the PE in its own handlespace, and then remove the PE 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 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. 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 If the peer fails to find the PE or the pool in its handlespace, it
SHOULD take no further actions. SHOULD take no further actions.
3.7. Detecting and Removing Unreachable PE 3.7. Detecting and Removing Unreachable PE
Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 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 Notification, see section 10.2 of [4]), the PU SHOULD send an
ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The
message SHOULD contain the pool handle and the PE Id of the message SHOULD contain the pool handle and the PE Id of the
unreachable PE. unreachable PE.
Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server
MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE 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 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 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 (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP
server MUST consider the PE as truly unreachable and MUST remove the server MUST consider the PE as truly unreachable and MUST remove the
skipping to change at page 29, line 24 skipping to change at page 29, line 24
fails, the ENRP server MUST consider the PE as unreachable and MUST fails, the ENRP server MUST consider the PE as unreachable and MUST
remove the PE from its handlespace and take actions described in 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, 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 the implementation should pay attention not to flood the network with
bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the
implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message
traffic over a time period. traffic over a time period.
The complete definition and rules of sending The complete definition and rules of sending
ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE
messages are described in [1]. messages are described in [9].
3.8. Helping PE and PU to Discover Home ENRP Server 3.8. Helping PE and PU to Discover Home ENRP Server
At its startup time, or whenever its current home ENRP server is not 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 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 server. For this reason, the PE or PU will need to maintain a list
of currently available ENRP servers in its scope. of currently available ENRP servers in its scope.
To help the PE or PU maintaining this list, an ENRP server, if it is To help the PE or PU maintaining this list, an ENRP server, if it is
enabled for multicast, SHOULD periodically send out an enabled for multicast, SHOULD periodically send out an
ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to
the well-known ASAP multicast channel. And in the the well-known ASAP multicast channel. And in the
ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the
transport addresses available for ASAP communications. If the ENRP transport addresses available for ASAP communications. If the ENRP
server only supports SCTP for ASAP communications, the transport server only supports SCTP for ASAP communications, the transport
information MAY be omitted in the ASAP_SERVER_ANNOUNCE message. information MAY be omitted in the ASAP_SERVER_ANNOUNCE message.
For the complete procedure of this, see Section 3.6?? in [1]. For the complete procedure of this, see Section 3.6?? in [9].
3.9. Maintaining Peer List and Monitoring Peer Status 3.9. Maintaining Peer List and Monitoring Peer Status
An ENRP server MUST keep an internal record on the status of each of 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 its known peers. This record is referred to as the server's "peer
list" list"
3.9.1. Discovering New Peer 3.9.1. Discovering New Peer
If a message of any type is received from a previously unknown peer, If a message of any type is received from a previously unknown peer,
skipping to change at page 30, line 26 skipping to change at page 30, line 26
3.9.2. Server Sending Heartbeat 3.9.2. Server Sending Heartbeat
Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its
continued presence to all its peer with a ENRP_PRESENCE message. In continued presence to all its peer with a ENRP_PRESENCE message. In
the ENRP_PRESENCE message, the ENRP server MUST set the the ENRP_PRESENCE message, the ENRP server MUST set the
'Replay_required' flag to '0', indicating that no response is 'Replay_required' flag to '0', indicating that no response is
required. required.
The arrival of this periodic ENRP_PRESENCE message will cause all its The arrival of this periodic ENRP_PRESENCE message will cause all its
peers to update their internal variable "peer.last.heard" for the peers to update their internal variable "peer_last_heard" for the
sending server (see Section 3.9.3 for more details). sending server (see Section 3.9.3 for more details).
3.9.3. Detecting Peer Server Failure 3.9.3. Detecting Peer Server Failure
An ENRP server MUST keep an internal variable "peer.last.heard" for 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 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 updated to the current local time every time a message of any type
(point-to-point or announcement) is received from the corresponding (point-to-point or announcement) is received from the corresponding
peer. peer.
If a peer has not been heard for more than MAX-TIME-LAST-HEARD 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 seconds, the ENRP server MUST immediately send a point-to-point
ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. 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- If the send fails or the peer does not reply after MAX-TIME-NO-
skipping to change at page 33, line 16 skipping to change at page 33, line 16
A checksum covering the data which should be the same is exchanged to A checksum covering the data which should be the same is exchanged to
figure out if the data is the same or not. figure out if the data is the same or not.
The auditing of handlespace consistency is based on the following The auditing of handlespace consistency is based on the following
procedures: procedures:
1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit
integer internal variable) for each of its known peers and for integer internal variable) for each of its known peers and for
itself. For an ENRP server with 'k' known peers, we denote these itself. For an ENRP server with 'k' known peers, we denote these
internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., internal variables as "pe_checksum_pr0", "pe_checksum_pr1", ...,
"pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE "pe_checksum_prk", where "pe_checksum_pr0" is the server's own PE
checksum. The list of what these checksums cover and a detailed checksum. The list of what these checksums cover and a detailed
algorithm for calculating them is given in Section 3.11.2. algorithm for calculating them is given in Section 3.11.2.
2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST 2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST
include in the message its current PE checksum (i.e., include in the message its current PE checksum (i.e.,
"pe.checksum.pr0"). "pe_checksum_pr0").
3. When an ENRP server (server A) receives a PE checksum (carried in 3. When an ENRP server (server A) receives a PE checksum (carried in
an arrived ENRP_PRESENCE) from a peer ENRP server (server B), an arrived ENRP_PRESENCE) from a peer ENRP server (server B),
server A SHOULD compare the PE checksum found in the server A SHOULD compare the PE checksum found in the
ENRP_PRESENCE with its own internal PE checksum of server B ENRP_PRESENCE with its own internal PE checksum of server B
(i.e., "pe.checksum.prB"). (i.e., "pe_checksum_prB").
4. If the two values match, server A will consider that there is no 4. If the two values match, server A will consider that there is no
handlespace inconsistency between itself and server B and should handlespace inconsistency between itself and server B and should
take no further actions. take no further actions.
5. If the two values do NOT match, server A SHOULD consider that 5. If the two values do NOT match, server A SHOULD consider that
there is a handlespace inconsistency between itself and server B there is a handlespace inconsistency between itself and server B
and a re-synchronization process SHOULD be carried out and a re-synchronization process SHOULD be carried out
immediately with server B (see Section 3.11.3). immediately with server B (see Section 3.11.3).
skipping to change at page 34, line 16 skipping to change at page 34, line 16
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 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 : : Pool handle string of the pool the PE belongs (padded with :
: zeros to next 32-bit word boundary if needed) : : zeros to next 32-bit word boundary if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Id (4 octets) | | PE Id (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, these are not TLVs. This byte block gives each PE a unique 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 byte pattern in the scope. The 16-bit PE checksum for server B
"pe.checksum.prB" is then calculated over the byte blocks contributed "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 by the 'M' PEs one by one. The PE checksum calculation MUST use the
Internet algorithm described in [4]. Internet algorithm described in [1].
Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") 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 in the same fashion, using the byte blocks of all the PEs owned by
itself. itself.
Note, whenever an ENRP finds that its internal handlespace has Note, whenever an ENRP finds that its internal handlespace has
changed (e.g., due to PE registration/deregistration, receiving peer changed (e.g., due to PE registration/deregistration, receiving peer
updates, removing failed PEs, downloading handlespace pieces from a updates, removing failed PEs, downloading handlespace pieces from a
peer, etc.), it MUST immediately update all its internal PE checksums peer, etc.), it MUST immediately update all its internal PE checksums
that are affected by the change. that are affected by the change.
Implementation Note: when the internal handlespace changes (e.g., a Implementation Note: when the internal handlespace changes (e.g., a
skipping to change at page 35, line 29 skipping to change at page 35, line 29
Note, similar to what is described in Section 3.2.3, the peer may 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 reject the ENRP_HANDLE_TABLE_REQUEST or use more than one
ENRP_HANDLE_TABLE_RESPONSE message to respond. ENRP_HANDLE_TABLE_RESPONSE message to respond.
3.12. Handling Unrecognized Message or Unrecognized Parameter 3.12. Handling Unrecognized Message or Unrecognized Parameter
When an ENRP server receives an ENRP message with an unknown message When an ENRP server receives an ENRP message with an unknown message
type or a message of known type that contains an unknown parameter, type or a message of known type that contains an unknown parameter,
it SHOULD handle the unknown message or the unknown parameter it SHOULD handle the unknown message or the unknown parameter
according to the unrecognized message and parameter handling rules according to the unrecognized message and parameter handling rules
defined in Sections 3 and 4 in [12]. defined in Sections 3 and 4 in [8].
According to the rules, if an error report to the message sender is 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 needed, the ENRP server that discovered the error SHOULD send back an
ENRP_ERROR message with proper error cause code. ENRP_ERROR message with proper error cause code.
4. Variables and Thresholds 4. Variables and Thresholds
4.1. Variables 4.1. Variables
peer.last.heard - the local time that a peer server was last heard peer_last_heard - the local time that a peer server was last heard
(via receiving either a multicast or point-to-point message from (via receiving either a multicast or point-to-point message from
the peer). the peer).
pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server 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 keeps for a peer. A separate PE checksum is kept for each of its
known peers as well as for itself. known peers as well as for itself.
4.2. Thresholds 4.2. Thresholds
MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender
will make to contact an ENRP server (Default=3 times). will make to contact an ENRP server (Default=3 times).
TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will
wait for a response from an ENRP server (Default=5 seconds). wait for a response from an ENRP server (Default=5 seconds).
skipping to change at page 37, line 41 skipping to change at page 37, line 41
0x05 ENRP_LIST_REQUEST RFCXXXX 0x05 ENRP_LIST_REQUEST RFCXXXX
0x06 ENRP_LIST_RESPONSE RFCXXXX 0x06 ENRP_LIST_RESPONSE RFCXXXX
0x07 ENRP_INIT_TAKEOVER RFCXXXX 0x07 ENRP_INIT_TAKEOVER RFCXXXX
0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX 0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX
0x09 ENRP_TAKEOVER_SERVER RFCXXXX 0x09 ENRP_TAKEOVER_SERVER RFCXXXX
0x0a ENRP_ERROR RFCXXXX 0x0a ENRP_ERROR RFCXXXX
0x0b-0xff (reserved by IETF) RFCXXXX 0x0b-0xff (reserved by IETF) RFCXXXX
For registering at IANA an ENRP Message Type in this table a request 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. has to be made to assign such a number. This number must be unique.
The "Specification Required" policy of RFC2434 [8] MUST be applied. The "Specification Required" policy of RFC2434 [3] MUST be applied.
5.2. A New Table for Update Action Types 5.2. A New Table for Update Action Types
Update Types have to be maintained by IANA. Two initial values Update Types have to be maintained by IANA. Two initial values
should be assigned by IANA. This requires a new table "Update Action should be assigned by IANA. This requires a new table "Update Action
Types": Types":
Type Update Action Reference Type Update Action Reference
------------- -------------------- --------- ------------- -------------------- ---------
0x0000 ADD_PE RFCXXXX 0x0000 ADD_PE RFCXXXX
0x0001 DEL_PE RFCXXXX 0x0001 DEL_PE RFCXXXX
0x0002-0xffff (reserved by IETF) RFCXXXX 0x0002-0xffff (reserved by IETF) RFCXXXX
For registering at IANA an Update Action Type in this table a request 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. has to be made to assign such a number. This number must be unique.
The "Specification Required" policy of RFC2434 [8] MUST be applied. The "Specification Required" policy of RFC2434 [3] MUST be applied.
5.3. Multicast Addresses 5.3. Multicast Addresses
IANA should assign one multicast address for the ENRP server channel IANA should assign one multicast address for the ENRP server channel
and another one for the ENRP client channel. and another one for the ENRP client channel.
6. Security Considerations 6. Security Considerations
We present a summary of the threats to the RSerPool architecture and We present a summary of the threats to the RSerPool architecture and
describe security requirements in response to mitigate the describe security requirements in response to mitigate the threats.
threats.ENext we present the security mechanisms, based on TLS, that Next we present the security mechanisms, based on TLS, that are
are implementation requirements in response to the threats.E Finally, implementation requirements in response to the threats. Finally, we
we present a chain of trust argument that examines critical data present a chain of trust argument that examines critical data paths
paths in RSerPool and shows how these paths are protected by the TLS in RSerPool and shows how these paths are protected by the TLS
implementation. implementation.
6.1. Summary of Rserpool Security Threats 6.1. Summary of Rserpool Security Threats
Threats Introduced by RSerPool and Requirements for Security in Threats Introduced by RSerPool and Requirements for Security in
Response to Threats [13] describes the threats to the RSerPool Response to Threats [10] describes the threats to the RSerPool
architecture in detail lists the security requirements in response to architecture in detail lists the security requirements in response to
each threat.E From the threats described in this document, the each threat. From the threats described in this document, the
security services required for the RSerPool protocol are enumerated security services required for the RSerPool protocol are enumerated
below. below.
Threat 1) PE registration/deregistration flooding or spoofing Threat 1) PE registration/deregistration flooding or spoofing
----------- -----------
Security mechanism in response: ENRP server authenticates the PE Security mechanism in response: ENRP server authenticates the PE
Threat 2) PE registers with a malicious ENRP server Threat 2) PE registers with a malicious ENRP server
----------- -----------
Security mechanism in response: PE authenticates the ENRP server Security mechanism in response: PE authenticates the ENRP server
skipping to change at page 40, line 36 skipping to change at page 40, line 36
from replay attacks. from replay attacks.
For RSerPool we need to authenticate the following: For RSerPool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server) PU <---- ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication)
6.2. Implementing Security Mechanisms 6.2. Implementing Security Mechanisms
We do not define any new security mechanisms specifically for EE We do not define any new security mechanisms specifically for
responding to threats 1-7.E Rather we use an existing IETF security responding to threats 1-7. Rather we use an existing IETF security
EE protocol, specifically [2], to provide the security services protocol, specifically [5], to provide the security services
required.ETLS supports all these requirements and MUST be required. TLS supports all these requirements and MUST be
implemented.EThe TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be
supported at a minimum by implementors of TLS for RSerPool.E For supported at a minimum by implementors of TLS for RSerPool. For
purposes of backwards compatibility, ENRP SHOULD support EE purposes of backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA.EImplementers MAY also support any EE TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other IETF approved ciphersuites. other IETF approved ciphersuites.
ENRP servers, PEs, PUs MUST implement TLS.E ENRP servers and PEs must ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication.E ENRP servers must support mutual support mutual authentication. ENRP servers must support mutual
authentication among themselves.E PUs MUST authenticate ENRP servers. authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname.E PUs MAY have certificates corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use.E All RSerPool elements are set forth in this document for their use. All RSerPool elements
that support TLS MUST have a mechanism for validating certificates that support TLS MUST have a mechanism for validating certificates
received during TLS negotiation; this entails possession of one or received during TLS negotiation; this entails possession of one or
more root certificates issued by certificate authorities (preferably more root certificates issued by certificate authorities (preferably
well-known distributors of site certificates comparable to those that well-known distributors of site certificates comparable to those that
issue root certificates for web browsers). issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in [10] or Implementations MUST support TLS with SCTP as described in [6] or TLS
TLS over TCP as described in [7].EWhen using TLS/SCTP we must ensure over TCP as described in [7]. When using TLS/SCTP we must ensure
that RSerPool does not use any features of SCTP that are not 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 available to an TLS/SCTP user. This is not a difficult technical
problem, but simply a requirement.E When describing an API of the problem, but simply a requirement. When describing an API of the
RSerPool lower layer we have also to take into account the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [1]) to the ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [9]) to the
ENRP server. ENRP server.
Threat 9 requires the ENRP protocol to limit the number of Threat 9 requires the ENRP protocol to limit the number of
ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see
section Section 3.7). section Section 3.7).
6.3. Chain of trust 6.3. Chain of trust
Security is mandatory to implement in RSerPool and is based on TLS Security is mandatory to implement in RSerPool and is based on TLS
implementation in all three architecture components that comprise implementation in all three architecture components that comprise
skipping to change at page 44, line 9 skipping to change at page 44, line 9
7. Acknowledgements 7. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
Thomas Dreibholz, and many others for their invaluable comments and Thomas Dreibholz, and many others for their invaluable comments and
feedback. feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [1] Braden, R., Borman, D., Partridge, C., and W. Plummer,
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12 "Computing the Internet checksum", RFC 1071, September 1988.
(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 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
RFC 2246, January 1999.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960, Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000. October 2000.
[10] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP", [5] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
RFC 3436, December 2002. J., and M. Stillman, "Requirements for Reliable Server
Pooling", RFC 3237, January 2002.
[11] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On [6] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
the Use of Stream Control Transmission Protocol (SCTP) with Security over Stream Control Transmission Protocol", RFC 3436,
IPsec", RFC 3554, July 2003. December 2002.
[12] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Server Access Protocol (ASAP) and Endpoint Handlespace Protocol Version 1.1", RFC 4346, April 2006.
Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-09 (work in progress),
July 2005.
[13] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M. [8] Stewart, R., "Aggregate Server Access Protocol (ASAP) and
Holdrege, "Threats Introduced by Rserpool and Requirements for Endpoint Handlespace Redundancy Protocol (ENRP) Parameters",
Security in Response to Threats", draft-ietf-rserpool-common-param-12 (work in progress),
draft-ietf-rserpool-threats-05 (work in progress), July 2005. July 2007.
[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [9] Stewart, R., "Aggregate Server Access Protocol (ASAP)",
Protocol Version 1.1", RFC 4346, April 2006. draft-ietf-rserpool-asap-16 (work in progress), July 2007.
[10] Gopal, R., Guttman, E., Holdrege, M., Sengodan, S., and M.
Stillman, "Threats Introduced by Rserpool and Requirements for
Security in response to Threats",
draft-ietf-rserpool-threats-08 (work in progress),
September 2007.
8.2. Informative References 8.2. Informative References
[15] Eastlake, D., Crocker, S., and J. Schiller, "Randomness [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Recommendations for Security", RFC 1750, December 1994. Requirements for Security", BCP 106, RFC 4086, June 2005.
Authors' Addresses Authors' Addresses
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, 2-F9 1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004 Arlington Heights, IL 60004
US US
Phone: Phone:
 End of changes. 62 change blocks. 
118 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/