draft-ietf-rserpool-asap-14.txt   draft-ietf-rserpool-asap-15.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational Q. Xie Intended status: Experimental Q. Xie
Expires: April 21, 2007 Motorola, Inc. Expires: July 8, 2007 Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
October 18, 2006 January 4, 2007
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-14.txt draft-ietf-rserpool-asap-15.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 39 skipping to change at page 1, line 39
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 April 21, 2007. This Internet-Draft will expire on July 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Handlespace Redundancy Protocol (ENRP) [8] provides a high Endpoint Handlespace Redundancy Protocol (ENRP) [8] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
handle-based addressing model which isolates a logical communication handle-based addressing model which isolates a logical communication
endpoint from its IP address(es), thus effectively eliminating the endpoint from its IP address(es), thus effectively eliminating the
binding between the communication endpoint and its physical IP binding between the communication endpoint and its physical IP
address(es) which normally constitutes a single point of failure. address(es) which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as a In addition, ASAP defines each logical communication destination as a
pool, providing full transparent support for server-pooling and load pool, providing full transparent support for server-pooling and load
sharing. It also allows dynamic system scalability - members of a sharing. It also allows dynamic system scalability - members of a
server pool can be added or removed at any time without interrupting server pool can be added or removed at any time without interrupting
the service. the service.
ASAP is designed to take full advantage of the network level ASAP is designed to take full advantage of the network level
redundancy provided by the Stream Transmission Control Protocol redundancy provided by the Stream Transmission Control Protocol
(SCTP) RFC2960 [4]. Each transport protocol to be used by Pool (SCTP) RFC2960 [4]. Each transport protocol, other than SCTP, MUST
Elements (PE) and Pool Users (PU) MUST have an accompanying have an accompanying transport mapping document. It should be noted
transports mapping document. It should be noted that ASAP messages that ASAP messages passed between PE's and ENRP servers MUST use the
passed between PE's and ENRP servers MUST use the SCTP transport SCTP transport protocol.
protocol.
The high availability server pooling is gained by combining two The high availability server pooling is gained by combining two
protocols, namely ASAP and ENRP, in which ASAP provides the user protocols, namely ASAP and ENRP, in which ASAP provides the user
interface for pool handle to address translation, load sharing interface for pool handle to address translation, load sharing
management, and fault management while ENRP defines the high management, and fault management while ENRP defines the high
availability pool handle translation service. availability pool handle translation service.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 6, line 47 skipping to change at page 6, line 47
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order: Most significant byte first, a.k.a Big Endian.
Transport address: A Transport Address is traditionally defined by Transport address: A Transport Address is traditionally defined by
Network Layer address, Transport Layer protocol and Transport Network Layer address, Transport Layer protocol and Transport
Layer port number. In the case of SCTP running over IP, a Layer port number. In the case of SCTP running over IP, a
transport address is defined by the combination of an IP address transport address is defined by the combination of an IP address
and an SCTP port number (where SCTP is the Transport protocol). and an SCTP port number (where SCTP is the Transport protocol).
1.2. Organization of this document 1.2. Organization of this document
Section 2 details the ASAP message formats. Section 3 details the Section 2 details the ASAP message formats. In Section 3 we provide
ASAP procedures for an ASAP implementor. Section 4 illustrate detailed ASAP procedures for for the ASAP implementer. In Section 4
details of the ASAP interface, focusing on the communication we give details of the ASAP interface, focusing on the communication
primitives employed between ASAP itself and the applications that primitives between ASAP the applications above ASAP and ASAP itself,
leverage ASAP, and the communications primitives between ASAP and and the communications primitives between ASAP and SCTP (or other
SCTP (or another transport layer). Also included in this discussion transport layers). Also included in this discussion are relevant
are relevant timers and configurable parameters as appropriate. timers and configurable parameters as appropriate. Section 5
Section 5 provides threshold and protocol variables. provides threshold and protocol variables.
1.3. Scope of ASAP 1.3. Scope of ASAP
The requirements for high availability and scalability do not imply The requirements for high availability and scalability do not imply
requirements on shared state and data. ASAP does not provide requirements on shared state and data. ASAP does not provide
transaction failover. If a host or application fails during the transaction failover. If a host or application fails during the
processing of a transaction, this transaction may be lost. Some processing of a transaction, this transaction may be lost. Some
services MAY provide a way to handle the failure, but this is not services MAY provide a way to handle the failure, but this is not
guaranteed. ASAP MAY provide hooks to assist an application in guaranteed. ASAP MAY provide hooks to assist an application in
building a mechanism to share state but ASAP in itself will NOT share building a mechanism to share state but ASAP in itself does NOT share
any state. any state.
1.3.1. Extent of the Handlespace 1.3.1. Extent of the Handlespace
The scope of ASAP/ENRP is NOT Internet wide. The handlespace is The scope of ASAP/ENRP is NOT Internet wide. The handlespace is
neither hierarchical nor arbitrarily large like DNS. A flat peer-to- neither hierarchical nor arbitrarily large like DNS. A flat peer-to-
peer model is detailed. Pools of servers will exist in different peer model is detailed. Pools of servers will exist in different
administrative domains. For example, suppose the use of ASAP and administrative domains. For example, suppose the use of ASAP and
ENRP is wanted. First, the PU may use DNS to contact an ENRP server. ENRP is wanted. First, the PU may use DNS to contact an ENRP server.
Suppose a PU in North America wishes to contact a server pool in Suppose a PU in North America wishes to contact a server pool in
skipping to change at page 42, line 50 skipping to change at page 42, line 50
concerning a pool handle resolution concerning a pool handle resolution
----------- -----------
Security mechanism in response: Security protocol which supports Security mechanism in response: Security protocol which supports
integrity protection integrity protection
Threat 7) Eavesdropper snooping on handlespace information Threat 7) Eavesdropper snooping on handlespace information
----------- -----------
Security mechanism in response: Security protocol which supports data Security mechanism in response: Security protocol which supports data
confidentiality confidentiality
Threat 8) Flood of ASAP Endpoint_Unreachable messages from the PU to Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to
ENRP server ENRP server
----------- -----------
Security mechanism in response: ASAP must control the number of ASAP Security mechanism in response: ASAP must control the number of ASAP
endpoint unreachable messages transmitted from the PU to the ENRP endpoint unreachable messages transmitted from the PU to the ENRP
server. server.
Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
the ENRP server the ENRP server
----------- -----------
Security mechanism in response: ENRP server must control the number Security mechanism in response: ENRP server must control the number
of ASAP_ENDPOINT_KEEP_AlIVE messages to the PE of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE
To summarize the threats 1-7 require security mechanisms which To summarize the threats 1-7 require security mechanisms which
support authentication, integrity, data confidentiality, protection support authentication, integrity, data confidentiality, protection
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)
skipping to change at page 43, line 34 skipping to change at page 43, line 34
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 existing IETF security responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports protocols to provide the security services required. TLS supports
all these requirements and MUST be implemented. The all these requirements and MUST be implemented. The
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum by implementors of TLS for Rserpool. For purposes of minimum by implementors of TLS for Rserpool. For purposes of
backwards compatibility, ENRP SHOULD support backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementors MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementors MAY also support any
other ciphersuite. other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of ASAP Threat 8 requires the ASAP protocol to limit the number of
Endpoint_Unreachable messages (see Section 3.5) to the ENRP server. ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5) 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 to the PE (see section x.y??? in ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see
[8]). Section 3.7 in [8]).
6.1. Chain of trust 6.1. 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. Rserpool -- namely PU, PE and ENRP server. We define an ENRP server
that uses TLS for all communication and authenticates ENRP peers and
PE registrants to be a secured ENRP server.
Here is a description of all possible data paths and a description of Here is a description of all possible data paths and a description of
the security. the security.
PU <---> ENRP Server (authentication of ENRP server; queries over PU <---> secured ENRP Server (authentication of ENRP server;
TLS) queries over TLS)
PE <----> ENRP servers (mutual authentication; registration/ PE <---> secured ENRP server (mutual authentication;
deregistration over TLS) registration/deregistration over TLS)
secured ENRP <---> secured ENRP server (mutual authentication;
ENRP <----> ENRP servers (mutual authentication; database updates database updates using TLS)
using TLS)
If all components of the system are secured and authenticated, the If all components of the system authenticate and communicate using
chain of trust is sound. The root of the trust chain is the ENRP TLS, the chain of trust is sound. The root of the trust chain is the
server. If that is secured, then security will be enforced for all ENRP server. If that is secured using TLS, then security will be
components that try to connect to it. enforced for all ENRP and PE components that try to connect to it.
Summary of interaction between secured and unsecured components: If Summary of interaction between secured and unsecured components: If
the PE is not secure and tries to register with a secure ENRP server, the PE does not use TLS and tries to register with a secure ENRP
the registration will be rejected. If an insecure ENRP server tries server, it will receive an error message response indicated as error
to update the database of an ENRP server, then the update will be due to security considerations and the registration will be rejected.
rejected. If an insecure PU communicates with an ENRP server, it If an ENRP server which does not use TLS tries to update the database
will get a response with the understanding that the response is not of a secure ENRP server, then the update will be rejected. If an PU
secured. does not use TLS and communicates with a secure ENRP server, it will
get a response with the understanding that the response is not secure
as the response can be tampered with in transit even if the ENRP
database is secured.
**** The final case is the PU sending a secured request to ENRP. It The final case is the PU sending a secure request to ENRP. It might
might be that ENRP and PEs are not secured and that is OK. The be that ENRP and PEs are not secured and this is an allowable
intent may be to secure the communication over the internet. **** configuration. The intent is to secure the communication over the
Internet between the PU and the ENRP server.
Summary: Summary:
Unsecured architecture components can all communicate with each other Rserpool architecture components can communicate with each other to
thus establishing a chain of trust. Secured PE and ENRP components establish a chain of trust. Secured PE and ENRP servers reject any
reject any communications with unsecured ENRP and PE components. 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.
6.2. Implementing Security Mechanisms 6.2. Implementing Security Mechanisms
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 47, line 32 skipping to change at page 47, line 32
[5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer [5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436, Security over Stream Control Transmission Protocol", RFC 3436,
December 2002. December 2002.
[6] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies", [6] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies",
draft-ietf-rserpool-policies-03 (work in progress), draft-ietf-rserpool-policies-03 (work in progress),
September 2006. September 2006.
[7] Stewart, R., "Aggregate Server Access Protocol (ASAP) and [7] Stewart, R., "Aggregate Server Access Protocol (ASAP) and
Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", Endpoint Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-10 (work in progress), draft-ietf-rserpool-common-param-11 (work in progress),
February 2006. October 2006.
[8] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", [8] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)",
draft-ietf-rserpool-enrp-13 (work in progress), February 2006. draft-ietf-rserpool-enrp-14 (work in progress), November 2006.
[9] Stillman, M., "Threats Introduced by Rserpool and Requirements [9] Stillman, M., "Threats Introduced by Rserpool and Requirements
for Security in response to Threats", for Security in response to Threats",
draft-ietf-rserpool-threats-05 (work in progress), July 2005. draft-ietf-rserpool-threats-06 (work in progress),
November 2006.
8.2. Informational References (non-normative) 8.2. Informational References (non-normative)
[10] Eastlake, D., Crocker, S., and J. Schiller, "Randomness [10] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 49, line 7 skipping to change at page 49, line 7
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 22 change blocks. 
55 lines changed or deleted 61 lines changed or added

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