Aggregate Server Access Protocol (ASAP)
RFC 5352

Received changes through RFC Editor sync (changed abstract to 'Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.

In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.

ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.

The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community.')

[Ballot discuss]
I don't believe this document correctly uses TLS as an authentication
mechanism.  First, it does not say _how_ the domain name is encoded
in client certificate subject.  It uses a lower case must for client
certificates.  I'll try to flesh this discuss out a bit more, but in
general I recommend looking at one of the documents applying TLS to
a specific protocol for examples in this area.  For example, RFC 4513
is a fairly recent and has a good "server identity check" section.

You would also need to create an equivalent "client identity check"
section if you're making client certificates the mandatory to implement
authentication mechanism for some scenarios.

[Ballot comment]
draft-ietf-rserpool-asap-20.txt: No-Obj
=======================================

Comments:

Section 1:

  When SCTP [RFC4960] is used as the transport layer protocol, ASAP can
  seamlessly incorporate the link-layer redundancy provided by SCTP.

Link layer? Its not just that. I think you mean ... the redundancy
provided by SCTP.

Section 2.2.2:

  Note that deregistration is NOT allowed by proxy, in other words a
  PE may only deregister itself.

I got confused here because at first I thought you had defined a
ASAP proxy role somewhere in the document. However, I think you
simply meant that the PE must de-register its own identifier.
I wonder how to check for this? Is the receiver tracking the
IP address of the sender of the register and de-register? Or
something else? If you can't test it, remove the statement.
Upon reading Section 3.2, I don't think I got any additional
clues about this.

Section 2.2.5:

  Note that if a new Home ENRP server is adopted any 'dynamic update
  request' will need to be resent to the new Home ENPR server if the
  endpoint would like to continue to receive updates.

How does the PU/PE know that a Home ENRP server has been added?

draft-ietf-rserpool-enrp-20.txt: No-Obj
=======================================

Section 3.2.1:

  Note, there is a very remote chance (about 1 in about 4 billion) that
  two ENRP servers in an operational scope will generate the same
  server Id and hence cause a server Id conflict in the pool.  However,
  no severe consequence of such a conflict has been identified.

Hmm. I thought that by the birthday paradox the chances of such a
conflict would be greater. Is there a recovery procedure upon a
conflict? Can the above text be modified to take into account the
paradox? Same issue exists in Section 3.1 of -asap.

draft-ietf-rserpool-common-param-17.txt: Yes
============================================

  This document is in good shape.

draft-ietf-rserpool-policies-09.txt: No-Obj
===========================================

  No comments.

All the documents:
==================

I am not particularly fond of the security mechanisms. They represent
the "hard-outside-soft-inside" security model. Outsiders will be
unable to pretend to be one of the parties. However, there are no
safeguards with nodes within the system becoming compromised or making
inappropriate actions for their role. For instance, the document does
not define or require the use of certificate fields to bind nodes into
particular addresses or PE/server identifiers.

As an interesting thought experiment, I wonder what RSERPOOL
security would have looked like, if it used HIP-like cryptographic
identities as server/pe identifiers?

However, I do not recommend the authors do anything abou this. Any
change here would be a major effort and not worth the time at this
stage.

IANA Last Call comments:

IANA has questions:

- Can you please verify that Message Type 0x00 is reserved, but
types 0x0b-0xff are available for assignment? If so, please update
the document to reflect this.

- What scope of IPv6 multicast address do you need?

- Do you want/need a registry of the Message Delivery Options in
section 6.5.5?

Action 1:

Upon approval of this document, the IANA will create the following
registry "ASAP Message Types" located at http://www.iana.org/assignments/TBD

Registration Procedures: Specification Required
Initial contents of this registry will be:

Type Message Name Reference
----- ------------------------- ---------
0x00 (reserved by IETF) [RFC-rserpool-asap-19]
0x01 ASAP_REGISTRATION [RFC-rserpool-asap-19]
0x02 ASAP_DEREGISTRATION [RFC-rserpool-asap-19]
0x03 ASAP_REGISTRATION_RESPONSE [RFC-rserpool-asap-19]
0x04 ASAP_DEREGISTRATION_RESPONSE [RFC-rserpool-asap-19]
0x05 ASAP_HANDLE_RESOLUTION [RFC-rserpool-asap-19]
0x06 ASAP_HANDLE_RESOLUTION_RESPONSE [RFC-rserpool-asap-19]
0x07 ASAP_ENDPOINT_KEEP_ALIVE [RFC-rserpool-asap-19]
0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK [RFC-rserpool-asap-19]
0x09 ASAP_ENDPOINT_UNREACHABLE [RFC-rserpool-asap-19]
0x0a ASAP_SERVER_ANNOUNCE [RFC-rserpool-asap-19]
0x0b ASAP_COOKIE [RFC-rserpool-asap-19]
0x0c ASAP_COOKIE_ECHO [RFC-rserpool-asap-19]
0x0d ASAP_BUSINESS_CARD [RFC-rserpool-asap-19]
0x0e ASAP_ERROR [RFC-rserpool-asap-19]
0x0b-0xff Available for assignment [RFC-rserpool-asap-19]


Action 2:

Upon approval of this document, the IANA will make the following
changes in "PORT NUMBERS" registry located at
http://www.iana.org/assignments/port-numbers

OLD:

Keyword Decimal Description References
------- ------- ----------- ----------
asap-tcp 3863/tcp asap tcp port
asap-udp 3863/udp asap udp port
# Lyndon Ong  August 2003
asap-sctp 3863/sctp asap sctp
# Lyndon Ong  November 2005
asap-tcp-tls 3864/tcp asap/tls tcp port
# Lyndon Ong  August 2003
asap-sctp-tls 3864/sctp asap-sctp/tls
# Lyndon Ong  June 2006

NEW:

Keyword Decimal Description References
------- ------- ----------- ----------
asap-tcp 3863/tcp asap tcp port [RFC-rserpool-asap-19]
asap-udp 3863/udp asap udp port [RFC-rserpool-asap-19]
# Lyndon Ong  August 2003
asap-sctp 3863/sctp asap sctp [RFC-rserpool-asap-19]
# Lyndon Ong  November 2005
asap-tcp-tls 3864/tcp asap/tls tcp port [RFC-rserpool-asap-19]
# Lyndon Ong  August 2003
asap-sctp-tls 3864/sctp asap-sctp/tls [RFC-rserpool-asap-19]
# Lyndon Ong  June 2006


Action 3:

Upon approval of this document, the IANA will make the following
changes in "SCTP Parameters - RFC 2960" registry located at
http://www.iana.org/assignments/sctp-parameters
sub-registry "SCTP Payload Protocol Identifiers"

OLD:

11 - ASAP  [Ong]

NEW:

11 - ASAP [RFC-rserpool-asap-19]


Action 4:

Upon approval of this document, the IANA will make the following
assignments in the "Internet Multicast Addresses" registry located at
http://www.iana.org/assignments/multicast-addresses
sub-registry "224.0.1.0 - 224.0.1.255 (224.0.1/24) Internetwork Control Block"

224.0.1.[TBD] ASAP [RFC-rserpool-asap-19]


Action 5:

Upon approval of this document, the IANA will make the following
assignments in the "INTERNET PROTOCOL VERSION 6 MULTICAST
ADDRESSES" registry located at
http://www.iana.org/assignments/ipv6-multicast-addresses

[TBD -- need the scope of the multicast assignment]


We understand the above to be the only IANA Actions for this
document.

RFC 4858 Writeup for ASAP, ENRP and Common Parameters specifications (draft-ietf-rserpool-asap-17.txt, draft-ietf-rserpool-enrp-17.txt and draft-ietf-rserpool-common-param-13.txt)

(1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

No Document Shepherd has been appointed for this document, the
Working Group Chairs are taking responsibility for reviewing and
Forwarding the document.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The documents have been reviewed by key WG members.

We have had a number of external comments, most particularly a detailed review and comments from Scott Bradner, former Transport AD.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No concerns that we know of.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

There are no IPR filings on any of these documents.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is strong WG consensus on these documents.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No one has threatened an appeal or otherwise objected.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Nit checker has been run on the documents successfully.  We are submitting the
Protocol documents as experimental.  The overview and threats can be either
Informational or experimental.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes, references are split as required. 

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

IANA considerations are documented in the ENRP, ASAP and Common Parameters drafts.  These are consistent with the bodies of the respective drafts.  The documents require that new registries be created for the ENRP and ASAP protocol parameters and provide initial contents of the registries plus allocation procedures for future registrations.  Naming and appropriate policies are called out for allocation of future values based on the Specification Required procedure defined in RFC 2434.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no sections written in a formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

Technical Summary

The three drafts provide a set of protocols and parameter definitions supporting Reliable Server Pooling requirements, as defined in RFC 3237.  ASAP defines a protocol for communication between server pool members and server pool users that supports functions such as server registration and lookup, liveness detection and limited failover.  ENRP defines a protocol for communication between name resolution servers that supports a fault-tolerant registry function for handling pool operation and membership information.  Parameter formats and codepoint assignments for both ASAP and ENRP are provided in a Common Parameters specification.

Working Group Summary

The Working Group process was constrained by the relatively small number of people actively involved (although those involved were committed to doing implementations of the protocols).  Otherwise there was little controversy within the group.

Document Quality

There are multiple implementations of both ENRP and ASAP protocols, thanks to participants.  However, there are no vendors that have indicated plans for implementation.  Based on this and the limited number of participants, Experimental track seems appropriate.  We received detailed comments and review from Scott Bradner and his help was greatly appreciated.

Personnel

Document Shepherding is being provided by the Working Group chairs, Maureen Stillman and Lyndon Ong.  Responsible Area Director is Magnus Westerland.