draft-ietf-rserpool-threats-10.txt   draft-ietf-rserpool-threats-11.txt 
Network Working Group M. Stillman, Ed. Network Working Group M. Stillman, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Informational R. Gopal Intended status: Informational R. Gopal
Expires: October 24, 2008 Nokia Research Center Expires: October 27, 2008 Nokia Siemens Networks
E. Guttman E. Guttman
Sun Microsystems Sun Microsystems
M. Holdrege M. Holdrege
Strix Systems Strix Systems
S. Sengodan S. Sengodan
Nokia Research Center Nokia Siemans Networks
April 22, 2008 April 25, 2008
Threats Introduced by RSerPool and Requirements for Security in Response Threats Introduced by RSerPool and Requirements for Security in
to Threats Response to Threats
draft-ietf-rserpool-threats-10.txt draft-ietf-rserpool-threats-11.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 42 skipping to change at page 1, line 42
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 October 24, 2008. This Internet-Draft will expire on October 27, 2008.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. PE Registration/Deregistration flooding -- 2.1. PE Registration/Deregistration flooding --
non-existent PE . . . . . . . . . . . . . . . . . . . . . 4 non-existent PE . . . . . . . . . . . . . . . . . . . . . 4
2.2. PE Registration/Deregistration flooding -- 2.2. PE Registration/Deregistration flooding --
unauthorized PE . . . . . . . . . . . . . . . . . . . . . 5 unauthorized PE . . . . . . . . . . . . . . . . . . . . . 5
2.3. PE Registration/Deregistration spoofing . . . . . . . . . 5 2.3. PE Registration/Deregistration spoofing . . . . . . . . . 5
2.4. PE Registration/Deregistration unauthorized . . . . . . . 6 2.4. PE Registration/Deregistration unauthorized . . . . . . . 6
2.5. Malicious ENRP server joins the group of legitimate 2.5. Malicious ENRP server joins the group of legitimate
ENRP servers . . . . . . . . . . . . . . . . . . . . . . . 6 ENRP servers . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Registration/deregistration with malicious ENRP server . . 7 2.6. Registration/deregistration with malicious ENRP server . . 7
2.7. Malicious ENRP Handlespace Resolution . . . . . . . . . . 7 2.7. Malicious ENRP Handlespace Resolution . . . . . . . . . . 7
2.8. Malicious node performs a replay attack . . . . . . . . . 7 2.8. Malicious node performs a replay attack . . . . . . . . . 7
2.9. Re-establishing PU-PE security during failover . . . . . . 8 2.9. Re-establishing PU-PE security during failover . . . . . . 8
2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 8 2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 8
2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 9 2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 9
2.12. ENRP Server Discovery . . . . . . . . . . . . . . . . . . 9 2.12. ENRP Server Discovery . . . . . . . . . . . . . . . . . . 9
2.13. Flood of endpoint unreachable messages from the PU to 2.13. Flood of endpoint unreachable messages from the PU to
the ENRP server . . . . . . . . . . . . . . . . . . . . . 10 the ENRP server . . . . . . . . . . . . . . . . . . . . . 10
2.14. Flood of endpoint keep alive messages from the ENRP 2.14. Flood of endpoint keep alive messages from the ENRP
server to a PE . . . . . . . . . . . . . . . . . . . . . . 11 server to a PE . . . . . . . . . . . . . . . . . . . . . . 11
2.15. Security of the ENRP Database . . . . . . . . . . . . . . 11 2.15. Security of the ENRP database . . . . . . . . . . . . . . 11
2.16. Cookie mechanism security . . . . . . . . . . . . . . . . 12 2.16. Cookie mechanism security . . . . . . . . . . . . . . . . 12
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Normative References . . . . . . . . . . . . . . . . . . . . . 14 5. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
RSerPool provides a session layer for robustness. The session layer RSerPool [I-D.ietf-rserpool-overview] provides a session layer for
function may redirect communication transparently to upper layers. robustness. The session layer function may redirect communication
This alters the direct one-to-one association between communicating transparently to upper layers. This alters the direct one-to-one
endpoints which typically exists between clients and servers. In association between communicating endpoints which typically exists
particular, secure operation of protocols often relies on assumptions between clients and servers. In particular, secure operation of
at different layers regarding the identity of the communicating party protocols often relies on assumptions at different layers regarding
and the continuity of the communication between endpoints. Further, the identity of the communicating party and the continuity of the
the operation of RSerPool itself has security implications and risks. communication between endpoints. Further, the operation of RSerPool
The session layer operates dynamically which imposes additional itself has security implications and risks. The session layer
concerns for the overall security of the end-to-end application. operates dynamically which imposes additional concerns for the
overall security of the end-to-end application.
The RSerPool architecture supports high-availability and load The RSerPool architecture supports high-availability and load
balancing by enabling a pool user to identify the most appropriate balancing by enabling a pool user to identify the most appropriate
server from the server pool at a given time. The architecture is server from the server pool at a given time. The architecture is
defined to support a set of basic goals. These include an defined to support a set of basic goals. These include an
application-independent protocol mechanisms, separation of server application-independent protocol mechanisms, separation of server
naming from IP addressing, the use of the end-to-end principle to naming from IP addressing, the use of the end-to-end principle to
avoid dependencies on intermediate equipment, separation of session avoid dependencies on intermediate equipment, separation of session
availability/failover functionality from application itself, the availability/failover functionality from application itself, the
ability to facilitate different server selection policies, the ability to facilitate different server selection policies, the
skipping to change at page 3, line 39 skipping to change at page 3, line 40
This document explores the security implications of RSerPool, both This document explores the security implications of RSerPool, both
due to its own functions and due to its being interposed between due to its own functions and due to its being interposed between
applications and transport interfaces. applications and transport interfaces.
1.1. Definitions 1.1. Definitions
This document uses the following terms: This document uses the following terms:
Endpoint Name Resolution Protocol (ENRP): Endpoint Name Resolution Protocol (ENRP):
Within the operational scope of Rserpool, ENRP defines the Within the operational scope of Rserpool, ENRP
procedures and message formats of a distributed fault-tolerant [I-D.ietf-rserpool-enrp] defines the procedures and message
registry service for storing, bookkeeping, retrieving, and formats of a distributed fault-tolerant registry service for
distributing pool operation and membership information. storing, bookkeeping, retrieving, and distributing pool operation
and membership information.
Aggregate Server Access Protocol (ASAP): Aggregate Server Access Protocol (ASAP):
A session layer protocol which uses ENRP to provide a high ASAP [I-D.ietf-rserpool-asap] is a session layer protocol which
availability handlespace. ASAP is responsible for the abstraction uses ENRP to provide a high availability handlespace. ASAP is
of the underlying transport technologies, load distribution responsible for the abstraction of the underlying transport
management,fault management, as well as the presentation to the technologies, load distribution management,fault management, as
upper layer (i.e., the ASAP user) a unified primitive interface. well as the presentation to the upper layer (i.e., the ASAP user)
a unified primitive 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.
Pool (or server pool): Pool (or server pool):
A collection of servers providing the same application A collection of servers providing the same application
functionality. functionality.
Pool handle: Pool handle:
skipping to change at page 4, line 26 skipping to change at page 4, line 26
pool handle. pool handle.
ENRP handlespace (or handlespace): ENRP handlespace (or handlespace):
A cohesive structure of pool names and relations that may be A cohesive structure of pool names and relations that may be
queried by a client. queried by a client.
Pool element (PE): A server entity having registered to a pool. Pool element (PE): A server entity having registered to a pool.
Pool user (PU): A server pool user. Pool user (PU): A server pool user.
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Threats 2. Threats
2.1. PE Registration/Deregistration flooding -- non-existent PE 2.1. PE Registration/Deregistration flooding -- non-existent PE
2.1.1. Threat 2.1.1. Threat
A malicious node could send a stream of false registrations/ A malicious node could send a stream of false registrations/
deregistrations on behalf of non-existent PEs to ENRP servers at a deregistrations on behalf of non-existent PEs to ENRP servers at a
very rapid rate and thereby create unnecessary state in an ENRP very rapid rate and thereby create unnecessary state in an ENRP
server. server.
skipping to change at page 10, line 35 skipping to change at page 10, line 35
ENRP servers. ENRP servers.
c. This malicious ENRP would either misrepresent, ignore or c. This malicious ENRP would either misrepresent, ignore or
otherwise hide or distort information about the PE to subvert otherwise hide or distort information about the PE to subvert
RSerPool operation. RSerPool operation.
d. Same as above. d. Same as above.
2.12.3. Requirement 2.12.3. Requirement
A provision for data confidentiality service SHOULD be present. A provision for authentication MUST be present and a provision for
data confidentiality service SHOULD be present.
2.13. Flood of endpoint unreachable messages from the PU to the ENRP 2.13. Flood of endpoint unreachable messages from the PU to the ENRP
server server
2.13.1. Threat 2.13.1. Threat
Endpoint unreachable messages are sent by ASAP to the ENRP server Endpoint unreachable messages are sent by ASAP to the ENRP server
when it is unable to contact a PE. There is the potential that a PU when it is unable to contact a PE. There is the potential that a PU
could flood the ENRP server intentionally or unintentionally with could flood the ENRP server intentionally or unintentionally with
these messages. The non-malicious case would require an incorrect these messages. The non-malicious case would require an incorrect
skipping to change at page 11, line 33 skipping to change at page 11, line 38
If the ENRP server maliciously sent a flood of endpoint keep alive If the ENRP server maliciously sent a flood of endpoint keep alive
messages to the PE, the PE would not be able to service clients. The messages to the PE, the PE would not be able to service clients. The
result is an unintentional DOS attack on the PE. result is an unintentional DOS attack on the PE.
2.14.3. Requirement 2.14.3. Requirement
ENRP SHOULD limit the frequency of keep alive messages to a given PE ENRP SHOULD limit the frequency of keep alive messages to a given PE
to prevent overwhelming the PE. to prevent overwhelming the PE.
2.15. Security of the ENRP Database 2.15. Security of the ENRP database
2.15.1. Threat
Another consideration involves the security characteristics of the Another consideration involves the security characteristics of the
ENRP database. Suppose that some of the PEs register with an ENRP ENRP database. Suppose that some of the PEs register with an ENRP
server using security and some do not. In this case, when a client server using security and some do not. In this case, when a client
requests handle space resolution information from ENRP, it would have requests handle space resolution information from ENRP, it would have
to be informed which entries are "secure" and which are not. This to be informed which entries are "secure" and which are not.
would not only complicate the protocol, but actually bring into
2.15.2. Effect
This would not only complicate the protocol, but actually bring into
question the security and integrity of such a database. What can be question the security and integrity of such a database. What can be
asserted about the security of such a database is a very thorny asserted about the security of such a database is a very thorny
question. Due to these two facts it was decided that either the question.
entire ENRP server database is secure, that is, it has registrations
exclusively from PEs that have used security mechanisms or the entire 2.15.3. Requirement
database is insecure, that is, registrations are from PEs that have
used no security mechanisms. ENRP servers that support security are The requirement is that either the entire ENRP server database MUST
required to reject any PE server registration that does not use the be secure, that is, it has registrations exclusively from PEs that
security mechanisms. Likewise, ENRP servers that support security have used security mechanisms or the entire database MUST be
should not accept updates from other ENRP servers that do not use insecure, that is, registrations are from PEs that have used no
security mechanisms. security mechanisms. ENRP servers that support security MUST reject
any PE server registration that does not use the security mechanisms.
Likewise, ENRP servers that support security MUST NOT accept updates
from other ENRP servers that do not use security mechanisms.
2.16. Cookie mechanism security 2.16. Cookie mechanism security
The application layer is out of scope for RSerPool. However, some The application layer is out of scope for RSerPool. However, some
questions have been raised about the security of the cookie mechanism questions have been raised about the security of the cookie mechanism
which will be addressed. which will be addressed.
Cookies are passed via the ASAP control channel. If TCP is selected Cookies are passed via the ASAP control channel. If TCP is selected
as the transport, the data and control channel must always be as the transport, then the data and control channel MUST be
multiplexed. Therefore, the cases: multiplexed. Therefore, the cases:
a. control channel is secured; data channel is not a. control channel is secured; data channel is not
b. data channel is secured; control channel is not b. data channel is secured; control channel is not
are not allowed. It is even hard to understand what this really are not possible as the multiplexing onto one TCP port results in
means from a security point of view. security for both data and control channels or neither.
The multiplexing requirement results in the following cases: The multiplexing requirement results in the following cases:
1. the multiplexed control channel-data channel is secure OR 1. the multiplexed control channel-data channel is secure OR
2. the multiplexed control channel-data channel is not secured 2. the multiplexed control channel-data channel is not secured
This applies to cookies in the sense that if you choose to secure This applies to cookies in the sense that if you choose to secure
your control-data channel, then the cookies are secured. your control-data channel, then the cookies are secured.
skipping to change at page 15, line 5 skipping to change at page 15, line 9
"Aggregate Server Access Protocol (ASAP)", "Aggregate Server Access Protocol (ASAP)",
draft-ietf-rserpool-asap-19 (work in progress), draft-ietf-rserpool-asap-19 (work in progress),
March 2008. March 2008.
[I-D.ietf-rserpool-enrp] [I-D.ietf-rserpool-enrp]
Kim, D., Stewart, R., Stillman, M., Tuexen, M., and A. Kim, D., Stewart, R., Stillman, M., Tuexen, M., and A.
Silverton, "Endpoint Handlespace Redundancy Protocol Silverton, "Endpoint Handlespace Redundancy Protocol
(ENRP)", draft-ietf-rserpool-enrp-19 (work in progress), (ENRP)", draft-ietf-rserpool-enrp-19 (work in progress),
March 2008. March 2008.
[I-D.ietf-rserpool-overview]
Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An
Overview of Reliable Server Pooling Protocols",
draft-ietf-rserpool-overview-05 (work in progress),
February 2008.
Authors' Addresses Authors' Addresses
Maureen Stillman (editor) Maureen Stillman (editor)
Nokia Nokia
35 Woodcrest Avenue 35 Woodcrest Avenue
Ithaca, NY 14850 Ithaca, NY 14850
US US
Email: maureen.stillman@nokia.com Email: maureen.stillman@nokia.com
Ram Gopal Ram Gopal
Nokia Research Center Nokia Siemens Networks
5 Wayside Road 12278 Scripps Summit Drive
Burlington, MA 01803 San Diego, CA 92131
US US
Email: ram.gopal@nokia.com Email: ram.gopal@nsn.com
Erik Guttman Erik Guttman
Sun Microsystems Sun Microsystems
Eichhoelzelstrasse 7 Eichhoelzelstrasse 7
74915 Waibstadt 74915 Waibstadt
DE DE
Email: Erik.Guttman@sun.com Email: Erik.Guttman@sun.com
Matt Holdrege Matt Holdrege
Strix Systems Strix Systems
26610 Agoura Road 26610 Agoura Road
Suite 110 Suite 110
Calabasas, CA 91302 Calabasas, CA 91302
US US
Email: matt@strixsystems.com Email: matt@strixsystems.com
Senthil Sengodan Senthil Sengodan
skipping to change at page 15, line 41 skipping to change at page 16, line 14
Matt Holdrege Matt Holdrege
Strix Systems Strix Systems
26610 Agoura Road 26610 Agoura Road
Suite 110 Suite 110
Calabasas, CA 91302 Calabasas, CA 91302
US US
Email: matt@strixsystems.com Email: matt@strixsystems.com
Senthil Sengodan Senthil Sengodan
Nokia Research Center Nokia Siemans Networks
5 Wayside Road 6000 Connection Drive
Burlington, MA 01803 Irving, TX 75039
US US
Email: Senthil.sengodan@nokia.com Email: Senthil.sengodan@nsn.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). 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
 End of changes. 24 change blocks. 
55 lines changed or deleted 79 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/