draft-ietf-rserpool-threats-13.txt   draft-ietf-rserpool-threats-14.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 12, 2008 Nokia Siemens Networks Expires: December 25, 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 Siemans Networks Nokia Siemans Networks
June 10, 2008 June 23, 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-13.txt draft-ietf-rserpool-threats-14.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 12, 2008. This Internet-Draft will expire on December 25, 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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 . . . . . . . . . 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 . . . . . . . . . . 7 2.7. Malicious ENRP Handlespace Resolution . . . . . . . . . . 8
2.8. Malicious node performs a replay attack . . . . . . . . . 8 2.8. Malicious node performs a replay attack . . . . . . . . . 8
2.9. Re-establishing PU-PE security during failover . . . . . . 8 2.9. Re-establishing PU-PE security during failover . . . . . . 9
2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9 2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9
2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 9 2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 10
2.12. ENRP Server Discovery . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . 11 server to a PE . . . . . . . . . . . . . . . . . . . . . . 12
2.15. Security of the ENRP database . . . . . . . . . . . . . . 12 2.15. Security of the ENRP database . . . . . . . . . . . . . . 13
2.16. Cookie mechanism security . . . . . . . . . . . . . . . . 13 2.16. Cookie mechanism security . . . . . . . . . . . . . . . . 13
3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 3. Security Considerations . . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Normative References . . . . . . . . . . . . . . . . . . . . . 15 5. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
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
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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.
This document is related to the RSerPool This document is related to the RSerPool
ASAP[I-D.ietf-rserpool-asap]and ENRP [I-D.ietf-rserpool-enrp]protocol ASAP[I-D.ietf-rserpool-asap]and ENRP [I-D.ietf-rserpool-enrp]protocol
documents which describe in their security consideration sections the documents which describe in their security consideration sections the
mechanisms for meeting the security requirements in this document. mechanisms for meeting the security requirements in this document.
TLS[RFC4346] is the security mechanism for RSerPool that was selected TLS[RFC4346] is the security mechanism for RSerPool that was selected
to meet all the requirements described in this document. to meet all the requirements described in this document. The
security considerations section of ASAP and ENRP describes how TLS is
actually used to provide the security that is discussed in this
document.
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, Within the operational scope of RSerPool,
ENRP[I-D.ietf-rserpool-enrp] defines the procedures and message ENRP[I-D.ietf-rserpool-enrp] defines the procedures and message
formats of a distributed fault-tolerant registry service for formats of a distributed fault-tolerant registry service for
storing, bookkeeping, retrieving, and distributing pool operation storing, bookkeeping, retrieving, and distributing pool operation
skipping to change at page 5, line 16 skipping to change at page 5, line 18
The malicious node will corrupt the pool registrar database and/or The malicious node will corrupt the pool registrar database and/or
disable the RSerPool discovery and database function. This disable the RSerPool discovery and database function. This
represents a denial of service attack as the PU would potentially get represents a denial of service attack as the PU would potentially get
an IP address of a non-existent PE in response to an ENRP query. an IP address of a non-existent PE in response to an ENRP query.
2.1.3. Requirement 2.1.3. Requirement
An ENRP server that receives a registration/deregistration MUST NOT An ENRP server that receives a registration/deregistration MUST NOT
create or update state information until it has authenticated the PE. create or update state information until it has authenticated the PE.
TLS is used as the authentication mechanism. The RECOMMENDED TLS with PSK is mandatory to implement as the authentication
authorization model is that all rserpool components in one pool are mechanism. For PSK, having a pre-shared-key constitutes
assigned to a dedicated CA. The network administrators of a pool authorization.The network administrators of a pool need to decide
need to decide which nodes are authorized to participate in the pool. which nodes are authorized to participate in the pool. The
justification for PSK is that we assume that one administrative
domain will control and manage the server pool. This allows for PSK
to be implemented and managed by a central security administrator.
2.2. PE Registration/Deregistration flooding -- unauthorized PE 2.2. PE Registration/Deregistration flooding -- unauthorized PE
2.2.1. Threat 2.2.1. Threat
A malicious node or PE could send a stream of registrations/ A malicious node or PE could send a stream of registrations/
deregistrations that are unauthorized to register/deregister - to deregistrations that are unauthorized to register/deregister - to
ENRP servers at a very rapid rate and thereby create unnecessary ENRP servers at a very rapid rate and thereby create unnecessary
state in an ENRP server. state in an ENRP server.
skipping to change at page 5, line 47 skipping to change at page 6, line 4
service. In addition, a flood of message could prevent legitimate service. In addition, a flood of message could prevent legitimate
PEs from registering. In the data interception attack, the rogue PE PEs from registering. In the data interception attack, the rogue PE
does provide the service as man in the middle which allows the does provide the service as man in the middle which allows the
attacker to collect data. attacker to collect data.
2.2.3. Requirement 2.2.3. Requirement
An ENRP server that receives a registration/deregistration MUST NOT An ENRP server that receives a registration/deregistration MUST NOT
create or update state information until the authentication create or update state information until the authentication
information of the registering/de-registering entity is verified. information of the registering/de-registering entity is verified.
TLS is used as the authentication mechanism between the ENRP server TLS is used as the authentication mechanism between the ENRP server
and PE. and PE. TLS with PSK is mandatory to implement as the authentication
mechanism. For PSK, having a pre-shared-key constitutes
authorization.The network administrators of a pool need to decide
which nodes are authorized to participate in the pool.
2.3. PE Registration/Deregistration spoofing 2.3. PE Registration/Deregistration spoofing
2.3.1. Threat 2.3.1. Threat
A malicious node could send false registrations/deregistrations to A malicious node could send false registrations/deregistrations to
ENRP servers concerning a legitimate PE thereby creating false state ENRP servers concerning a legitimate PE thereby creating false state
information in the ENRP servers. information in the ENRP servers.
2.3.2. Effect 2.3.2. Effect
skipping to change at page 6, line 29 skipping to change at page 6, line 35
that a lot of PUs will try to connect to. This allows man in the that a lot of PUs will try to connect to. This allows man in the
middle or masquerade attacks on the service provided by the middle or masquerade attacks on the service provided by the
legitimate PEs. If a attacker registers its server address as a PE legitimate PEs. If a attacker registers its server address as a PE
and handles the requests he can eavesdrop on service data. and handles the requests he can eavesdrop on service data.
2.3.3. Requirement 2.3.3. Requirement
An ENRP server that receives a registration/deregistration MUST NOT An ENRP server that receives a registration/deregistration MUST NOT
create or update state information until it has authenticated the PE. create or update state information until it has authenticated the PE.
TLS is used as the authentication mechanism between the ENRP server TLS is used as the authentication mechanism between the ENRP server
and the PE. A PE can register only for itself and cannot register on and the PE. TLS with PSK is mandatory to implement as the
behalf of other PEs. authentication mechanism. For PSK, having a pre-shared-key
constitutes authorization.The network administrators of a pool need
to decide which nodes are authorized to participate in the pool. A
PE can register only for itself and cannot register on behalf of
other PEs.
2.4. PE Registration/Deregistration unauthorized 2.4. PE Registration/Deregistration unauthorized
2.4.1. Threat 2.4.1. Threat
A PE who is not authorized to join a pool could send registrations/ A PE who is not authorized to join a pool could send registrations/
deregistrations to ENRP servers thereby creating false state deregistrations to ENRP servers thereby creating false state
information in the ENRP servers. information in the ENRP servers.
2.4.2. Effect 2.4.2. Effect
skipping to change at page 7, line 4 skipping to change at page 7, line 18
concerning a PE and would be propagated to other ENRP servers thereby concerning a PE and would be propagated to other ENRP servers thereby
corrupting the ENRP database. This allows man in the middle or corrupting the ENRP database. This allows man in the middle or
masquerade attacks on the service provided by the legitimate PEs. If masquerade attacks on the service provided by the legitimate PEs. If
a attacker registers its server address as a PE and handles the a attacker registers its server address as a PE and handles the
requests he can eavesdrop on service data. requests he can eavesdrop on service data.
2.4.3. Requirement 2.4.3. Requirement
An ENRP server that receives a registration/deregistration MUST NOT An ENRP server that receives a registration/deregistration MUST NOT
create or update state information until it has authorized the create or update state information until it has authorized the
requesting entity. TLS is used as the authentication mechanism. requesting entity. TLS is used as the authentication mechanism. TLS
with PSK is mandatory to implement as the authentication mechanism.
For PSK, having a pre-shared-key constitutes authorization.The
network administrators of a pool need to decide which nodes are
authorized to participate in the pool.
2.5. Malicious ENRP server joins the group of legitimate ENRP servers 2.5. Malicious ENRP server joins the group of legitimate ENRP servers
2.5.1. Threat 2.5.1. Threat
A malicious ENRP server joins the group of legitimate ENRP servers A malicious ENRP server joins the group of legitimate ENRP servers
with the intent of propagating inaccurate updates to corrupt the ENRP with the intent of propagating inaccurate updates to corrupt the ENRP
database. The attacker sets up an ENRP server and attempts to database. The attacker sets up an ENRP server and attempts to
communicate with other ENRP servers. communicate with other ENRP servers.
2.5.2. Effect 2.5.2. Effect
The result would be Inconsistent ENRP database state. The result would be Inconsistent ENRP database state.
2.5.3. Requirement 2.5.3. Requirement
ENRP servers MUST perform mutual authentication. This would prevent ENRP servers MUST perform mutual authentication. This would prevent
the attacker from joining its ENRP server to the pool. TLS is used the attacker from joining its ENRP server to the pool. TLS is used
as the mutual authentication mechanism. Any server that presents a as the mutual authentication mechanism. TLS with PSK is mandatory to
valid certificate is allowed to join. implement as the authentication mechanism. For PSK, having a pre-
shared-key constitutes authorization.The network administrators of a
pool need to decide which nodes are authorized to participate in the
pool.
2.6. Registration/deregistration with malicious ENRP server 2.6. Registration/deregistration with malicious ENRP server
2.6.1. Threat 2.6.1. Threat
A PE unknowingly registers/deregisters with malicious ENRP server. A PE unknowingly registers/deregisters with malicious ENRP server.
2.6.2. Effect 2.6.2. Effect
The registration might not be properly processed or ignored. A rogue The registration might not be properly processed or ignored. A rogue
ENRP server has the ability to return any address to a user ENRP server has the ability to return any address to a user
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. for the authentication. TLS with PSK is mandatory to implement as
the authentication mechanism. For PSK, having a pre-shared-key
constitutes authorization.The network administrators of a pool need
to decide which nodes are authorized to participate in 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 17 skipping to change at page 8, line 40
PU application communicates with the wrong PE or is unable to locate PU application communicates with the wrong PE or is unable to locate
the PE since the response is incorrect in saying that a PE with that the PE since the response is incorrect in saying that a PE with that
handle did not exist. A rouge ENRP server has the ability to return handle did not exist. A rouge ENRP server has the ability to return
any address to ASAP requesting an address list which could result in any address to ASAP requesting an address list which could result in
denial of service or connection to a rouge PE of the attackers choice denial of service or connection to a rouge PE of the attackers choice
for service. From the PE, the attacker could eavesdrop or tamper for service. From the PE, the attacker could eavesdrop or tamper
with the application. with the application.
2.7.3. Requirement 2.7.3. Requirement
ASAP SHOULD authenticate the ENRP server. TLS is the mechanism used ASAP SHOULD authenticate the ENRP server. TLS with certificates is
for authentication. the mandatory to implement mechanism used for authentication. The
administrator uses a centralized CA to generate and sign
certificates. The certificate is stored on the ENRP server. A CA
trusted root certification authority certificate is sent to the
client out of band and the certificate signature on the ENRP server
certificate is checked for validity during TLS handshake.
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 11, line 18 skipping to change at page 11, line 48
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 authentication MUST be present and a provision for A provision for authentication MUST be present and a provision for
data confidentiality service SHOULD be present. TLS is the mechanism data confidentiality service SHOULD be present. TLS has a mechanism
used for both confidentiality and authentication. for confidentiality.
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 12, line 20 skipping to change at page 12, line 49
2.14.2. Effect 2.14.2. Effect
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 MUST limit the frequency of keep alive messages to a given PE to ENRP MUST limit the frequency of keep alive messages to a given PE to
prevent overwhelming the PE. This mechanism is described in the prevent overwhelming the PE. This mechanism is described in
ENRP[I-D.ietf-rserpool-enrp] protocol document. ENRP.[I-D.ietf-rserpool-enrp] protocol document.
2.15. Security of the ENRP database 2.15. Security of the ENRP database
2.15.1. Threat 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. to be informed which entries are "secure" and which are not.
 End of changes. 21 change blocks. 
32 lines changed or deleted 61 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/