Subject: RE: [Syslog] 3195bis before syslog-sign

From: [email-masked]
Date: Mon, 29 Jan 2007 09:45:55 -0500

I will clarify this a bit more.  We have said not to implement it *for
now*.  The Reliable-Syslog does meet all the various healthcare
requirements.  It has a couple minor bugs to fix, but if it were being
deployed we would be happily using it.  We can tolerate syslog-protocol if
it is widely available.  It meets the needs of many of our installations.
It is not as general a solution as Reliable-Syslog, but we can deal with
the exception cases with our own solutions and it is much better than
bsd-syslog.

As examples of the gaps in syslog-protocol:
  Reliable-syslog channels identify message schema and source during
channel setup.  This enables limited-support error responses during setup,
and permits faster message processing and better message handling.
  Reliable-syslog provides robust application level datagram
acknowledgement.  This is necessary to avoid data loss due to power failure
and network physical disconnections.  That would be a minor issue except
that the trend in medical equipment is toward mobile systems.  They are
disconnected and moved without warning.

R Horn

                      "Moehrke, John                                                                                             
                      \(GE                     To:       <[email-masked]>                                                       
                      Healthcare\)"            cc:       (bcc: Robert Horn/MOPOO/AGFA)                                           
                      <John.Moehrke@med        Subject:  RE: [Syslog] 3195bis before syslog-sign                                 
                      .ge.com>                                                                                                   
                                                                                                                                 
                      01/29/2007 09:05                                                                                           
                      AM                                                                                                         

Do not fear about deployments from the Healthcare (IHE) community. Due
to the lack of syslog-community support for Reliable-Syslog, we have
told our members to not implement it. My important point in my post last
week is that right now the only thing we can find as a transport for our
security-audit-message is BSD-Syslog. You are all very aware of the
problems with that. The Healthcare community is very anxious about using
a protocol that is lossy-without-notice, as we take great care in
handling patient data (and thus patient health and safety).  THEREFORE,
I want the to encourage the syslog-community to work on one thing, the
replacement for BSD-Syslog. I now understand that syslog-protocol and
family are out... I thus want to encourage the implementation of
syslog-protocol and family by you all. The Healthcare (IHE) community is
very happy to leave BSD-Syslog and Reliable-Syslog if we have evidence
that syslog-protocol will be widely implemented.

Things like syslog-sign are interesting, but are not as high priority as
a well implemented working replacement for BSD-Syslog.

