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: Clarifying Channel-Based TAXII (was TAXII 1.5)


Changed subject to not take away from the discussion of your proposal, which is now listed on the TAXII 2 landing page [1].

I'll do my best to answer those questions:

> Are there separate parts in that idea that can be evolved separately?
Yes, absolutely. 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.
Note: I've added this information to the Channel-Based Concept overview.

> are there different discussions about the components?
Not yet, though that needs to happen in order to make progress. My hope would be to have a "rough consensus" design on Channels and ways to access channels, and focus the discussion on "which channels and for what purposes".

> what are the must-haves and nice-to-haves in the proposal?
I don't have a good answer for this right now, but it's a good question!

> is there a low level protocol definition (like the one I tried to describe in my mail)?
Not yet. The idea would be to use an existing protocol (like one of the ones listed here [2]). We've put together some requirements on the requirements page [3]. I see TAXII 1.x as not being "native" HTTP (because of all the X-Headers and such), to the detriment of TAXII 1.x. Ideally, whatever protocol we'd pick, we'd have be as close to the bare protocol as possible.

Thank you.
-Mark
[1] http://taxiiproject.github.io/taxii2/
[2] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Formats-and-Protocols
[3] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements#protocol-requirements

-----Original Message-----
From: Sergey Polzunov [mailto:sergey@intelworks.com] 
Sent: Tuesday, August 25, 2015 9:30 AM
To: Davidson II, Mark S <mdavidson@mitre.org>
Cc: cti-taxii@lists.oasis-open.org
Subject: Re: TAXII 1.5

Hey Mark,

>> 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?

In terms of Channel-Based TAXII proposal. I think the change of thinking here is very steep and I just got confused about how everything is structured:
- are there separate parts in that idea that can be evolved separately? 
- are there different discussions about the components?
- what are the mast-haves and nice-to-haves in the proposal?
- is there a low level protocol definition (like the one I tried to describe in my mail)?

Clear answers to those questions will help estimate risk and get people on board with discussion, and I feel that this was overlooked.

Thanks,
Sergey Polzunov
Intelworks


> On 25 Aug 2015, at 14:10, Davidson II, Mark S <mdavidson@MITRE.ORG> wrote:
> 
> 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]