Some Comments on Logging Protocols

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

Some Comments on Logging Protocols

Burnes, James - NRCS, Fort Collins, CO
Since I just joined the list, I thought I’d forward some comments I’ve shared with Bill that I would have posted to the list anyway.
 
Regarding requests for recommendations for a “better” logging protocol…
 
This something we are definitely working with here at the USDA Security Group.   One of the protocols we find very intriguing is XMPP. 
 
  1. It’s based on a persistent connection stream, with no inherent limits to message length. 
  2. It’s XML-based so individual messages can be clearly augmented with additional attributes.
  3. The log event itself is delineated by clean and recognizable start/end tokens
  4. XMPP routers and gateways exist to forward and relay XMPP messages from local DMZs to backend servers
  5. Obviously any IM user with a XMPP client can receive, tap or view the events in stream.  If XMPP is carrying log-specific markup, its ignored by default by XMPP user clients.
  6. XMPP tracks presence of all XMPP participants (log sources, log sinks, users, routers, bots in our case) – whether they are online, how long since last message etc.  
  7. Excellent (both Open Source and Commercial) implementations of XMPP servers exist to process both XMPP wrapped log traffic as well as user conversations
  8. Most of the better servers support publish/subscribe (observer) semantics for XMPP messages either through direct pubsub (XEP-0060) or Chat Rooms (XEP-0045) where security/system administrators can discuss the XMPP log messages streaming right before their yes.  This is rather unique as it allows chat discussions about system events happening presented at a human level.  Using various mechanisms, administrative teams can remotely introspect log event generators or log sinks.
  9. XMPP is routable, which allows connected user clients to direct logging commands at a log event sink via a “Bot”.  Would you like to subscribe to a different event stream?  Would you like to quench an overload of log events coming your way?  Send a command to a log bot.
  10. An automated process (Bot) can subscribe to a log message stream, select from certain events, reformat them and even forward them to a different protocol (say syslog etc).  This bot could also answer requests for gateway statistics, total log size, perhaps even queries against a particular log sink.
  11. XMPP is usually carried over a persistent TCP session and has native provisions for TLS stream encryption.  In fact, both session and inter-server security is supported by TLS.  Many servers have options which only allow encrypted sessions.  For particularly difficult firewall environments XMPP can flow over a bidirectional synchronous http connection (BOSH).
  12. RELP-like functionality could easily be provided by having log sink/target bots assert IO completion (writing to a log) by periodically sending an XMPP response message with the last completed message number.  The XMPP server or router could queue XMPP log messages until the logbot indicates that a portion of the message cache has been committed, thus allowing local event stream reconstruction in the event of failure.
  13. XMPP connections to servers and router/gateways can use a number of different standard authentication systems.
  14. Multiple XMPP servers can communicate via the server-to-server protocol.  Since servers share entity rosters, this allows connected entities (users, bots etc) to determine all of the logging endpoints in an enterprise.
  15. A great variety of commercial and open source development tools in various languages (Java, .Net, Python, Ruby, C, C++ etc) are available.
  16. Numerous user clients are available either in the system by default or free.
  17. XMPP already has widespread use throughout the industry being the basis for Google Talk and iChat as well as a messaging bus for VOIP and numerous other systems.
  18. Finally both log4net and log4j (standardized logging libraries for .net and java) have appender-listener extensions for XMPP that emit XMPP logging streams.
 
Against all of that, an XMPP message does carry some overhead for XML markup and parsing, but I think that’s relatively minute compared to the already massive XML and TLS processing burden that most systems already take for granted.  High performance parsers are in use and available for free.
 
After a recent design review were very excited about the incredible potential for monitoring, flexibility and de-coupling that a log4net/log4j  and XMPP log event streaming provide.
 
The good news is that an open source server like OpenFire and its connection-manager component already provide the forwarding/routing/TLS/SSL/Interconnect and bot plugin architecture at relatively high-speed (modern Java/JVM).  The cost of entry is really minimal.   This setup also makes debugging of any logging deployment fairly trivial.
 
The only thing that I believe is missing from the picture is a simple XMPP to System/SYSLOG bot plugin for OpenFire to translate XMPP messages to the system syslog calls.   From there it can be logged locally or forwarded out via RSYSLOG to more conventional log endpoints.  If XMPP is eventually widely adopted for logging then backend remote logging services can simply implement the XMPP server-to-server TLS connection to accept those messages directly (though I think unwrapping it from XMPP is probably a design win if done at the source).
 
