Subject: Re: [mile] Transport discussion was: New draft notification ...

From: "Field, John" <[email-masked]>
Date: Wed, 3 Oct 2012 15:33:00 -0400

Thanks everyone for these comments.   

Peter,  
I agree that XMPP is a good suggestion for any event driven use cases.  Since it is based on HTTP, the ROLIE REST model is a "pull" model.  However, if you need to receive asynchronous notification of some event, say, an alarm from an intrusion detection system, etc., then XMPP may be a very good choice for that.  I think this approach would be complementary to the current ROLIE draft, and XMPP could co-exist nicely (to support those different types of use cases and consumers).  I don't have a need to pursue the event-driven use case in my current work, but I would be supportive if someone wanted to pursue that and write something up.

Francis,
I am not an expert on BEEP so I can't comment too much on the pros and cons of using it.  In principal, it seems to me that BEEP could be a good choice for a traditional RID exchange in a *message-based architecture*.  Interesting to know (via Kathleen's prior post), that in fact BEEP + RID has already been explored, but the community chose to switch over to HTTP for reasons of low deployment of BEEP.  So this may be moot, unless there is now greater adoption of BEEP, in which case the group might want to revisit that.

My reason for writing the ROLIE draft was not just a matter of defining a different transport protocol.  Indeed RFC 6546 already specifies a simple HTTP binding for RID.  The goal for ROLIE was to enable an entirely different interaction model, one that follows the RESTful architectural style, rather than a message exchange model.  In short, this means that:

- everything is a resource
- all resources are addressable via a URL
- support for a Uniform interface (in the case of HTTP: GET, PUT, POST, DELETE, HEAD ((PATCH)).
- use Media types to negotiate the representation sent to the client (i.e. HTML, Application/Atom+XML, XML+RID, XML+IODEF, JSON, PDF, other...)
- use Hypertext as the Embodiment of Application State (HATEOAS)

So the intent is to provide a new/better alternative that will improve cyber security information sharing, by moving from a message-based model to a more loosely-coupled resource-based approach.  In theory, one can even do the REST style without necessarily using HTTP, although as a practical matter, real systems always use HTTP because it is ubiquitous.

Lots has already been written on the pros and cons of message-oriented versus resource-oriented architectures (i.e. "SOAP versus REST") so I won't rehash all those discussions here (unless we really want to).  

I prefer the REST model due to its simplicity and flexibility, and I thought it could be helpful to specifically describe how the REST approach could be applied to some of the use cases of interest to the MILE community.  If we can make the exchange of cyber security information simpler and easier, then that might help to make us all safer.

Thanks again, I appreciate people taking the time to comment.  Looking forward to more good discussion...

Regards,
John

// John P. Field 
// Security Architect 
// EMC Office of the CTO 

-----Original Message-----
From: Moriarty, Kathleen [mailto:[email-masked]] 
Sent: Friday, September 28, 2012 2:05 PM
To: Francis Brosnan Blazquez
Cc: [email-masked]
Subject: [mile] Transport discussion was: New draft notification ...

Interesting...  RID used BEEP in an earlier version because of the suitability to the protocol needs, but because of low deployment of BEEP, we switched to HTTPS.

I am curious to see if different exchange types may use different bindings.  The RESTful binding in the ROLIE draft may be well suited for repository access and IODEF + RID + transport where object security is needed.  What are the use cases for each if they differ and what do folks prefer and think will help adoption.

As Brian said, other formats are possible.  IODEF has been implemented in JSON from the data model description already.

I would love to see more views on this discussion!

Thanks,
Kathleen

Sent from my iPhone

On Sep 28, 2012, at 1:46 PM, "Francis Brosnan Blazquez" <[email-masked]> wrote:

> Hi,
> 
> The working group could also consider BEEP. It is lightweight,
> extensible and it allows any format for your message (since it sees the
> payload as a bunch of octets). 
> 
> Specifically, we are using it in a real-time monitoring solution where
> hundred of nodes are watched and queried, without having to use a
> polling solutions to get those events...
> 
> Best Regards,
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> On 9/28/12 11:00 AM, John Howie wrote:
>> 
>>> I would really like to see information exchange be secure, fast
>>> and lightweight, and a new protocol could well be preferable here.
>> 
>> If you didn't have a bias against XML, XMPP would be a good solution
>> to the requirements you've outlined.
>> 
>> (With regard to the "bloat" of XML, note that XMPP uses long-lived XML
>> streams so the compression ratios are significant.)
>> 
>> Peter
>> 
>> - -- 
>> Peter Saint-Andre
>> https://stpeter.im/
>> 
>> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>> 
>> iEYEARECAAYFAlBl2e0ACgkQNL8k5A2w/vwQ/ACfQ/JoLf08je6WoBkk9A+OpqTo
>> 09wAoOoCRYp1ImSAJMKMWClDKL26qlJ4
>> =DJzM
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> mile mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mile
> 
> -- 
> Francis Brosnan Blázquez <[email-masked]>
> ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
> 
> AVISO LEGAL
> 
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y sometidos a secreto
> profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
> usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
> por cualquier motivo, le rogamos que nos lo comunique por este medio y
> proceda a destruirlo o borrarlo.
> 
> En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de Carácter Personal, le informamos de
> que sus datos de carácter personal, recogidos de fuentes accesibles al
> público o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y oposición dispuestos en la mencionada Ley
> Orgánica, notificándolo por escrito a:
> ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> Henares (Madrid).
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Oct 2012 20:51:52 +0000

So, what I get from this is that HTTP/REST is a pull model when you know you want to go get a resource.
While XMPP is a presence-based messaging system for notifying others of the presence of events, e.g. a change in the resource state.

So, does this imply a 3-phase exchange:
XMPP subscribe to resource
XMPP notify of resource change
HTTP fetch of resource status?

Not an either/or choice.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Field, John
Sent: Wednesday, October 03, 2012 3:33 PM
To: Francis Brosnan Blazquez; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] Transport discussion was: New draft notification ...

