Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
RFC 5355
|
| Document |
Type |
|
RFC - Informational
(September 2008; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5355 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Magnus Westerlund
|
|
Send notices to |
|
(None)
|
Network Working Group M. Stillman, Ed.
Request for Comments: 5355 Nokia
Category: Informational R. Gopal
Nokia Siemens Networks
E. Guttman
Sun Microsystems
S. Sengodan
Nokia Siemens Networks
M. Holdrege
September 2008
Threats Introduced by Reliable Server Pooling (RSerPool)
and Requirements for Security in Response to Threats
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
Reliable Server Pooling (RSerPool) is an architecture and set of
protocols for the management and access to server pools supporting
highly reliable applications and for client access mechanisms to a
server pool. This document describes security threats to the
RSerPool architecture and presents requirements for security to
thwart these threats.
Stillman, et. al. Informational [Page 1]
RFC 5355 RSerPool Threats September 2008
Table of Contents
1. Introduction ....................................................3
1.1. Definitions ................................................3
1.2. Conventions ................................................4
2. Threats .........................................................4
2.1. PE Registration/De-Registration Flooding --
Non-Existent PE ............................................4
2.2. PE Registration/De-Registration Flooding --
Unauthorized PE ............................................5
2.3. PE Registration/De-Registration Spoofing ...................6
2.4. PE Registration/De-Registration Unauthorized ...............6
2.5. Malicious ENRP Server Joins the Group of Legitimate
ENRP Servers ...............................................7
2.6. Registration/De-Registration with Malicious ENRP Server ....7
2.7. Malicious ENRP Handlespace Resolution ......................8
2.8. Malicious Node Performs a Replay Attack ....................9
2.9. Re-Establishing PU-PE Security during Failover .............9
2.10. Integrity ................................................10
2.11. Data Confidentiality .....................................10
2.12. ENRP Server Discovery ....................................11
2.13. Flood of Endpoint-Unreachable Messages from the
PU to the ENRP Server ....................................12
2.14. Flood of Endpoint Keep-Alive Messages from the
ENRP Server to a PE ......................................12
2.15. Security of the ENRP Database ............................13
2.16. Cookie Mechanism Security ................................13
2.17. Potential Insider Attacks from Legitimate ENRP Servers ...14
3. Security Considerations ........................................15
4. Normative References ...........................................17
Stillman, et. al. Informational [Page 2]
RFC 5355 RSerPool Threats September 2008
1. Introduction
The RSerPool architecture [RFC5351] supports high-availability and
load balancing by enabling a pool user to identify the most
appropriate server from the server pool at a given time. The
architecture is defined to support a set of basic goals. These
include application-independent protocol mechanisms, separation of
server naming from IP addressing, the use of the end-to-end principle
to avoid dependencies on intermediate equipment, separation of
session availability/failover functionality from the application
itself, the ability to facilitate different server selection
policies, the ability to facilitate a set of application-independent
failover capabilities, and a peer-to-peer structure.
RSerPool provides a session layer for robustness. The session layer
function may redirect communication transparently to upper layers.
This alters the direct one-to-one association between communicating
endpoints that typically exists between clients and servers. In
particular, secure operation of protocols often relies on assumptions
Show full document text