Anyway – that’s my 2 cents.
 
 
Bill Heinbockel said,
 
…. As for your comments, there are many protocols out there that have some feature sets ideal for logging. I do like lighter weight and more feature rich protocols such as XMPP. Right now, the log protocol arena is fairly stagnant, you have Syslog, SOAP, or proprietary. Nothing offers the openness, features, and timeliness necessary for a log protocol.
 
MITRE has been putting together a list of requirements for log protocols which will be released along with the first public drafts of the other CEE specifications. These documents have been finalized and are just waiting for the final govt. approvals.
 
 
I replied:
 
Agreed about the stagnant nature of the protocols.
 
1. With Syslog (remote syslog in particular) you have significant issues with message reliability and length, which should be transparent at our layer.   RSyslog is great, but it's system availability is spotty at best in the Windows world.
2. SOAP, don't get me started.   Massive overkill for a messaging protocol - makes XMPP look like ICMP.   SOAP is, stripped of equivocation, a glorified RPC protocol.  RPC protocols are built on messaging protocols, not the other way around.
 
XMPP creates a distributed, reliable, bidirectional, authenticated and encrypted, routable, pubsub messaging bus for *users and processes*.  App/System/Network events that used to be opaque are not just visible, but sharable and discussable in real-time between widely dispersed experts.  Inside the bus you can makes requests of bots that can act as assistants, analysts, etc.
 
There are free and commercial implementations.
 
What's not to like?
 
 
 
Jim Burnes
Application Security Engineer
USDA/NRCS/ITC/Fort Collins
 
 
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Some Comments on Logging Protocols

Mark Poepping

A few naïve questions:

 

1)      How fast have you seen XMPP go?  Say pushing 1K log entries from bot to bot, presuming that you have to marshall to XML on the source side and unmarshall on the sink side?  How many per second?  Hundreds, thousands, or tens of thousands?

2)      Are you thinking about XMPP tiers to serve an enterprise that might need to handle a million messages/second?  How would you manage the tiers?

3)      What are you thinking regarding naming?  Since you have push and pull, you need to decide how you’ll name, by src and/or by dest, how will you format the entity names?

4)      You’re talking about a ‘private network’ for your XMPP-based logging, right?  Some of the messages may be sensitive - What access control model are you thinking?  I’m not terribly familiar with access control in XMPP, aside from the retracted XEP-0074, all I could find was references to white-listing, so I presume there’s block-listing too, but managing this matters, how were you thinking about managing, delegating, and/or forwarding access control information in a single tier?  And multi-tier, either for scale or federation?

5)      And continuing on access control, I presume it’s only channel-based, not content-based..  An example might be a syslog stream where you want security events to go to the security group and application events to go to the application and security groups (maybe), but if you have multiple applications served from a single syslog stream, how do you separate the events for app A from the events for app B (supported by separate groups)?

6)      And about queuing – what’s the typical server strategy for a sink that stops listening – I presume they buffer for a while and then give up, but if you’re a little sloppy with user or test instances, will the server image balloon?

 

Thanks, and sorry if the answers are obvious..

Mark.

 

 

From: Burnes, James - Fort Collins, CO [mailto:[hidden email]]
Sent: Wednesday, August 24, 2011 6:15 PM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols

 

Since I just joined the list, I thought I’d forward some comments I’ve shared with Bill that I would have posted to the list anyway.

 

Regarding requests for recommendations for a “better” logging protocol…

 

This something we are definitely working with here at the USDA Security Group.   One of the protocols we find very intriguing is XMPP. 

 

1.       It’s based on a persistent connection stream, with no inherent limits to message length. 

2.       It’s XML-based so individual messages can be clearly augmented with additional attributes.

3.       The log event itself is delineated by clean and recognizable start/end tokens

4.       XMPP routers and gateways exist to forward and relay XMPP messages from local DMZs to backend servers

5.       Obviously any IM user with a XMPP client can receive, tap or view the events in stream.  If XMPP is carrying log-specific markup, its ignored by default by XMPP user clients.

6.       XMPP tracks presence of all XMPP participants (log sources, log sinks, users, routers, bots in our case) – whether they are online, how long since last message etc.  

7.       Excellent (both Open Source and Commercial) implementations of XMPP servers exist to process both XMPP wrapped log traffic as well as user conversations

