draft-ietf-rserpool-threats-04.txt   draft-ietf-rserpool-threats-05.txt 
Internet Engineering Task Force Maureen Stillman(editor) Internet Engineering Task Force Maureen Stillman(editor)
INTERNET DRAFT Ram Gopal INTERNET DRAFT Ram Gopal
Senthil Sengodan Senthil Sengodan
Nokia Nokia
Erik Guttman Erik Guttman
Sun Microsystems Sun Microsystems
Matt Holdrege Matt Holdrege
Strix Systems Strix Systems
04 January 2005 04 July 2005
expires July 4, 2005 expires January 4, 2006
Threats Introduced by Rserpool and Requirements for Security Threats Introduced by Rserpool and Requirements for Security
in response to Threats in response to Threats
<draft-ietf-rserpool-threats-04.txt> <draft-ietf-rserpool-threats-05.txt>
Status of This Memo Status of This Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 July 4, 2005. This Internet-Draft will expire on January 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
Rserpool is an architecture and set of protocols for the management Rserpool is an architecture and set of protocols for the management
and access to server pools supporting highly reliable applications and access to server pools supporting highly reliable applications
and for client access mechanisms to a server pool. This Internet and for client access mechanisms to a server pool. This Internet
draft describes security threats to the Rserpool architecture and draft describes security threats to the Rserpool architecture and
presents requirements for security to thwart these threats. presents requirements for security to thwart these threats.
Contents Contents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
2.9 Re-establishing PU-PE security during failover. . . . . . 6 2.9 Re-establishing PU-PE security during failover. . . . . . 6
2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6
2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6 2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6
2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7 2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7
2.13 Flood of endpoint unreachable messages . . . . . . . . . 7 2.13 Flood of endpoint unreachable messages . . . . . . . . . 7
2.14 Flood of endpoint keep alive messages . . . . . . . . . . 7 2.14 Flood of endpoint keep alive messages . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
3.1 Database security . . . . . . . . . . . . . . . . . . . . 10 3.1 Database security . . . . . . . . . . . . . . . . . . . . 10
3.2 Cookie security . . . . . . . . . . . . . . . . . . . . . 10 3.2 Cookie security . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Normative References . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Informative References. . . . . . . . . . . . . . . . . . . . . 11
7. Intellectual Property Statement . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 13 8. Intellectual Property Statement . . . . . . . . . . . . . . . . 12
9. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
RSERPOOL provides a session layer for robustness. The session layer RSERPOOL provides a session layer for robustness. The session layer
function may redirect communication transparently to upper layers. This function may redirect communication transparently to upper layers. This
alters the direct one-to-one association between communicating endpoints alters the direct one-to-one association between communicating endpoints
which typically exists between clients and servers. In particular, which typically exists between clients and servers. In particular,
secure operation of protocols often relies on assumptions at different secure operation of protocols often relies on assumptions at different
layers regarding the identity of the communicating party and the layers regarding the identity of the communicating party and the
continuity of the communication between endpoints. Further, the continuity of the communication between endpoints. Further, the
skipping to change at page 3, line 33 skipping to change at page 3, line 33
This document uses the following terms: This document uses the following terms:
ENRP Endpoint haNdlespace Redundancy Protocol: ENRP Endpoint haNdlespace Redundancy Protocol:
Within the operational scope of Rserpool, ENRP defines the Within the operational scope of Rserpool, ENRP defines the
procedures and message formats of a distributed fault-tolerant procedures and message formats of a distributed fault-tolerant
registry service for storing, bookkeeping, retrieving, and registry service for storing, bookkeeping, retrieving, and
distributing pool operation and membership information. distributing pool operation and membership information.
ASAP Aggregate Server Access Protocol: ASAP Aggregate Server Access Protocol:
A session layer protocol which uses the Endpoint haNdlespace A session layer protocol which uses the Endpoint haNdlespace
Reduncancy Protocol to provide a high availability Redundancy Protocol to provide a high availability
handlespace. ASAP is responsible for the abstraction of the handlespace. ASAP is responsible for the abstraction of the
underlying transport technologies, load distribution underlying transport technologies, load distribution
management,fault management, as well as the presentation to management,fault management, as well as the presentation to
the upper layer (i.e., the ASAP user) a unified primitive the upper layer (i.e., the ASAP user) a unified primitive
interface. interface.
Operational scope: Operational scope:
The part of the network visible to pool users by a specific The part of the network visible to pool users by a specific
instance of the reliable server pooling protocols. instance of the reliable server pooling protocols.
skipping to change at page 4, line 12 skipping to change at page 4, line 12
A cohesive structure of pool names and relations that may be A cohesive structure of pool names and relations that may be
queried by an internal or external agent. queried by an internal or external agent.
Pool element (PE): Pool element (PE):
A server entity that runs ASAP and has registered to a pool. A server entity that runs ASAP and has registered to a pool.
Pool user (PU): Pool user (PU):
A server pool user that runs ASAP. Note, a PU can also be a A server pool user that runs ASAP. Note, a PU can also be a
PE if it has registered itself to a pool. PE if it has registered itself to a pool.
ENRP handlepace server (or ENRP server): ENRP handlespace server (or ENRP server):
Entity which runs ENRP and is responsible for managing and Entity which runs ENRP and is responsible for managing and
maintaining the handlespace within the operational scope. maintaining the handlespace within the operation scope.
2. Threats 2. Threats
2.1 PE Registration/Deregistration flooding -- non-existent PE 2.1 PE Registration/Deregistration flooding -- non-existent PE
Threat: A malicious node could send a stream of false Threat: A malicious node could send a stream of false
registrations/deregistrations on behalf of non-existent PEs to ENRP registrations/deregistrations on behalf of non-existent PEs to ENRP
servers at a very rapid rate and thereby create unnecessary state in an servers at a very rapid rate and thereby create unnecessary state in an
ENRP server. ENRP server.
skipping to change at page 8, line 47 skipping to change at page 9, line 8
Threat 2.9) Re-establishing PU-PE security during failover Threat 2.9) Re-establishing PU-PE security during failover
Requirement: Either notify the application when fail over occurs so the Requirement: Either notify the application when fail over occurs so the
application can take appropriate action to establish a trusted application can take appropriate action to establish a trusted
relationship with PE B OR reestablish the security context relationship with PE B OR reestablish the security context
transparently. transparently.
Threat 2.10) Corrupted data which causes a PU to have misinformation Threat 2.10) Corrupted data which causes a PU to have misinformation
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 2.11) Eavesdropper snooping on handlespace information Threat 2.11) 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
To summarize the threats 2.1-2.12 require security mechanisms which To summarize the threats 2.1-2.12 require security mechanisms which
support authentication, integrity, data confidentiality and protection support authentication, integrity, data confidentiality and protection
from replay attacks. from replay attacks.
For Rserpool we need to authenticate the following: For Rserpool we need to authenticate the following:
skipping to change at page 11, line 9 skipping to change at page 11, line 9
A second issue is that the PE could choose to sign and/or encrypt the A second issue is that the PE could choose to sign and/or encrypt the
cookie. In this case, it must share keys and other information with cookie. In this case, it must share keys and other information with
other PEs. This application level state sharing is out of scope of other PEs. This application level state sharing is out of scope of
Rserpool. Rserpool.
4. IANA Considerations 4. IANA Considerations
This document introduces no additional considerations for IANA. This document introduces no additional considerations for IANA.
5. References 5. Normative References
Normative References:
[Rserarch] M. Tuexen, et. al., "Architecture for Reliable Server [Rserarch] M. Tuexen, et. al., "Architecture for Reliable Server
Pooling", draft-ietf-reserpool-arch-08.txt, October, 2004, work in Pooling", draft-ietf-reserpool-arch-10.txt, July, 2005, work in
progress. progress.
Informative References: 6. Informative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. RFC 2026, October 1996.
[RFC3365] RFC 3365, Strong Security Requirements for IETF Standard [RFC3365] RFC 3365, Strong Security Requirements for IETF Standard
Protocols, August, 2002. Protocols, August, 2002.
6. Acknowledgements 7. Acknowledgements
Thanks to the Rserpool security design team and others that provided Thanks to the Rserpool security design team and others that provided
valuable comments: Lyndon Ong, Randy Stewart, Melinda Shore, Qiaobing valuable comments: Lyndon Ong, Randy Stewart, Melinda Shore, Qiaobing
Xie, Michael Tuexen, Aron Silverton, Sohrab Modi, Javier Pastor-Balbas, Xie, Michael Tuexen, Aron Silverton, Sohrab Modi, Javier Pastor-Balbas,
Xingang Guo, M. Piramanayagam, Bernard Aboba and Dhooria Manoj. Xingang Guo, M. Piramanayagam, Bernard Aboba and Dhooria Manoj.
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
7. Intellectual Property Statement 7. Intellectual Property Statement
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is Copyright (C) The Internet Society (2005).
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their This document is subject to the rights, licenses and restrictions
rights. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
expires 04 July 2005 expires 04 January 2006
8. Author's Addresses 8. Author's Addresses
Ram Gopal Ram Gopal
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803 Burlington, MA 01803
USA USA
email: ram.gopal@nokia.com email: ram.gopal@nokia.com
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/