Subject: [Syslog] 3195bis before syslog-sign

From: Chris Lonvick <[email-masked]>
Date: Thu, 25 Jan 2007 18:51:54 -0800 (PST)

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Jan 2007 11:46:12 +0100

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.
>
> 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
>

---

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Fri, 26 Jan 2007 07:44:46 -0500

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,
>

---

From: Balazs Scheidler <[email-masked]>
Date: Fri, 26 Jan 2007 14:00:01 +0100

>       will conform to draft-ietf-syslog-protocol's syntax, and have no

RAW also had line termination issues when multiple messages are
piggybacked to the same BEEP block. This was the reason that we
introduced framing in syslog-protocol-tls

-- 
Bazsi

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 26 Jan 2007 14:17:03 +0100

> Sent: Friday, January 26, 2007 11:46 AM
> To: Chris Lonvick
> Cc: [email-masked]

I agree with Bazsi, multiple messages inside a single beep block need a
different framing. The question is if we drop the multiple message per
block capability. Beep framing is not inefficient per se...

> IMHO the existing text in 3164 is sufficient.

syslog-protocol had carried over all security considerations from RFC
3164. Those now missing have been removed because it was WG consensus
that these are not valid security considerations. I suggest consulting
the mailing list archive before mandating any of them.

If we now find that something essential has been removed, we should add
this to -protocol during IETF last call. This would be the place where
it belongs.

> necessary either for draft-ietf-syslog-protocol or for the forthcoming

I will think about this, but out of my head I do not see any change I
would desire. One thing that would potentially be useful is the
transport path indication that was available with COOKED. However, I do
not know of a single implementation (including mine) that acutally
supports it - it was a very complicated beast. So it is probably not
desirable to have it.

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 26 Jan 2007 15:31:19 +0100

Hi John,

> From: Moehrke, John (GE Healthcare) [mailto:[email-masked]]
> Sent: Friday, January 26, 2007 1:45 PM
> To: Eliot Lear; Chris Lonvick
> Cc: [email-masked]
> Subject: RE: [Syslog] 3195bis before syslog-sign
> 

As you know, I value the work you are doing in IHE very much. I consider
the IHE record a payload of the syslog message. So having the protocol
itself XML-based does not neccesarily have any influence on IHE, as the
payload is not directly related to it.

On the issue of COOKED, I tend to agree that it has not received any
vital interest. As you know, I have implemented it, too. My
implementation, as I now know, seems to have some problems. I have not
intended to fix them as I actually never received any real demand on
that functionality. I had one interop conversation with someone working
on an IHE project (a very smart guy, was nice talking to him). This is
where I became aware of the problem with COOKED in my stack. One or two
other folks asked about COOKED and I think some university project
implemented it. But again, no real demand. Also, I do not know a single
*complete* implementation of COOKED. In my previous reply, I talked
about the PATH elements. In theory, these can be quite useful. But it is
pain in the ... to generate and to track them. Nobody has done that. For
IHE, keep in mind that you would need to implement PATH elements if you
ever want to (really) claim compliance to 3195 (these are not optional,
as far as I remember out of my head).

As a last example, I have learned that Cisco has implemented 3195 (which
is very welcome), but also only RAW. With RAW, we have at least some
actual implementations, even though I have yet to see someone who
deploys them. But they would work and would interoperate.

So my personal conclusion, too, is that COOKED is "no uptake". I like
the idea of obsoleting it. That does not mean you can no longer use it.
I question there is any specific value of COOKED for IHE. If it is done
in the spirit of syslog-protocol, the IHE record needs to be encoded as
sturctured data anyhow. So it does not matter if the underlying
transport is XML-based or not.

> thought this was the agreement of the committee last year.

Here I fully agree with you. I think, however, there is currently
nothing we can do to help advancing -protocol and the transport
mappings. They have been submited to the IESG and are now waiting for
IESG attention. So the WG can either idle or do other things. As we know
3195 needs to be revised, I find it useful to think about that.
Especially as I agree it should be straightforward activity.

