draft-ietf-rserpool-asap-20.txt   draft-ietf-rserpool-asap-21.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Q. Xie Internet-Draft Q. Xie
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
May 29, 2008 July 11, 2008
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-20.txt draft-ietf-rserpool-asap-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 38 skipping to change at page 1, line 38
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
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
[I-D.ietf-rserpool-enrp] provides a high availability data transfer [I-D.ietf-rserpool-enrp] provides a high availability data transfer
mechanism over IP networks. ASAP uses a handle-based addressing mechanism over IP networks. ASAP uses a handle-based addressing
model which isolates a logical communication endpoint from its IP model which isolates a logical communication endpoint from its IP
address(es), thus effectively eliminating the binding between the address(es), thus effectively eliminating the binding between the
communication endpoint and its physical IP address(es) which normally communication endpoint and its physical IP address(es) which normally
skipping to change at page 4, line 28 skipping to change at page 4, line 28
7.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 45 7.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 45 7.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 45
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
8.1. A New Table for ASAP Message Types . . . . . . . . . . . . 47 8.1. A New Table for ASAP Message Types . . . . . . . . . . . . 47
8.2. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 47 8.2. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 47
8.3. SCTP payload protocol identifier . . . . . . . . . . . . . 48 8.3. SCTP payload protocol identifier . . . . . . . . . . . . . 48
8.4. Multicast addresses . . . . . . . . . . . . . . . . . . . 48 8.4. Multicast addresses . . . . . . . . . . . . . . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9.1. Summary of Rserpool Security Threats . . . . . . . . . . . 49 9.1. Summary of Rserpool Security Threats . . . . . . . . . . . 49
9.2. Implementing Security Mechanisms . . . . . . . . . . . . . 50 9.2. Implementing Security Mechanisms . . . . . . . . . . . . . 50
9.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 51 9.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 53
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.1. Normative References . . . . . . . . . . . . . . . . . . . 54 11.1. Normative References . . . . . . . . . . . . . . . . . . . 56
11.2. Informative References . . . . . . . . . . . . . . . . . . 55 11.2. Informative References . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . . . 59
1. Introduction 1. Introduction
The Aggregate Server Access Protocol (ASAP) when used in conjunction The Aggregate Server Access Protocol (ASAP) when used in conjunction
with Endpoint Name Resolution Protocol [I-D.ietf-rserpool-enrp] with Endpoint Name Resolution Protocol [I-D.ietf-rserpool-enrp]
provides a high availability data transfer mechanism over IP provides a high availability data transfer mechanism over IP
networks. ASAP uses a handle-based addressing model which isolates a networks. ASAP uses a handle-based addressing model which isolates a
logical communication endpoint from its IP address(es), thus logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication effectively eliminating the binding between the communication
endpoint and its physical IP address(es) which normally constitutes a endpoint and its physical IP address(es) which normally constitutes a
skipping to change at page 50, line 46 skipping to change at page 50, line 46
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
skipping to change at page 54, line 9 skipping to change at page 56, line 9
10. Acknowledgments 10. 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, and many others for their invaluable comments and Thomas Dreibholz, and many others for their invaluable comments and
feedback. feedback.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[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-policies] [I-D.ietf-rserpool-policies]
Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Tuexen, M. and T. Dreibholz, "Reliable Server Pooling
Policies", draft-ietf-rserpool-policies-08 (work in Policies", draft-ietf-rserpool-policies-09 (work in
progress), March 2008. progress), 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-enrp] [I-D.ietf-rserpool-enrp]
Kim, D., Stewart, R., Stillman, M., Tuexen, M., and A. Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.
Silverton, "Endpoint Handlespace Redundancy Protocol Silverton, "Endpoint Handlespace Redundancy Protocol
(ENRP)", draft-ietf-rserpool-enrp-19 (work in progress), (ENRP)", draft-ietf-rserpool-enrp-20 (work in progress),
March 2008. May 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.
11.2. Informative References 11.2. Informative References
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
4875 Forest Drive 4875 Forest Drive
 End of changes. 16 change blocks. 
32 lines changed or deleted 128 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/