Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
RFC 5355

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 15

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
   at different layers regarding the identity of the communicating party
   and the continuity of the communication between endpoints.  Further,