Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
TAXII 2.0 Concept Overview
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 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"
Here is a rough drawing illustrating the channel concept. Note that Message Handlers can reject/rewrite messages.
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.
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.
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.