draft-ietf-rserpool-threats-08.txt   draft-ietf-rserpool-threats-09.txt 
Internet Engineering Task Force Maureen Stillman(editor)
INTERNET DRAFT Ram Gopal Network Working Group M. Stillman, Ed.
Intended status:Informational Senthil Sengodan Internet-Draft Nokia
Nokia Intended status: Informational R. Gopal
Erik Guttman Expires: April 26, 2008 Nokia Research Center
E. Guttman
Sun Microsystems Sun Microsystems
Matt Holdrege M. Holdrege
Strix Systems Strix Systems
17 September 2007 S. Sengodan
expires March 17, 2008 Nokia Research Center
October 24, 2007
Threats Introduced by Rserpool and Requirements for Security Threats Introduced by RSerPool and Requirements for Security in Response
in response to Threats to Threats
<draft-ietf-rserpool-threats-08.txt> draft-ietf-rserpool-threats-09.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 aware will be disclosed, in accordance with Section 6 of BCP 79.
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 March 17, 2008. This Internet-Draft will expire on April 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). All Rights Reserved. Copyright (C) The IETF Trust (2007).
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 Table of Contents
Status of This Memo 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
Abstract 1 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction 3 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. PE Registration/Deregistration flooding --
2. Threats 4 non-existent PE . . . . . . . . . . . . . . . . . . . . . 4
2.1 PE Registration/Deregistration flooding . . . . . . . . . 4 2.2. PE Registration/Deregistration flooding --
2.2 PE Registration/Deregistration flooding . . . . . . . . . 4 unauthorized PE . . . . . . . . . . . . . . . . . . . . . 4
2.3 PE Registration/Deregistration spoofing . . . . . . . . . 4 2.3. PE Registration/Deregistration spoofing . . . . . . . . . 5
2.4 PE Registration/Deregistration unauthorized . . . . . . . 5 2.4. PE Registration/Deregistration unauthorized . . . . . . . 5
2.5 Malicious ENRP server joins the group of legitimate ENRP 2.5. Malicious ENRP server joins the group of legitimate
servers . . . . . . . . . . . . . . . . . 5 ENRP servers . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Registration/deregistration with malicious ENRP servers . 5 2.6. Registration/deregistration with malicious ENRP server . . 6
2.7 Malicious ENRP Handlespace Resolution . . . . . . . . . . 5 2.7. Malicious ENRP Handlespace Resolution . . . . . . . . . . 6
2.8 Malicious node performs a replay attack.. . . . . . . . . 6 2.8. Malicious node performs a replay attack . . . . . . . . . 7
2.9 Re-establishing PU-PE security during failover. . . . . . 6 2.9. Re-establishing PU-PE security during failover . . . . . . 7
2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 8
2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6 2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 8
2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7 2.12. ENRP Server Discovery . . . . . . . . . . . . . . . . . . 9
2.13 Flood of endpoint unreachable messages . . . . . . . . . 7 2.13. Flood of endpoint unreachable messages from the PU to
2.14 Flood of endpoint keep alive messages . . . . . . . . . . 7 the ENRP server . . . . . . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 2.14. Flood of endpoint keep alive messages from the ENRP
3.1 Database security . . . . . . . . . . . . . . . . . . . . 10 server to a PE . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Cookie security . . . . . . . . . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Security of the ENRP Database . . . . . . . . . . . . . . 12
5. Normative References . . . . . . . . . . . . . . . . . . . . . 11 3.2. Cookie mechanism security . . . . . . . . . . . . . . . . 12
6. Informative References. . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Intellectual Property Statement . . . . . . . . . . . . . . . . 12 5.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
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.
alters the direct one-to-one association between communicating endpoints This alters the direct one-to-one association between communicating
which typically exists between clients and servers. In particular, endpoints which typically exists between clients and servers. In
secure operation of protocols often relies on assumptions at different particular, secure operation of protocols often relies on assumptions
layers regarding the identity of the communicating party and the at different layers regarding the identity of the communicating party
continuity of the communication between endpoints. Further, the and the continuity of the communication between endpoints. Further,
operation of RSERPOOL itself has security implications and risks. The the operation of RSerPool itself has security implications and risks.
session layer operates dynamically which imposes additional concerns for The session layer operates dynamically which imposes additional
the overall security of the end-to-end application. This document concerns for the overall security of the end-to-end application.
explores the security implications of RSERPOOL, both due to its own This document explores the security implications of RSerPool, both
functions and due to its being interposed between applications and due to its own functions and due to its being interposed between
transport interfaces. applications and transport interfaces.
1.1 Definitions 1.1. Definitions
This document uses the following terms: This document uses the following terms:
ENRP 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 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: Aggregate Server Access Protocol (ASAP):
A session layer protocol which uses ENRP to provide a high A session layer protocol which uses ENRP to provide a high
availability handlespace. ASAP is responsible for the availability handlespace. ASAP is responsible for the abstraction
abstraction of the underlying transport technologies, load of the underlying transport technologies, load distribution
distribution management,fault management, as well as the management,fault management, as well as the presentation to the
presentation to the upper layer (i.e., the ASAP user) a upper layer (i.e., the ASAP user) a unified primitive interface.
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:
A logical pointer to a pool. Each server pool will be A logical pointer to a pool. Each server pool will be
identifiable in the operational scope of the system by a identifiable in the operational scope of the system by a unique
unique 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 an internal or external agent. queried by an internal or external agent.
Pool element (PE): Pool element (PE): A server entity having registered to a pool.
A server entity that runs ASAP and has registered to a pool.
Pool user (PU):
A server pool user that runs ASAP. Note, a PU can also be a
PE if it has registered itself to a pool.
ENRP server: Pool user (PU): A server pool user.
Entity which runs ENRP and is responsible for managing and
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 2.1.1. Threat
registrations/deregistrations on behalf of non-existent PEs to ENRP
servers at a very rapid rate and thereby create unnecessary state in an
ENRP server.
Effect: Corrupting the pool registrar database and/or disabling the A malicious node could send a stream of false registrations/
Rserpool discovery and database function. deregistrations on behalf of non-existent PEs to ENRP servers at a
very rapid rate and thereby create unnecessary state in an ENRP
server.
Requirement: An ENRP server that receives a registration/deregistration 2.1.2. Effect
should not create or update state information until it has authenticated
the PE.
2.2 PE Registration/Deregistration flooding -- unauthorized PE Corrupting the pool registrar database and/or disabling the Rserpool
discovery and database function. This 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.
Threat: A malicious node or PE could send a stream of 2.1.3. Requirement
registrations/deregistrations that are unauthorized to
register/deregister - to ENRP servers at a very rapid rate and thereby
create unnecessary state in an ENRP server.
Effect: Corrupting the pool registrar database and/or disabling the An ENRP server that receives a registration/deregistration should not
Rserpool discovery and database function. create or update state information until it has authenticated the PE.
Requirement: An ENRP server that receives a registration/deregistration 2.2. PE Registration/Deregistration flooding -- unauthorized PE
should not create or update state information until the authorization of
the registering/de-registering entity is verified.
2.3 PE Registration/Deregistration spoofing 2.2.1. Threat
Threat: A malicious node could send false registrations/deregistrations A malicious node or PE could send a stream of registrations/
to ENRP servers concerning a legitimate PE thereby creating false state deregistrations that are unauthorized to register/deregister - to
ENRP servers at a very rapid rate and thereby create unnecessary
state in an ENRP server.
2.2.2. Effect
Corrupting the pool registrar database and/or disabling the Rserpool
discovery and database function. This represents a denial of service
attack as the PU would potentially get an IP address of a rogue PE in
response to an ENRP query which might not provide the actual service.
If it does provide the service, this would be a man in the middle
attack to allow them to collect data. This could also prevent
legitimate PEs from registering.
2.2.3. Requirement
An ENRP server that receives a registration/deregistration should not
create or update state information until the authorization of the
registering/de-registering entity is verified.
2.3. PE Registration/Deregistration spoofing
2.3.1. Threat
A malicious node could send false registrations/deregistrations to
ENRP servers concerning a legitimate PE thereby creating false state
information in the ENRP servers. information in the ENRP servers.
Effect: Misinformation in the ENRP server concerning a PE would get 2.3.2. Effect
propagated to other ENRP servers thereby corrupting the ENRP database.
Requirement: An ENRP server that receives a registration/deregistration Misinformation in the ENRP server concerning a PE would get
should not create or update state information until it has authenticated propagated to other ENRP servers thereby corrupting the ENRP
the PE. database. DDoS, by adding a PE that is a target for DDoS attack for
some popular high volume service the attacker can register a PE 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 legitimate PEs.
If a hacker registers its server address as a PE and handles the
requests he can eavesdrop on service data.
2.4 PE Registration/Deregistration unauthorized 2.3.3. Requirement
Threat: A PE who is not authorized to join a pool could send An ENRP server that receives a registration/deregistration should not
registrations/deregistrations to ENRP servers thereby creating false create or update state information until it has authenticated the PE.
state information in the ENRP servers.
Effect: Misinformation in the ENRP server concerning a PE would get 2.4. PE Registration/Deregistration unauthorized
propagated to other ENRP servers thereby corrupting the ENRP database.
Requirement: An ENRP server that receives a registration/deregistration 2.4.1. Threat
should not create or update state information until it has authorized
the requesting entity.
2.5 Malicious ENRP server joins the group of legitimate ENRP servers A PE who is not authorized to join a pool could send registrations/
deregistrations to ENRP servers thereby creating false state
information in the ENRP servers.
Threat: Malicious ENRP server joins the group of legitimate ENRP servers 2.4.2. Effect
with the intent of propagating inaccurate updates to corrupt the ENRP
Misinformation in the ENRP server concerning a PE would get
propagated to other ENRP servers thereby corrupting the ENRP
database. This allows man in the middle or masquerade attacks on the
service provided by the legitimate PEs. If a hacker registers its
server address as a PE and handles the requests he can eavesdrop on
service data.
2.4.3. Requirement
An ENRP server that receives a registration/deregistration should not
create or update state information until it has authorized the
requesting entity.
2.5. Malicious ENRP server joins the group of legitimate ENRP servers
2.5.1. Threat
Malicious ENRP server joins the group of legitimate ENRP servers with
the intent of propagating inaccurate updates to corrupt the ENRP
database. database.
Effect: Inconsistent ENRP database state. 2.5.2. Effect
Requirement: Mutual authentication of ENRP servers. Inconsistent ENRP database state.
2.6 Registration/deregistration with malicious ENRP server 2.5.3. Requirement
Threat: A PE unknowingly registers/deregisters with malicious ENRP Mutual authentication of ENRP servers.
server.
Effect: Registration might not be properly processed or ignored. 2.6. Registration/deregistration with malicious ENRP server
Requirement: PE needs to authenticate the ENRP server. 2.6.1. Threat
2.7 Malicious ENRP Handlespace Resolution A PE unknowingly registers/deregisters with malicious ENRP server.
Threat: The ASAP protocol receives a handlespace resolution response 2.6.2. Effect
from an ENRP server, but the ENRP server is malicious and returns random
IP addresses or an inaccurate list in response to the pool handle.
Effect: PU application communicates with the wrong PE or is unable to Registration might not be properly processed or ignored. A rogue
locate the PE since the response is incorrect in saying that a PE with ENRP server has the ability to return any address to a user
that handle did not exist. requesting service which could result in denial of service or
connection to a rouge PE of the hackers choice for service.
Requirement: ASAP needs to authenticate the ENRP server. 2.6.3. Requirement
2.8 Malicious node performs a replay attack PE needs to authenticate the ENRP server.
Threat: A malicious node could replay the entire message previously sent 2.7. Malicious ENRP Handlespace Resolution
by a legitimate entity. This could create false/unnecessary state in the
2.7.1. Threat
The ASAP protocol receives a handlespace resolution response from an
ENRP server, but the ENRP server is malicious and returns random IP
addresses or an inaccurate list in response to the pool handle.
2.7.2. Effect
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
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
denial of service or connection to a rouge PE of the hackers choice
for service. From the PE, the hacker could eavesdrop or tamper with
the application.
2.7.3. Requirement
ASAP needs to authenticate the ENRP server.
2.8. Malicious node performs a replay attack
2.8.1. Threat
A malicious node could replay the entire message previously sent by a
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.
Effect: False/extra state is maintained by ENRP servers 2.8.2. Effect
Requirement: Care should be taken to prevent replay attacks. False/extra state is maintained by ENRP servers. This would most
likely be used as a denial of service attack if the replay is used to
deregister all PEs.
2.9 Re-establishing PU-PE security during failover 2.8.3. Requirement
Threat: PU fails over from PE A to PE B. In the case that the PU had a Care should be taken to prevent replay attacks.
2.9. Re-establishing PU-PE security during failover
2.9.1. Threat
PU fails over from PE A to PE B. In the case that the PU had a
trusted relationship with PE A, then the PU will likely not have the trusted relationship with PE A, then the PU will likely not have the
same relationship established with PE B. same relationship established with PE B.
Effect: If there was a trust relationship involving security context 2.9.2. Effect
between PU and PE A, the equivalent trust relationship will not exist
between PU and PE B. This will violate security policy.
Requirement: Either notify the application when fail over occurs so the If there was a trust relationship involving security context between
PU and PE A, the equivalent trust relationship will not exist between
PU and PE B. This will violate security policy.
2.9.3. 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.
2.10 Integrity 2.10. Integrity
Threats: 2.10.1. Threat
a) ENRP response to pool handle resolution is corrupted during
transmission a. ENRP response to pool handle resolution is corrupted during
b) ENRP peer messages are corrupted during transmission
c) PE sends update for values and that information is corrupted during
transmission transmission
Effect: ASAP receives corrupt information for pool handle resolution b. ENRP peer messages are corrupted during transmission
which the PU believes to be accurate.
Requirement: Integrity mechanism needed. c. PE sends update for values and that information is corrupted
during transmission
2.11 Data Confidentiality 2.10.2. Effect
Threat: An eavesdropper capable of snooping on fields within messages in ASAP receives corrupt information for pool handle resolution which
transit, may be able to garner information such as topology/location/IP the PU believes to be accurate.
addresses etc. that may not be desirable to divulge.
Effect: Information that an administrator does not wish to divulge are 2.10.3. Requirement
divulged.
Requirement: Provision for data confidentiality service. Integrity mechanism needed.
2.12 ENRP Server Discovery 2.11. Data Confidentiality
Threat A: Thwarting successful discovery: When a PE wishes to register 2.11.1. Threat
with an ENRP server, it needs to discover an ENRP server. An attacker
could thwart the successful discovery of ENRP server(s) thereby inducing
the PE to believe that no ENRP server is available. For instance, the
attacker could reduce the returned set of ENRP servers to null or a
small set of inactive ENRP servers.
Threat B: A similar thwarting scenario also applies when an ENRP server An eavesdropper capable of snooping on fields within messages in
or ASAP on behalf of a PU needs to discover ENRP servers. transit, may be able to garner information such as
topology/location/IP addresses etc. that may not be desirable to
divulge.
Threat C: Spoofing successful discovery: An attacker could spoof the 2.11.2. Effect
discovery by claiming to be a legitimate ENRP server. When a PE wishes
to register, it finds the spoofed ENRP server.
Threat D: A similar spoofing scenario also applies when an ENRP server Information that an administrator does not wish to divulge are
or ASAP on behalf of a PU needs to discover ENRP servers. divulged. The hacker gains valuable information that can be used for
financial gain or attacks on hosts.
Effect A: A PE that could have been in an application server pool does 2.11.3. Requirement
not become part of a pool. The PE does not complete discovery operation.
This is a DOS attack.
Effect B: An ENRP server that could have been in an ENRP server pool Provision for data confidentiality service.
does not become part of a pool. A PU is unable to utilize services of
2.12. ENRP Server Discovery
2.12.1. Threats
a. Thwarting successful discovery: When a PE wishes to register with
an ENRP server, it needs to discover an ENRP server. An attacker
could thwart the successful discovery of ENRP server(s) thereby
inducing the PE to believe that no ENRP server is available. For
instance, the attacker could reduce the returned set of ENRP
servers to null or a small set of inactive ENRP servers.
b. A similar thwarting scenario also applies when an ENRP server or
ASAP on behalf of a PU needs to discover ENRP servers.
c. Spoofing successful discovery: An attacker could spoof the
discovery by claiming to be a legitimate ENRP server. When a PE
wishes to register, it finds the spoofed ENRP server.
d. A similar spoofing scenario also applies when an ENRP server or
ASAP on behalf of a PU needs to discover ENRP servers.
2.12.2. Effects
a. A PE that could have been in an application server pool does not
become part of a pool. The PE does not complete discovery
operation. This is a DOS attack.
b. An ENRP server that could have been in an ENRP server pool does
not become part of a pool. A PU is unable to utilize services of
ENRP servers. ENRP servers.
Effect C,D: This malicious ENRP would either misrepresent, ignore c. This malicious ENRP would either misrepresent, ignore or
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.
Requirement: Discovery phase needs to be authenticated. d. Same as last.
2.13 Flood of endpoint unreachable messages from the PU to the ENRP 2.12.3. Requirement
Provision for data confidentiality service.
2.13. Flood of endpoint unreachable messages from the PU to the ENRP
server server
These messages are sent by ASAP to the ENRP server when it is unable to 2.13.1. Threat
contact a PE. There is the potential that a PU could flood the ENRP
server intentionally or unintentionally with these messages.
Effect: DOS attack on the ENRP server These messages are sent by ASAP to the ENRP server when it is unable
to contact a PE. There is the potential that a PU could flood the
ENRP server intentionally or unintentionally with these messages.
Requirement: Need to limit the number of endpoint unreachable messages 2.13.2. Effect
sent to the ENRP server from the PU.
2.14 Flood of endpoint keep alive messages from the ENRP server to a PE DOS attack on the ENRP server.
These messages would be sent in response to a flood of endpoint 2.13.3. Requirement
unreachable messages from the PUs to the ENRP server.
Effect: Unintentional DOS attack on the PE Need to limit the number of endpoint unreachable messages sent to the
ENRP server from the PU.
Requirement: ENRP must limit the frequency of keep alive messages to a 2.14. Flood of endpoint keep alive messages from the ENRP server to a
given PE to prevent overwhelming the PE. PE
3. Security Considerations for Rserpool 2.14.1. Threat
This informational document characterizes potential security threats These messages would be sent in response to a flood of endpoint
targeting the Rserpool architecture. The security mechanisms required unreachable messages from the PUs to the ENRP server.
to mitigate these threats are summarized for each architectural
component. It will be noted which mechanisms are required and which are
optional.
From the threats described in this document, the security services 2.14.2. Effect
required for the Rserpool protocol are enumerated below.
Threat 2.1, 2.2, 2.3, 2.4) PE registration/deregistration flooding Unintentional DOS attack on the PE.
and/or spoofing.
Security mechanism in response: ENRP server authenticates the PE
Threat 2.6) PE registers with a malicious ENRP server 2.14.3. Requirement
Security mechanism in response: PE authenticates the ENRP server
These combined threats result in a requirement for mutual authentication ENRP must limit the frequency of keep alive messages to a given PE to
of the ENRP server and the PE. prevent overwhelming the PE.
Threat 2.5) Malicious ENRP server joins the ENRP server pool 3. Security Considerations
Security mechanism in response: ENRP servers mutually authenticate
Threat 2.7, 2.12) A PU communicates with a malicious ENRP server for This informational document characterizes potential security threats
handlespace resolution targeting the Rserpool architecture. The security mechanisms
Security mechanism in response: The PU authenticates the ENRP server. required to mitigate these threats are summarized for each
If the authentication fails, it looks for another ENRP server. architectural component. It will be noted which mechanisms are
required and which are optional.
Threat 2.8) Replay attack From the threats described in this document, the security services
Security mechanism in response: Security protocol which has protection required for the RSerPool protocol suite are given in the following
from replay attacks table.
Threat 2.9) Re-establishing PU-PE security during failover +--------------+----------------------------------------------------+
Requirement: Either notify the application when fail over occurs so the | Threat | Security mechanism in response |
application can take appropriate action to establish a trusted +--------------+----------------------------------------------------+
relationship with PE B OR reestablish the security context | Section 2.1 | ENRP server authenticates the PE. |
transparently. | Section 2.2 | ENRP server authenticates the PE. |
| Section 2.3 | ENRP server authenticates the PE. |
| Section 2.4 | ENRP server authenticates the PE. |
| Section 2.5 | ENRP servers mutually authenticate. |
| Section 2.6 | PE authenticates the ENRP server. |
| Section 2.7 | The PU authenticates the ENRP server. If the |
| | authentication fails, it looks for another ENRP |
| | server. |
| Section 2.8 | Security protocol which has protection from replay |
| | attacks. |
| Section 2.9 | Either notify the application when fail over |
| | occurs so the application can take appropriate |
| | action to establish a trusted relationship with PE |
| | B OR reestablish the security context |
| | transparently. |
| Section 2.10 | Security protocol which supports integrity |
| | protection. |
| Section 2.12 | Security protocol which supports data |
| | confidentiality. |
| Section 2.11 | The PU authenticates the ENRP server. If the |
| | authentication fails, it looks for another ENRP |
| | server. |
| Section 2.13 | ASAP must control the number of endpoint |
| | unreachable messages transmitted from the PU to |
| | the ENRP server. |
| Section 2.14 | ENRP server must control the number of |
| | Endpoint_KeepAlive messages to the PE. |
+--------------+----------------------------------------------------+
Threat 2.10) Corrupted data which causes a PU to have misinformation The first four threats combined with the sixth threat result in a
concerning a pool handle resolution requirement for mutual authentication of the ENRP server and the PE.
Security mechanism in response: Security protocol which supports
integrity protection
Threat 2.11) Eavesdropper snooping on handlespace information To summarize the first twelve threats require security mechanisms
Security mechanism in response: Security protocol which supports data which support authentication, integrity, data confidentiality and
confidentiality protection from replay attacks. For RSerPool we need to authenticate
the following:
To summarize the threats 2.1-2.12 require security mechanisms which o PU -----> ENRP Server (PU authenticates the ENRP server)
support authentication, integrity, data confidentiality and protection
from replay attacks.
For Rserpool we need to authenticate the following: o PE <----> ENRP Server (mutual authentication)
PU -----> ENRP Server (PU authenticates the ENRP server) o ENRP server <-----> ENRP Server (mutual authentication)
PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication)
Summary by component: Summary by component:
Rserpool client -- mandatory to implement authentication of the ENRP RSerPool client -- mandatory to implement authentication of the ENRP
server is required for accurate pool handle resolution. This is to server is required for accurate pool handle resolution. This is
protect against threats from rogue ENRP servers. In addition, to protect against threats from rogue ENRP servers. In addition,
confidentiality, integrity and preventing replay attack are also confidentiality, integrity and preventing replay attack are also
mandatory to implement to protect from eavesdropping and data corruption mandatory to implement to protect from eavesdropping and data
or false data transmission. Confidentiality is mandatory to implement corruption or false data transmission. Confidentiality is
and is used when privacy is required. mandatory to implement and is used when privacy is required.
PE to ENRP communications -- mandatory to implement mutual PE to ENRP communications -- mandatory to implement mutual
authentication, integrity and protection from replay attack is required authentication, integrity and protection from replay attack is
for PE to ENRP communications. This is to protect the integrity of the required for PE to ENRP communications. This is to protect the
ENRP handle space database. Confidentiality is mandatory to implement integrity of the ENRP handle space database. Confidentiality is
and is used when privacy is required. mandatory to implement and is used when privacy is required.
ENRP to ENRP communications -- mandatory to implement mutual ENRP to ENRP communications -- mandatory to implement mutual
authentication, integrity and protection from replay attack is required authentication, integrity and protection from replay attack is
for ENRP to ENRP communications. This is to protect the integrity of required for ENRP to ENRP communications. This is to protect the
the ENRP handle space database. Confidentiality is mandatory to integrity of the ENRP handle space database. Confidentiality is
implement and is used when privacy is required. mandatory to implement and is used when privacy is required.
Threat 2.13) Flood of Endpoint_Unreachable messages from the PU to ENRP
server
Security mechanism in response: ASAP must control the number of endpoint
unreachable messages transmitted from the PU to the ENRP server.
Threat 2.14) Flood of Endpoint_KeepAlive messages to the PE from the
ENRP server
Security mechanism in response: ENRP server must control the number of
Endpoint_KeepAlive messages to the PE
3.1 Security of the ENRP Database 3.1. Security of the ENRP Database
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 to requests handle space resolution information from ENRP, it would have
be informed which entries are "secure" and which are not. This would to be informed which entries are "secure" and which are not. This
not only complicate the protocol, but actually bring into question the would not only complicate the protocol, but actually bring into
security and integrity of such a database. What can be asserted about question the security and integrity of such a database. What can be
the security of such a database is a very thorny question. Due to these asserted about the security of such a database is a very thorny
two facts it was decided that either the entire ENRP server database is question. Due to these two facts it was decided that either the
secure, that is, it has registrations exclusively from PEs entire ENRP server database is secure, that is, it has registrations
that have used security mechanisms or the entire database is insecure, exclusively from PEs that have used security mechanisms or the entire
that is, registrations are from PEs that have used no security database is insecure, that is, registrations are from PEs that have
mechanisms. ENRP servers that support security are required to reject used no security mechanisms. ENRP servers that support security are
any PE server registration that does not use the security mechanisms. required to reject any PE server registration that does not use the
Likewise, ENRP servers that support security should not accept updates security mechanisms. Likewise, ENRP servers that support security
from other ENRP servers that do not use security mechanisms. should not accept updates from other ENRP servers that do not use
security mechanisms.
3.2 Cookie mechanism security 3.2. 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, the data and control channel must always 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
are not allowed. It is even hard to understand what this really means b. data channel is secured; control channel is not
from a security point of view.
are not allowed. It is even hard to understand what this really
means from a security point of view.
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
This applies to cookies in the sense that if you choose to secure your 2. the multiplexed control channel-data channel is not secured
control-data channel, then the cookies are secured.
This applies to cookies in the sense that if you choose to secure
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.
4. IANA Considerations 4. IANA Considerations
This document introduces no additional considerations for IANA. This document introduces no additional considerations for IANA.
5. Normative References 5. References
[Rserarch] P. Lei, et. al., "An Overview of Reliable Server
Pooling Protocols", draft-ietf-rserpool-overview-02.txt, July, 2007,
work in progress.
6. Informative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[RFC3365] RFC 3365, Strong Security Requirements for IETF Standard
Protocols, August, 2002.
7. Acknowledgements
Thanks to the Rserpool security design team and others that provided
valuable comments: Lyndon Ong, Randy Stewart, Melinda Shore, Qiaobing
Xie, Michael Tuexen, Aron Silverton, Sohrab Modi, Javier Pastor-Balbas,
Xingang Guo, M. Piramanayagam, Bernard Aboba and Dhooria Manoj.
Funding for the RFC Editor function is currently provided by the
Internet Society.
7. Intellectual Property Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007). 5.1. Normative References
This document is subject to the rights, licenses and restrictions [1] Lei, P., "An Overview of Reliable Server Pooling Protocols",
contained in BCP 78, and except as set forth therein, the authors draft-ietf-rserpool-overview-02 (work in progress), July 2007.
retain all their rights.
This document and the information contained herein are provided on 5.2. Informative References
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property [2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
The IETF takes no position regarding the validity or scope of any [3] Schiller, J., "Strong Security Requirements for Internet
Intellectual Property Rights or other rights that might be claimed Engineering Task Force Standard Protocols", BCP 61, RFC 3365,
to pertain to the implementation or use of the technology August 2002.
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Authors' Addresses
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention Maureen Stillman (editor)
any copyrights, patents or patent applications, or other Nokia
proprietary rights that may cover technology that may be required 35 Woodcrest Avenue
to implement this standard. Please address the information to the Ithaca, NY 14850
IETF at ietf-ipr@ietf.org. US
8. Author's Addresses Email: maureen.stillman@nokia.com
Ram Gopal Ram Gopal
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803 Burlington, MA 01803
USA US
email: ram.gopal@nokia.com
Email: ram.gopal@nokia.com
Erik Guttman Erik Guttman
Sun Microsystems Sun Microsystems
Eichhoelzelstr. 7 Eichhoelzelstrasse 7
74915 Waibstadt 74915 Waibstadt
Germany DE
Email: Erik.Guttman@sun.com Email: Erik.Guttman@sun.com
Matt Holdrege Matt Holdrege
Strix Systems Strix Systems
26610 Agoura Road, Suite 110 26610 Agoura Road
Calabasas, CA, 91302 Suite 110
matt@strixsystems.com Calabasas, CA 91302
US
Email: matt@strixsystems.com
Senthil Sengodan Senthil Sengodan
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803 Burlington, MA 01803
USA US
email: Senthil.sengodan@nokia.com
Maureen Stillman Email: Senthil.sengodan@nokia.com
Nokia
35 Woodcrest Ave. Full Copyright Statement
Ithaca, NY 14850
USA Copyright (C) The IETF Trust (2007).
email: maureen.stillman@nokia.com
This document is subject to the rights, licenses and restrictions
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 an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 121 change blocks. 
356 lines changed or deleted 419 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/