tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5352


Aggregate Server Access Protocol (ASAP)

Part 3 of 3, p. 42 to 53
Prev RFC Part


prevText      Top      Up      ToC       Page 42 
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.

Top      Up      ToC       Page 43 
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
   0x05       ASAP_HANDLE_RESOLUTION           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

Top      Up      ToC       Page 44 
   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 ( 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.

Top      Up      ToC       Page 45 
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
   integrity protection.

   Threat 7) Eavesdropper snooping on handlespace information.
   Security mechanism in response: Security protocol that supports data

Top      Up      ToC       Page 46 
   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

   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.

Top      Up      ToC       Page 47 
   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,

Top      Up      ToC       Page 48 
   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 * matches the server names
   and, but does not match or

   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

Top      Up      ToC       Page 49 
   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
   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.

Top      Up      ToC       Page 50 

   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

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.

Top      Up      ToC       Page 51 
   [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.

Top      Up      ToC       Page 52 
Authors' Addresses

   Randall R. Stewart
   The Resource Group
   1700 Pennsylvania Ave NW
   Suite 560
   Washington, D.C.,   20006


   Qiaobing Xie
   The Resource Group
   1700 Pennsylvania Ave NW
   Suite 560
   Washington, D.C.,   20006

   Phone: +1 224-465-5954

   Maureen Stillman
   1167 Peachtree Ct.
   Naperville, IL  60540


   Michael Tuexen
   Muenster Univ. of Applied Sciences
   Stegerwaldstr. 39
   48565 Steinfurt


Top      Up      ToC       Page 53 
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

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

   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