Bret -
Thanks for the info. As we are currently focusing on a TAXII client implementation and need to talk to existing public TAXII servers (which are 2.0-based), we cannot implement based on the draft 2.1 spec.
I am glad to hear that pagination is being revamped for 2.1, as the 2.0 pagination mechanism is cumbersome to deal with, particularly when dealing with inconsistent server implementations. I will take a look at the draft 2.1 spec as time permits and provide
feedback.
--Mike
From: Bret Jordan <>
Sent: Thursday, November 29, 2018 5:29:21 PM
To: Michael Daleiden
Cc:
Subject: Re: [EXT] [cti-comment] cti-taxii: Inconsistent examples for Range header in TAXII v2.0 Committee Specification 01
Michael,
Thank you for your feedback. Please note that Range based pagination was removed in TAXII 2.1 due to several problems and has been replaced with a better pagination solution. If you are building a new TAXII solution I might suggest you look to the 2.1
version as it contains several key fixes for problems that were found with 2.0.
The TC is rapidly finishing up the work on 2.1 and you can see the current state by looking at TAXII 2.1 Working Draft 04
Thanks
Bret
Sent from my Commodore 128D
PGP Fingerprint: 63B4
FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
On Nov 29, 2018, at 8:50 AM, Michael Daleiden <> wrote:
The TAXII v2.0 Committee Specification 01, Section 3.4.1 (Object and Collection Ranges) describes the use of the “items” range unit as conforming to HTTP RFC7233:
The items range unit is defined for expressing subranges of a resource [HTTP 7233].
According to Section 3.1 of the RFC, the range unit should be specified with an equals (=) between the range unit specifier (“items”) and the value set (i.e., “0-999”). However, all examples in the pagination
section of the TAXII2 specification use a space between the specifier and value set, as shown below:
GET Request
-----------------
GET .../collections/my-collection/objects/?added_after=2016-02-01T00:00:01.000Z HTTP/1.1
Range: items 0-49
Accept: application/vnd.oasis.stix+json; version=2.0
This appears to have led to inconsistent implementations of TAXII 2.0 servers. For example, the TAXII 2.0 server managed by Anomali (https://clicktime.symantec.com/a/1/x4vnohtfKhx6Y5rEOjla3jH1KVohM_yIOWsVvIOSaUQ=?d=OeIFh44A_P-ge4aB3BVgXUyvYIRxmi-TCjaaPI8f6VV5hupVS8Y1RYSxjtQFqASQRy2fE10gCpwvcbHx2luV7oX2oIYrMqH2UtamhGUoPlpxXV2j0n0-u7VQsOjETfpzG1HFyHkGenxdI0mK5xs9fWORn5XTRHddI11-NV1UiVBzfgWN2PmbcITAUX1cDkWHH1x7MvEe6G9tWd0c-Qo_nLdQZaMtT8L8bSCp8IEiFaTBY9JbrlyfY6hGaexUWz0nYxMCMZG4nw_1n0X_SVakI4X2JlttoBt7fr1KsEBUjW939ej2GJXQsVvipVNxLY5435-GIPE1JFCVI0T4VLyDpiNpwIODybCBwgA98kxCcexYaUNrrn8-ixEMZ0ldFDbdqVtBFobUiRL4LOMEJSLyD_l9ojQeToQnvgZw1IScXbGW9Dt2z9foSUIFy5FXSaR1k5hAhyXu-1v09iUp7Kiy5G1-uJcFo9L58-QZvGymcTCtaWs5FP9TTiqk3tfyriUD6oET_qSOx1NQ-PlW&u=https%3A%2F%2Flimo.anomali.com%2Fapi%2Fv1%2Ftaxii2%2Ffeeds%2Fcollections)
only accepts a Range header that has a space between the specifier (i.e., “Range: items 0-999”, which does not conform to the RFC but does match the examples in the TAXII 2.0 specification), whereas the MITRE ATT&CK TAXII 2.0 server (https://clicktime.symantec.com/a/1/5-iXHQ1AF_nTsGXNFhblQEIZHi7YjD4Ff_dJuN8Jnzc=?d=OeIFh44A_P-ge4aB3BVgXUyvYIRxmi-TCjaaPI8f6VV5hupVS8Y1RYSxjtQFqASQRy2fE10gCpwvcbHx2luV7oX2oIYrMqH2UtamhGUoPlpxXV2j0n0-u7VQsOjETfpzG1HFyHkGenxdI0mK5xs9fWORn5XTRHddI11-NV1UiVBzfgWN2PmbcITAUX1cDkWHH1x7MvEe6G9tWd0c-Qo_nLdQZaMtT8L8bSCp8IEiFaTBY9JbrlyfY6hGaexUWz0nYxMCMZG4nw_1n0X_SVakI4X2JlttoBt7fr1KsEBUjW939ej2GJXQsVvipVNxLY5435-GIPE1JFCVI0T4VLyDpiNpwIODybCBwgA98kxCcexYaUNrrn8-ixEMZ0ldFDbdqVtBFobUiRL4LOMEJSLyD_l9ojQeToQnvgZw1IScXbGW9Dt2z9foSUIFy5FXSaR1k5hAhyXu-1v09iUp7Kiy5G1-uJcFo9L58-QZvGymcTCtaWs5FP9TTiqk3tfyriUD6oET_qSOx1NQ-PlW&u=https%3A%2F%2Fcti-taxii.mitre.org%2Fstix%2Fcollections)
only accepts a Range header that conforms to the RFC (i.e., “Range: items=0-999”).
Is it possible to update the examples in the TAXII 2.0 specification (and future specification versions) so that they conform to the RFC? This would eliminate the confusion and potential for additional inconsistent
implementations going forward.
<image001.jpg>
Michael Daleiden
Lead System Architect
office: (407) 732-7507
mobile: (407) 923-7452
email:
www.redlambda.com
