TAXII 2.0 Concept Overview

jordan2175 edited this page Sep 23, 2015 · 6 revisions

This page contains the conceptual overview of the Channel-based TAXII 2.0 proposal. Please note that the information on this page is a work in progress and may change over time.

TAXII 2.0 Architecture

  • We are using a Publish and Subscribe model for the TAXII 2.0 architecture over an HTTP RESTful interface

  • TAXII Servers are plumbing for CTI between TAXII Clients

  • TAXII Servers handle authentication, authorization, and policy based message handling (block, allow, rewrite, redirect etc.)

  • TAXII Servers handle TTL values for messages, channels, and clients

  • TAXII Clients are light weight clients that only sends or receives CTI to a channel on a TAXII Server

  • The output from a TAXII Client is a raw CTI object such as a STIX package.

  • A TAXII server MAY have a special embedded TAXII client called a TAXII Router to facilitate communications with another TAXII Server

  • An ingress or egress policy MAY be applied to all traffic between the TAXII Server channel and this embedded TAXII Router

  • NOTE: we may want to scratch the router terminology so as not to confuse people and just say that a TAXII Server can also, itself, publish and subscribe to another TAXII Server.

  • Each TAXII Server will have some defined out-of-the box channels that clients can publish or subscribe to

  • A TAXII Server MAY have additional channels beyond what we define

  • Channels MAY have ingress or egress policies

  • Channels MAY be read-only

  • Channels MAY require out-of-band subscription information in addition to authentication

  • Channels MAY be auto-deleted if there are no more clients attached to it

  • Channels MAY be exclusive, meaning on the creator can subscribe

Channels

Channels are the core design concept of this proposal. A "Channel" is a communication mechanism that transmits messages from producers to consumers. Channels have the following properties:

  • Channels are many-to-many broadcasts
  • Channels have a name and a set of messages that are allowed on them.
  • For instance, an "Indicator" channel might permit only "Indicator" messages and "Sighting" messages.
  • Clients publish messages to a channel. These clients are producers.
  • Clients consume messages from a channel. These clients are consumers.
  • Consumers can, when connecting to the server, specify a "filter" to downselect the messages that are received from the server.
  • Clients can be producers and/or consumers, depending on implementation.
  • Servers maintain channels and delivery
  • All TAXII Servers always have a pre-defined set of Channels
  • Custom channels serve as an extension point
  • Servers maintain authentication and subscriptions
  • Channels have zero to many "Message Handlers" that can perform validation, rewrite, policy, and other capabilities before a message is accepted to a channel.
  • TAXII Servers are "dumb plumbing"

Channel Drawing

Here is a rough drawing illustrating the channel concept. Note that Message Handlers can reject/rewrite messages.

Channel Concept

Notional Workflow

This is an example workflow meant to illustrate the channel concept. This does not necessarily describe any proposed feature set for a Channel-based TAXII 2.0.

Channel Concept

What parts of this discussion can evolve separately?

The idea is that the channel concept and the ways to access channels (i.e., the protocol) would be defined in TAXII 2.0. What channels exist and what messages are permitted on them would evolve separately. The idea would be to nail down a small set of channels for TAXII 2.0, and then add channels as necessary in TAXII 2.x releases. The idea would be to not touch the channel concept or underlying protocol after TAXII 2.0.

Asynchronous Communications

In the Channel-based proposal, message delivery is asynchronous at the application level. An application that sends a message does not wait for an application-level response (however, there may be underlying protocol-level responses). This enables certain interesting features:

  • "consumer only" TAXII Clients. These are consumers that might listen on a particular channel and never publish messages. Using the notional indicator workflow from above, it's possible to envision a dashboarding application that provides a view of the indicators with the most sightings. The dashboarding application would get it's information by listening on the indicator channel.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.