draft-ietf-rserpool-asap-18.txt   draft-ietf-rserpool-asap-19.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Experimental Q. Xie Intended status: Experimental Q. Xie
Expires: May 22, 2008 Motorola, Inc. Expires: September 29, 2008 Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
November 19, 2007 March 28, 2008
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-18.txt draft-ietf-rserpool-asap-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 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 May 22, 2008. This Internet-Draft will expire on September 29, 2008.
Copyright Notice
Copyright (C) The IETF Trust (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) Endpoint Handlespace Redundancy Protocol (ENRP)
[I-D.ietf-rserpool-enrp] provides a high availability data transfer [I-D.ietf-rserpool-enrp] provides a high availability data transfer
mechanism over IP networks. ASAP uses a handle-based addressing mechanism over IP networks. ASAP uses a handle-based addressing
model which isolates a logical communication endpoint from its IP model which isolates a logical communication endpoint from its IP
address(es), thus effectively eliminating the binding between the address(es), thus effectively eliminating the binding between the
communication endpoint and its physical IP address(es) which normally communication endpoint and its physical IP address(es) which normally
skipping to change at page 4, line 22 skipping to change at page 4, line 22
6.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 43 6.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 43
6.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 43 6.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 43
6.9.1. Translation.Request Primitive . . . . . . . . . . . . 43 6.9.1. Translation.Request Primitive . . . . . . . . . . . . 43
6.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 44 6.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 44
7. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 45 7. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 45
7.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 45 7.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 45 7.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 45
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
8.1. A New Table for ASAP Message Types . . . . . . . . . . . . 47 8.1. A New Table for ASAP Message Types . . . . . . . . . . . . 47
8.2. Multicast addresses . . . . . . . . . . . . . . . . . . . 47 8.2. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 47
9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 8.3. SCTP payload protocol identifier . . . . . . . . . . . . . 48
9.1. Summary of Rserpool Security Threats . . . . . . . . . . . 48 8.4. Multicast addresses . . . . . . . . . . . . . . . . . . . 48
9.2. Implementing Security Mechanisms . . . . . . . . . . . . . 49 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 50 9.1. Summary of Rserpool Security Threats . . . . . . . . . . . 49
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 9.2. Implementing Security Mechanisms . . . . . . . . . . . . . 50
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 51
11.1. Normative References . . . . . . . . . . . . . . . . . . . 53 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
11.2. Informative References . . . . . . . . . . . . . . . . . . 54 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 11.1. Normative References . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 56 11.2. Informative References . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 57
1. Introduction 1. Introduction
The Aggregate Server Access Protocol (ASAP) when used in conjunction The Aggregate Server Access Protocol (ASAP) when used in conjunction
with Endpoint Name Resolution Protocol [I-D.ietf-rserpool-enrp] with Endpoint Name Resolution Protocol [I-D.ietf-rserpool-enrp]
provides a high availability data transfer mechanism over IP provides a high availability data transfer mechanism over IP
networks. ASAP uses a handle-based addressing model which isolates a networks. ASAP uses a handle-based addressing model which isolates a
logical communication endpoint from its IP address(es), thus logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication effectively eliminating the binding between the communication
endpoint and its physical IP address(es) which normally constitutes a endpoint and its physical IP address(es) which normally constitutes a
skipping to change at page 25, line 36 skipping to change at page 25, line 36
ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU.
In the response message, the ENRP server SHOULD list all the PEs In the response message, the ENRP server SHOULD list all the PEs
currently registered in this pool, in a list of PE parameters. The currently registered in this pool, in a list of PE parameters. The
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 Pool
Handle error. Handle error.
3.4. Endpoint keep alive 3.4. Endpoint keep alive
The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a
PE in order to verify it is reachable. If the transport level heart PE in order to verify it is reachable. If the transport level heart
beat mechanism is insufficient, this message can be used in a heart beat mechanism is insufficient, this message can be used in a heart
beat mechanism for the ASAP level whose goal is determining the beat mechanism for the ASAP level whose goal is determining the
health status of the ASAP level in a timely fashion. (The transport health status of the ASAP level in a timely fashion. (The transport
level heart beat mechanism may be insufficient due to either the time level heart beat mechanism may be insufficient due to either the time
skipping to change at page 47, line 47 skipping to change at page 47, line 47
0x0b ASAP_COOKIE RFCXXXX 0x0b ASAP_COOKIE RFCXXXX
0x0c ASAP_COOKIE_ECHO RFCXXXX 0x0c ASAP_COOKIE_ECHO RFCXXXX
0x0d ASAP_BUSINESS_CARD RFCXXXX 0x0d ASAP_BUSINESS_CARD RFCXXXX
0x0e ASAP_ERROR RFCXXXX 0x0e ASAP_ERROR RFCXXXX
0x0b-0xff (reserved by IETF) RFCXXXX 0x0b-0xff (reserved by IETF) RFCXXXX
For registering at IANA an ASAP Message Type in this table a request For registering at IANA an ASAP 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] MUST be applied. The "Specification Required" policy of [RFC2434] MUST be applied.
8.2. Multicast addresses 8.2. Port numbers
IANA needs to assign an IPv4 and an IPv6 mulitcast address. The references for the already assigned port numbers
asap-tcp 3863/tcp
asap-udp 3863/udp
asap-sctp 3863/sctp
asap-tcp-tls 3864/tcp
asap-sctp-tls 3864/sctp
should be updated to RFCXXXX.
8.3. SCTP payload protocol identifier
The reference for the already assigned ASAP payload protocol
identifier 11 should be updated to RFCXXXX.
8.4. Multicast addresses
IANA needs to assign an IPv4 and an IPv6 mulitcast address. The IPv4
address should be part of the Internetwork Control Block
(224.0.1/24).
9. Security Considerations 9. Security Considerations
We present a summary of the of the threats to the Rserpool We present a summary of the of the threats to the Rserpool
architecture and describe security requirements in response to architecture and describe security requirements in response to
mitigate the threats. Next we present the security mechanisms, based mitigate the threats. Next we present the security mechanisms, based
on TLS, that are implementation requirements in response to the on TLS, that are implementation requirements in response to the
threats. Finally, we present a chain of trust argument that examines threats. Finally, we present a chain of trust argument that examines
critical data paths in Rserpool and shows how these paths are critical data paths in Rserpool and shows how these paths are
protected by the TLS implementation. protected by the TLS implementation.
skipping to change at page 50, line 28 skipping to change at page 51, line 28
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 this document) ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document)
to the ENRP server. 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
[I-D.ietf-rserpool-enrp]). [I-D.ietf-rserpool-enrp]).
There is no security mechanism defined for the multicast
announcements. Therefore a receiver of such an announcement can not
consider the source address of such a message to be a trustworthy
address of an ENRP server. A receiver must also be prepared to
receive a large number of multicast announcements from attackers.
9.3. Chain of trust 9.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
the security. the security.
skipping to change at page 53, line 32 skipping to change at page 54, line 32
RFC 3436, December 2002. RFC 3436, December 2002.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[I-D.ietf-rserpool-policies] [I-D.ietf-rserpool-policies]
Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Tuexen, M. and T. Dreibholz, "Reliable Server Pooling
Policies", draft-ietf-rserpool-policies-07 (work in Policies", draft-ietf-rserpool-policies-08 (work in
progress), November 2007. progress), March 2008.
[I-D.ietf-rserpool-common-param] [I-D.ietf-rserpool-common-param]
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
"Aggregate Server Access Protocol (ASAP) and Endpoint "Aggregate Server Access Protocol (ASAP) and Endpoint
Handlespace Redundancy Protocol (ENRP) Parameters", Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-14 (work in progress), draft-ietf-rserpool-common-param-16 (work in progress),
November 2007. March 2008.
[I-D.ietf-rserpool-enrp] [I-D.ietf-rserpool-enrp]
Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.
Silverton, "Endpoint Handlespace Redundancy Protocol Silverton, "Endpoint Handlespace Redundancy Protocol
(ENRP)", draft-ietf-rserpool-enrp-17 (work in progress), (ENRP)", draft-ietf-rserpool-enrp-18 (work in progress),
September 2007. November 2007.
[I-D.ietf-rserpool-threats] [I-D.ietf-rserpool-threats]
Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
Sengodan, "Threats Introduced by RSerPool and Requirements Sengodan, "Threats Introduced by RSerPool and Requirements
for Security in Response to Threats", 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.2. Informative References 11.2. Informative References
skipping to change at page 56, line 7 skipping to change at page 57, 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 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 56, line 44 skipping to change at line 2320
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. 14 change blocks. 
29 lines changed or deleted 55 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/