8.       Most of the better servers support publish/subscribe (observer) semantics for XMPP messages either through direct pubsub (XEP-0060) or Chat Rooms (XEP-0045) where security/system administrators can discuss the XMPP log messages streaming right before their yes.  This is rather unique as it allows chat discussions about system events happening presented at a human level.  Using various mechanisms, administrative teams can remotely introspect log event generators or log sinks.

9.       XMPP is routable, which allows connected user clients to direct logging commands at a log event sink via a “Bot”.  Would you like to subscribe to a different event stream?  Would you like to quench an overload of log events coming your way?  Send a command to a log bot.

10.   An automated process (Bot) can subscribe to a log message stream, select from certain events, reformat them and even forward them to a different protocol (say syslog etc).  This bot could also answer requests for gateway statistics, total log size, perhaps even queries against a particular log sink.

11.   XMPP is usually carried over a persistent TCP session and has native provisions for TLS stream encryption.  In fact, both session and inter-server security is supported by TLS.  Many servers have options which only allow encrypted sessions.  For particularly difficult firewall environments XMPP can flow over a bidirectional synchronous http connection (BOSH).

12.   RELP-like functionality could easily be provided by having log sink/target bots assert IO completion (writing to a log) by periodically sending an XMPP response message with the last completed message number.  The XMPP server or router could queue XMPP log messages until the logbot indicates that a portion of the message cache has been committed, thus allowing local event stream reconstruction in the event of failure.

13.   XMPP connections to servers and router/gateways can use a number of different standard authentication systems.

14.   Multiple XMPP servers can communicate via the server-to-server protocol.  Since servers share entity rosters, this allows connected entities (users, bots etc) to determine all of the logging endpoints in an enterprise.

15.   A great variety of commercial and open source development tools in various languages (Java, .Net, Python, Ruby, C, C++ etc) are available.

16.   Numerous user clients are available either in the system by default or free.

17.   XMPP already has widespread use throughout the industry being the basis for Google Talk and iChat as well as a messaging bus for VOIP and numerous other systems.

18.   Finally both log4net and log4j (standardized logging libraries for .net and java) have appender-listener extensions for XMPP that emit XMPP logging streams.

 

Against all of that, an XMPP message does carry some overhead for XML markup and parsing, but I think that’s relatively minute compared to the already massive XML and TLS processing burden that most systems already take for granted.  High performance parsers are in use and available for free.

 

After a recent design review were very excited about the incredible potential for monitoring, flexibility and de-coupling that a log4net/log4j  and XMPP log event streaming provide.

 

The good news is that an open source server like OpenFire and its connection-manager component already provide the forwarding/routing/TLS/SSL/Interconnect and bot plugin architecture at relatively high-speed (modern Java/JVM).  The cost of entry is really minimal.   This setup also makes debugging of any logging deployment fairly trivial.

 

The only thing that I believe is missing from the picture is a simple XMPP to System/SYSLOG bot plugin for OpenFire to translate XMPP messages to the system syslog calls.   From there it can be logged locally or forwarded out via RSYSLOG to more conventional log endpoints.  If XMPP is eventually widely adopted for logging then backend remote logging services can simply implement the XMPP server-to-server TLS connection to accept those messages directly (though I think unwrapping it from XMPP is probably a design win if done at the source).

 

Anyway – that’s my 2 cents.

 

 

Bill Heinbockel said,

 

…. As for your comments, there are many protocols out there that have some feature sets ideal for logging. I do like lighter weight and more feature rich protocols such as XMPP. Right now, the log protocol arena is fairly stagnant, you have Syslog, SOAP, or proprietary. Nothing offers the openness, features, and timeliness necessary for a log protocol.

 

MITRE has been putting together a list of requirements for log protocols which will be released along with the first public drafts of the other CEE specifications. These documents have been finalized and are just waiting for the final govt. approvals.

 

 

I replied:

 

Agreed about the stagnant nature of the protocols.

 

1. With Syslog (remote syslog in particular) you have significant issues with message reliability and length, which should be transparent at our layer.   RSyslog is great, but it's system availability is spotty at best in the Windows world.

2. SOAP, don't get me started.   Massive overkill for a messaging protocol - makes XMPP look like ICMP.   SOAP is, stripped of equivocation, a glorified RPC protocol.  RPC protocols are built on messaging protocols, not the other way around.

 

