Internet DRAFT - draft-adligo-hybi-asbp
draft-adligo-hybi-asbp
INTERNET-DRAFT
expiration date: April 9, 2016
Intended status: Draft Standard
draft-adligo-hybi-asbp-02
Internet Engineering Task Force (IETF) S. Morgan
Request for Comments: Adligo Inc
Obsoletes: October 7, 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 ASCII or 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 <rfc-no> Asynchronous Services Bus Protocol October 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..................................20
9. Acknowledgements..............................................20
Author's Addresses................................................20
Morgan Standards Track [Page 2]
RFC <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 [RFC7230]). 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 MAY 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 <rfc-no> Asynchronous Services Bus Protocol October 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 ASCII or UTF-8 [RFC3629] and the data is unknown.
Morgan Standards Track [Page 5]
RFC <rfc-no> Asynchronous Services Bus Protocol October 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 ASCII or 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). The ASBP protocol header
is assumed to be ASCII but may be upgraded to the UTF-8 character
encoding by starting the header withthe '+' character.
Morgan Standards Track [Page 6]
RFC <rfc-no> Asynchronous Services Bus Protocol October 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').
Note the Deliver Command-Name 'd' is reserved for CP.
d Destination: One or more Channel-Identifiers where this
ASBP message should be sent to.
Morgan Standards Track [Page 7]
RFC <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 (see [RFC6101]). 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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 <rfc-no> Asynchronous Services Bus Protocol October 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
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
Morgan Standards Track [Page 19]
8.2. Informative References
[RFC1945] T. Berners-Lee, R. Fielding, and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
DOI 10.17487/RFC6101, August 2011,
<http://www.rfc-editor.org/info/rfc6101>.
[RFC6455] I. Fette, and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, June 2014.
[RFC7540] M. Belshe, R. Peon, and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
May 2015
Morgan Standards Track [Page 20]
RFC <rfc-no> Asynchronous Services Bus Protocol October 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 21]
