idnits 2.17.1 draft-adligo-hybi-asbp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2016) is 2751 days in the past. Is this intentional? Checking references for intended status: Draft Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 expiration date: April 9, 2016 3 Intended status: Draft Standard 5 draft-adligo-hybi-asbp-02 6 Internet Engineering Task Force (IETF) S. Morgan 7 Request for Comments: Adligo Inc 8 Obsoletes: October 7, 2016 9 Category: Standards Track 10 ISSN: 12 Asynchronous Services Bus Protocol 14 Abstract 16 ASBP (Asynchronous Services Bus Protocol) is a simple command based 17 application-level protocol for routing data and messages. ASBP 18 is intended to allow implementation of fully Asynchronous 19 Service Bus Architectures, in a simple standardized 20 manor. ASBP is intended to be layered over 21 WebSocket or HTTP. The protocol consists of a simple ASCII or UTF-8 22 key value(s) header and any arbitrary data (text, binary, XML, JSON, 23 etc.), which the application's specific Command-Attendant or 24 Command-Respondent processes. In addition this document touches on 25 an extension to ASBP, CP (Conversation Protocol) a protocol used 26 to facilitate communication between Asynchronous Service Busses 27 implemented or hosted by different organizations. CP will be 28 covered in more detail in another RFC still in progress. 30 Internet-Draft 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current 38 Internet-Drafts is at http://datatracker.ietf.org/drafts/current. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other 42 documents at any time. It is inappropriate to use Internet- 43 Drafts as reference material or to cite them other than as 44 "work in progress. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. 58 RFC Asynchronous Services Bus Protocol October 2016 60 Table of Contents 62 1. Introduction ...................................................3 63 1.1. Background.................................................3 64 1.2. Conventions and Terminology................................3 65 1.3. Protocol Overview..........................................5 66 1.3.1 ASBP Layered on HTTP.................................6 67 1.3.2 ASBP Layered on WebSocket............................6 68 1.3.3 ASBP Layered on Extended WebSocket...................6 69 1.3.4 Header Overview......................................6 70 1.3.4.1 Header Syntax................................7 71 1.3.4.2 Reserved Header Keys.........................7 72 2. Asynchronous-Services-Bus Components............................9 73 2.1. Channels...................................................9 74 2.2. Course.....................................................9 75 2.3. Tubes......................................................9 76 2.4. Brokers....................................................8 77 2.5. Broker-Agents.............................................10 78 2.6. User Agents...............................................10 79 2.7. Application Agents........................................10 80 3 Advantages of Asynchronous-Services-Bus Architecture...........11 81 3.1. Maintenance and Upgrades Without Down Time................11 82 3.1.1 Large Scale Deployment Diagram........................12 83 3.2. Asynchronous-Services-Bus Architecture Usage in 84 Three Tiers..........................................13 85 3.2.1 Three Tier Command Diagram............................13 86 3.3. Asynchronous-Services-Bus Architecture Usage on 87 Four+ Tiers..........................................13 88 3.3.1 Four Tier Command Diagram.............................14 89 3.4. Unlimited Extension of Tiers..............................14 90 3.4.1 Unlimited Tier Command Diagram........................15 91 4. Protocol Versions..............................................15 92 5. IANA Considerations............................................15 93 6. Internationalization Considerations............................16 94 7. Security Considerations........................................16 95 7.1 Firewall Diagram...........................................16 96 7.2. Application-Agents Security...............................17 97 7.3. User-Agent Subject Security...............................17 98 7.3.1. User-Agent Subject Authentication..................17 99 7.3.2. User-Agent Subject Authorization...................18 100 8. References.....................................................19 101 8.1. Normative References....................................19 102 8.2. Informative References..................................20 103 9. Acknowledgements..............................................20 104 Author's Addresses................................................20 106 RFC Asynchronous Services Bus Protocol October 2016 108 1. Introduction 110 1.1. Background 112 _This section is non-normative._ 114 Over the past few decades enterprise system architecture has evolved 115 quite dramatically with the rise of service oriented architecture, 116 cloud computing, WebSockets, and an increasing popularity of 117 asynchronous programming. These improvements to enterprise 118 system architecture are all impressive on their own, however they 119 would have a much greater impact when combined. 121 Service oriented architecture (SOA) is fundamentally a way for 122 enterprise architects to separate concerns, add modularization, and 123 encapsulation to application code. However most implementations of 124 SOA revolve around the request response paradigm, which does not 125 facilitate notification / real time communication very well. 127 Cloud computing allows organizations to out-source maintenance 128 of computer hardware, high capacity bandwidth, and other cost saving 129 advantages. However cloud computing providers seem to have hardly 130 any interest in creating and ad-hearing to standards for the cloud 131 computing provider industry. The large cloud computing providers 132 seem to be interested in creating their own APIs in an attempt to 133 block customers from moving their applications between providers or 134 hosting their applications on multiple providers simultaneously. 135 This creates the pseudo cloud industry standard of treating the 136 (virtual) operating system as the common component provided by 137 most cloud providers, which can make application architects 138 hesitant to use any of the cloud providers custom APIs. 140 The ASBP protocol is designed to create a simple standard to take 141 advantage of the major evolutions in enterprise application 142 architecture by aggregating the improvements into a abstract modular 143 design for asynchronous enterprise services buses. Hopefully the 144 ASBP protocol will become a standard allowing independent software 145 vendors to build software components which use the common ASBP 146 protocol as a standard intermediary for services. 148 1.2. Conventions and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 RFC Asynchronous Services Bus Protocol October 2016 156 The following terms are capitalized and concatenated with a dash to 157 indicate a reference to this section; 159 Application-Agent: A program that connects to a Broker to form a 160 Tube, with the intention of processing (handling) Commands. 161 Each Application-Agent MUST contain a unique 162 Application-Agent-Identifier to the Asynchronous-Services-Bus. 163 Application-Agents MUST allow for runtime deployment and 164 removal of Command-Respondents. Application Agents often will 165 manage shared resources (i.e. database connection pools), 166 so that the Command-Respondents can perform storage and other 167 operations (i.e. start a Hadoop application, send a email, 168 etc.). 170 Asynchronous-Services-Bus: A software architecture model used for 171 designing and implementing communication between asynchronous 172 software agents. 174 Authenticate-Command: A Command known by the the 175 Asynchronous-Services-Bus as the Command which 176 has a Command-Respondent that authenticates Subjects. 178 Authenticated-Command: A Command sent by a Subject 179 who is currently authenticated. 181 Broker: A application running in a web server which MUST be 182 compatible with HTTP 1.0 (see [RFC1945]), and HTTP 1.1 183 (see [RFC7230]). A Broker MUST also be compatible with 184 the WebSocket (see [RFC6455]) or the HTTP/2 (see [RFC7540]) 185 protocol. A Broker SHOULD be compatible with all protocols 186 mentioned. 188 Broker-Agent: A Broker-Agent is a combination of a Broker 189 and an Application-Agent for three tier implementations of 190 Asynchronous-Services-Bus architecture. Broker-Agents MAY 191 use Command-Respondents in a asynchronous or synchronous 192 manor. Broker-Agents are MAY to have 193 Application-Agent-Identifiers or runtime deployment and 194 removal of Command-Respondents. Broker-Agents are 195 RECOMMENDED only when migrating legacy applications to an 196 Asynchronous-Services-Bus architecture, or when a four plus 197 tier Asynchronous-Services-Bus architecture is NOT available. 198 Four plus tier Asynchronous-Services-Bus 199 architecture is RECOMMENDED. 201 Channel: The logical (not physical) connection between a 202 User-Agent and a Broker. A Channel MAY be a 203 physical connection in addition to a logical connection. 205 RFC Asynchronous Services Bus Protocol October 2016 207 Command: The Command is a ASBP protocol message which includes a 208 ASBP header and MAY include arbitrary data (text, XML, JSON, 209 binary, etc.).. The Command's name MAY be obfuscated. 211 Command-Attendant: A part of an User-Agent which attends to 212 individual message based on the Command's name. 214 Command-Respondent: A part of a Application-Agent, 215 Application-Broker or Broker which responds to 216 individual message based on the Command's name. 218 Conversation-Address: A address similar to a email address 219 which has a * instead of an @ (i.e. scott*adligo.com 220 instead of scott@adligo.com). The Conversation-Address 221 can be used to target where to send Commands that pertain 222 to a conversation of various types (audio, audio/video, 223 text/file, and video). Conversation-Addresses MUST NOT 224 include the single quote character ('). 226 Course: The logical and physical remote connection between an 227 Brokers and or Broker-Agents from different Asynchronous 228 Service Busses. 230 Cracker: A entity that is attempting to compromise, or gain access 231 and or information that they SHOULD NOT be able to access. 233 Broker-Spoofing-Agent: A program created by a Cracker that acting 234 like an Application-Agent in an attempt to compromise a Broker. 236 Subject: A authenticated User-Agent user. 238 Tube: The logical and physical remote connection between an 239 Application-Agent and a Broker. 241 User-Agent: The client which initiates a Channel. These are often 242 web browsers, web applications running in browsers, 243 mobile applications, desktop applications, and other 244 software as a service client applications. 246 1.3. Protocol Overview 248 _This section is non-normative._ 250 The ASBP protocol is intended to be layered on existing 251 protocols like WebSokets and HTTP (1.0, 1.1 & 2) in order to 252 facilitate adoption and reduce the number of implementations. 253 The protocol consists of a header similar to a HTTP Query (see 254 Section 3.4 of [RFC3986]) followed by data of any type 255 (text, binary, XML, JSON, etc.). The ASBP messages are always 256 intended to be encoded/transferred a binary data, where the ASBP 257 header is ASCII or UTF-8 [RFC3629] and the data is unknown. 259 RFC Asynchronous Services Bus Protocol October 2016 261 1.3.1. ASBP Layered on HTTP 263 When the ASBP protocol is layered over HTTP 1.0 the ASBP 264 header and OPTIONAL data MUST be placed in the Entity-Body 265 (see 4 of [RFC1945]). In HTTP server responses which use the 266 ASBP protocol the HTTP Content-Encoding (see 3.6 of [RFC1945]) 267 MUST be set to "application" for binary data and the Content-Length 268 (see 10.4 of [RFC1945]) MUST be specified. 270 When the ASBP protocol is layered over HTTP 1.1 the ASBP 271 header and OPTIONAL data MUST placed in the Message Body 272 (see 3.3. of [RFC7230]). In HTTP server responses which use the 273 ASBP protocol the HTTP Transfer-Encoding (see 3.3.1 of [RFC7230]) 274 MUST be set to "BINARY" and the Content-Length 275 (see 3.3.2 of [RFC7230]) MUST be specified. 277 When the ASBP protocol is layered over HTTP/2 the ASBP 278 header and OPTIONAL data MUST be placed in the Application data 279 (see 6.1 of [RFC7540]). In HTTP server responses which use the 280 ASBP protocol the HTTP Transfer-Encoding (see 3.3.1 of [RFC7230]) 281 MUST be set to "BINARY" and the Content-Length 282 (see 3.3.2 of [RFC7230]) MUST be specified. 284 1.3.2. ASBP Layered on WebSocket 286 When the ASBP protocol is layered over WebSocket(s) the ASBP 287 header and OPTIONAL data MUST be placed in the Application Data 288 section (see 1.2 of [RFC6455]). 290 1.3.3. ASBP Layered on Extended WebSocket 292 _This section is non-normative._ 294 The ASBP protocol may be upgraded so that the ASBP header 295 is separated from the Application Data section 296 (see 1.2 of [RFC6455]) and encoded using a 297 Sec-WebSocket-Extensions (see 11.3.2 of [RFC6455]). 298 This document leaves the details on how this would be 299 accomplished to other RFCs. 301 1.3.4. Header Overview 303 The ASBP protocol header is a simple Key Value-Token(s) pair data 304 structure in the ASCII or UTF-8 character encoding. The ASBP 305 protocol does NOT allow characters to be escaped, however 306 Value-Tokens may be wrapped in single quotes to allow usage of 307 reserved characters in Value-Token(s). The ASBP protocol header 308 is assumed to be ASCII but may be upgraded to the UTF-8 character 309 encoding by starting the header withthe '+' character. 311 RFC Asynchronous Services Bus Protocol October 2016 313 An example ASBP header follows (Note RFC line wrap formatting); 315 c='display text',g=['friends','country men'], 316 d=de305d5475b4431badb2eb6b9e546014; 318 An example ASBP message (header and data) follows 319 (Note RFC line wrap formatting); 321 c='display text',g=[friends,'country men'], 322 +d=de305d5475b4431badb2eb6b9e546014;Hello World! 324 1.3.4.1. Header Syntax 326 The following characters are reserved by the ASBP protocol; 328 reserved = ";" / "=" / "," / "'" / "[" / "]" / "+" 330 All whitespace characters MUST NOT be included in a ASBP header 331 outside of a Value-Token wrapped by single quotes. In 332 addition Value-Tokens MUST NOT contain Carriage-Return (CR) or 333 Line-Feed (LF) characters. 335 The ASBP header consists of Key Value-Token(s) pairs followed by a 336 semicolon which terminates the header. Each set of Key 337 Value-Token(s) is separated by a comma. Each Value-Token MAY be 338 wrapped by single quotes. If a Key has multiple Value-Tokens the 339 Value-Tokens MUST be wrapped by square brackets, and the 340 Value-Tokens MUST be separated by commas. 342 1.3.4.2. Reserved Header Keys 344 The following chart specifies the reserved ASBP header keys and 345 their allowed values and purpose. Most of these keys are optional 346 and should only be used as required by the specific ASBP Commands 347 routing requirements. 349 Key Meaning and allowed Values 350 a Application-Agent-Identifier: A single textual value 351 which uniquely identifies an Application-Agent in the 352 Asynchronous-Services-Bus. 354 b Broker-Identifier: A single textual value that uniquely 355 identifies the Broker within the Asynchronous-Services-Bus. 357 c Command-Name: A single textual value, which MAY indicate 358 what to do with the data (i.e. 'display text message'). 359 Note the Deliver Command-Name 'd' is reserved for CP. 361 d Destination: One or more Channel-Identifiers where this 362 ASBP message should be sent to. 364 RFC Asynchronous Services Bus Protocol October 2016 366 e Encoding: The encoding (i.e. Charset name from RFC 2978 367 (see [RFC2978]) ASCII, UTF-8, UTF-16, etc) binary is assumed 368 by default when this is absent. Inside of a application or 369 enterprise encoding can also be determined by the Command's 370 name. 372 f Format: A OID used to identify the data type 373 when one organization's Asynchronous Services Bus is 374 communicating with another organization's 375 Asynchronous Services Bus using CP. 377 g Group: One or more group names where this ASBP message 378 should be sent to. A group is a collection of 379 Channel-Identifiers that is specific to a Broker. 381 i Channel-Identifier: A single UUID (without dashes) that is 382 created by the Broker and guaranteed to be unique at that 383 Broker in order to identify the User-Agent Broker channel. 385 o Of-Total: A single unsigned one based text integer of any 386 size. This value is used to identify the order and place 387 of this Command in a large number of Commands. 388 (i.e. Frame 1,143 in a stream of movie frames.) 390 m Mime Type: The mime type (see [RFC2046]) if a file is being 391 delivered through the Command's data. This is only 392 necessary when the Command could contain arbitrary files in 393 the data section. 395 r Recipient: One or more Conversation-Addresses where this 396 Command should be sent to. This field is only used / 397 reserved for Conversation Protocol. 399 p Publisher: A single Conversation-Addresses identifying 400 the Subject who published this Command. This field is only 401 used / reserved for Conversation Protocol. 403 s Subject-Identifier: A single UUID (without dashes) that 404 uniquely identifies an authenticated User-Agent's subject 405 at the Broker. The Broker MUST create and provides a unique 406 Subject UUID for an authenticated Subject. ASBP allows 407 standard HTTP session tracking to be overridden by the 408 Subject-Identifier, in order to enable concurrent usage of 409 multiple accounts with in User-Agents. 411 t Total: A single unsigned text integer of any size. This 412 value is used to identify the total number of ASBP messages 413 that are expected for a large response. This key value pair 414 should only be included with the first ASBP message in a 415 long stream of ASBP messages. (i.e. Total number of video 416 frames in a movie.) 418 RFC Asynchronous Services Bus Protocol October 2016 420 u User-Agent to Channel Command-Identifier: A single unsigned 421 text integer unique to the User Agent Channel. The value 422 should be between 0 and 65,563. The User Agent provides 423 this number and should wrap back to 0 after using all 424 65,563 identifiers. This allows the User Agent to 425 match request response commands, and order or skip frames 426 when necessary. 428 x Exchange-Command-Name: This field was added in order to 429 encapsulate command names to a particular Asynchronous 430 Services Bus. This field is used for the CP (Conversation 431 Protocol) in addition to the Command-Name. This fields 432 values MUST use OID or other mechanism which has been 433 reserved for the CP. 435 z Compression: The MIME type for compression used to compress 436 the data (i.e. application/x-bzip2, application/x-lzma, 437 application/x-gzip, etc). Note if the MIME type name 438 starts with 'application/' the value MAY be abbreviated 439 to include the value after the slash (i.e. x-gzip, x-bzip2). 441 2. Asynchronous Service Bus Components 443 There are three major components to an Asynchronous Service Bus 444 User-Agents, Brokers and Application-Agents. All components 445 communicate using Commands. Commands are transported over the 446 various network layers using Channels, Courses, and or Tubes. A 447 Channel is the medium of network communication between a 448 User-Agent and a Broker. A Tube is the medium of network 449 communication between an Application-Agent and a Broker. A 450 Course is a medium of network communication between Brokers 451 which belong to separate Asynchronous Service Busses. 453 2.1. Channels 455 A Channel MAY be layered on any of the network protocols mentioned 456 by the ASBP protocol including HTTP 1.1 long pooling (for legacy 457 User-Agents). Upon creation of a Channel the Broker MUST assign 458 a Broker unique UUID to the Channel as it's Channel-Identifier. 460 2.2 Courses 462 A Course MUST be layered on either a secure WebSocket or 463 secure HTTP/2 connection. Detail on communication through Courses 464 will be covered in the RFC for Conversation Protocol. 466 2.3 Tubes 468 A Tube MUST be layered on either a secure WebSocket or 469 secure HTTP/2 connection. 471 RFC Asynchronous Services Bus Protocol October 2016 473 2.4. Brokers 475 Brokers act as the intermediary between User-Agents and 476 Application-Agents. Commands sent to the broker MUST either 477 originate from a User-Agent or an Application-Agent. Brokers 478 MUST create a unique User-Agent Channel-Identifier for each 479 User-Agent connection. 481 Commands originating from a User-Agent are intended to be handled by 482 a Broker's, Broker-Agent's, or Application-Agent's 483 Command-Respondent. The Broker MAY alter the Commands header and 484 data. The Broker MAY respond directly to the originating 485 User-Agent. The Broker MAY send the Command to non-originating 486 User-Agents. The Broker MAY send the Command to an 487 Application-Agent. The Broker MAY send the Command to a Broker in 488 another Asynchronous Services Bus. 490 Commands originating from an Application-Agent are intended to be 491 sent to one or more User-Agents, Brokers and or Application-Agents. 492 The Broker MAY alter the Command's header or data. The Broker MAY 493 respond directly to the originating Application-Agent. The Broker 494 MAY send the Command to one or more User-Agents. The Broker MAY 495 send the Command to one or more Application-Agents. The Broker MAY 496 send the Command to a Broker in another Asynchronous Services Bus. 498 2.5. Broker-Agents 500 Broker-Agents MUST only be used in three tier 501 Asynchronous-Services-Bus implementations. Broker-Agents MAY be 502 used to migrate away from legacy three tier systems or when no 503 Broker/Application-Agent frameworks are available. Brokers-Agents 504 MAY send Commands to the same locations as Brokers. 506 2.6. User-Agents 508 Stateless (HTTP 1.0, 1.1) User-Agents MUST obtain a unique channel 509 identifier from the Broker and submit the channel identifier with 510 all subsequent commands. 512 2.7. Application-Agents 514 Application-Agents MUST connect to Brokers using a Tube. 515 Application-Agents MUST authenticate with the Broker during 516 Tube connection (this is covered in more detail in Security 517 Considerations). Application Agents MUST notify the broker of 518 commands supported by the Application-Agent. 520 Application-Agents MAY be created as a single program (i.e. JVM) 521 or as a group of programs which share a 522 Application-Agent-Identifier. Application-Agents MUST be able to 523 add or remove Command-Respondents at runtime. 525 RFC Asynchronous Services Bus Protocol October 2016 527 3. Advantages of Asynchronous-Services-Bus Architecture 529 _This section is non-normative._ 531 Asynchronous-Services-Bus Architecture provides a number of 532 advantages, many of which are already 533 enjoyed today by service oriented architectures. 534 Asynchronous-Services-Bus architecture can be easily scaled by 535 adding additional layers of Brokers and Application-Agents. 536 Additional resources can be added with ease while running in a 537 production environment from almost all public clouds or private 538 clouds. In addition since the Asynchronous-Services-Bus 539 Architecture is designed to be compatible with most 540 cloud service providers, switching between cloud providers to save 541 money becomes less difficult improving ROI, and the potential risk 542 of a single cloud provider raising prices on the organization is 543 reduced. 545 3.1. Maintenance and Upgrades Without Down Time 547 _This section is non-normative._ 549 Medium to large installations of Asynchronous-Services-Bus 550 architecture allow maintenance and upgrades without down time! 551 Each of the three Asynchronous-Services-Bus components may be 552 removed or added while the Asynchronous-Services-Bus stays in 553 production. 555 RFC Asynchronous Services Bus Protocol October 2016 557 Consider the following deployment diagram when upgrading 558 an Enterprise scale application from Version 1.0 to Version 2.0 559 (lines indicate network connection bundles); 561 3.1.1 Large Scale Deployment Diagram 563 Application-Agent A Application-Agent B Application-Agent C 564 | \ / \ / | 565 | \ / \ / | 566 | \ / \ / | 567 | \/ \/ | 568 | /\ /\ | 569 | / \ / \ | 570 | / \ / \ | 571 | / \ / \ | 572 | / \ / \ | 573 | / \ / \ | 574 | / \ / \ | 575 Broker A Broker B Broker C 576 \ | / 577 \ | / 578 \ | / 579 \ | / 580 \ | / 581 \ | / 582 \ | / 583 \ | / 584 \ | / 585 \ | / 586 \ | / 587 Domain Name System 588 User-Agents 590 1) Remove Broker C from the DNS entries. 591 2) Shutdown Application-Agent C, 592 Configure Application-Agent C to connect to Broker B only 593 Start Application-Agent C 594 3) Shutdown Application-Agent B, 595 Configure Application-Agent B to connect to Broker A only 596 Start Application-Agent B 597 4) After 24 hours (proliferation of DNS caching), 598 shutdown Broker C 599 5) Upgrade and start Broker C 600 6) Shutdown and Upgrade Application-Agent C 601 Configure Application-Agent C to connect to Broker C only 602 Start Application-Agent C 603 7) Add Broker C to the DNS entries 605 At this point one third of the Asynchronous-Services-Bus is running 606 Version 2.0. The other two thirds are running Version 1.0. Simply 607 repeat the upgrade pattern until all nodes are running Version 2.0. 609 RFC Asynchronous Services Bus Protocol October 2016 611 The above upgrade procedure is actually a worse case scenario! 612 Most of the upgrades for software running on a 613 Asynchronous-Services-Bus can be accomplished with much less effort. 614 Brokers have a very small amount of code, and need to be upgraded 615 quite infrequently. New web application front ends (User-Agent) 616 can be hot deployed and favored using URL rewriting. 617 Application-Agents can be added and removed at any time. The 618 Subjects SHOULD only see errors if a Broker receives Commands 619 which are not know by any attached Application-Agents. 621 3.2. Asynchronous-Services-Bus Architecture Usage on Three Tiers 623 _This section is non-normative._ 625 Asynchronous-Services-Bus Architecture does not necessarily need 626 a large number of servers or a complex DNS setup. Asynchronous 627 Services Bus Architecture can be developed for a typical three 628 tier system, and scaled as growth and demand is needed. 630 The following diagram displays a three tier deployment of an 631 Asynchronous-Services-Bus Architecture; 633 3.2.1 Three Tier Command Diagram 634 Database or other 635 User-Agent Broker-Agent Storage 636 | | | 637 --- --- --- 638 | |----Socket---->| | | | 639 | | ----ASBP----->| | | | 640 | | | |-----Socket------>| | 641 | | | |<------Data-------| | 642 | |<----ASBP------| | | | 643 --- --- --- 644 | | | 646 Diagram Note: The lines on the above diagram display both socket 647 connections (which could be any non ASBP protocol) and 648 Command flows. The lines which include the word Socket indicate 649 the directionality of the network sockets. The ASBP lines do 650 NOT show the directionality of the network sockets, but instead 651 show the flow of the Command. 653 3.3. Asynchronous-Services-Bus Architecture Usage on Four+ Tiers 655 _This section is non-normative._ 657 Great care should be taken when writing Asynchronous Services 658 Bus Architecture so that the great majority of Application 659 Agent code can be simply moved to a four tier deployment. 661 RFC Asynchronous Services Bus Protocol October 2016 663 The following diagram displays a four tier deployment of an 664 Asynchronous-Services-Bus Architecture; 666 3.3.1 Four Tier Command Diagram 668 Database or other 669 User-Agent Broker Application Agent Storage 670 | | | | 671 --- --- --- --- 672 | | | |<-Socket--| | | | 673 | |-----Socket--->| | | | | | 674 | | ----ASBP----->| | | | | | 675 | | | |--ASBP--->| | | | 676 | | | | | |-----Socket------->| | 677 | | | | | |<-----Data---------| | 678 | | | |<--ASBP---| | | | 679 | |<----ASBP------| | | | | | 680 --- --- --- --- 681 | | | | 683 Diagram Note: The lines on the above diagram display both socket 684 connections (which could be any non ASBP protocol) and ASBP 685 Command flows. The lines which include the word Socket indicate 686 the directionality of the network sockets. The ASBP lines do 687 NOT show the directionality of the network sockets, but instead 688 show the flow of the Commands. 690 3.4. Unlimited Extension of Tiers 692 _This section is non-normative._ 694 The following diagram uses the term Intermediary-Agent, which 695 is simply a Application-Agent that is also a User-Agent in this 696 context. The following diagram displays a unlimited tier 697 deployment of an Asynchronous-Services-Bus Architecture; 699 RFC Asynchronous Services Bus Protocol October 2016 701 3.4.1 Unlimited Tier Command Diagram 703 User-Agent Broker Intermediary-Agent Broker 704 | | | | 705 --- --- --- --- 706 | |----Socket---->| |<--Socket-| |-----Socket>------>| |<-Socket 707 | |-----ASBP----->| | | | | | 708 | | | |---ASBP-->| | | | 709 | | | | | |-------ASBP------->| |etc.-> 710 | | | | | |<------ASBP--------| |<-etc. 711 | | | |<--ASBP---| | | | 712 | |<----ASBP------| | | | | | 713 --- --- --- --- 714 | | | | 716 Diagram Note: The lines on the above diagram display both socket 717 connections (which could be any non ASBP protocol) and ASBP 718 Command flows. The lines which include the word Socket indicate 719 the directionality of the network sockets. The ASBP lines do 720 NOT show the directionality of the network sockets, but instead 721 show the flow of the Commands. 723 4. Protocol Versions 725 The initial ASBP version if accepted as a IETF standard will be 1.0. 726 Subsequent versions of ASBP should use the following major dot 727 minor version scheme. 729 Major version numbers MUST only be incremented when a break in 730 backward compatibility with the previous major version is 731 required. Backward compatibility is always preferred. 733 Minor version number MUST be incremented for each approved 734 update to the Asynchronous-Services-Bus Protocol standard by the 735 IETF. 737 5. IANA Considerations 739 ASBP is layered on other protocols 740 including HTTP and WebSockets in order to keep IANA considerations 741 minimal for use and implementation with in organizations. There are 742 no schemes or keywords to be registered for ASBP for use and 743 implementation with in organizations. 745 However, CP (Conversation Protocol) an extension to ASBP which 746 will enable conversations by utilizing Asynchronous 747 Service Busses from multiple organizations will require IANA 748 considerations. In particular the Exchange-Command-Names 749 and Formats will require a OID to extend from for each extension. 751 RFC Asynchronous Services Bus Protocol October 2016 753 6. Internationalization Considerations 755 The only internationalization consideration was to require the 756 ASBP header to be encoded in UTF-8, so that command names and 757 other values could use non English languages. 759 7. Security Considerations 761 _This section is non-normative._ 763 This section describes some security considerations applicable to 764 ASBP. ASBP relies on the protocols it is layered on to provide 765 details on how to secure usage of ASBP, namely HTTP, or WebSocket 766 over SSL (see [RFC6101]). This section focuses on topics not 767 covered by the secure protocol layers which ASBP supports. 769 The ASBP protocol originally started as a Java application framework 770 called the ASDC (Adligo Secure Data Connector), which was inspired 771 by the Google Secure Data Connector. One of the initial goals of 772 the protocol and framework was to allow data centers to protect 773 themselves better by blocking all in bound fire wall ports as 774 follows. 776 7.1 Firewall Diagram 778 Application-Agent Firewall A Broker Firewall B User-Agent 779 | | | | | 780 --- --- --- --- --- 781 | | | | | | | | | | 782 | | --------ASBP------------>| | | | | | 783 | | | | | | | | | | 784 | | | | | | <-------ASBP----------| | 785 | | | | | | | | | | 786 --- --- --- --- --- 787 | | | | | 789 Firewall A would not require any open in bound ports since the 790 Application-Agent dials out to the Broker. If two 791 Application-Agents were hosted at different data centers they 792 could synchronize data stores through the Brokers. Data centers 793 could also synchronize data stores through actual private networks, 794 or virtual private networks. Virtual private network 795 synchronization would require opening up some in bound 796 ports, however even in this case data center is much more difficult 797 to breach even when the Broker layer is compromised. 799 Firewall B would require standard ports to be open (i.e. 80, 443) 800 for public web applications. Other ports could be open for non 801 standard applications as well (i.e. 22, 8080, etc.) 803 RFC Asynchronous Services Bus Protocol October 2016 805 Using this design also allows the Broker's SSL certificates to be 806 used for both Tubes and Channels. This reduces the number of 807 SSL certificate installations by roughly half for end to end 808 SSL in most applications. 810 7.2. Application-Agents Security 812 _This section is non-normative._ 814 Application-Agents must authenticate with the Broker in order to 815 prove that they are the agents which are suppose to be handling 816 the Commands. Failure to create an extra strong 817 authentication mechanism from the Application-Agent to the Broker 818 would enable a new type of application attack 819 'Application-Agent spoofing'. 821 A Application-Agent spoofing attack would occur when a Cracker 822 creates a program (Broker-Spoofing-Agent) that attempts to connect 823 to a Broker in the same manor as a Application-Agent. If the 824 Broker-Spoofing-Agent was able to successfully connect to a Broker, 825 it could potentially receive Commands pertaining to Subject 826 credentials or other sensitive data. 828 The ASBP protocol does not attempt to create any sort of a standard 829 for Application-Agent to Broker authenticate. It is believed that 830 each organization that uses a Asynchronous-Service-Bus with the 831 ASBP protocol should develop their own unique authentication 832 mechanism. By not specifying a standard here, users of the 833 protocol will create a more secure web through diversity, and 834 Crackers will have more difficulty compromising the systems because 835 they all work differently. 837 7.3. User-Agent Subject Security 839 The ASBP protocol supports multiple Subjects using a 840 particular User-Agent. Brokers and Broker-Agents MUST allow 841 multiple Subjects to authenticate from a single User-Agent. 842 Brokers and Broker-Agents MAY also allow 843 the single Subject/User-Agent authentication session 844 methodology in use by most web applications today. 845 ASBP REQUIRES multiple Subject per User-Agent in order 846 to allow a user to use multiple accounts in a web 847 application, and to facilitate more efficient use of User-Agent 848 (browsers) resources during concurrent testing of 849 Asynchronous-Service-Bus applications. 851 7.3.1. User-Agent Subject Authentication 853 The ASBP protocol facilitates Subject based authentication at the 854 Broker-Agent, and Application-Agent tiers. The ASBP 855 protocol provides Subject-Identifier and Broker-Identifiers to 856 allow authentication security as follows. 858 RFC Asynchronous Services Bus Protocol October 2016 860 When the Broker receives a authentication attempt from a 861 User-Agent's Subject the Broker MUST create a 862 Subject-Identifier (a UUID unique to the Broker). Next the Broker 863 MUST modify or create a ASBP header appending the 864 Subject-Identifier and the Broker-Identifier, before sending 865 the Authentication-Command to one or more Application-Agents 866 which are known to process the Authenticate-Command. 868 This allows the Application-Agents to be aware of which 869 Broker the Subject authenticated through, and the 870 Subject-Identifier at that Broker. After a successful 871 authentication the Application-Agent MUST return 872 the Subjects model through a Command which includes 873 the Application-Agent-Identifier to the Broker. 874 Broker MUST return the Subject-Identifier through a 875 'authentication successful' Command to the User-Agent. 877 When the Broker-Agent receives a authentication attempt from a 878 User-Agent's Subject the Broker MUST create a 879 Subject-Identifier (a UUID unique to the Broker). The Broker-Agent 880 would then find a Command-Respondent to authenticate the Subject 881 from the Broker-Agent tier. 883 User-Agents that are state-less MUST provide the 884 Subject-Identifier in the ASBP header in all subsequent 885 Authenticated-Commands. 887 If the Broker or Broker-Agent is using the single Subject per 888 User-Agent paradigm it MAY use the HTTP sessions identifier to 889 locate the Subject-Identifier. 891 The Broker MUST keep track of which Application-Agents 892 have authenticated particular Subjects, in order for 893 Application-Agents to correctly process authorization. 894 The Broker MUST only submit Commands to Application-Agents 895 that have authenticated the Subject for subsequent 896 Authenticated-Commands. The Broker MUST ensure inclusion 897 of the Subject-Identifier in all subsequent 898 Authenticated-Commands that are sent to the Application-Agents. 900 7.3.2. User-Agent Subject Authorization 902 The ASBP protocol facilitates Subject based authorization security 903 at the Broker, Broker-Agent, and Application-Agent layers. The ASBP 904 protocol does not specify or suggest any particular structure for 905 Subject authorization models, however it is designed to support 906 common ACL, LDAP User/Group/Role isInRole(X) style authorization 907 security with out knowledge of implementation. 909 RFC Asynchronous Services Bus Protocol October 2016 911 Application-Agents, Brokers, Broker-Agents and User-Agents MAY all 912 perform authorization security checks. User-Agents authorization 913 security checks are considered informative to the Subject only, and 914 MUST NOT be relied on to prevent unauthorized Command usage. 915 User-Agent authorization checks SHOULD obfuscate the names of roles 916 if isInRole(X) style checks are used. Broker, 917 Broker-Agent, and Application-Agent authorization security checks are 918 considered a reliable way to prevent unauthorized Command usage. 920 Most Asynchronous-Services-Bus implementations SHOULD attempt to 921 reuse code for identical authorization security check in the 922 Broker, Broker-Agent and Application-Agent layers. 924 8. References 926 8.1. Normative References 928 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 929 Extensions (MIME) Part Two: Media Types", RFC 2046, 930 November 1996. 932 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, March 1997 935 [RFC2978] N. Freed, J. Postel, "IANA Charset Registration 936 Procedures", BCP 19, RFC 2978, October 2000. 938 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 939 10646", STD 63, RFC 3629, November 2003. 941 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 942 "Uniform Resource Identifier (URI): Generic Syntax", 943 STD 66, RFC 3986, January 2005. 945 8.2. Informative References 947 [RFC1945] T. Berners-Lee, R. Fielding, and H. Frystyk, "Hypertext 948 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996 950 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 951 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 952 DOI 10.17487/RFC6101, August 2011, 953 . 955 [RFC6455] I. Fette, and A. Melnikov, "The WebSocket Protocol", 956 RFC 6455, December 2011 958 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 959 Protocol (HTTP/1.1): Message Syntax and Routing", 960 RFC 7230, June 2014. 962 [RFC7540] M. Belshe, R. Peon, and M. Thomson, Ed., "Hypertext 963 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 964 May 2015 966 RFC Asynchronous Services Bus Protocol October 2016 968 9. Acknowledgements 970 Note I am waiting on a response from this thread to acknowledge 971 the authors of the Google Secure Data Connector; 972 https://groups.google.com/forum/#!topic/google-sdc/fL4TsSxZD_Q 974 Author's Addresses 976 Scott Morgan 977 scott@adligo.com 979 Adligo Inc 980 http://www.adligo.com 982 expiration date: 10/07/2016