John

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Friday, January 26, 2007 10:51 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: RE: [Syslog] 3195bis before syslog-sign
>
> Hi David,
>
> I am keeping track of 3195 implementations here:
>
> http://www.syslog.cc/ietf/rfcs/3195.html
>
> I've just added the Cisco implementation, which is the first one by a
> major player (but RAW mode only).
>
> I do *not* know of any actual deployments, at least not in production
> environments. I'd suspect there are some users of SDSC syslog which
> eventually use 3195 and maybe even in the limited COOKED mode
> available.
> As far as I can tell, noone from our own user basis has ever deployed
> 3195. There were some test cases and some university projects, but as
> far as I know nothing lasting. I assume there are some deployments in
> IHE environments, but John can probably comment on that much
> better. As
> far as I know, the most interest has come from the IHE community,
> because there was a somewhat imprecise specification of the
> message size
> limit found in 3195, which enabled IHE to transfer oversize
> messages in
> a way that could be claimed to be standards-compliant (see
> http://www.syslog.cc/ietf/autoarc/msg01454.html).
>
> A side note: While I browsed that threat, I found this message here:
>
>    http://www.syslog.cc/ietf/autoarc/msg01463.html
>
> The important quote is:
> ###
> As a specific example of what Rob Horn mentioned, see RFC
> 3881.  This is
> also incorporated in the work of multiple healthcare standards groups.
> Cooked reliable syslog messages are the transport.
>
> Glen Marshall
> ###
>
> This seems to indicate there is a field of yet-unknown deployed
> implementations. This also seems to be at the bottom of John's concern
> from earlier today. If COOKED reliable syslog is already
> referenced AND
> implementend AND eventually even deployed, we should be very careful
> about obsoleting 3195.
>
> Rainer
>
> > -----Original Message-----
> > From: David Harrington [mailto:[email-masked]]
> > Sent: Friday, January 26, 2007 4:57 PM
> > To: Rainer Gerhards; 'Chris Lonvick'; 'Moehrke, John (GE
> Healthcare)'
> > Cc: [email-masked]
> > Subject: RE: [Syslog] 3195bis before syslog-sign
> >
> > Hi Rainer,
> >
> > Since you have looked around already, can you give us a quick survey
> > of how many have implemented or deployed RAW mode?
> >
> > David Harrington
> > [email-masked]
> > [email-masked]
> > [email-masked]
> >
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[email-masked]]
> > > Sent: Friday, January 26, 2007 10:42 AM
> > > To: Chris Lonvick; Moehrke, John (GE Healthcare)
> > > Cc: [email-masked]
> > > Subject: RE: [Syslog] 3195bis before syslog-sign
> > >
> > > Chris,
> > >
> > > I know that SDSC syslog has a partial implementation of
> > > COOKED (PATH is
> > > not covered). I have an implementation of COOKED (also without
> > PATH),
> > > but now know that there are some issues with it (which I do not
> > intend
> > > to fix, given the desinterest of the logging community). I know of
> > at
> > > least one other proprietary implementation of COOOKED
> inside the IHE
> > > community. I do not know if that project is still active.
> > >
> > > I do not know of any *deployment* of COOKED. I do not know of
> > > any major
> > > vendor COOKED implementation.
> > >
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: Chris Lonvick [mailto:[email-masked]]
> > > > Sent: Friday, January 26, 2007 4:08 PM
> > > > To: Moehrke, John (GE Healthcare)
> > > > Cc: [email-masked]
> > > > Subject: RE: [Syslog] 3195bis before syslog-sign
> > > >
> > > > Hi John,
> > > >
> > > > Is the healthcare industry using COOKED now?  I can't tell from
> > your
> > > > note
> > > > below.  I'll invite all others to say if they know of any
> > > > implementations
> > > > of RFC 3195 that use COOKED.  From what I've seen the
> > > implementations
> > > > are
> > > > only using RAW.  Now is the time to set the direction
> for 3195bis.
> > > >
> > > > A point on the process:  We are done with
> syslog-protocol.  It has
> > > been
> > > > submitted to the IESG along with syslog-transport-udp and
> > > > syslog-transport-tls.  We're waiting on IESG review and
> > > then time for
> > > > the
> > > > RFC Editor to get it published.  We're now focusing on
> > > syslog-device-
> > > > mib,
> > > > syslog-sign, and now 3195bis. You can follow the
> progress of these
> > > > here:
> > > >
> > > https://datatracker.ietf.org/public/pidtracker.cgi?command=sea
> > > rch_list&
> > > >
> > > search_job_owner=0&search_group_acronym=syslog&search_status_i
> > > d=1&searc
> > > >
> > > h_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber=
> > > &search_a
> > > > rea_acronym=&search_button=SEARCH
> > > >
> > > > Thanks,
> > > > Chris
> > > >
> > > >
> > > > On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote:
> > > >
> > > > > The Healthcare industry has tried to use COOKED... WHY is it
> > > > considered
> > > > > "no uptake"? We have security audit events that get
> captured in
> > an
> > > > XML
> > > > > message; thus COOKED would be preferred. (See RFC 3881)
> > > > >
> > > > > I agree that the audit servers have not implemented
> it, but then
> > > > again
> > > > > there isn't much conformance to any other syslog specification
> > > > either. I
> > > > > would like to understand why "no uptake" is a reason for
> > removing
> > > > this.
> > > > > It is not for lack of trying.
> > > > >
> > > > > As a very interested observer and consumer of your
> standards, I
> > am
> > > > > getting very frustrated at the lack of commitment to ANY
> > > > specification
> > > > > and lack of interest in completing anything. I strongly
> > recommend
> > > > > singular focus on syslog-protocol and it's bindings. Get them
> > > > > implemented before you start messing around with other
> > > things. I had
> > > > > thought this was the agreement of the committee last year.
> > > > >
> > > > > John Moehrke
> > > > > GE Healthcare
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Eliot Lear [mailto:[email-masked]]
> > > > >> Sent: Friday, January 26, 2007 4:46 AM
> > > > >> To: Chris Lonvick
> > > > >> Cc: [email-masked]
> > > > >> Subject: Re: [Syslog] 3195bis before syslog-sign
> > > > >>
> > > > >> Chris & all,
> > > > >>
> > > > >> As you mentioned, Darren, Marshall, and I will produce an
> > > > >> internet-draft
> > > > >> that revises RFC 3195 (rfc3195bis).  As part of that effort
> > > > >> we envision
> > > > >> accomplishing the following:
> > > > >>
> > > > >>     * Obsoleting RAW and COOKED profiles.  The RAW profile
> > > > >> has a length
> > > > >>       limitation that we have been told is not
> appropriate for
> > > > >>       syslog-signed.  The COOKED profile has seen no
> > > uptake.  This
> > > > >>       dramatically simplifies the draft.
> > > > >>     * A new profile that has taken on the name of
> TARTARE will
> > > > >>       essentially be RAW rev 2.  Messages sent with the
> > > > >> TARTARE profile
> > > > >>       will conform to draft-ietf-syslog-protocol's
> > > syntax, and have
> > > > no
> > > > >>       length limitation.
> > > > >>     * We will review existing security considerations.  For
> > > > instance,
> > > > >>       RFC 3195 calls for use of 3DES for TLS.  We
> > > propose that the
> > > > new
> > > > >>       draft take on a more modern approach with regard
> > > to algorithm
> > > > >>       agility and which algorithm SHOULD be the low bar.
> > > > >>
> > > > >> In our early drafty draft, we were unable to eliminate all
> > > > >> references to
> > > > >> RFC 3164, due to reference of security considerations
> > > seemingly not
> > > > >> covered in draft-ietf-syslog-protocol. However, those
> > references
> > > > that
> > > > >> remain are NOT normative.  If a complete separation for 3164
> > > > >> is desired
> > > > >> we will need to incorporate a few of those remaining
> concerns,
> > > where
> > > > >> IMHO the existing text in 3164 is sufficient.
> > > > >>
> > > > >> Finally, do people desire any other changes that would be
> > > considered
> > > > >> necessary either for draft-ietf-syslog-protocol or for the
> > > > >> forthcoming
> > > > >> syslog-signed work?
> > > > >>
> > > > >> We predict this work to progress rapidly.
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Eliot
> > > > >>
> > > > >> Chris Lonvick wrote:
> > > > >>> Hi Folks,
> > > > >>>
> > > > >>> David Harrington and I had a talk about syslog-sign and its
> > > > >>> dependencies upon 3195bis.  As was noted in the email
> > discussion
> > > it
> > > > >>> would be messy to try to publish syslog-sign with
> dependencies
> > > upon
> > > > >>> 3195, then update 3195, then revise syslog-sign.  We had a
> > > > >> talk with
> > > > >>> Sam Hartman, our AD, who agreed that we should revise
> > > RFC 3195 to
> > > > >>> eliminate unnecessary dependencies.
> > > > >>>
> > > > >>> David and I are pleased to announce that Darren New,
> > > > >> Marshall Rose and
> > > > >>> Eliot Lear have volunteered to produce a revision to
> > > RFC 3195.  We
> > > > >>> expect that this will be a transport for syslog-protocol so
> > that
> > > > >>> syslog-sign, and any other, future applications,
> can make use
> > of
> > > > >>> syslog-protocol without having to worry about transport
> > > > >> dependencies.
> > > > >>> Other goals of 3195bis will be to deal with the length
> > > > >> limitation in a
> > > > >>> manner consistent with the other transports, and to
> eliminate
> > > > >>> references to RFC 3164.
> > > > >>>
> > > > >>> We've have had an initial explanation of how the authors
> > > > >> will revise
> > > > >>> 3195 which sounds reasonable.  I will let Darren, Marshall
> > > > >> and Eliot
> > > > >>> propose the changes to the list.  This should be a
> > > quick effort so
> > > > >>> please pay attention and discuss this on the list so we
> > > can get it
> > > > >>> moving.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Chris & David
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> Syslog mailing list
> > > > >>> [email-masked]
> > > > >>> https://www1.ietf.org/mailman/listinfo/syslog
> > > > >>>
> > > > >>
> > > > >> _______________________________________________
> > > > >> Syslog mailing list
> > > > >> [email-masked]
> > > > >> https://www1.ietf.org/mailman/listinfo/syslog
> > > > >>
> > > > >
> > > >
> > > > _______________________________________________
> > > > Syslog mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> > > _______________________________________________
> > > Syslog mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> >
>
>
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
>

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog