RFC 5352
Aggregate Server Access Protocol (ASAP)
Pages: 53
Experimental
Experimental
Part 3 of 3 – Pages 42 to 53
7. Timers, Variables, and Thresholds
The following is a summary of the timers, variables, and pre-set protocol constants used in ASAP.7.1. Timers
T1-ENRPrequest - A timer started when a request is sent by ASAP to the ENRP server (providing application information is queued). Normally set to 15 seconds. T2-registration - A timer started when sending an ASAP_REGISTRATION request to the Home ENRP server, normally set to 30 seconds. T3-deregistration - A timer started when sending a de-registration request to the Home ENRP server, normally set to 30 seconds. T4-reregistration - This timer is started after successful registration into the ENRP handlespace and is used to cause a re- registration at a periodic interval. This timer is normally set to 10 minutes or 20 seconds less than the Lifetime parameter used in the registration request (whichever is less). T5-Serverhunt - This timer is used during the ENRP Server Hunt procedure and is normally set to 10 seconds. T6-Serverannounce - This timer gives the time between the sending of consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to 1 second. T7-ENRPoutdate - This timer gives the time a server announcement is valid. It is normally set to 5 seconds.7.2. Variables
stale_cache_value - A threshold variable that indicates how long a cache entry is valid for.
7.3. Thresholds
MAX-REG-ATTEMPT - The maximum number of registration attempts to be made before a server hunt is issued. The default value of this is set to 2. MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made when requesting information from the local ENRP server before a server hunt is issued. The default value for this is 2. RETRAN-MAX - This value represents the maximum time between registration attempts and puts a ceiling on how far the registration timer will back off. The default value for this is normally set to 60 seconds.8. IANA Considerations
This document (RFC 5352) is the reference for all registrations described in this section. All registrations have been listed on the Reliable Server Pooling (RSerPool) Parameters page.8.1. A New Table for ASAP Message Types
ASAP Message Types are maintained by IANA. Fourteen initial values have been assigned by IANA as described in Figure 1. IANA created a new table, "ASAP Message Types": Type Message Name Reference ----- ------------------------- --------- 0x00 (Reserved by IETF) RFC 5352 0x01 ASAP_REGISTRATION RFC 5352 0x02 ASAP_DEREGISTRATION RFC 5352 0x03 ASAP_REGISTRATION_RESPONSE RFC 5352 0x04 ASAP_DEREGISTRATION_RESPONSE RFC 5352 0x05 ASAP_HANDLE_RESOLUTION RFC 5352 0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFC 5352 0x07 ASAP_ENDPOINT_KEEP_ALIVE RFC 5352 0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFC 5352 0x09 ASAP_ENDPOINT_UNREACHABLE RFC 5352 0x0a ASAP_SERVER_ANNOUNCE RFC 5352 0x0b ASAP_COOKIE RFC 5352 0x0c ASAP_COOKIE_ECHO RFC 5352 0x0d ASAP_BUSINESS_CARD RFC 5352 0x0e ASAP_ERROR RFC 5352 0x0b-0xff (Available for Assignment) RFC 5352
Requests to register an ASAP Message Type in this table should be sent to IANA. The number must be unique. The "Specification Required" policy of [RFC5226] MUST be applied.8.2. Port Numbers
The references for the already assigned port numbers asap-tcp 3863/tcp asap-udp 3863/udp asap-sctp 3863/sctp asap-tcp-tls 3864/tcp asap-sctp-tls 3864/sctp have been updated to RFC 5352.8.3. SCTP Payload Protocol Identifier
The reference for the already assigned ASAP payload protocol identifier 11 has been updated to RFC 5352.8.4. Multicast Addresses
IANA has assigned an IPv4 multicast address (224.0.1.185) and an IPv6 multicast address (FF0X:0:0:0:0:0:0:133). The IPv4 address is part of the Internetwork Control Block (224.0.1/24).9. Security Considerations
We present a summary of the of the threats to the RSerPool architecture and describe security requirements in response in order to mitigate the threats. Next, we present the security mechanisms, based on TLS, that are implementation requirements in response to the threats. Finally, we present a chain-of-trust argument that examines critical data paths in RSerPool and shows how these paths are protected by the TLS implementation.
9.1. Summary of RSerPool Security Threats
"Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats" [RFC5355] describes the threats to the RSerPool architecture in detail and lists the security requirements in response to each threat. From the threats described in this document, the security services required for the RSerPool protocol are enumerated below. Threat 1) PE registration/de-registration flooding or spoofing. ----------- Security mechanism in response: ENRP server authenticates the PE. Threat 2) PE registers with a malicious ENRP server. ----------- Security mechanism in response: PE authenticates the ENRP server. Threats 1 and 2, taken together, result in mutual authentication of the ENRP server and the PE. Threat 3) Malicious ENRP server joins the ENRP server pool. ----------- Security mechanism in response: ENRP servers mutually authenticate. Threat 4) A PU communicates with a malicious ENRP server for handle resolution. ----------- Security mechanism in response: The PU authenticates the ENRP server. Threat 5) Replay attack. ----------- Security mechanism in response: Security protocol that has protection from replay attacks. Threat 6) Corrupted data that causes a PU to have misinformation concerning a pool handle resolution. ----------- Security mechanism in response: Security protocol that supports integrity protection. Threat 7) Eavesdropper snooping on handlespace information. ----------- Security mechanism in response: Security protocol that supports data confidentiality.
Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to
ENRP server.
-----------
Security mechanism in response: ASAP must control the number of ASAP
Endpoint unreachable messages transmitted from the PU to the ENRP
server.
Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
the ENRP server.
-----------
Security mechanism in response: ENRP server must control the number
of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE.
To summarize, the threats 1-7 require security mechanisms that
support authentication, integrity, data confidentiality, and
protection from replay attacks.
For RSerPool we need to authenticate the following:
PU <---- ENRP server (PU authenticates the ENRP server)
PE <----> ENRP server (mutual authentication)
ENRP server <-----> ENRP server (mutual authentication)
9.2. Implementing Security Mechanisms
We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather, we use an existing IETF security
protocol, specifically [RFC3237], to provide the security services
required. TLS supports all these requirements and MUST be
implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be
supported, at a minimum, by implementers of TLS for RSerPool. For
purposes of backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other IETF-approved ciphersuites.
ENRP servers, PEs, and PUs MUST implement TLS. ENRP servers and PEs
MUST support mutual authentication using PSK (pre-shared-key). ENRP
servers MUST support mutual authentication among themselves using
PSK. PUs MUST authenticate ENRP servers using certificates.
TLS with PSK is mandatory to implement as the authentication
mechanism for ENRP to ENRP authentication and PE to ENRP
authentication. For PSK, having a pre-shared-key constitutes
authorization. The network administrators of a pool need to decide
which nodes are authorized to participate in the pool. The
justification for PSK is that we assume that one administrative
domain will control and manage the server pool. This allows for PSK
to be implemented and managed by a central security administrator.
TLS with certificates is mandatory to implement as the authentication mechanism for PUs to the ENRP server. PUs MUST authenticate 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 DNS Security (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 RFC 3490. 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 in [RFC0791] and [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 a session, both parties are to 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 RFC 4511)[RFC4511]. Implementations may re-evaluate 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] or TLS over TCP, as described in [RFC5246]. When using TLS/SCTP we must ensure that RSerPool does not use any features of SCTP that are not available to a TLS/SCTP user. This is not a difficult technical problem, but simply a requirement. When describing an API of the RSerPool lower layer, we also have to take into account the differences between TLS and SCTP. Threat 8 requires the ASAP protocol to limit the number of ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5) to the ENRP server.
Threat 9 requires the ENRP protocol to limit the number of ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see [RFC5353]). There is no security mechanism defined for the multicast announcements. Therefore, a receiver of such an announcement cannot 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.9.3. 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/de-registration over TLS) secured ENRP server <---> 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 an error due to security considerations and the registration will be rejected. If an ENRP server that does not use TLS tries to update the database of a secure ENRP server, then the update will be rejected. If a 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.10. Acknowledgments
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, Thomas Dreibholz, and many others for their invaluable comments and feedback.11. 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 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., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002. [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling Policies", RFC 5356, September 2008. [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008. [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008. [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege, M., and S. Sengodan, "Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats", RFC 5355, September 2008.11.2. Informative References
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
Authors' Addresses
Randall R. Stewart The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA EMail: randall@lakerest.net Qiaobing Xie The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA Phone: +1 224-465-5954 EMail: Qiaobing.Xie@gmail.com Maureen Stillman Nokia 1167 Peachtree Ct. Naperville, IL 60540 USA EMail: maureen.stillman@nokia.com Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany EMail: tuexen@fh-muenster.de
Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.