[TAXII] new X-TAXII-Content-Types header for automatic version negotiation

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[TAXII] new X-TAXII-Content-Types header for automatic version negotiation

Sergey Polzunov
Dear community,

    I would like to hear your opinion about TAXII version auto negotiation (in the scope of HTTP based implementations). I think this is an important issue that needs to be in HTTP Protocol Bindings specification.

    At the moment, Discovery Service is the only source of information about any configured service instance. It is the only way to get the Message Bindings that a service instance supports. If the host decided not to run Discovery Service, the clients have no way to get this information, they can only try to guess.

    I propose to add X-TAXII-Content-Types header to TAXII HTTP Protocol Binding Specification. The negotiation scenario would be:
        - client knows service instance URL (for example http://taxii.example.com/service/inbox)
        but knows nothing about TAXII version that this service supports.
        - client sends OPTIONS HTTP request to that service-specific URL (http://taxii.example.com/service/inbox)
        - TAXII service replies with appropriate response and X-TAXII-Content-Types header configured.
        X-TAXII-Content-Types contains all Message Binding IDs that this particular service supports (comma separated).
        - client sends a request to the service, as a correct TAXII message that corresponds to one of the Message Binding IDs
        from X-TAXII-Content-Types header value.

I see this addition as a one step towards version agnostic client/server implementations.

What do you think?

Thanks,
Sergey Polzunov
Intelworks
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] new X-TAXII-Content-Types header for automatic version negotiation

Jordan, Bret
Very interesting…  On the surface this sounds great.. I would need to think and play with it a bit before I had a solid opinion.  


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 3, 2015, at 6:38 AM, Sergey Polzunov <[hidden email]> wrote:

Dear community,

   I would like to hear your opinion about TAXII version auto negotiation (in the scope of HTTP based implementations). I think this is an important issue that needs to be in HTTP Protocol Bindings specification.

   At the moment, Discovery Service is the only source of information about any configured service instance. It is the only way to get the Message Bindings that a service instance supports. If the host decided not to run Discovery Service, the clients have no way to get this information, they can only try to guess.

   I propose to add X-TAXII-Content-Types header to TAXII HTTP Protocol Binding Specification. The negotiation scenario would be:
- client knows service instance URL (for example http://taxii.example.com/service/inbox)
but knows nothing about TAXII version that this service supports.
- client sends OPTIONS HTTP request to that service-specific URL (http://taxii.example.com/service/inbox)
- TAXII service replies with appropriate response and X-TAXII-Content-Types header configured.
X-TAXII-Content-Types contains all Message Binding IDs that this particular service supports (comma separated).
- client sends a request to the service, as a correct TAXII message that corresponds to one of the Message Binding IDs
from X-TAXII-Content-Types header value.

I see this addition as a one step towards version agnostic client/server implementations.

What do you think?

Thanks,
Sergey Polzunov
Intelworks


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] new X-TAXII-Content-Types header for automatic version negotiation

Terry MacDonald
Sounds like an idea worth tracking and testing. Any chance you can write it up on the TAXII Issue Tracker Sergey? https://github.com/TAXIIProject/TAXII-Specifications/issues/new

Cheers
Terry MacDonald


On 4 April 2015 at 04:08, Jordan, Bret <[hidden email]> wrote:
Very interesting…  On the surface this sounds great.. I would need to think and play with it a bit before I had a solid opinion.  


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 3, 2015, at 6:38 AM, Sergey Polzunov <[hidden email]> wrote:

Dear community,

   I would like to hear your opinion about TAXII version auto negotiation (in the scope of HTTP based implementations). I think this is an important issue that needs to be in HTTP Protocol Bindings specification.

   At the moment, Discovery Service is the only source of information about any configured service instance. It is the only way to get the Message Bindings that a service instance supports. If the host decided not to run Discovery Service, the clients have no way to get this information, they can only try to guess.

   I propose to add X-TAXII-Content-Types header to TAXII HTTP Protocol Binding Specification. The negotiation scenario would be:
- client knows service instance URL (for example http://taxii.example.com/service/inbox)
but knows nothing about TAXII version that this service supports.
- client sends OPTIONS HTTP request to that service-specific URL (http://taxii.example.com/service/inbox)
- TAXII service replies with appropriate response and X-TAXII-Content-Types header configured.
X-TAXII-Content-Types contains all Message Binding IDs that this particular service supports (comma separated).
- client sends a request to the service, as a correct TAXII message that corresponds to one of the Message Binding IDs
from X-TAXII-Content-Types header value.

I see this addition as a one step towards version agnostic client/server implementations.

What do you think?

Thanks,
Sergey Polzunov
Intelworks


Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] new X-TAXII-Content-Types header for automatic version negotiation

mdavidson

I second the idea that this belongs on GitHub. Does this comment fit best as a comment on the “Make TAXII more discoverable” [1] issue? Sergey, I encourage you to post this thought (either as a new issue or as a comment on an existing issue, depending on what you think is best) in the tracker.

 

Thank you.

-Mark

 

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/58

 

From: Terry MacDonald [mailto:[hidden email]]
Sent: Friday, April 03, 2015 3:06 PM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: [TAXII] new X-TAXII-Content-Types header for automatic version negotiation

 

Sounds like an idea worth tracking and testing. Any chance you can write it up on the TAXII Issue Tracker Sergey? https://github.com/TAXIIProject/TAXII-Specifications/issues/new


Cheers
Terry MacDonald

 

 

On 4 April 2015 at 04:08, Jordan, Bret <[hidden email]> wrote:

Very interesting…  On the surface this sounds great.. I would need to think and play with it a bit before I had a solid opinion.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Apr 3, 2015, at 6:38 AM, Sergey Polzunov <[hidden email]> wrote:

 

Dear community,

   I would like to hear your opinion about TAXII version auto negotiation (in the scope of HTTP based implementations). I think this is an important issue that needs to be in HTTP Protocol Bindings specification.

   At the moment, Discovery Service is the only source of information about any configured service instance. It is the only way to get the Message Bindings that a service instance supports. If the host decided not to run Discovery Service, the clients have no way to get this information, they can only try to guess.

   I propose to add X-TAXII-Content-Types header to TAXII HTTP Protocol Binding Specification. The negotiation scenario would be:
- client knows service instance URL (for example http://taxii.example.com/service/inbox)
but knows nothing about TAXII version that this service supports.
- client sends OPTIONS HTTP request to that service-specific URL (http://taxii.example.com/service/inbox)
- TAXII service replies with appropriate response and X-TAXII-Content-Types header configured.
X-TAXII-Content-Types contains all Message Binding IDs that this particular service supports (comma separated).
- client sends a request to the service, as a correct TAXII message that corresponds to one of the Message Binding IDs
from X-TAXII-Content-Types header value.

I see this addition as a one step towards version agnostic client/server implementations.

What do you think?

Thanks,
Sergey Polzunov
Intelworks

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] new X-TAXII-Content-Types header for automatic version negotiation

Sergey Polzunov
Terry, thanks for a suggestion! I created an issue - https://github.com/TAXIIProject/TAXII-Specifications/issues/70


Sergey Polzunov
Intelworks




> On 06 Apr 2015, at 14:00, Davidson II, Mark S <[hidden email]> wrote:
>
> I second the idea that this belongs on GitHub. Does this comment fit best as a comment on the “Make TAXII more existing issue, depending on what you think is best) in the tracker.
>
>  
>
> Thank you.
>
> -Mark
>
>  
>
> [1] https://github.com/TAXIIProject/TAXII-Specifications/issues/58
>
>  
>
> From: Terry MacDonald [mailto:[hidden email]]
> Sent: Friday, April 03, 2015 3:06 PM
> To: taxii-discussion-list Trusted Automated Exchange of Indicator In
> Subject: Re: [TAXII] new X-TAXII-Content-Types header for automatic version negotiation
>
>  
>
> Sounds like an idea worth tracking and testing. Any chance you can write it up on the TAXII Issue Trackerhttps://github.com/TAXIIProject/TAXII-Specifications/issues/new
>
>
> Cheers
> Terry MacDonald
>
>  
>
>  
>
> On 4 April 2015 at 04:08, Jordan, Bret <[hidden email]> wrote:
>
> Very interesting…  On the surface this sounds great.. I would need to think and play with it a bit before I had solid opinion.  
>
>  
>
> Thanks,
>
>  
>
> Bret
>
>  
>
>  
>
>  
>
> Bret Jordan CISSP
>
> Director of Security Architecture and Standards | Office of the CTO
>
> Blue Coat Systems
>
> PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
>
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
>
>  
>
> On Apr 3, 2015, at 6:38 AM, Sergey Polzunov <[hidden email]> wrote:
>
>  
>
> Dear community,
>
>    I would like to hear your opinion about TAXII version auto negotiation (in the scope of HTTP based implementations). I think this is an important issue that needs to be in HTTP Protocol Bindings specification.
>
>    At the moment, Discovery Service is the only source of information about any configured service instance. It is the only way to get the Message Bindings that a service instance supports. If the host decided not to run Discovery Service, the clients have no way to get this information, they can only try to guess.
>
>    I propose to add X-TAXII-Content-Types header to TAXII HTTP Protocol Binding Specification. The negotiation scenario would be:
> - client knows service instance URL (for example http://taxii.example.com/service/inbox)
> but knows nothing about TAXII version that this service supports.
> - client sends OPTIONS HTTP request to that service-specific URL (http://taxii.example.com/service/inbox)
> - TAXII service replies with appropriate response and X-TAXII-Content-Types header configured.
> X-TAXII-Content-Types contains all Message Binding IDs that this particular service supports (comma separated).
> - client sends a request to the service, as a correct TAXII message that corresponds to one of the Message Binding IDs
> from X-TAXII-Content-Types header value.
>
> I see this addition as a one step towards version agnostic client/server implementations.
>
> What do you think?
>
> Thanks,
> Sergey Polzunov
> Intelworks
>
>  
>
>  
>