OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: TAXII 1.5


Sergey,

Great email!  If I may make an assertion, it sounds like you've come up with a proposal for TAXII that needs to be evaluated alongside the Channel-Based proposal. If that's the case, I can add some information to the taxiiproject.github.io page and make some space on the wiki. Overall, I think your email raises a lot of good points and I agree with a lot of it (notably getting rid of Content Blocks and just using MIME objects). 

There's some things I think we can explore. Lately I've taken to the idea that all TAXII Servers should have a required baseline of functionality, so right now I think that in the context of your proposal I'd like to consider all services being required (though I think the "only one service of each type" idea is very good!). But those details can be figured out as we explore these thoughts further.

One high level question for you.

> It is unclear to me at the moment what is TAXII 2.0 scope
MD: This should be improved - what can be done to help clear this up? And, do you mean in terms of this subcommittee, or in terms of the Channel-Based TAXII proposal? Or something else?

Thank you.
-Mark

-----Original Message-----
From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Sergey Polzunov
Sent: Tuesday, August 25, 2015 8:05 AM
To: cti-taxii@lists.oasis-open.org
Subject: [cti-taxii] TAXII 1.5

Hey guys,

	I spent last weekend time reading through TAXII 2.0 documents on the wiki and thinking about challenges I faced as an engineer integration TAXII in a software product.
	My general feeling is: current design mixes different levels of abstraction and tries to solve everything. I'm not a fan of building the system from the top to bottom. I believe the solutions designed this way tend to be heavy, less customisable, difficult to integrate and as a result - slow to progress (think Unix vs Windows). As an opposite to that, building from bottom up is very flexible and has freedom of extension. Adding layers of abstraction is easy if foundation is solid. So my first thought was to go back to basics (TAXII 1.1) and investigate what didn’t work there. It is unclear to me at the moment what is TAXII 2.0 scope is so I will treat TAXII as a simple content exchange protocol for now, mostly because there are no alternatives and this is the lowest level of abstraction.
	 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.

- 4 services types are: Discovery service, Inbox service, Poll service, Event service and 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
- accepts username/password, returns "token" that needs to be supplied with every request to server marked with "authentication required". See OpenTAXII auth as an example (https://opentaxii.readthedocs.org/en/latest/auth.html)

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.

Again, the main goal of this email is to outline an evolutionary step that I think is logical. I don’t have an opinion on other use cases that TAXII 2.0 tries to cover mostly because I don’t have those issues or requirements. So I would prefer light basic exchange protocol, that TAXII defined initially, to evolve. Complimentary specifications of high-level extensions can be developed in parallel, of course.

Thanks,
Sergey Polzunov
Intelworks




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]