7. Timers, Variables, and Thresholds
The following is a summary of the timers, variables, and pre-set
protocol constants used in ASAP.
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
T7-ENRPoutdate - This timer gives the time a server announcement is
valid. It is normally set to 5 seconds.
stale_cache_value - A threshold variable that indicates how long a
cache entry is valid for.
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
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 (188.8.131.52) 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
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
Threat 7) Eavesdropper snooping on handlespace information.
Security mechanism in response: Security protocol that supports data
Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to
Security mechanism in response: ASAP must control the number of ASAP
Endpoint unreachable messages transmitted from the PU to the ENRP
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
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
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
Threat 9 requires the ENRP protocol to limit the number of
ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see
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
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.
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.
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
Thomas Dreibholz, and many others for their invaluable comments and
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
[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,
[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.
Randall R. Stewart
The Resource Group
1700 Pennsylvania Ave NW
Washington, D.C., 20006
The Resource Group
1700 Pennsylvania Ave NW
Washington, D.C., 20006
Phone: +1 224-465-5954
1167 Peachtree Ct.
Naperville, IL 60540
Muenster Univ. of Applied Sciences
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.
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
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