draft-ietf-rserpool-enrp-20.txt   draft-ietf-rserpool-enrp-21.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft R. Stewart Internet-Draft R. Stewart
Intended status: Experimental Intended status: Experimental
Expires: November 30, 2008 M. Stillman Expires: January 12, 2009 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.
May 29, 2008 July 11, 2008
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-20.txt draft-ietf-rserpool-enrp-21.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 40 skipping to change at page 1, line 40
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 November 30, 2008. This Internet-Draft will expire on January 12, 2009.
Abstract Abstract
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to
work in conjunction with the Aggregate Server Access Protocol (ASAP) work in conjunction with the Aggregate Server Access Protocol (ASAP)
to accomplish the functionality of the Reliable Server Pooling to 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 16 skipping to change at page 3, line 16
4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 30 5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 30
5.2. A New Table for Update Action Types . . . . . . . . . . . 30 5.2. A New Table for Update Action Types . . . . . . . . . . . 30
5.3. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. SCTP payload protocol identifier . . . . . . . . . . . . . 31 5.4. SCTP payload protocol identifier . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32
6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33
6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 34 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 36
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . . 39
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . . . 42
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP ENRP is designed to work in conjunction with ASAP
[I-D.ietf-rserpool-asap] to accomplish the functionality of RSerPool [I-D.ietf-rserpool-asap] to accomplish the functionality of RSerPool
as defined by its requirements [RFC3237]. as defined by its requirements [RFC3237].
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 33, line 41 skipping to change at page 33, line 41
PE <----> ENRP Server (mutual authentication) PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication)
6.2. Implementing Security Mechanisms 6.2. Implementing Security Mechanisms
We do not define any new security mechanisms specifically for We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use an existing IETF security responding to threats 1-7. Rather we use an existing IETF security
protocol, specifically [RFC3237], to provide the security services protocol, specifically [RFC3237], to provide the security services
required. TLS supports all these requirements and MUST be required. TLS supports all these requirements and MUST be
implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be
supported at a minimum by implementors of TLS for RSerPool. For supported at a minimum by implementors of TLS for Rserpool. For
purposes of backwards compatibility, ENRP SHOULD support purposes of 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 IETF approved ciphersuites. other IETF approved ciphersuites.
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 using PSK. ENRP servers MUST support
authentication among themselves. PUs MUST authenticate ENRP servers. mutual authentication among themselves using PSK. PUs MUST
authenticate ENRP servers using certificates.
ENRP servers and PEs SHOULD possess a site certificate whose subject TLS with PSK is mandatory to implement as the authentication
corresponds to their canonical hostname. PUs MAY have certificates mechanism for ENRP to ENRP authentication and PE to ENRP
of their own for mutual authentication with TLS, but no provisions authentication. For PSK, having a pre-shared-key constitutes
are set forth in this document for their use. All RSerPool elements authorization.The network administrators of a pool need to decide
that support TLS MUST have a mechanism for validating certificates which nodes are authorized to participate in the pool. The
received during TLS negotiation; this entails possession of one or justification for PSK is that we assume that one administrative
more root certificates issued by certificate authorities (preferably domain will control and manage the server pool. This allows for PSK
well-known distributors of site certificates comparable to those that to be implemented and managed by a central security administrator.
issue root certificates for web browsers).
TLS with certificates is mandatory to implement as the authentication
mechanism for PU to ENRP server. PUs MUST autnthenticate ENRP
servers using certificates. ENRP servers MUST possess a site
certificate whose subject corresponds to their canonical hostname.
PUs MAY have certificates of their own for mutual authentication with
TLS, but no provisions are set forth in this document for their use.
All Rserpool elements that support TLS MUST have a mechanism for
validating certificates received during TLS negotiation; this entails
possession of one or more root certificates issued by certificate
authorities (preferably well-known distributors of site certificates
comparable to those that issue root certificates for web browsers).
In order to prevent man-in-the-middle attacks, the client MUST verify
the server's identity (as presented in the server's Certificate
message). The client's understanding of the server's identity
(typically the identity used to establish the transport connection)
is called the "reference identity". The client determines the type
(e.g., DNS name or IP address) of the reference identity and performs
a comparison between the reference identity and each subjectAltName
value of the corresponding type until a match is produced. Once a
match is produced, the server's identity has been verified, and the
server identity check is complete. Different subjectAltName types
are matched in different ways. The client may map the reference
identity to a different type prior to performing a comparison.
Mappings may be performed for all available subjectAltName types to
which the reference identity can be mapped; however, the reference
identity should only be mapped to types for which the mapping is
either inherently secure (e.g., extracting the DNS name from a URI to
compare with a subjectAltName of type dNSName) or for which the
mapping is performed in a secure manner (e.g., using DNSSEC, or using
user- or admin-configured host- to-address/address-to-host lookup
tables)..
If the server identity check fails, user-oriented clients SHOULD
either notify the user or close the transport connection and indicate
that the server's identity is suspect. Automated clients SHOULD
close the transport connection and then return or log an error
indicating that the server's identity is suspect or both. Beyond the
server identity check described in this section, clients should be
prepared to do further checking to ensure that the server is
authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making
this determination.
If the reference identity is an internationalized domain name,
conforming implementations MUST convert it to the ASCII Compatible
Encoding (ACE) format as specified in Section 4 of [RFC3490] before
comparison with subjectAltName values of type dNSName. Specifically,
conforming implementations MUST perform the conversion operation
specified in Section 4 of [RFC3490] as follows: * in step 1, the
domain name SHALL be considered a "stored string"; * in step 3, set
the flag called "UseSTD3ASCIIRules"; * in step 4, process each label
with the "ToASCII" operation; and * in step 5, change all label
separators to U+002E (full stop).
After performing the "to-ASCII" conversion, the DNS labels and names
MUST be compared for equality according to the rules specified in
Section 3 of RFC3490. The '*' (ASCII 42) wildcard character is
allowed in subjectAltName values of type dNSName, and then only as
the left-most (least significant) DNS label in that value. This
wildcard matches any left-most DNS label in the server name. That
is, the subject *.example.com matches the server names a.example.com
and b.example.com, but does not match example.com or a.b.example.com.
When the reference identity is an IP address, the identity MUST be
converted to the "network byte order" octet string representation RFC
791[RFC0791][RFC2460][RFC2460]. For IP Version 4, as specified in
RFC 791, the octet string will contain exactly four octets. For IP
Version 6, as specified in RFC 2460, the octet string will contain
exactly sixteen octets. This octet string is then compared against
subjectAltName values of type iPAddress. A match occurs if the
reference identity octet string and value octet strings are
identical.
After a TLS layer is established in an session, both parties are to
each independently decide whether or not to continue based on local
policy and the security level achieved. If either party decides that
the security level is inadequate for it to continue, it SHOULD remove
the TLS layer immediately after the TLS (re)negotiation has completed
(see RFC4511)[RFC4511]. Implementations may reevaluate the security
level at any time and, upon finding it inadequate, should remove the
TLS layer.
Implementations MUST support TLS with SCTP as described in [RFC3436] Implementations MUST support TLS with SCTP as described in [RFC3436]
or TLS over TCP as described in [RFC4346]. When using TLS/SCTP we or TLS over TCP as described in [RFC4346]. When using TLS/SCTP we
must ensure that RSerPool does not use any features of SCTP that are must ensure that RSerPool does not use any features of SCTP that are
not available to an TLS/SCTP user. This is not a difficult technical not available to an TLS/SCTP user. This is not a difficult technical
problem, but simply a requirement. When describing an API of the problem, but simply a requirement. When describing an API of the
RSerPool lower layer we have also to take into account the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
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 ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document)
[I-D.ietf-rserpool-asap]) to the ENRP server. to the ENRP server.
Threat 9 requires the ENRP protocol to limit the number of Threat 9 requires the ENRP protocol to limit the number of
ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE.
3.5 in [I-D.ietf-rserpool-asap]).
There is no security mechanism defined for the multicast
announcements. Therefore a receiver of such an announcement can not
consider the source address of such a message to be a trustworthy
address of an ENRP server. A receiver must also be prepared to
receive a large number of multicast announcements from attackers.
6.3. Chain of trust 6.3. Chain of trust
Security is mandatory to implement in RSerPool and is based on TLS Security is mandatory to implement in RSerPool and is based on TLS
implementation in all three architecture components that comprise implementation in all three architecture components that comprise
RSerPool -- namely PU, PE and ENRP server. We define an ENRP server RSerPool -- namely PU, PE and ENRP server. We define an ENRP server
that uses TLS for all communication and authenticates ENRP peers and that uses TLS for all communication and authenticates ENRP peers and
PE registrants to be a secured ENRP server. PE registrants to be a secured ENRP server.
Here is a description of all possible data paths and a description of Here is a description of all possible data paths and a description of
skipping to change at page 37, line 9 skipping to change at page 39, line 9
7. Acknowledgments 7. Acknowledgments
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
Thomas Dreibholz, Frank Volkmer, and many others for their invaluable Thomas Dreibholz, Frank Volkmer, and many others for their invaluable
comments and feedback. comments and feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071, "Computing the Internet checksum", RFC 1071,
September 1988. September 1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
Loughney, J., and M. Stillman, "Requirements for Reliable Loughney, J., and M. Stillman, "Requirements for Reliable
Server Pooling", RFC 3237, January 2002. Server Pooling", RFC 3237, January 2002.
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol", Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002. RFC 3436, December 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-rserpool-common-param] [I-D.ietf-rserpool-common-param]
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
"Aggregate Server Access Protocol (ASAP) and Endpoint "Aggregate Server Access Protocol (ASAP) and Endpoint
Handlespace Redundancy Protocol (ENRP) Parameters", Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-16 (work in progress), draft-ietf-rserpool-common-param-17 (work in progress),
March 2008. May 2008.
[I-D.ietf-rserpool-asap] [I-D.ietf-rserpool-asap]
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
"Aggregate Server Access Protocol (ASAP)", "Aggregate Server Access Protocol (ASAP)",
draft-ietf-rserpool-asap-19 (work in progress), draft-ietf-rserpool-asap-20 (work in progress), May 2008.
March 2008.
[I-D.ietf-rserpool-threats] [I-D.ietf-rserpool-threats]
Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
Sengodan, "Threats Introduced by RSerPool and Requirements Sengodan, "Threats Introduced by RSerPool and Requirements
for Security in Response to Threats", for Security in Response to Threats",
draft-ietf-rserpool-threats-12 (work in progress), draft-ietf-rserpool-threats-15 (work in progress),
May 2008. July 2008.
[I-D.ietf-tsvwg-sctpsocket] [I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Xie, Q., Corp, T., Poon, K., Tuexen, M., and Stewart, R., Xie, Q., Corp, T., Poon, K., Tuexen, M., and
V. Yasevich, "Sockets API Extensions for Stream Control V. Yasevich, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-16 (work in progress), draft-ietf-tsvwg-sctpsocket-16 (work in progress),
February 2008. February 2008.
8.2. Informative References 8.2. Informative References
 End of changes. 17 change blocks. 
34 lines changed or deleted 134 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/