Peter,

Francis,

Regards,
John

// John P. Field
// Security Architect
// EMC Office of the CTO 

-----Original Message-----
From: Moriarty, Kathleen [mailto:[email-masked]]
Sent: Friday, September 28, 2012 2:05 PM
To: Francis Brosnan Blazquez
Cc: [email-masked]
Subject: [mile] Transport discussion was: New draft notification ...

Thanks,
Kathleen

Sent from my iPhone

On Sep 28, 2012, at 1:46 PM, "Francis Brosnan Blazquez" <[email-masked]> wrote:

> extensible and it allows any format for your message (since it sees 
> the payload as a bunch of octets).
> 
>>> I would really like to see information exchange be secure, fast and 
>>> lightweight, and a new protocol could well be preferable here.
>> 
>> (With regard to the "bloat" of XML, note that XMPP uses long-lived 
>> XML streams so the compression ratios are significant.)
>> 
>> Peter
>> 
>> - --
>> Peter Saint-Andre
>> https://stpeter.im/
>> 
>> 
> Francis Brosnan Blázquez <[email-masked]> ASPL
> incluidos en el presente correo son confidenciales y sometidos a 
> secreto profesional, se prohíbe divulgarlos, en virtud de las leyes 
> vigentes. Si usted no lo es y lo ha recibido por error o tiene 
> conocimiento del mismo por cualquier motivo, le rogamos que nos lo 
> comunique por este medio y proceda a destruirlo o borrarlo.
> 
> diciembre, de Protección de Datos de Carácter Personal, le informamos 
> de que sus datos de carácter personal, recogidos de fuentes accesibles 
> al público o datos que usted nos ha facilitado previamente, proceden 
> de bases de datos propiedad de Advanced Software Production Line, S.L.

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Fri, 05 Oct 2012 09:52:15 +0200

Hi John,

> Francis,
> I am not an expert on BEEP so I can't comment too much on the pros and
> cons of using it.  In principal, it seems to me that BEEP could be a
> good choice for a traditional RID exchange in a *message-based
> architecture*.  Interesting to know (via Kathleen's prior post), that
> in fact BEEP + RID has already been explored, but the community chose
> to switch over to HTTP for reasons of low deployment of BEEP.  So this
> may be moot, unless there is now greater adoption of BEEP, in which
> case the group might want to revisit that.

This would be something to consider, especially because until recently
(in terms of protocol definition) there weren't any comercial
grade/production ready BEEP stacks so without them, it is not possible
to do anything with BEEP.

I just wanted to draw attention to that fact, that is, now it is
possible to use BEEP without investing time in writing a proven stack. 

> My reason for writing the ROLIE draft was not just a matter of
> defining a different transport protocol.  Indeed RFC 6546 already
> specifies a simple HTTP binding for RID.  The goal for ROLIE was to
> enable an entirely different interaction model, one that follows the
> RESTful architectural style, rather than a message exchange model. 

I think your effort is good especially because it comes to add
possibilities which is always a good thing.

Best Regards,

AVISO LEGAL

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 9 Oct 2012 09:26:45 -0600

On Wed, Oct 3, 2012 at 2:51 PM, Michael Hammer <[email-masked]
> wrote:

> While XMPP is a presence-based messaging system for notifying others of
> the presence of events, e.g. a change in the resource state.
>

That is one possibility, yes, although one could also fetch the status over
XMPP.

Peter