XMPP creates a distributed, reliable, bidirectional, authenticated and encrypted, routable, pubsub messaging bus for *users and processes*.  App/System/Network events that used to be opaque are not just visible, but sharable and discussable in real-time between widely dispersed experts.  Inside the bus you can makes requests of bots that can act as assistants, analysts, etc.

 

There are free and commercial implementations.

 

What's not to like?

 

 

 

Jim Burnes

Application Security Engineer

USDA/NRCS/ITC/Fort Collins

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Some Comments on Logging Protocols

Adam Montville
From: Mark Poepping <[hidden email]<mailto:[hidden email]>>
Reply-To: Mark Poepping <[hidden email]<mailto:[hidden email]>>
Date: Thu, 25 Aug 2011 02:02:31 +0000
To: <[hidden email]<mailto:[hidden email]>>
Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols

5.       Obviously any IM user with a XMPP client can receive, tap or view the events in stream.  If XMPP is carrying log-specific markup, its ignored by default by XMPP user clients.

Is this something that concerns others?  It's not clear whether this is being stated as identifying or mitigating a risk.  The implication is that user clients might ignore by default, but that they can be configured (or completely rebuilt in the open source case) to tap the event stream.  Does XMPP have any facilities to counter this?  All that said, I don't really know XMPP…
Reply | Threaded
Open this post in threaded view
|

Re: Some Comments on Logging Protocols

Bill Scherr IV
Is there a problem with tapping logs?  Credentials should not be in log files or
streams.

Circa 14:41, 25 Aug 2011, a note, claiming source Adam Montville
<[hidden email]>, was sent to me:

Date sent:       Thu, 25 Aug 2011 14:41:23 +0000
Send reply to:   Adam Montville <[hidden email]>
From:           Adam Montville <[hidden email]>
Subject:         Re: [CEE-DISCUSSION-LIST] Some Comments on Logging
Protocols
To:             [hidden email]

> From: Mark Poepping <[hidden email]<mailto:[hidden email]>>
> Reply-To: Mark Poepping <[hidden email]<mailto:[hidden email]>>
> Date: Thu, 25 Aug 2011 02:02:31 +0000
> To: <[hidden email]<mailto:[hidden email]>>
> Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols
>

> 5.       Obviously any IM user with a XMPP client can receive, tap or
> view the events in stream.  If XMPP is carrying log-specific markup,
> its ignored by default by XMPP user clients.
>
> Is this something that concerns others?  It's not clear whether this
> is being stated as identifying or mitigating a risk.  The implication
> is that user clients might ignore by default, but that they can be
> configured (or completely rebuilt in the open source case) to tap the
> event stream.  Does XMPP have any facilities to counter this?  All
> that said, I don't really know XMPP¦
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Some Comments on Logging Protocols

Mark Poepping
> Is there a problem with tapping logs?  

If you mean 'any user tapping logs', I'd say "absolutely YES!".  Since I presume that you likely mean 'any admin tapping logs', I'd still offer an emphatic "yes!".  In both cases, there are relevant 'need to know' issues.  You might have a small-enough shop that has a single set of do-it-all admins, but that's not really what you want, and you can't have that at any scale.   We have sets of network, systems, applications, and security operators and they have different needs for log information.  They have no business seeing *all of the logs* - that would be a significant (unacceptable) increase in our insider-threat profile..

I agree that you probably don't want credentials or acls *in* log files or streams (at least not now, though I don't discount it entirely), but *somebody* needs to manage access control - these were my point for items (4) and (5) in my original naïve questions.

Mark.

> -----Original Message-----
> From: Bill Scherr IV [mailto:[hidden email]]
> Sent: Thursday, August 25, 2011 10:54 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols
>
> Is there a problem with tapping logs?  Credentials should not be in log files or
> streams.
>
> Circa 14:41, 25 Aug 2011, a note, claiming source Adam Montville
> <[hidden email]>, was sent to me:
>
> Date sent:       Thu, 25 Aug 2011 14:41:23 +0000
> Send reply to:   Adam Montville <[hidden email]>
> From:           Adam Montville <[hidden email]>
> Subject:         Re: [CEE-DISCUSSION-LIST] Some Comments on Logging
> Protocols
> To:             [hidden email]
>
> > From: Mark Poepping
> <[hidden email]<mailto:[hidden email]>>
> > Reply-To: Mark Poepping
> <[hidden email]<mailto:[hidden email]>>
> > Date: Thu, 25 Aug 2011 02:02:31 +0000
> > To: <[hidden email]<mailto:CEE-DISCUSSION-
> [hidden email]>>
> > Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols
> >
>
> > 5.       Obviously any IM user with a XMPP client can receive, tap or
> > view the events in stream.  If XMPP is carrying log-specific markup,
> > its ignored by default by XMPP user clients.
> >
> > Is this something that concerns others?  It's not clear whether this
> > is being stated as identifying or mitigating a risk.  The implication
> > is that user clients might ignore by default, but that they can be
> > configured (or completely rebuilt in the open source case) to tap the
> > event stream.  Does XMPP have any facilities to counter this?  All
> > that said, I don't really know XMPP¦
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: Some Comments on Logging Protocols