What is questionable is if it is right to old -sign once again for
completion of other work. This has done many time, maybe too many times.
On the other hand, there is good reasoning to do so and the chairs have
explained their reasoning. I agree with their position.

HOWEVER, as soon as new work items for -protocol and the transport
mappings come up, we should immediately turn our attention to them.
Being through thru 4 years (or were it 5?) of revisions of -protocol, I
definitely want to see this work finished ASAP. I agree there is some
danger in discussing things. If -protocol and mappings need attention,
it might be problematic to switch back attention to them. I see this
risk. Maybe it is important enough to actually do nothing but idling...

I hope this clarifies my position. I honestly believe that the current
discussion is useful and is also useful for IHE.

Rainer

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 26 Jan 2007 07:08:02 -0800 (PST)

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=search_list&search_job_owner=0&search_group_acronym=syslog&search_status_id=1&search_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber=&search_area_acronym=&search_button=SEARCH

Thanks,
Chris

---

From: "David Harrington" <[email-masked]>
Date: Fri, 26 Jan 2007 10:25:40 -0500

Hi,

[speaking as co-chair]

> thought this was the agreement of the committee last year. 

That is what we are doing. The protocol, udp, and tls documents have
been submitted to the IESG for advancement. We are (almost) done with
those.

Our charter very explicitly shows the agreement from last year.
The next steps are to complete syslog-sign and syslog-mib. 
That is what we are attempting to do, by resolving some dependency
problems between syslog-sign and RFC3195, as discussed in my other
email.

David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, syslog WG

> Sent: Friday, January 26, 2007 7:45 AM

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 26 Jan 2007 16:41:32 +0100

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

> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Friday, January 26, 2007 4:08 PM
> To: Moehrke, John (GE Healthcare)
> Cc: [email-masked]
https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&
search_job_owner=0&search_group_acronym=syslog&search_status_id=1&searc
h_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber=&search_a
> rea_acronym=&search_button=SEARCH
> 
> Thanks,
> Chris
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 26 Jan 2007 10:56:54 -0500

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]

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Friday, January 26, 2007 10:42 AM
> To: Chris Lonvick; Moehrke, John (GE Healthcare)
> Cc: [email-masked]
> > Is the healthcare industry using COOKED now?  I can't tell from
your
> > note
> > of RFC 3195 that use COOKED.  From what I've seen the 
> implementations
> > are
> > 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,
> > > "no uptake"? We have security audit events that get captured in
an
> > XML
> > > would like to understand why "no uptake" is a reason for
removing
> > this.
> > >>       will conform to draft-ietf-syslog-protocol's 
> syntax, and have
> > no
> > >>       length limitation.
> > >>       RFC 3195 calls for use of 3DES for TLS.  We 
> propose that the
> > new
> > >> covered in draft-ietf-syslog-protocol. However, those
references
> > that
> > >>> dependencies upon 3195bis.  As was noted in the email
discussion
> it

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 26 Jan 2007 17:51:18 +0100

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

> 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]

---

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Mon, 29 Jan 2007 09:05:20 -0500

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 

> Sent: Friday, January 26, 2007 10:51 AM
> To: David Harrington
> Cc: [email-masked]
> > > > A point on the process:  We are done with 
> syslog-protocol.  It has
> > > been
> > > > syslog-sign, and now 3195bis. You can follow the 
> progress of these
> > > > here:
> > > >
> > > > > I agree that the audit servers have not implemented 
> it, but then
> > > > again
> > > > > As a very interested observer and consumer of your 
> standards, I
> > am
> > > > >> we will need to incorporate a few of those remaining 
> concerns,
> > > where
> > > > >>> would be messy to try to publish syslog-sign with 
> dependencies
> > > upon
> > > > >>> syslog-sign, and any other, future applications, 
> can make use
> > of

---

From: Peter Hall <[email-masked]>
Date: Mon, 29 Jan 2007 20:50:30 -0500

Quovadx  have a COOKED implementation but the project is on hold  
because the IHE have it on hold.
it also supports RAW. I don't remember but I'm guessing PATH was not  
implemented.

Peter