Re: [cti] Use of XMPP in CTI

[Dave Cridland <dave.cridland@surevine.com>]

Going through these one at a time:

On 10 Mar 2017 22:41, "Sergey Polzunov" <sergey@eclecticiq.com> wrote:

Hi Dave,

    In the alternative proposal I presented last call we suggested to split TAXII 2.0 into 2 specs: JSON API and Channels.

I've not examined JSON-API in great detail, and I would have expected a major shift in underlying technology to be capable of a wider range of use-cases, but in general a split between basic functionality and more complex use-cases seems to make sense.

    Do you think XMPP spec/extensions can be used as an inspiration for Channels spec?

Inspiration? You could build it directly.

Taking a "Channel" to be an asynchronous-capable publish-subscribe topic, you could build a simple "Channel" directly in existing XMPP protocols. Off the top of my head, using MAM (XEP-0313) on top of PubSub (XEP-0060), and combined with the usual base specs, would be pretty much all you need. There are existing implementations of this. You could skip XEP-0313 for simple cases; in which case there are a large number of existing implementations.

This would give discovery (XEP-0030), polling (XEP-0313/XEP-0060), and push notifications (XEP-0060).

A limitation here is that fine-grained access control hasn't been completed in a PubSub setting - while XMPP does have a label concept (XEP-0258) which is compatible with SDN.801(c) models (and therefore STANAG 4774, GENSER, IC-IHM, et al) the work on its companion for PubSub, XEP-0314, stalled some time back - I'm hoping to revive this soon, since Surevine's work relies on it. Right now, only basic ACL systems (IBAC), and approval-required subscriptions, are available in XEP-0060 (roughly equivalent to that in XMPP-Grid).

This far, everything required for a CTI distribution service is available using existing services - hence my confusion with XMPP-Grid.

A more advanced service might make a break between the "pub" and "sub" aspects; therefore the XMPP PubSub "nodes" become more like AMQP topics with some bespoke (and CTI-aware) code to choose which XMPP nodes nominally contain which STIX objects. This also allows topics/nodes representing particular IP addresses, networks, and other items of interest not directly represented in STIX SDOs.

How this latter might work is what I'd expect to see in XMPP-Grid, but it's not there - XMPP-grid seems to be a content-neutral publish-subscribe service, but XMPP has one of those already.

and maybe as an engine for a prototype implementation?

This is somewhat easier. There are a number of open-source servers built in a number of different languages which implement part or all of this.

Thanks,
Sergey Polzunov
EclecticIQ

> On 10 Mar 2017, at 17:17, Dave Cridland <dave.cridland@surevine.com> wrote:
>
> Folks,
>
> I'm sorry to have missed the presentation and discussion around Cisco's XMPP-Grid. As some of you already know, I've spent the past decade or so working with XMPP within the XMPP Standards Foundation, and I'm currently serving on their XMPP Council, the technical council for the standards. I'm happy to make myself available to people wanting further information on how XMPP works, and what facilities is has in various spaces.
>
> At Surevine, we're already using XMPP within the CTI space, and are moving to exposing STIX data stores over XMPP. It's useful as it provides a clear mechanism for publish/subscribe operations across multiple domains (both in terms of the DNS and autonomous organisations), and since we're largely focussed on people rather than simply the raw data, the inclusion of discussion and chat capability is extremely convenient.
>
> We are using a combination of the base specifications (RFC 6120 and RFC 6121), and selected XMPP Extension Protocols (XEP-0060, XEP-0258, XEP-0369 being the primary ones of interest).
>
> It's never been clear to me precisely what XMPP-Grid offers over and above these - for example it appears to provide its own subscription syntax (which offers nothing beyond the XEP-0060 syntax it replaces), but does not provide any guidance on topic layout.
>
> To put it another way, we're already achieving much of XMPP-Grid's stated aims, but without having had to write new protocol extensions. So while I do like the idea of using XMPP for CTI data exchange, I'm not interested in XMPP-Grid.
>
> I've raised this on the IETF MAIL WG list, but never actually had an answer as to what XMPP-Grid is doing that cannot be done using pre-existing protocol.
>
> As a final note, I would exhort people to continue with TAXII (or at least, some form of classical Web API), since developers often find XMPP quite a steep learning curve. But for higher volumes and higher complexity, XMPP will save a vast amount of engineering design.
>
> Dave.
> --
> Dave Cridland
>
> phone  +448454681066
> email  dave.cridland@surevine.com
> skype  dave.cridland.surevine
>
>

> Participate | Collaborate | Innovate
>
> Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND
> If you think you have received this message in error, please notify us.