dpal
On 08/25/2011 12:22 PM, Mark Poepping wrote:
>> Is there a problem with tapping logs?  
> If you mean 'any user tapping logs', I'd say "absolutely YES!".  Since I presume that you likely mean 'any admin tapping logs', I'd still offer an emphatic "yes!".  In both cases, there are relevant 'need to know' issues.  You might have a small-enough shop that has a single set of do-it-all admins, but that's not really what you want, and you can't have that at any scale.   We have sets of network, systems, applications, and security operators and they have different needs for log information.  They have no business seeing *all of the logs* - that would be a significant (unacceptable) increase in our insider-threat profile..
>
> I agree that you probably don't want credentials or acls *in* log files or streams (at least not now, though I don't discount it entirely), but *somebody* needs to manage access control - these were my point for items (4) and (5) in my original naïve questions.
>
> Mark.

Has anyone considered using http://www.amqp.org/ as a message transport?
It has everything you need to accumulate, send, route, filter, encrypt
messages. It can send files. We also have some code (aside) that can do
some interrupted file upload.
Different access for different topics comes really handy.
IMO the future of log transportation and consolidation is behind it.

And frankly I am not sure that the message format is that important in
terms of encoding. If the grammar is defined the data can be translated
easily from XML to JSON to key pairs or something else including binary
blobs of data as long as the encoding is a part of the metadata.

Just 2c.


>> -----Original Message-----
>> From: Bill Scherr IV [mailto:[hidden email]]
>> Sent: Thursday, August 25, 2011 10:54 AM
>> To: [hidden email]
>> Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols
>>
>> Is there a problem with tapping logs?  Credentials should not be in log files or
>> streams.
>>
>> Circa 14:41, 25 Aug 2011, a note, claiming source Adam Montville
>> <[hidden email]>, was sent to me:
>>
>> Date sent:       Thu, 25 Aug 2011 14:41:23 +0000
>> Send reply to:   Adam Montville <[hidden email]>
>> From:           Adam Montville <[hidden email]>
>> Subject:         Re: [CEE-DISCUSSION-LIST] Some Comments on Logging
>> Protocols
>> To:             [hidden email]
>>
>>> From: Mark Poepping
>> <[hidden email]<mailto:[hidden email]>>
>>> Reply-To: Mark Poepping
>> <[hidden email]<mailto:[hidden email]>>
>>> Date: Thu, 25 Aug 2011 02:02:31 +0000
>>> To: <[hidden email]<mailto:CEE-DISCUSSION-
>> [hidden email]>>
>>> Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols
>>>
>>> 5.       Obviously any IM user with a XMPP client can receive, tap or
>>> view the events in stream.  If XMPP is carrying log-specific markup,
>>> its ignored by default by XMPP user clients.
>>>
>>> Is this something that concerns others?  It's not clear whether this
>>> is being stated as identifying or mitigating a risk.  The implication
>>> is that user clients might ignore by default, but that they can be
>>> configured (or completely rebuilt in the open source case) to tap the
>>> event stream.  Does XMPP have any facilities to counter this?  All
>>> that said, I don't really know XMPP¦
>>>
>>>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Reply | Threaded
Open this post in threaded view
|

Re: Some Comments on Logging Protocols

Eric Fitzgerald
CEE is trying to be transport-neutral.  The board felt strongly that adoption of a particular transport protocol was one of the most likely ways to hamper adoption of CEE.

