[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-taxii] TAXII Protocol Shortlist
|
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. Thank you. -Mark From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Wunder, John A. So in the interest of spurring discussion, here are my thoughts: HTTP 1.1 would be my preferred option:
·
Easy to implement against
·
Well understood
·
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
·
Pros:
o
Probably a better fit for lots of small messages (sightings) and publish/subscribe type models
o
Might be worth trying?
·
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. John From:
<cti-taxii@lists.oasis-open.org> on behalf of "Jordan, Bret" Updated.... HTTP/1.1 HTTP/2 ZMTP AMQP 0.9 AMQP 1.0 MQTT SMTP 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.
Thanks, Bret Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO Blue Coat Systems 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."
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]