Just to throw another thought into the mix – HTTP does not preclude messaging backends. In fact, many messaging products have HTTP interfaces.
-Mark
From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Thursday, August 27, 2015 2:23 PM
To: Davidson II, Mark S <mdavidson@mitre.org>; Wunder, John A. <jwunder@mitre.org>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] TAXII Protocol Shortlist
HTTP/1.1
1) Easiest for us to do, as it is what we do today.
2) The change from TAXII 1.1 to TAXII 2.0 will be less scary as it can be made to look relatively the same but with added functionality and improved features
3) Developers are very familiar with it
4) There is nearly ubiquitous support for it
5) Everything can speak HTTP. This makes it very easy for vendors to do TAXII as they already do HTTP for their updates, for talking with other vendors, and most of their APIs run over HTTP.
6) HTTP also is allowed out the firewall, even when deep packet inspection is enabled.
8) Allows us to build very light weight clients
9) It can scale nicely behind load balancers that are well understood today, so we can have infinite scalability with tools and technologies that are very common in IT shops today.
10) It will work well with cloud based services
11) Works well over the internet
12) Can be made to work with things like server push, using something like Long-Polling
1) seems neat, very progressive
2) not a lot of support for it today.
3) I would suggest adding support for HTTP/2 in a future release of TAXII, maybe 2.5
All of the messaging queue systems generally suffer from these sort of things
1) Developers in generally are not familiar with them
2) You often hear, we need to bring in an expert to talk about them. That by definition illustrates the problem.
3) There is no clear winner. There are big vendor versions, and great open source versions and non compatible religious debates within specific versions (AMQP 0.9 vs AMQP 1.0)
4) Firewalls do not allow this traffic out be default, so that is a show stopper
5) Hacking them to run over HTTP is not always "easy"
6) Client support can be iffy or it requires you to run "their" client, there is not always a client library to use
7) Adding on top of the MQ can be hard, some times it requires hacking the source of the server to do or adding a lot of extra software packages to do it
8) Some of the best MQ system are PAID products, so requiring people to buy a MQ just to support TAXII is a show stopper
9) A lot of times MQs are designed for the server to be super light weight and have all of the heavy lifting to be done on the end client. I think this is also a show stopper
10) A lot of cloud based services only allow HTTP type connectivity, so unless the MQ supports HTTP natively, then this is a show stopper.
11) Usually designed for closed systems
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I think all three proposals could be implemented using any of the protocols mentioned so far, so maybe it’s a bit more about the social
and political aspects of these protocols than anything strictly technical.
For me, the various messaging protocols usually have some combination of the following flaws:
1) Developers
are not familiar with them
2) Available
brokers/servers are hard to extend and write code on top of (e.g., to implement Message Handlers)
3) Firewalls
generally do not let them through, and therefore existing firewall configs would be a barrier to adoption
4) Adoption
is limited and clients are not ubiquitous
Note that none of those flaws are strictly technical – they have to do with the social and political aspects and the ecosystem surrounding
the protocol. There’s a reason the messaging space is so hard to understand – there’s no clear “winner”.
For me at least right now, I’m leaning toward HTTP as my opinion for moving forward. My key reasons are in line with John’s, though I’ll
also add: Vibrant ecosystem of platforms, tools, and knowledge for building applications.
So in the interest of spurring discussion, here are my thoughts:
HTTP 1.1 would be my preferred option:
· Easy
to implement against
· Very
extensive library support
· Will
go through a firewall
· Will
not freak out security teams
HTTP 2 is intriguing, I can see how it would be nice. It seems like a trade-off: it’s not as well supported as HTTP 1.1 right now but that should be
changing in the (near??) future. So given that it might be worth exploring it, and if nothing else adding support or switching over in a future version of TAXII?
The various messaging protocols:
· I
was under the impression that ZeroMQ is specific to a single software platform, which probably means it should not be used?
· MQTT
seems to be optimized for devices and small sensors, not sure that’s the biggest target now?
· In
general, the big cons of these seem to me to be:
o Probably
will not go through a corporate firewall without a lot of justification, so bad on the open internet
o Not
an awesome fit for the query model, though it’s doable
o Probably
a better fit for lots of small messages (sightings) and publish/subscribe type models
· No
opinion on AMQP 1.0 vs. 0.9.
I’m not sure of the reasoning behind SMTP so I can’t really evaluate it.
Please submit pros and cons for each of these and any others you think we should look at over the next 2 weeks. Also, if there is no discussion of
pros/cons for a given item, then it will be dropped from the list. No reason for having it on the list if there is no supporting data one way or another for it. So if you feel strongly about one of the above, or another yet to be added item, please do the
research and identify why you think it would be a good option for us to go with and how it would solve the TAXII problems we have identified and further, how it will meet the protocol requirements we have identified on the wiki.
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
|