draft-ietf-rserpool-threats-14.txt   draft-ietf-rserpool-threats-15.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: December 25, 2008 Nokia Siemens Networks Expires: January 9, 2009 Nokia Siemens Networks
E. Guttman E. Guttman
Sun Microsystems Sun Microsystems
M. Holdrege M. Holdrege
Strix Systems Strix Systems
S. Sengodan S. Sengodan
Nokia Siemans Networks Nokia Siemans Networks
June 23, 2008 July 8, 2008
Threats Introduced by RSerPool and Requirements for Security in Response Threats Introduced by RSerPool and Requirements for Security in Response
to Threats to Threats
draft-ietf-rserpool-threats-14.txt draft-ietf-rserpool-threats-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 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 December 25, 2008. This Internet-Draft will expire on January 9, 2009.
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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . . 6 2.3. PE Registration/Deregistration spoofing . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . 7 ENRP servers . . . . . . . . . . . . . . . . . . . . . . . 7
2.6. Registration/deregistration with malicious ENRP server . . 7 2.6. Registration/deregistration with malicious ENRP server . . 7
2.7. Malicious ENRP Handlespace Resolution . . . . . . . . . . 8 2.7. Malicious ENRP Handlespace Resolution . . . . . . . . . . 8
2.8. Malicious node performs a replay attack . . . . . . . . . 8 2.8. Malicious node performs a replay attack . . . . . . . . . 9
2.9. Re-establishing PU-PE security during failover . . . . . . 9 2.9. Re-establishing PU-PE security during failover . . . . . . 9
2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9 2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9
2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 10 2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 10
2.12. ENRP Server Discovery . . . . . . . . . . . . . . . . . . 11 2.12. ENRP Server Discovery . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . 12 the ENRP server . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . 12 server to a PE . . . . . . . . . . . . . . . . . . . . . . 12
2.15. Security of the ENRP database . . . . . . . . . . . . . . 13 2.15. Security of the ENRP database . . . . . . . . . . . . . . 13
2.16. Cookie mechanism security . . . . . . . . . . . . . . . . 13 2.16. Cookie mechanism security . . . . . . . . . . . . . . . . 13
3. Security Considerations . . . . . . . . . . . . . . . . . . . 14 2.17. Potential insider attacks from legitmate ENRP servers . . 14
3. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Normative References . . . . . . . . . . . . . . . . . . . . . 16 5. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The RSerPool architecture[I-D.ietf-rserpool-overview] supports high- The RSerPool architecture[I-D.ietf-rserpool-overview] supports high-
availability and load balancing by enabling a pool user to identify availability and load balancing by enabling a pool user to identify
the most appropriate server from the server pool at a given time. the most appropriate server from the server pool at a given time.
The architecture is defined to support a set of basic goals. These The architecture is defined to support a set of basic goals. These
include an application-independent protocol mechanisms, separation of include an application-independent protocol mechanisms, separation of
server naming from IP addressing, the use of the end-to-end principle server naming from IP addressing, the use of the end-to-end principle
to avoid dependencies on intermediate equipment, separation of to avoid dependencies on intermediate equipment, separation of
skipping to change at page 8, line 19 skipping to change at page 8, line 19
requesting service which could result in denial of service or requesting service which could result in denial of service or
connection to a rouge PE of the attackers choice for service. connection to a rouge PE of the attackers choice for service.
2.6.3. Requirement 2.6.3. Requirement
The PE MUST authenticate the ENRP server. TLS is the mechanism used The PE MUST authenticate the ENRP server. TLS is the mechanism used
for the authentication. TLS with PSK is mandatory to implement as for the authentication. TLS with PSK is mandatory to implement as
the authentication mechanism. For PSK, having a pre-shared-key the authentication mechanism. For PSK, having a pre-shared-key
constitutes authorization.The network administrators of a pool need constitutes authorization.The network administrators of a pool need
to decide which nodes are authorized to participate in the pool. to decide which nodes are authorized to participate in the pool.
This requirement prevents malicious outsiders and insiders from
adding their own ENRP server to the pool.
2.7. Malicious ENRP Handlespace Resolution 2.7. Malicious ENRP Handlespace Resolution
2.7.1. Threat 2.7.1. Threat
The ASAP protocol receives a handlespace resolution response from an The ASAP protocol receives a handlespace resolution response from an
ENRP server, but the ENRP server is malicious and returns random IP ENRP server, but the ENRP server is malicious and returns random IP
addresses or an inaccurate list in response to the pool handle. addresses or an inaccurate list in response to the pool handle.
2.7.2. Effect 2.7.2. Effect
skipping to change at page 8, line 46 skipping to change at page 8, line 48
with the application. with the application.
2.7.3. Requirement 2.7.3. Requirement
ASAP SHOULD authenticate the ENRP server. TLS with certificates is ASAP SHOULD authenticate the ENRP server. TLS with certificates is
the mandatory to implement mechanism used for authentication. The the mandatory to implement mechanism used for authentication. The
administrator uses a centralized CA to generate and sign administrator uses a centralized CA to generate and sign
certificates. The certificate is stored on the ENRP server. A CA certificates. The certificate is stored on the ENRP server. A CA
trusted root certification authority certificate is sent to the trusted root certification authority certificate is sent to the
client out of band and the certificate signature on the ENRP server client out of band and the certificate signature on the ENRP server
certificate is checked for validity during TLS handshake. certificate is checked for validity during TLS handshake. This
authentication prevents malicious outsiders and insiders from adding
an ENRP server to the pool that may be accessed by ASAP.
2.8. Malicious node performs a replay attack 2.8. Malicious node performs a replay attack
2.8.1. Threat 2.8.1. Threat
A malicious node could replay the entire message previously sent by a A malicious node could replay the entire message previously sent by a
legitimate entity. This could create false/unnecessary state in the legitimate entity. This could create false/unnecessary state in the
ENRP servers when the replay is for registration/de-registration or ENRP servers when the replay is for registration/de-registration or
update. update.
skipping to change at page 14, line 17 skipping to change at page 14, line 23
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.
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.
2.17. Potential insider attacks from legitmate ENRP servers
The previous text does not address all byzantine attacks that could
arise from legitimate ENRP servers. True protection against
misbehavior by authentic (but rogue) servers is beyond the capability
of TLS security mechanisms. Authentication using TLS does not
protect against byzantine attacks as authenticated ENRP servers might
have been maliciously hacked. Protections against insider attacks
are generally specific to the attack, so more experimentation is
needed. For example, the following discusses two insider attacks and
potential mitigations.
One issue is that legitimate users may choose to not follow the
proposed policies regarding choice of servers (namely, members in the
pool). If the "choose a member at random" policy is employed, then a
pool user can always set its "random choices" so that it picks a
particular pool member. This bypasses the "load sharing" idea behind
the policy. Another issue is that a pool member (or server) may
report a wrong policy to a user.
To mitigate the first attack, the protocol may require the pool user
to "prove" to the pool member that the pool member was chosen
"randomly", say by demonstrating that the random choice was the
result of applying some hash function to a public nonce. Different
methods may be appropriate for other member scheduling policies.
To mitigate the second attack, the protocol might require the PE to
sign the policy sent to the ENRP server. During pool handle
resolution, the signed policy needs to be sent from an ENRP server to
an ASAP endpoint in a way that will allow the user to later hold the
server accountable to the policy.
3. Security Considerations 3. Security Considerations
This informational document characterizes potential security threats This informational document characterizes potential security threats
targeting the RSerPool architecture. The security mechanisms targeting the RSerPool architecture. The security mechanisms
required to mitigate these threats are summarized for each required to mitigate these threats are summarized for each
architectural component. It will be noted which mechanisms are architectural component. It will be noted which mechanisms are
required and which are optional. required and which are optional.
From the threats described in this document, the security services From the threats described in this document, the security services
required for the RSerPool protocol suite are given in the following required for the RSerPool protocol suite are given in the following
skipping to change at page 16, line 38 skipping to change at page 17, line 27
[I-D.ietf-rserpool-overview] [I-D.ietf-rserpool-overview]
Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An
Overview of Reliable Server Pooling Protocols", Overview of Reliable Server Pooling Protocols",
draft-ietf-rserpool-overview-06 (work in progress), draft-ietf-rserpool-overview-06 (work in progress),
May 2008. May 2008.
Authors' Addresses Authors' Addresses
Maureen Stillman (editor) Maureen Stillman (editor)
Nokia Nokia
35 Woodcrest Avenue 1167 Peachtree Court
Ithaca, NY 14850 Naperville, IL 60540
US US
Email: maureen.stillman@nokia.com Email: maureen.stillman@nokia.com
Ram Gopal Ram Gopal
Nokia Siemens Networks Nokia Siemens Networks
12278 Scripps Summit Drive 12278 Scripps Summit Drive
San Diego, CA 92131 San Diego, CA 92131
US US
Email: ram.gopal@nsn.com Email: ram.gopal@nsn.com
Erik Guttman Erik Guttman
Sun Microsystems Sun Microsystems
 End of changes. 12 change blocks. 
11 lines changed or deleted 49 lines changed or added

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