Incremental Improvement Concept Overview

Sergey Polzunov edited this page Aug 25, 2015 · 2 revisions

TAXII 1.0 and 1.1 were designed to be very flexible. Now, as a community, we know which features work and used in the wild, so we can trim the spec. Thinking about obstacles we (Intelworks) encountered and looking at PainPoints page (https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-1.1-1.0-Pain-Points) I assembled a set of changes that I would like to suggest as a possible to-do list for not-so-drastic evolutionary spec upgrade. Here it goes:

Generic changes:

  • Services are purely semantic concepts. Services are not required to have own endpoint in TAXII 1.1, so this will be the next logical step. Services are just families of message types.

  • 5 services types are:

    • Discovery service
    • Inbox service
    • Poll service
    • Event service
    • Auth service Collection Management Service features are partially integrated into Poll service. Subscription management service is removed. (responsibility to keep state is moved to a client, so subscription model is not supported)
  • All services are optional and there can be only one service of a specific type. Server host may decide to support Inbox and Poll service and it can't have 2 Poll services. (current support for multiple services of the same type has no significant benefits while makes integration difficult)

  • Content blocks are MIME objects and server is required to treat them as strings. Server may decode/analyze the content to support a specific content query format but it is not required.

Discovery Service

  • advertised in SRV record
  • can NOT broadcast 3rd party services (limited practical benefits with significant integration difficulties)
  • replies with short info on services enabled.
    • Poll Service info- lists available collection names with the content types
    • Inbox Service info - lists available destination names with the content types or a flag that destination is not supported

Poll service:

  • Supports 2 message types: info and query.
    • Info request returns collections with their properties - name, last/first timestamp, volume, content types, etc. (can be used to cheaply fetch collection state)
    • Query request supports parameters (offset, limit, start, end) and optional content query (gives a power to limit response size to a client)
  • Content query:
    • support is optional. Server may decide not to look into content receives/serves. Implementation of a specific query format is up to a server.
    • exact content query formats are outside of this spec and may be defined in a complimentary spec. We might think of a basic "required" query formats that are non-intrusionary, like hash based or signature based filtering.
  • service is required to support "count only" requests (allows client to easily get a content block count for a specific query, greatly simplifies integration)
  • no active push - only poll model is supported by this service.
  • content binding subtypes are removed from the spec (confusing and rarely used)

Event service:

  • client can subscribe to various events;
  • one of the basic events - new content block in a collection. subscription may accept filtering parameters
  • may be used for TAXII "group" synchronization - one TAXII server, accumulating data from multiple locations

Auth service

Please note, that details of an implementation are not described here. For example, protocol may be implemented over HTTP or ZMQ, authentication may or may not use JWT, etc.

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.