When we publish the draft specifications (which are ready, we're just waiting for them to show up on the web site), we'll provide a mapping for syslog and a general requirements document that indicates both mandatory and desirable optional protocol characteristics.  Mandatory requirements include things like carrying a true, CEE-compatible representation of the event records, etc.  Optional requirements include things like security and reliability characteristics of the protocol.

If someone wants to write a transport specification for CEE over XMPP, or CEE over AMQP, or CEE over IF-MAP, then they are free to do so (and in fact it will probably be easy to find volunteers to assist from among the draft specification authors).  The CEE specifications include an XML representational format so any protocol that can carry XML can carry CEE.

Best regards,
Eric

-----Original Message-----
From: Dmitri Pal [mailto:[hidden email]]
Sent: Thursday, August 25, 2011 10:17 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols

On 08/25/2011 12:22 PM, Mark Poepping wrote:
>> Is there a problem with tapping logs?  
> If you mean 'any user tapping logs', I'd say "absolutely YES!".  Since I presume that you likely mean 'any admin tapping logs', I'd still offer an emphatic "yes!".  In both cases, there are relevant 'need to know' issues.  You might have a small-enough shop that has a single set of do-it-all admins, but that's not really what you want, and you can't have that at any scale.   We have sets of network, systems, applications, and security operators and they have different needs for log information.  They have no business seeing *all of the logs* - that would be a significant (unacceptable) increase in our insider-threat profile..
>
> I agree that you probably don't want credentials or acls *in* log files or streams (at least not now, though I don't discount it entirely), but *somebody* needs to manage access control - these were my point for items (4) and (5) in my original naïve questions.
>
> Mark.

Has anyone considered using http://www.amqp.org/ as a message transport?
It has everything you need to accumulate, send, route, filter, encrypt messages. It can send files. We also have some code (aside) that can do some interrupted file upload.
Different access for different topics comes really handy.
IMO the future of log transportation and consolidation is behind it.

And frankly I am not sure that the message format is that important in terms of encoding. If the grammar is defined the data can be translated easily from XML to JSON to key pairs or something else including binary blobs of data as long as the encoding is a part of the metadata.

Just 2c.


>> -----Original Message-----
>> From: Bill Scherr IV [mailto:[hidden email]]
>> Sent: Thursday, August 25, 2011 10:54 AM
>> To: [hidden email]
>> Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging Protocols
>>
>> Is there a problem with tapping logs?  Credentials should not be in
>> log files or streams.
>>
>> Circa 14:41, 25 Aug 2011, a note, claiming source Adam Montville
>> <[hidden email]>, was sent to me:
>>
>> Date sent:       Thu, 25 Aug 2011 14:41:23 +0000
>> Send reply to:   Adam Montville <[hidden email]>
>> From:           Adam Montville <[hidden email]>
>> Subject:         Re: [CEE-DISCUSSION-LIST] Some Comments on Logging
>> Protocols
>> To:             [hidden email]
>>
>>> From: Mark Poepping
>> <[hidden email]<mailto:[hidden email]>>
>>> Reply-To: Mark Poepping
>> <[hidden email]<mailto:[hidden email]>>
>>> Date: Thu, 25 Aug 2011 02:02:31 +0000
>>> To: <[hidden email]<mailto:CEE-DISCUSSION-
>> [hidden email]>>
>>> Subject: Re: [CEE-DISCUSSION-LIST] Some Comments on Logging
>>> Protocols
>>>
>>> 5.       Obviously any IM user with a XMPP client can receive, tap or
>>> view the events in stream.  If XMPP is carrying log-specific markup,
>>> its ignored by default by XMPP user clients.
>>>
>>> Is this something that concerns others?  It's not clear whether this
>>> is being stated as identifying or mitigating a risk.  The
>>> implication is that user clients might ignore by default, but that
>>> they can be configured (or completely rebuilt in the open source
>>> case) to tap the event stream.  Does XMPP have any facilities to
>>> counter this?  All that said, I don't really know XMPP¦
>>>
>>>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
Reply | Threaded
Open this post in threaded view
|

Re: Some Comments on Logging Protocols

Adam Montville
On 8/25/11 10:25 AM, "Eric Fitzgerald" <[hidden email]>
wrote:

>CEE is trying to be transport-neutral.  The board felt strongly that
>adoption of a particular transport protocol was one of the most likely
>ways to hamper adoption of CEE.

Fair enough.  Sounds, then, like this discussion should be posted (moved?)
to the EMAP dev list.  I would expect EMAP to be explicit in which
transport mechanisms it will support.