draft-ietf-rserpool-enrp-18.txt   draft-ietf-rserpool-enrp-19.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: May 22, 2008 Cisco Systems, Inc. Expires: September 29, 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.
November 19, 2007 March 28, 2008
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-18.txt draft-ietf-rserpool-enrp-19.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 May 22, 2008. This Internet-Draft will expire on September 29, 2008.
Copyright Notice
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
(RSerPool) requirements and architecture. Within the operational (RSerPool) requirements and architecture. Within the operational
scope of RSerPool, ENRP defines the procedures and message formats of scope of RSerPool, ENRP defines the procedures and message formats of
a distributed, fault-tolerant registry service for storing, a distributed, fault-tolerant registry service for storing,
bookkeeping, retrieving, and distributing pool operation and bookkeeping, retrieving, and distributing pool operation and
skipping to change at page 3, line 11 skipping to change at page 3, line 11
3.6.1. Auditing Procedures . . . . . . . . . . . . . . . . . 26 3.6.1. Auditing Procedures . . . . . . . . . . . . . . . . . 26
3.6.2. PE Checksum Calculation Algorithm . . . . . . . . . . 27 3.6.2. PE Checksum Calculation Algorithm . . . . . . . . . . 27
3.6.3. Re-synchronization Procedures . . . . . . . . . . . . 28 3.6.3. Re-synchronization Procedures . . . . . . . . . . . . 28
3.7. Handling Unrecognized Message or Unrecognized Parameter . 28 3.7. Handling Unrecognized Message or Unrecognized Parameter . 28
4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 29 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 29
4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 30 5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 30
5.2. A New Table for Update Action Types . . . . . . . . . . . 30 5.2. A New Table for Update Action Types . . . . . . . . . . . 30
5.3. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. SCTP payload protocol identifier . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32
6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33
6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 34 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 41
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP [9] to accomplish ENRP is designed to work in conjunction with ASAP
the functionality of RSerPool as defined by its requirements [5]. [I-D.ietf-rserpool-asap] to accomplish the functionality of RSerPool
as defined by its requirements [RFC3237].
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.
skipping to change at page 5, line 9 skipping to change at page 5, line 14
ENRP server channel: Defined by a list of IP addresses (one for each ENRP server channel: Defined by a list of IP addresses (one for each
ENRP servers in an operational scope) and a well known port ENRP servers in an operational scope) and a well known port
number. All ENRP servers in an operational scope can send "group- number. All ENRP servers in an operational scope can send "group-
cast" messages to other servers through this channel. In a cast" messages to other servers through this channel. In a
"group-cast", the sending server sends multiple copies of the "group-cast", the sending server sends multiple copies of the
message, one to each of its peer servers, over a set of point-to- message, one to each of its peer servers, over a set of point-to-
point SCTP associations between the sending server and the peers. point SCTP associations between the sending server and the peers.
The "group-cast" may be conveniently implemented with the use of The "group-cast" may be conveniently implemented with the use of
the "SCTP_SENDALL" option on an one-to-many style SCTP socket the "SCTP_SENDALL" option on an one-to-many style SCTP socket
[11]. [I-D.ietf-tsvwg-sctpsocket].
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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2]. document are to be interpreted as described in RFC2119 [RFC2119].
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 [9]. A common format, that is are part of ASAP and are defined in [I-D.ietf-rserpool-asap]. A
defined in [8], is used for all ENRP and ASAP messages. common format, that is defined in [I-D.ietf-rserpool-common-param],
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 [8]. If a nested TLV parameter is not ended on a 32-bit word in [I-D.ietf-rserpool-common-param]. If a nested TLV parameter is
boundary, it will be padded with all '0' octets to the next 32-bit not ended on a 32-bit word boundary, it will be padded with all '0'
word boundary. octets to the next 32-bit word boundary.
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 19 skipping to change at page 7, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Checksum Param : : PE Checksum Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Param (optional) : : Server Information Param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (reply_required) flag: 1 bit
Set to '1' if the sender requires a response to this message,
otherwise set to '0'. If sent to the ENRP server channel this
field MUST be set to '0'.
Sending Server's ID: 32 bit (unsigned integer) Sending Server's ID: 32 bit (unsigned integer)
This is the ID of the ENRP server which sent this message. This is the ID of the ENRP server which sent this message.
Receiving Server's ID: 32 bit (unsigned integer) Receiving Server's ID: 32 bit (unsigned integer)
This is the ID of the ENRP server to which this message is This is the ID of the ENRP server to which this message is
intended. If the message is not intended for an individual intended. If the message is not intended for an individual
server (e.g., the message is group-casted to a group of server (e.g., the message is group-casted to a group of
servers), this field MUST be sent with all 0's. If the message servers), this field MUST be sent with all 0's. If the message
skipping to change at page 7, line 48 skipping to change at page 7, line 42
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.6.1 for details. Section 3.6.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 [8]). This parameter is optional. Parameter is defined in [I-D.ietf-rserpool-common-param]).
However, if this message is sent in response to a received This parameter is optional. However, if this message is sent
"reply required" ENRP_PRESENCE from a peer, the sender then in response to a received "reply required" ENRP_PRESENCE from a
MUST include its server information. peer, the sender then 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
An ENRP server sends this message to one of its peers to request a An ENRP server sends this message to one of its peers to request a
copy of the handlespace data. This message is normally used during copy of the handlespace data. This message is normally used during
server initialization or handlespace re-synchronization. server initialization or handlespace re-synchronization.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Pool entry #1-#n: Pool entry #1-#n:
If the R flag is set to '0', at least one pool entry SHOULD be If the R flag is set to '0', at least one pool entry SHOULD be
present in this message. Each pool entry MUST start with a present in this message. Each pool entry MUST start with a
Pool Handle parameter as defined in section 3.9 of [8], and is Pool Handle parameter as defined in section 3.9 of
followed by one or more Pool Element parameters in TLV format, [I-D.ietf-rserpool-common-param], and is followed by one or
as shown below: more Pool Element parameters in TLV format, as shown below:
+---------------------------+ +---------------------------+
: Pool handle : : Pool handle :
+---------------------------+ +---------------------------+
: PE #1 : : PE #1 :
+---------------------------+ +---------------------------+
: PE #2 : : PE #2 :
+---------------------------+ +---------------------------+
: ... : : ... :
+---------------------------+ +---------------------------+
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
[8]. [I-D.ietf-rserpool-common-param].
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 [8], indicates the type of error(s) This parameter, defined in [I-D.ietf-rserpool-common-param],
being reported. indicates the type of error(s) 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 [9]. are defined in [I-D.ietf-rserpool-asap].
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 17, line 51 skipping to change at page 17, line 51
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 among all the ENRP servers in the operational as unique as possible among all the ENRP servers in the operational
scope and this server Id MUST remain unchanged for the lifetime of scope and this server Id MUST remain unchanged for the lifetime of
the server. Normally, a good 32-bit random number will be good the server. Normally, a good 32-bit random number will be good
enough as the server Id (RFC4086 [12] provides some information on enough as the server Id (RFC4086 [RFC4086] provides some information
randomness guidelines). 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.
Note, the ENRP server Id space is separate from the PE Id space Note, the ENRP server Id space is separate from the PE Id space
defined in [9]. defined in [I-D.ietf-rserpool-asap].
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,
or to determine that it is alone in the scope. or to determine that it is alone in the scope.
The initiating server uses an existing peer server to bootstrap The initiating server uses an existing peer server to bootstrap
itself into service. We call this peer server the mentor server. itself into service. We call this peer server the mentor server.
skipping to change at page 22, line 37 skipping to change at page 22, line 37
carried in the message. carried in the message.
3. If the named pool exists AND the PE is already a member of the 3. If the named pool exists AND the PE is already a member of the
pool, the peer MUST replace the attributes of the PE with the new pool, the peer MUST replace the attributes of the PE with the new
information carried in the message. information carried in the message.
3.3.2. Announcing Removal of PE 3.3.2. Announcing Removal of PE
When an existing PE is granted de-registration or is removed from its When an existing PE is granted de-registration or is removed from its
handlespace for some other reasons (e.g., purging an unreachable PE, handlespace for some other reasons (e.g., purging an unreachable PE,
see 3.5 in [9]), the ENRP server MUST uses this procedure to inform see 3.5 in [I-D.ietf-rserpool-asap]), the ENRP server MUST uses this
all its peers about the change just made. procedure to inform all its peers about the change just made.
This is an ENRP announcement and is sent to all the peer of the home This is an ENRP announcement and is sent to all the peer of the home
ENRP server. See Section 3.1 on how announcements are sent. ENRP server. See Section 3.1 on how announcements are sent.
An ENRP server MUST announce the PE removal to all its peers in an An ENRP server MUST announce the PE removal to all its peers in an
ENRP_HANDLE_UPDATE message with the Update Action field set to ENRP_HANDLE_UPDATE message with the Update Action field set to
DEL_PE, indicating the removal of an existing PE. The complete DEL_PE, indicating the removal of an existing PE. The complete
information of the PE and the pool its belongs to MUST be indicated information of the PE and the pool its belongs to MUST be indicated
in the message with a PE parameter and a Pool Handle parameter, in the message with a PE parameter and a Pool Handle parameter,
respectively. respectively.
skipping to change at page 27, line 34 skipping to change at page 27, line 34
: 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 [1]. Internet algorithm described in [RFC1071].
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.
skipping to change at page 28, line 47 skipping to change at page 28, line 47
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.7. Handling Unrecognized Message or Unrecognized Parameter 3.7. 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 [8]. defined in Sections 3 and 4 in [I-D.ietf-rserpool-common-param].
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
skipping to change at page 30, line 41 skipping to change at page 30, 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 [3] MUST be applied. The "Specification Required" policy of RFC2434 [RFC2434] 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 [3] MUST be applied. The "Specification Required" policy of RFC2434 [RFC2434] MUST be
applied.
5.3. Port numbers
The references for the already assigned port numbers
enrp-udp 9901/udp
enrp-sctp 9901/sctp
enrp-sctp-tls 9902/sctp
should be updated to RFCXXXX.
5.4. SCTP payload protocol identifier
The reference for the already assigned ENRP payload protocol
identifier 12 should be updated to RFCXXXX.
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 threats. describe security requirements in response to mitigate the threats.
Next we present the security mechanisms, based on TLS, that are Next we present the security mechanisms, based on TLS, that are
implementation requirements in response to the threats. Finally, we implementation requirements in response to the threats. Finally, we
present a chain of trust argument that examines critical data paths present a chain of trust argument that examines critical data 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 [10] describes the threats to the RSerPool Response to Threats [I-D.ietf-rserpool-threats] describes the threats
architecture in detail lists the security requirements in response to to the RSerPool architecture in detail lists the security
each threat. From the threats described in this document, the requirements in response to each threat. From the threats described
security services required for the RSerPool protocol are enumerated in this document, the security services required for the RSerPool
below. protocol are enumerated 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
Threat 1 and 2 taken together results in mutual authentication of the Threat 1 and 2 taken together results in mutual authentication of the
skipping to change at page 33, line 38 skipping to change at page 33, line 38
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 We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use an existing IETF security responding to threats 1-7. Rather we use an existing IETF security
protocol, specifically [5], to provide the security services protocol, specifically [RFC3237], to provide the security services
required. TLS supports all these requirements and MUST be required. TLS supports all these requirements and MUST be
implemented. The 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. For supported at a minimum by implementors of TLS for RSerPool. For
purposes of backwards compatibility, ENRP SHOULD support purposes of backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 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. ENRP servers and PEs must ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers. authentication among themselves. PUs MUST authenticate ENRP servers.
skipping to change at page 34, line 12 skipping to change at page 34, line 12
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. 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. 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 [6] or TLS Implementations MUST support TLS with SCTP as described in [RFC3436]
over TCP as described in [7]. When using TLS/SCTP we must ensure or TLS over TCP as described in [RFC4346]. When using TLS/SCTP we
that RSerPool does not use any features of SCTP that are not must ensure that RSerPool does not use any features of SCTP that are
available to an TLS/SCTP user. This is not a difficult technical not available to an TLS/SCTP user. This is not a difficult technical
problem, but simply a requirement. 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 [9]) to the ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in
ENRP server. [I-D.ietf-rserpool-asap]) to the 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
3.5 in [9]). 3.5 in [I-D.ietf-rserpool-asap]).
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
RSerPool -- namely PU, PE and ENRP server. We define an ENRP server RSerPool -- namely PU, PE and ENRP server. We define an ENRP server
that uses TLS for all communication and authenticates ENRP peers and that uses TLS for all communication and authenticates ENRP peers and
PE registrants to be a secured ENRP server. PE registrants to be a secured ENRP server.
Here is a description of all possible data paths and a description of Here is a description of all possible data paths and a description of
skipping to change at page 36, line 8 skipping to change at page 36, line 8
RSerPool architecture components can communicate with each other to RSerPool architecture components can communicate with each other to
establish a chain of trust. Secured PE and ENRP servers reject any establish a chain of trust. Secured PE and ENRP servers reject any
communications with unsecured ENRP or PE servers. communications with unsecured ENRP or PE servers.
If the above is enforced, then a chain of trust is established for If the above is enforced, then a chain of trust is established for
the RSerPool user. the RSerPool user.
7. Acknowledgments 7. Acknowledgments
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, Frank Volkmer, and many others for their invaluable
feedback. comments and feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Braden, R., Borman, D., Partridge, C., and W. Plummer, [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071, September 1988. "Computing the Internet checksum", RFC 1071,
September 1988.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Paxson, "Stream Control Transmission Protocol", RFC 2960, Zhang, L., and V. Paxson, "Stream Control Transmission
October 2000. Protocol", RFC 2960, October 2000.
[5] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
J., and M. Stillman, "Requirements for Reliable Server Loughney, J., and M. Stillman, "Requirements for Reliable
Pooling", RFC 3237, January 2002. Server Pooling", RFC 3237, January 2002.
[6] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Security over Stream Control Transmission Protocol", RFC 3436, Layer Security over Stream Control Transmission Protocol",
December 2002. RFC 3436, December 2002.
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[8] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [I-D.ietf-rserpool-common-param]
Server Access Protocol (ASAP) and Endpoint Handlespace Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
Redundancy Protocol (ENRP) Parameters", "Aggregate Server Access Protocol (ASAP) and Endpoint
draft-ietf-rserpool-common-param-14 (work in progress), Handlespace Redundancy Protocol (ENRP) Parameters",
November 2007. draft-ietf-rserpool-common-param-16 (work in progress),
March 2008.
[9] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [I-D.ietf-rserpool-asap]
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-18 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
(work in progress), November 2007. "Aggregate Server Access Protocol (ASAP)",
draft-ietf-rserpool-asap-18 (work in progress),
November 2007.
[10] Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. [I-D.ietf-rserpool-threats]
Sengodan, "Threats Introduced by RSerPool and Requirements for Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
Security in Response to Threats", Sengodan, "Threats Introduced by RSerPool and Requirements
for Security in Response to Threats",
draft-ietf-rserpool-threats-09 (work in progress), draft-ietf-rserpool-threats-09 (work in progress),
October 2007. October 2007.
[11] Stewart, R., "Sockets API Extensions for Stream Control [I-D.ietf-tsvwg-sctpsocket]
Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-15 Stewart, R., Xie, Q., Corp, T., Poon, K., Tuexen, M., and
(work in progress), July 2007. V. Yasevich, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-16 (work in progress),
February 2008.
8.2. Informative References 8.2. Informative References
[12] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. 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
skipping to change at page 41, line 7 skipping to change at page 41, line 7
1301 E. Algonquin Road 1301 E. Algonquin Road
Room 2246 Room 2246
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Phone: +1 847-576-8747 Phone: +1 847-576-8747
Email: aron.j.silverton@motorola.com Email: aron.j.silverton@motorola.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 41, line 44 skipping to change at line 1638
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 43 change blocks. 
92 lines changed or deleted 113 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/