draft-ietf-rserpool-enrp-14.txt   draft-ietf-rserpool-enrp-15.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Intended status: Experimental R. Stewart Intended status: Experimental R. Stewart
Expires: May 13, 2007 Cisco Systems, Inc. Expires: July 8, 2007 Cisco Systems, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
A. Silverton A. Silverton
Motorola, Inc. Motorola, Inc.
November 9, 2006 January 4, 2007
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-14.txt draft-ietf-rserpool-enrp-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 41 skipping to change at page 1, line 41
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 May 13, 2007. This Internet-Draft will expire on July 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
Abstract Abstract
Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work
in conjunction with the Aggregate Server Access Protocol (ASAP) to in conjunction with the Aggregate Server Access Protocol (ASAP) to
accomplish the functionality of the Reliable Server Pooling accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture. Within the operational (Rserpool) requirements and architecture. Within the operational
scope of Rserpool, ENRP defines the procedures and message formats of scope of Rserpool, ENRP defines the procedures and message formats of
a distributed, fault-tolerant registry service for storing, a distributed, fault-tolerant registry service for storing,
bookkeeping, retrieving, and distributing pool operation and bookkeeping, retrieving, and distributing pool operation and
skipping to change at page 3, line 15 skipping to change at page 3, line 15
3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32 3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32
3.11. Handlespace Data Auditing and Re-synchronization . . . . . 33 3.11. Handlespace Data Auditing and Re-synchronization . . . . . 33
3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33 3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33
3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 34 3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 34
3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34 3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34
3.12. Handling Unrecognized Message or Unrecognized Parameter . 35 3.12. Handling Unrecognized Message or Unrecognized Parameter . 35
4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36
4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37
5.1. Implementing Security Mechanisms . . . . . . . . . . . . . 38 5.1. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 38
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 5.2. Implementing Security Mechanisms . . . . . . . . . . . . . 39
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.2. Informative References . . . . . . . . . . . . . . . . . . 42 7.1. Normative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 7.2. Informative References . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 46
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP [1] to accomplish ENRP is designed to work in conjunction with ASAP [1] to accomplish
the functionality of Rserpool as defined by its requirements [2] and the functionality of Rserpool as defined by its requirements [2] and
architecture [3]. architecture [3].
Within the operational scope of Rserpool, ENRP defines the procedures Within the operational scope of Rserpool, ENRP defines the procedures
and message formats of a distributed fault-tolerant registry service and message formats of a distributed fault-tolerant registry service
for storing, bookkeeping, retrieving, and distributing pool operation for storing, bookkeeping, retrieving, and distributing pool operation
skipping to change at page 38, line 4 skipping to change at page 38, line 4
integrity protection integrity protection
Threat 7) Eavesdropper snooping on handlespace information Threat 7) Eavesdropper snooping on handlespace information
----------- -----------
Security mechanism in response: Security protocol which supports data Security mechanism in response: Security protocol which supports data
confidentiality confidentiality
Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to
ENRP server ENRP server
----------- -----------
Security mechanism in response: ASAP must control the number of Security mechanism in response: ASAP must control the number of ASAP
endpoint unreachable messages transmitted from the PU to the ENRP endpoint unreachable messages transmitted from the PU to the ENRP
server. server.
Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
ENRP server the ENRP server
----------- -----------
Security mechanism in response: ENRP server must control the number Security mechanism in response: ENRP server must control the number
of Endpoint_KeepAlive messages to the PE of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE
To summarize the threats 1-7 require security mechanisms which To summarize the threats 1-7 require security mechanisms which
support authentication, integrity, data confidentiality, protection support authentication, integrity, data confidentiality, protection
from replay attacks. from replay attacks.
For Rserpool we need to authenticate the following: For Rserpool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server) PU <---- ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication)
skipping to change at page 38, line 35 skipping to change at page 38, line 35
responding to threats 1-7. Rather we use existing IETF security responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports protocols to provide the security services required. TLS supports
all these requirements and MUST be implemented. The all these requirements and MUST be implemented. The
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum by implementers of TLS for Rserpool. For purposes of minimum by implementers of TLS for Rserpool. For purposes of
backwards compatibility, ENRP SHOULD support backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other ciphersuite. other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5??? in [1]) to the ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [1]) to the
ENRP server. ENRP server.
Threat 9 requires the ENRP protocol to limit the number of Threat 9 requires the ENRP protocol to limit the number of
Endpoint_KeepAlive messages to the PE (see Section x.y???). ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see
Section Section 3.7).
5.1. Implementing Security Mechanisms 5.1. Chain of trust
Security is mandatory to implement in Rserpool and is based on TLS
implementation in all three architecture components that comprise
Rserpool -- namely PU, PE and ENRP server. We define an ENRP server
that uses TLS for all communication and authenticates ENRP peers and
PE registrants to be a secured ENRP server.
Here is a description of all possible data paths and a description of
the security.
PU <---> secured ENRP Server (authentication of ENRP server;
queries over TLS)
PE <---> secured ENRP server (mutual authentication;
registration/deregistration over TLS)
secured ENRP <---> secured ENRP server (mutual authentication;
database updates using TLS)
If all components of the system authenticate and communicate using
TLS, the chain of trust is sound. The root of the trust chain is the
ENRP server. If that is secured using TLS, then security will be
enforced for all ENRP and PE components that try to connect to it.
Summary of interaction between secured and unsecured components: If
the PE does not use TLS and tries to register with a secure ENRP
server, it will receive an error message response indicated as error
due to security considerations and the registration will be rejected.
If an ENRP server which does not use TLS tries to update the database
of a secure ENRP server, then the update will be rejected. If an PU
does not use TLS and communicates with a secure ENRP server, it will
get a response with the understanding that the response is not secure
as the response can be tampered with in transit even if the ENRP
database is secured.
The final case is the PU sending a secure request to ENRP. It might
be that ENRP and PEs are not secured and this is an allowable
configuration. The intent is to secure the communication over the
Internet between the PU and the ENRP server.
Summary:
Rserpool architecture components can communicate with each other to
establish a chain of trust. Secured PE and ENRP servers reject any
communications with unsecured ENRP or PE servers.
If the above is enforced, then a chain of trust is established for
the Rserpool user.
5.2. Implementing Security Mechanisms
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers. authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname. PUs MAY have certificates corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use. All Rserpool elements are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates that support TLS MUST have a mechanism for validating certificates
skipping to change at page 45, line 7 skipping to change at page 46, line 7
1301 E. Algonquin Road 1301 E. Algonquin Road
Room 2246 Room 2246
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Phone: +1 847-576-8747 Phone: +1 847-576-8747
Email: aron.j.silverton@motorola.com Email: aron.j.silverton@motorola.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 13 change blocks. 
20 lines changed or deleted 70 lines changed or added

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