Thoughts about subscription requirements

All,

In thinking through how subscriptions would work for a channel based TAXII, Bret and I have put together some thoughts on requirements. Let us know what you think. We’ll add them to the wiki pending feedback.

1. Subscriptions are durable - Ensure subscribed clients do not miss a message while they are temporarily off-line or are in the process of re-connecting. Messages need to be stored for some defined period of time.

2. Pipelining is a thing – Multiple TAXII Messages can be delivered at once. This is to reduce the number of network connections required to transport a given number of messages. In keeping with “one way of doing things”, this is mandatory functionality.

3. Clients can specify response limits. The response limit controls how much information can be sent to the client in one response. The only exception is if a single message would exceed the response limit – in that case the single message can be sent. We do not want to get in to the business of breaking CTI (STIX / other) messages apart.

4. Servers have certain minimum requirements:

a. A minimum amount of messages the server MUST store for each subscription (either XYZ days, XYZ bytes, or XYZ messages, or something)

b. A minimum amount of subscriptions the server MUST keep for each client (e.g., if we do the implicit-subscribe, there needs to be an eventual implicit-unsubscribe). I’m thinking “At least 10 subscriptions per channel” or something. A client could reasonably want multiple subscriptions on a channel for different reasons (I think).

c. A minimum amount of time the subscription MUST be active for (Maybe this is a restatement of #1)

The way this would work would be something like (using HTTP as an example):

1. Client connects to a TAXII server group

2. TAXII server authenticates the client

3. If the client successfully authenticates then the client sends HTTP POST subscription information to server

4. TAXII server does long polling for all requests with a server dependent timeout value

5. Client might not get a response for a while, if timeout on connection is reached, client just reconnects

6. TAXII server gets a message and sends that to all connected clients that should get the message

7. If a client is not connected, but subscribed, then the message is stored for some period of time and then sent to the client when it reconnects

8. If a client does not reconnect before its subscription timeout hits a defined timeout value, the connection is closed and messages stored for that client are purged.

Thank you.

Mark Davidson

MDavidson@MITRE.org

(781) 271-3703

Lead Cyber Security Engineer

The MITRE Corporation

cti-taxii message