INTERNET-DRAFT expiration date: 10/07/2016 Intended status: Draft draft-adligo-hybi-asbp-01 Internet Engineering Task Force (IETF) S. Morgan Request for Comments: Adligo Inc Obsoletes: April 2016 Category: Standards Track ISSN: Asynchronous Services Bus Protocol Abstract ASBP (Asynchronous Services Bus Protocol) is a simple command based application-level protocol for routing data and messages. ASBP is intended to allow implementation of fully Asynchronous Service Bus Architectures, in a simple standardized manor. ASBP is intended to be layered over WebSocket or HTTP. The protocol consists of a simple UTF-8 key value(s) header and any arbitrary data (text, binary, XML, JSON, etc.), which the application's specific Command-Attendant or Command-Respondent processes. In addition this document touches on an extension to ASBP, CP (Conversation Protocol) a protocol used to facilitate communication between Asynchronous Service Busses implemented or hosted by different organizations. CP will be covered in more detail in another RFC still in progress. Internet-Draft This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Morgan Standards Track [Page 1] RFC Asynchronous Services Bus Protocol April 2016 Table of Contents 1. Introduction .....................................................3 1.1. Background...................................................3 1.2. Conventions and Terminology..................................3 1.3. Protocol Overview............................................5 1.3.1 ASBP Layered on HTTP...................................6 1.3.2 ASBP Layered on WebSocket..............................6 1.3.3 ASBP Layered on Extended WebSocket.....................6 1.3.4 Header Overview........................................6 1.3.4.1 Header Syntax..................................7 1.3.4.2 Reserved Header Keys...........................7 2. Asynchronous-Services-Bus Components..............................9 2.1. Channels.....................................................9 2.2. Course.......................................................9 2.3. Tubes........................................................9 2.4. Brokers......................................................8 2.5. Broker-Agents...............................................10 2.6. User Agents.................................................10 2.7. Application Agents..........................................10 3 Advantages of Asynchronous-Services-Bus Architecture.............11 3.1. Maintenance and Upgrades Without Down Time..................11 3.1.1 Large Scale Deployment Diagram..........................12 3.2. Asynchronous-Services-Bus Architecture Usage in Three Tiers.13 3.2.1 Three Tier Command Diagram..............................13 3.3. Asynchronous-Services-Bus Architecture Usage on Four+ Tiers.13 3.3.1 Four Tier Command Diagram...............................14 3.4. Unlimited Extension of Tiers................................14 3.4.1 Unlimited Tier Command Diagram..........................15 4. Protocol Versions................................................15 5. IANA Considerations..............................................15 6. Internationalization Considerations..............................16 7. Security Considerations..........................................16 7.1 Firewall Diagram.............................................16 7.2. Application-Agents Security.................................17 7.3. User-Agent Subject Security.................................17 7.3.1. User-Agent Subject Authentication....................17 7.3.2. User-Agent Subject Authorization.....................18 8. References.......................................................19 8.1. Normative References......................................19 8.2. Informative References....................................19 9. Acknowledgements................................................20 Author's Addresses..................................................20 Morgan Standards Track [Page 2] RFC Asynchronous Services Bus Protocol April 2016 1. Introduction 1.1. Background _This section is non-normative._ Over the past few decades enterprise system architecture has evolved quite dramatically with the rise of service oriented architecture, cloud computing, WebSockets, and an increasing popularity of asynchronous programming. These improvements to enterprise system architecture are all impressive on their own, however they would have a much greater impact when combined. Service oriented architecture (SOA) is fundamentally a way for enterprise architects to separate concerns, add modularization, and encapsulation to application code. However most implementations of SOA revolve around the request response paradigm, which does not facilitate notification / real time communication very well. Cloud computing allows organizations to out-source maintenance of computer hardware, high capacity bandwidth, and other cost saving advantages. However cloud computing providers seem to have hardly any interest in creating and ad-hearing to standards for the cloud computing provider industry. The large cloud computing providers seem to be interested in creating their own APIs in an attempt to block customers from moving their applications between providers or hosting their applications on multiple providers simultaneously. This creates the pseudo cloud industry standard of treating the (virtual) operating system as the common component provided by most cloud providers, which can make application architects hesitant to use any of the cloud providers custom APIs. The ASBP protocol is designed to create a simple standard to take advantage of the major evolutions in enterprise application architecture by aggregating the improvements into a abstract modular design for asynchronous enterprise services buses. Hopefully the ASBP protocol will become a standard allowing independent software vendors to build software components which use the common ASBP protocol as a standard intermediary for services. 1.2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Morgan Standards Track [Page 3] RFC Asynchronous Services Bus Protocol April 2016 The following terms are capitalized and concatenated with a dash to indicate a reference to this section; Application-Agent: A program that connects to a Broker to form a Tube, with the intention of processing (handling) Commands. Each Application-Agent MUST contain a unique Application-Agent-Identifier to the Asynchronous-Services-Bus. Application-Agents MUST allow for runtime deployment and removal of Command-Respondents. Application Agents often will manage shared resources (i.e. database connection pools), so that the Command-Respondents can perform storage and other operations (i.e. start a Hadoop application, send a email, etc.). Asynchronous-Services-Bus: A software architecture model used for designing and implementing communication between asynchronous software agents. Authenticate-Command: A Command known by the the Asynchronous-Services-Bus as the Command which has a Command-Respondent that authenticates Subjects. Authenticated-Command: A Command sent by a Subject who is currently authenticated. Broker: A application running in a web server which MUST be compatible with HTTP 1.0 (see [RFC1945]), and HTTP 1.1 (see [RFC2616]). A Broker MUST also be compatible with the WebSocket (see [RFC6455]) or the HTTP/2 (see [RFC7540]) protocol. A Broker SHOULD be compatible with all protocols mentioned. Broker-Agent: A Broker-Agent is a combination of a Broker and an Application-Agent for three tier implementations of Asynchronous-Services-Bus architecture. Broker-Agents MAY use Command-Respondents in a asynchronous or synchronous manor. Broker-Agents are NOT REQUIRED to have Application-Agent-Identifiers or runtime deployment and removal of Command-Respondents. Broker-Agents are RECOMMENDED only when migrating legacy applications to an Asynchronous-Services-Bus architecture, or when a four plus tier Asynchronous-Services-Bus architecture is NOT available. Four plus tier Asynchronous-Services-Bus architecture is RECOMMENDED. Channel: The logical (not physical) connection between a User-Agent and a Broker. A Channel MAY be a physical connection in addition to a logical connection. Morgan Standards Track [Page 4] RFC Asynchronous Services Bus Protocol April 2016 Command: The Command is a ASBP protocol message which includes a ASBP header and MAY include arbitrary data (text, XML, JSON, binary, etc.).. The Command's name MAY be obfuscated. Command-Attendant: A part of an User-Agent which attends to individual message based on the Command's name. Command-Respondent: A part of a Application-Agent, Application-Broker or Broker which responds to individual message based on the Command's name. Conversation-Address: A address similar to a email address which has a * instead of an @ (i.e. scott*adligo.com instead of scott@adligo.com). The Conversation-Address can be used to target where to send Commands that pertain to a conversation of various types (audio, audio/video, text/file, and video). Conversation-Addresses MUST NOT include the single quote character ('). Course: The logical and physical remote connection between an Brokers and or Broker-Agents from different Asynchronous Service Busses. Cracker: A entity that is attempting to compromise, or gain access and or information that they SHOULD NOT be able to access. Broker-Spoofing-Agent: A program created by a Cracker that acting like an Application-Agent in an attempt to compromise a Broker. Subject: A authenticated User-Agent user. Tube: The logical and physical remote connection between an Application-Agent and a Broker. User-Agent: The client which initiates a Channel. These are often web browsers, web applications running in browsers, mobile applications, desktop applications, and other software as a service client applications. 1.3. Protocol Overview _This section is non-normative._ The ASBP protocol is intended to be layered on existing protocols like WebSokets and HTTP (1.0, 1.1 & 2) in order to facilitate adoption and reduce the number of implementations. The protocol consists of a header similar to a HTTP Query (see Section 3.4 of [RFC3986]) followed by data of any type (text, binary, XML, JSON, etc.). The ASBP messages are always intended to be encoded/transferred a binary data, where the ASBP header is UTF-8 and the data is unknown. Morgan Standards Track [Page 5] RFC Asynchronous Services Bus Protocol April 2016 1.3.1. ASBP Layered on HTTP When the ASBP protocol is layered over HTTP 1.0 the ASBP header and OPTIONAL data MUST be placed in the Entity-Body (see 4 of [RFC1945]). In HTTP server responses which use the ASBP protocol the HTTP Content-Encoding (see 3.6 of [RFC1945]) MUST be set to "application" for binary data and the Content-Length (see 10.4 of [RFC1945]) MUST be specified. When the ASBP protocol is layered over HTTP 1.1 the ASBP header and OPTIONAL data MUST placed in the Message Body (see 3.3. of [RFC7230]). In HTTP server responses which use the ASBP protocol the HTTP Transfer-Encoding (see 3.3.1 of [RFC7230]) MUST be set to "BINARY" and the Content-Length (see 3.3.2 of [RFC7230]) MUST be specified. When the ASBP protocol is layered over HTTP/2 the ASBP header and OPTIONAL data MUST be placed in the Application data (see 6.1 of [RFC7540]). In HTTP server responses which use the ASBP protocol the HTTP Transfer-Encoding (see 3.3.1 of [RFC7230]) MUST be set to "BINARY" and the Content-Length (see 3.3.2 of [RFC7230]) MUST be specified. 1.3.2. ASBP Layered on WebSocket When the ASBP protocol is layered over WebSocket(s) the ASBP header and OPTIONAL data MUST be placed in the Application Data section (see 1.2 of [RFC6455]). 1.3.3. ASBP Layered on Extended WebSocket _This section is non-normative._ The ASBP protocol may be upgraded so that the ASBP header is separated from the Application Data section (see 1.2 of [RFC6455]) and encoded using a Sec-WebSocket-Extensions (see 11.3.2 of [RFC6455]). This document leaves the details on how this would be accomplished to other RFCs. 1.3.4. Header Overview The ASBP protocol header is a simple Key Value-Token(s) pair data structure in the UTF-8 character encoding. The ASBP protocol does NOT allow characters to be escaped, however Value-Tokens may be wrapped in single quotes to allow usage of reserved characters in Value-Token(s). Morgan Standards Track [Page 6] RFC Asynchronous Services Bus Protocol April 2016 An example ASBP header follows (Note RFC line wrap formatting); c='display text',g=['friends','country men'], d=de305d5475b4431badb2eb6b9e546014; An example ASBP message (header and data) follows (Note RFC line wrap formatting); c='display text',g=[friends,'country men'], d=de305d5475b4431badb2eb6b9e546014;Hello World! 1.3.4.1. Header Syntax The following characters are reserved by the ASBP protocol; reserved = ";" / "=" / "," / "'" / "[" / "]" All whitespace characters MUST NOT be included in a ASBP header outside of a Value-Token wrapped by single quotes. In addition Value-Tokens MUST NOT contain Carriage-Return (CR) or Line-Feed (LF) characters. The ASBP header consists of Key Value-Token(s) pairs followed by a semicolon which terminates the header. Each set of Key Value-Token(s) is separated by a comma. Each Value-Token MAY be wrapped by single quotes. If a Key has multiple Value-Tokens the Value-Tokens MUST be wrapped by square brackets, and the Value-Tokens MUST be separated by commas. 1.3.4.2. Reserved Header Keys The following chart specifies the reserved ASBP header keys and their allowed values and purpose. Most of these keys are optional and should only be used as required by the specific ASBP Commands routing requirements. Key Meaning and allowed Values a Application-Agent-Identifier: A single textual value which uniquely identifies an Application-Agent in the Asynchronous-Services-Bus. b Broker-Identifier: A single textual value that uniquely identifies the Broker within the Asynchronous-Services-Bus. c Command-Name: A single textual value, which MAY indicate what to do with the data (i.e. 'display text message'). d Destination: One or more Channel-Identifiers where this ASBP message should be sent to. Morgan Standards Track [Page 7] RFC Asynchronous Services Bus Protocol April 2016 e Encoding: The encoding (i.e. Charset name from RFC 2978 (see [RFC2978]) ASCII, UTF-8, UTF-16, etc) binary is assumed by default when this is absent. Inside of a application or enterprise encoding can also be determined by the Command's name. f Format: A OID used to identify the data type when one organization's Asynchronous Services Bus is communicating with another organization's Asynchronous Services Bus using CP. g Group: One or more group names where this ASBP message should be sent to. A group is a collection of Channel-Identifiers that is specific to a Broker. i Channel-Identifier: A single UUID (without dashes) that is created by the Broker and guaranteed to be unique at that Broker in order to identify the User-Agent Broker channel. o Of-Total: A single unsigned one based text integer of any size. This value is used to identify the order and place of this Command in a large number of Commands. (i.e. Frame 1,143 in a stream of movie frames.) m Mime Type: The mime type (see [RFC2046]) if a file is being delivered through the Command's data. This is only necessary when the Command could contain arbitrary files in the data section. r Recipient: One or more Conversation-Addresses where this Command should be sent to. This field is only used / reserved for Conversation Protocol. p Publisher: A single Conversation-Addresses identifying the Subject who published this Command. This field is only used / reserved for Conversation Protocol. s Subject-Identifier: A single UUID (without dashes) that uniquely identifies an authenticated User-Agent's subject at the Broker. The Broker MUST create and provides a unique Subject UUID for an authenticated Subject. ASBP allows standard HTTP session tracking to be overridden by the Subject-Identifier, in order to enable concurrent usage of multiple accounts with in User-Agents. t Total: A single unsigned text integer of any size. This value is used to identify the total number of ASBP messages that are expected for a large response. This key value pair should only be included with the first ASBP message in a long stream of ASBP messages. (i.e. Total number of video frames in a movie.) Morgan Standards Track [Page 8] RFC Asynchronous Services Bus Protocol April 2016 u User-Agent to Channel Command-Identifier: A single unsigned text integer unique to the User Agent Channel. The value should be between 0 and 65,563. The User Agent provides this number and should wrap back to 0 after using all 65,563 identifiers. This allows the User Agent to match request response commands, and order or skip frames when necessary. x Exchange-Command-Name: This field was added in order to encapsulate command names to a particular Asynchronous Services Bus. This field is used for the CP (Conversation Protocol) in addition to the Command-Name. This fields values MUST use OID or other mechanism which has been reserved for the CP. z Compression: The MIME type for compression used to compress the data (i.e. application/x-bzip2, application/x-lzma, application/x-gzip, etc). Note if the MIME type name starts with 'application/' the value MAY be abbreviated to include the value after the slash (i.e. x-gzip, x-bzip2). 2. Asynchronous Service Bus Components There are three major components to an Asynchronous Service Bus User-Agents, Brokers and Application-Agents. All components communicate using Commands. Commands are transported over the various network layers using Channels, Courses, and or Tubes. A Channel is the medium of network communication between a User-Agent and a Broker. A Tube is the medium of network communication between an Application-Agent and a Broker. A Course is a medium of network communication between Brokers which belong to separate Asynchronous Service Busses. 2.1. Channels A Channel MAY be layered on any of the network protocols mentioned by the ASBP protocol including HTTP 1.1 long pooling (for legacy User-Agents). Upon creation of a Channel the Broker MUST assign a Broker unique UUID to the Channel as it's Channel-Identifier. 2.2 Courses A Course MUST be layered on either a secure WebSocket or secure HTTP/2 connection. Detail on communication through Courses will be covered in the RFC for Conversation Protocol. 2.3 Tubes A Tube MUST be layered on either a secure WebSocket or secure HTTP/2 connection. Morgan Standards Track [Page 9] RFC Asynchronous Services Bus Protocol April 2016 2.4. Brokers Brokers act as the intermediary between User-Agents and Application-Agents. Commands sent to the broker MUST either originate from a User-Agent or an Application-Agent. Brokers MUST create a unique User-Agent Channel-Identifier for each User-Agent connection. Commands originating from a User-Agent are intended to be handled by a Broker's, Broker-Agent's, or Application-Agent's Command-Respondent. The Broker MAY alter the Commands header and data. The Broker MAY respond directly to the originating User-Agent. The Broker MAY send the Command to non-originating User-Agents. The Broker MAY send the Command to an Application-Agent. The Broker MAY send the Command to a Broker in another Asynchronous Services Bus. Commands originating from an Application-Agent are intended to be sent to one or more User-Agents, Brokers and or Application-Agents. The Broker MAY alter the Command's header or data. The Broker MAY respond directly to the originating Application-Agent. The Broker MAY send the Command to one or more User-Agents. The Broker MAY send the Command to one or more Application-Agents. The Broker MAY send the Command to a Broker in another Asynchronous Services Bus. 2.5. Broker-Agents Broker-Agents MUST only be used in three tier Asynchronous-Services-Bus implementations. Broker-Agents MAY be used to migrate away from legacy three tier systems or when no Broker/Application-Agent frameworks are available. Brokers-Agents MAY send Commands to the same locations as Brokers. 2.6. User-Agents Stateless (HTTP 1.0, 1.1) User-Agents MUST obtain a unique channel identifier from the Broker and submit the channel identifier with all subsequent commands. 2.7. Application-Agents Application-Agents MUST connect to Brokers using a Tube. Application-Agents MUST authenticate with the Broker during Tube connection (this is covered in more detail in Security Considerations). Application Agents MUST notify the broker of commands supported by the Application-Agent. Application-Agents MAY be created as a single program (i.e. JVM) or as a group of programs which share a Application-Agent-Identifier. Application-Agents MUST be able to add or remove Command-Respondents at runtime. Morgan Standards Track [Page 10] RFC Asynchronous Services Bus Protocol April 2016 3. Advantages of Asynchronous-Services-Bus Architecture _This section is non-normative._ Asynchronous-Services-Bus Architecture provides a number of advantages, many of which are already enjoyed today by service oriented architectures. Asynchronous-Services-Bus architecture can be easily scaled by adding additional layers of Brokers and Application-Agents. Additional resources can be added with ease while running in a production environment from almost all public clouds or private clouds. In addition since the Asynchronous-Services-Bus Architecture is designed to be compatible with most cloud service providers, switching between cloud providers to save money becomes less difficult improving ROI, and the potential risk of a single cloud provider raising prices on the organization is reduced. 3.1. Maintenance and Upgrades Without Down Time _This section is non-normative._ Medium to large installations of Asynchronous-Services-Bus architecture allow maintenance and upgrades without down time! Each of the three Asynchronous-Services-Bus components may be removed or added while the Asynchronous-Services-Bus stays in production. Morgan Standards Track [Page 11] RFC Asynchronous Services Bus Protocol April 2016 Consider the following deployment diagram when upgrading an Enterprise scale application from Version 1.0 to Version 2.0 (lines indicate network connection bundles); 3.1.1 Large Scale Deployment Diagram Application-Agent A Application-Agent B Application-Agent C | \ / \ / | | \ / \ / | | \ / \ / | | \/ \/ | | /\ /\ | | / \ / \ | | / \ / \ | | / \ / \ | | / \ / \ | | / \ / \ | | / \ / \ | Broker A Broker B Broker C \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / Domain Name System User-Agents 1) Remove Broker C from the DNS entries. 2) Shutdown Application-Agent C, Configure Application-Agent C to connect to Broker B only Start Application-Agent C 3) Shutdown Application-Agent B, Configure Application-Agent B to connect to Broker A only Start Application-Agent B 4) After 24 hours (proliferation of DNS caching), shutdown Broker C 5) Upgrade and start Broker C 6) Shutdown and Upgrade Application-Agent C Configure Application-Agent C to connect to Broker C only Start Application-Agent C 7) Add Broker C to the DNS entries At this point one third of the Asynchronous-Services-Bus is running Version 2.0. The other two thirds are running Version 1.0. Simply repeat the upgrade pattern until all nodes are running Version 2.0. Morgan Standards Track [Page 12] RFC Asynchronous Services Bus Protocol April 2016 The above upgrade procedure is actually a worse case scenario! Most of the upgrades for software running on a Asynchronous-Services-Bus can be accomplished with much less effort. Brokers have a very small amount of code, and need to be upgraded quite infrequently. New web application front ends (User-Agent) can be hot deployed and favored using URL rewriting. Application-Agents can be added and removed at any time. The Subjects SHOULD only see errors if a Broker receives Commands which are not know by any attached Application-Agents. 3.2. Asynchronous-Services-Bus Architecture Usage on Three Tiers _This section is non-normative._ Asynchronous-Services-Bus Architecture does not necessarily need a large number of servers or a complex DNS setup. Asynchronous Services Bus Architecture can be developed for a typical three tier system, and scaled as growth and demand is needed. The following diagram displays a three tier deployment of an Asynchronous-Services-Bus Architecture; 3.2.1 Three Tier Command Diagram Database or other User-Agent Broker-Agent Storage | | | --- --- --- | |----Socket---->| | | | | | ----ASBP----->| | | | | | | |-----Socket------>| | | | | |<------Data-------| | | |<----ASBP------| | | | --- --- --- | | | Diagram Note: The lines on the above diagram display both socket connections (which could be any non ASBP protocol) and Command flows. The lines which include the word Socket indicate the directionality of the network sockets. The ASBP lines do NOT show the directionality of the network sockets, but instead show the flow of the Command. 3.3. Asynchronous-Services-Bus Architecture Usage on Four+ Tiers _This section is non-normative._ Great care should be taken when writing Asynchronous Services Bus Architecture so that the great majority of Application Agent code can be simply moved to a four tier deployment. Morgan Standards Track [Page 13] RFC Asynchronous Services Bus Protocol April 2016 The following diagram displays a four tier deployment of an Asynchronous-Services-Bus Architecture; 3.3.1 Four Tier Command Diagram Database or other User-Agent Broker Application Agent Storage | | | | --- --- --- --- | | | |<-Socket--| | | | | |-----Socket--->| | | | | | | | ----ASBP----->| | | | | | | | | |--ASBP--->| | | | | | | | | |-----Socket------->| | | | | | | |<-----Data---------| | | | | |<--ASBP---| | | | | |<----ASBP------| | | | | | --- --- --- --- | | | | Diagram Note: The lines on the above diagram display both socket connections (which could be any non ASBP protocol) and ASBP Command flows. The lines which include the word Socket indicate the directionality of the network sockets. The ASBP lines do NOT show the directionality of the network sockets, but instead show the flow of the Commands. 3.4. Unlimited Extension of Tiers _This section is non-normative._ The following diagram uses the term Intermediary-Agent, which is simply a Application-Agent that is also a User-Agent in this context. The following diagram displays a unlimited tier deployment of an Asynchronous-Services-Bus Architecture; Morgan Standards Track [Page 14] RFC Asynchronous Services Bus Protocol April 2016 3.4.1 Unlimited Tier Command Diagram User-Agent Broker Intermediary-Agent Broker | | | | --- --- --- --- | |----Socket---->| |<--Socket-| |-----Socket>------>| |<-Socket | |-----ASBP----->| | | | | | | | | |---ASBP-->| | | | | | | | | |-------ASBP------->| |etc.-> | | | | | |<------ASBP--------| |<-etc. | | | |<--ASBP---| | | | | |<----ASBP------| | | | | | --- --- --- --- | | | | Diagram Note: The lines on the above diagram display both socket connections (which could be any non ASBP protocol) and ASBP Command flows. The lines which include the word Socket indicate the directionality of the network sockets. The ASBP lines do NOT show the directionality of the network sockets, but instead show the flow of the Commands. 4. Protocol Versions The initial ASBP version if accepted as a IETF standard will be 1.0. Subsequent versions of ASBP should use the following major dot minor version scheme. Major version numbers MUST only be incremented when a break in backward compatibility with the previous major version is required. Backward compatibility is always preferred. Minor version number MUST be incremented for each approved update to the Asynchronous-Services-Bus Protocol standard by the IETF. 5. IANA Considerations ASBP is layered on other protocols including HTTP and WebSockets in order to keep IANA considerations minimal for use and implementation with in organizations. There are no schemes or keywords to be registered for ASBP for use and implementation with in organizations. However, CP (Conversation Protocol) an extension to ASBP which will enable conversations by utilizing Asynchronous Service Busses from multiple organizations will require IANA considerations. In particular the Exchange-Command-Names and Formats will require a OID to extend from for each extension. Morgan Standards Track [Page 15] RFC Asynchronous Services Bus Protocol April 2016 6. Internationalization Considerations The only internationalization consideration was to require the ASBP header to be encoded in UTF-8, so that command names and other values could use non English languages. 7. Security Considerations _This section is non-normative._ This section describes some security considerations applicable to ASBP. ASBP relies on the protocols it is layered on to provide details on how to secure usage of ASBP, namely HTTP, or WebSocket over SSL. This section focuses on topics not covered by the secure protocol layers which ASBP supports. The ASBP protocol originally started as a Java application framework called the ASDC (Adligo Secure Data Connector), which was inspired by the Google Secure Data Connector. One of the initial goals of the protocol and framework was to allow data centers to protect themselves better by blocking all in bound fire wall ports as follows. 7.1 Firewall Diagram Application-Agent Firewall A Broker Firewall B User-Agent | | | | | --- --- --- --- --- | | | | | | | | | | | | --------ASBP------------>| | | | | | | | | | | | | | | | | | | | | | <-------ASBP----------| | | | | | | | | | | | --- --- --- --- --- | | | | | Firewall A would not require any open in bound ports since the Application-Agent dials out to the Broker. If two Application-Agents were hosted at different data centers they could synchronize data stores through the Brokers. Data centers could also synchronize data stores through actual private networks, or virtual private networks. Virtual private network synchronization would require opening up some in bound ports, however even in this case data center is much more difficult to breach even when the Broker layer is compromised. Firewall B would require standard ports to be open (i.e. 80, 443) for public web applications. Other ports could be open for non standard applications as well (i.e. 22, 8080, etc.) Morgan Standards Track [Page 16] RFC Asynchronous Services Bus Protocol April 2016 Using this design also allows the Broker's SSL certificates to be used for both Tubes and Channels. This reduces the number of SSL certificate installations by roughly half for end to end SSL in most applications. 7.2. Application-Agents Security _This section is non-normative._ Application-Agents must authenticate with the Broker in order to prove that they are the agents which are suppose to be handling the Commands. Failure to create an extra strong authentication mechanism from the Application-Agent to the Broker would enable a new type of application attack 'Application-Agent spoofing'. A Application-Agent spoofing attack would occur when a Cracker creates a program (Broker-Spoofing-Agent) that attempts to connect to a Broker in the same manor as a Application-Agent. If the Broker-Spoofing-Agent was able to successfully connect to a Broker, it could potentially receive Commands pertaining to Subject credentials or other sensitive data. The ASBP protocol does not attempt to create any sort of a standard for Application-Agent to Broker authenticate. It is believed that each organization that uses a Asynchronous-Service-Bus with the ASBP protocol should develop their own unique authentication mechanism. By not specifying a standard here, users of the protocol will create a more secure web through diversity, and Crackers will have more difficulty compromising the systems because they all work differently. 7.3. User-Agent Subject Security The ASBP protocol supports multiple Subjects using a particular User-Agent. Brokers and Broker-Agents MUST allow multiple Subjects to authenticate from a single User-Agent. Brokers and Broker-Agents MAY also allow the single Subject/User-Agent authentication session methodology in use by most web applications today. ASBP REQUIRES multiple Subject per User-Agent in order to allow a user to use multiple accounts in a web application, and to facilitate more efficient use of User-Agent (browsers) resources during concurrent testing of Asynchronous-Service-Bus applications. 7.3.1. User-Agent Subject Authentication The ASBP protocol facilitates Subject based authentication at the Broker-Agent, and Application-Agent tiers. The ASBP protocol provides Subject-Identifier and Broker-Identifiers to allow authentication security as follows. Morgan Standards Track [Page 17] RFC Asynchronous Services Bus Protocol April 2016 When the Broker receives a authentication attempt from a User-Agent's Subject the Broker MUST create a Subject-Identifier (a UUID unique to the Broker). Next the Broker MUST modify or create a ASBP header appending the Subject-Identifier and the Broker-Identifier, before sending the Authentication-Command to one or more Application-Agents which are known to process the Authenticate-Command. This allows the Application-Agents to be aware of which Broker the Subject authenticated through, and the Subject-Identifier at that Broker. After a successful authentication the Application-Agent MUST return the Subjects model through a Command which includes the Application-Agent-Identifier to the Broker. Broker MUST return the Subject-Identifier through a 'authentication successful' Command to the User-Agent. When the Broker-Agent receives a authentication attempt from a User-Agent's Subject the Broker MUST create a Subject-Identifier (a UUID unique to the Broker). The Broker-Agent would then find a Command-Respondent to authenticate the Subject from the Broker-Agent tier. User-Agents that are state-less MUST provide the Subject-Identifier in the ASBP header in all subsequent Authenticated-Commands. If the Broker or Broker-Agent is using the single Subject per User-Agent paradigm it MAY use the HTTP sessions identifier to locate the Subject-Identifier. The Broker MUST keep track of which Application-Agents have authenticated particular Subjects, in order for Application-Agents to correctly process authorization. The Broker MUST only submit Commands to Application-Agents that have authenticated the Subject for subsequent Authenticated-Commands. The Broker MUST ensure inclusion of the Subject-Identifier in all subsequent Authenticated-Commands that are sent to the Application-Agents. 7.3.2. User-Agent Subject Authorization The ASBP protocol facilitates Subject based authorization security at the Broker, Broker-Agent, and Application-Agent layers. The ASBP protocol does not specify or suggest any particular structure for Subject authorization models, however it is designed to support common ACL, LDAP User/Group/Role isInRole(X) style authorization security with out knowledge of implementation. Morgan Standards Track [Page 18] RFC Asynchronous Services Bus Protocol April 2016 Application-Agents, Brokers, Broker-Agents and User-Agents MAY all perform authorization security checks. User-Agents authorization security checks are considered informative to the Subject only, and MUST NOT be relied on to prevent unauthorized Command usage. User-Agent authorization checks SHOULD obfuscate the names of roles if isInRole(X) style checks are used. Broker, Broker-Agent, and Application-Agent authorization security checks are considered a reliable way to prevent unauthorized Command usage. Most Asynchronous-Services-Bus implementations SHOULD attempt to reuse code for identical authorization security check in the Broker, Broker-Agent and Application-Agent layers. 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 [RFC2978] N. Freed, J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC6455] I. Fette, and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011 [RFC7540] M. Belshe, R. Peon, and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, May 2015 8.2. Informative References [RFC1945] T. Berners-Lee, R. Fielding, and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996 [RFC6101] A. Freier, P. Karlton, and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011 [RFC7322] H. Flanagan, and S. Ginoza "RFC Style Guide", RFC 7322, September 2014 Morgan Standards Track [Page 19] RFC Asynchronous Services Bus Protocol April 2016 9. Acknowledgements Note I am waiting on a response from this thread to acknowledge the authors of the Google Secure Data Connector; https://groups.google.com/forum/#!topic/google-sdc/fL4TsSxZD_Q Author's Addresses Scott Morgan scott@adligo.com Adligo Inc http://www.adligo.com expiration date: 10/07/2016 Morgan Standards Track [Page 20]