Re: [Syslog] plain tcp syslog
> > I'd like to see that too, although I think the length needs to be 32K for > healthcare audit records (see RFC 3881). Why ? RFC 3881 doesn't specify that syslog needs to be anywhere. If you've got long records that need to be saved for audit purposes then perhaps a protocol other than syslog should be used for this ? Just because you have a hammer doesn't make everything you want to fix a nail. (or however it goes :) Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] plain tcp syslog
.. > This discussion is largely targeted at SNMP and NETCONF over TCP-based > transports, such as SSH. It sounds like the syslog WG should be > involved in this discussion as well, even if the WG chooses to just do > a TCP transport mapping. The security and transport needs for SNMP, > Netconf, and syslog are converging. So what you're saying is that the others are tunelling via ssh to deliver data back via secure means as well as have that connection properly authenticated ? (for some value of "proper") > Note that a TCP transport mapping was developed for SNMP (RFC3430), > and the demand was for more than just TCP; the demand was for a > secured TCP transport. Why was SSL/TLS rejected ? > For the record, I believe standardizing a TCP-based transport mapping > for syslog, preferably using SSH, would be a good supplement to the > UDP transport mapping. How do you propose (or imagine) that this would work for an arbitrary device connected to your network (say printer) that wants to use this mechanism to deliver syslog messages ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] plain tcp syslog
[ Charset ISO-8859-1 unsupported, converting... ] > Rainer: > > Just my 2 cents... > > I am not in favor of informational RFC describing some behavior "as > seen in the wild". If you want to create a standard - that's a different > matter. But an informational RFC just clouds the water because it makes > an appearance of describing a standard, while not really making any > standard. Good, so you don't have any technical problems with doing it. > This has been a point of major confusion around syslog RFC 3164, for > example. I have personally had to explain over and over to a lot of > engineers/managers that it is not a standard and "compliant" > implementation can send petty much anything yet claim consistency with > that RFC. That's what you end up with when you don't have strict > requirements in the RFC. Have you also mentioned to your engineers/managers that all of the Cisco devices, for years and years, were RFC 3164 compliant ? Or that this RFC documents an otherwise undocumented protocol that they have been implementing for years ? What you're describing are organisation problems and not the domain of this working group to solve. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] plain tcp syslog
> > We have discussed the issue of a very-simple, non-BEEP based plain tcp > > syslog several times on this list. The idea always has violently been > > rejected. > > Iff (if and only if) there will be a standard for syslog-over-tcp, I > think it should do more then replace UDP by TCP. Eventually, yes. But we don't have to get there in one big jump, especially if there is evidence that the proposed result will be widely rejected. > I mention this example; to show replacing UDP by TCP is simple and > will suffice. I think, there is need for a TCP version. Personally, I > don't like BEEP, nor the syslog-over-BEEP option. But a don't like a > simple TCP syslog nether. I think starting off with a simple TCP syslog and adding to it with a reliable version (matching the UDP progress) is the right way to start. I think there is much more chance of getting progress and useful RFCs and internet drafts published that way than trying to solve the entire solution space in one hit. i.e. BEEP has been proposed as "the solution", nobody likes it, lets back off, do what we know people like and along the way maybe we will learn about how to deliver the ultimate solution that people do want. btw, I'm willing to add my voice to this in Vancouver, if it matters to anyone. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] plain tcp syslog
> > RFC 3881 is transport agnostic. However, DICOM Supplement 99 and the IHE > technical framework that specify its implementations currently require > Reliable Syslog COOKED. The issue is the maximum supported length. RFC > 3195 does not specify a limit. So the issue is what that limit should be. Well whoever wrote DICOM Supplement 99 and the IHE technical framework should be told they screwed up in deciding that this was the way to go and implementors should use something else that makes sense. > Many of the medical devices that implement an audit capability are not > general-purpose computers, e.g., radiological modalities. A simple protocol > stack like BEEP is preferable, for a variety of good reasons, for those > cases. BEEP is NOT simple. BEEP is extraordinarily complex solution for what is a very simple problem. If it was simple syslog over TCP, today, would use it. In open source, people vote with their feet (or their code) and the result of that poll is that BEEP for syslog over TCP is a failure. BEEP and syslog is like an orphan looking for someone or something to make it feel loved. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] TCP and SSH Discussion
> Hi, > > Our charter says: > > At a minimum this group will address providing authenticity, integrity > and confidentiality of Syslog messages as they traverse the network. > > If the WG feels that an SSH transport will accomplish this goal, and it > will be used, then I'm open to having that discussion. I don't feel that > documenting current tcp transports works towards that goal. The only concern I'd have would be syslog being _only_ UDP over ssh. But then if SNMP is operating in this manner, I'm much less concerned about it being a problem of any kind. If there are 4 different TCP transports for syslog out there, it might be worth trying to get them to converge and be interoperable. If the number can be reduced to 1 or 2, and this represents a sizable portion of the syslog over TCP install base, I think it behooves us have that protocol published. This might be something to push back on the implementors of said protocol(s). > I've heard a > few voices say that they would support an SSH transport on the mailing > list. Does anyone object or have a differing view? I'd add that we should look at supporting both TCP and UDP transports to the ssh endpoint but also, see the above. Using ssh is clearly a winning proposition at this piont in time. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] TCP and SSH Discussion
> Hi Darren, > > It's not "syslog/udp/ssh" nor "syslog/tcp/ssh", it's going to be > "syslog/ssh/tcp/ip". syslog will be a defined subsystem for SSH much like > sftp and netconf. Oh! Hmmm. Do you have any links to critiques about sftp ? I've spoken to at least one person recently (but I can't recall *who*) that wasn't too impressed with sftp, so I'm curious if there is anything substantial that discusses its drawbacks and what lessons (if any) need to be learnt from it. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] TCP and SSH Discussion - where are we heading to?
.. > But the low implementor participation and end-user adoption rate is > raising a very important question to me: are we still heading into the > right direction? What does it help if we create better and better > standards (assumed they are, which is obviously arguable) but nobody > cares? In practice, mostly non-official-standard solutions are being > asked form, developed and deployed. For example, I will begin to > implement plain tcp syslog with ssl encryption shortly. Not because it > is so secure or reliable - simply because there is so much demand for > it. Current approaches typically use plain tcp syslog together with > stunnel (which, by the way, is valid solution for many needs). Right. This is close to the approach I took, over 5 years ago now, that started this off. I wasn't happy with the unbounded record problem you have with TCP and so added a small header to mark the start of messages. This was more just for the sake of doing it than any market driver(s). > May be it is just me feeling some asynchronicity between what the field > is asking for and what we are doing. I think there has been too little feedback to this group and research done by this group about how syslog is evolving "out there". If someone is deploying a syslog using TCP solution, what are they likely to do? My bet is pick one software bundle and use it everywhere they can. For the most part, this is going to be of most signifance to Linux people. If you're using AIX, HP-UX or Solaris, chances are you don't have the freedom to upgrade/replace syslogd so you're stuck using UDP. If you're using various pieces of network equipment, I'm willing to bet people use syslog/udp because that is what everyone does & understands, removing problem of interoperable syslog/tcp implementations. If you were a commercial Un*x vendor, what would it take you to want to spend $$ on replacing your in-house syslogd? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] plain tcp syslog
> Darren: > > Well... You say all of Cisco devices "were RFC 3164 compliant". > This illustrates my point. What exactly does this compliance mean? That the device delivers an ASCII text message that can be easily read and understood, without any translation tools, by someone familiar with the product. > My point is that any product can legitimately claim compliance with > RFC 3164 and this claim has zero practical usefulness! I don't know > what that compliance means, if RFC 3164 says in Sec 4.2: > > "There are no set requirements on the contents of the syslog packet as > it is originally sent from a device. It should be reiterated here that > the payload of any IP packet destined to UDP port 514 MUST be considered > to be a valid syslog message." Right, so that's way too loose, but is it like that because some devices do not implement the header with the priority, etc ? > Now, one may argue that we could make a more strict informational RFC > than RFC 3164. But if we can do an RFC with strict requirements - then > make it a standard. I think it is a better investment of WG resources. > But obviously consensus opinion rules. Maybe we need to say "RFC 3164 documents the past but this new RFC is the document that defines syslog/udp for the future" ? If we did that, just rewrote section 4.2 so that it required the header, rather than left it open, it would be minimal effort for establishing a new RFC to define a proposed BSD syslog/UDp standard. Is there any reason why we wouldn't want to do that? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Secure substrate - need your input
[ Charset ISO-8859-1 unsupported, converting... ] > > 1) What secure substrate should the WG look towards: > > > > __ ssl > > > > __ ssh > > > > __ dtls > > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > > > > __ other > > I believe it should be SSL 3.0 / TLS 1.0. I agree and for all the reasons you said. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: Why not TLS was Re: [Syslog] Secure substrate - need your input
[ Charset ISO-8859-1 unsupported, converting... ] > Just to add the figures that support my assertion, in an e-mail from Wes > Hardaker, who surveyed the network operators, to isms > > "Of the various authentication systems in use at that time by the people that > responded: > > 66% local accounts > 49% SSH-keys > 40% Radius > 29% TACACS+ > 14% X.509 Certificates > 10% Kerberos > > [numbers don't add to 100 because more than one option could be selected]" > > which I have paraphrased as > SSH a significant number > TLS so small as to be invisible I disagree. I don't think the numbers above provide that kind of conclusion at all. We don't know what the survey was, etc. Just like any set of statistics, they can be interpreted to mean many things, depending on how you want to read them. Anyway, I'm not interested in that. But, to put the problem differently, in how many different places can you use TLS/SSL for authentication today, to sign in ? If there's nowhere for people to use TLS then of course the numbers won't be high. Darrn ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: Why not TLS was Re: [Syslog] Secure substrate - need your input
> > I think that the issue of I-Ds is a red herring. TLS is a string of I-Ds, > reflecting recent work on a protocol that many have not heard of, knowing > only of SSL. SSH is a string of I-Ds, reflecting recent work on a protocol > that many are familiar with. In both cases, there are problems of > conformance, of there being different, not quite standard flavours, and > the work of the IETF is to bring conformity to two well established > protocols (bit like syslog:-). I think most people are going to be about as familiar with the TLS protocol as they are with the SSH one - in terms of depth of knowledge. As for use, well as you've pointed out, anyone using "https" is using TLS/SSL, so it's hard to say people are unaware of it. In both cases, people generally follow a specific "script" to achieve a given goal without being overly concerned about the flow of bits and bytes in the middle. In summary, I find this line of argument quite specious. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter revision - why is there so a big difference between list concensus and meeting concensus?
> Chris, > > We have been working 2+ years on syslog-protocol and > syslog-transport-udp. We had hard discussions. It looked we reached > concensus on the mailing list. Then, in the meeting, non-concensus was > found. It looks like we have a big discrepancy between what is said on > the mailing list and what is said in meetings. I think we need to tackle > that *issue* first. Well, if more people from the list showed up in meetings, that might not be such a problem. > Why are we pushing for more and more changes on the mailing list, just > to abandon things when they come close to being finished. To get me > right: I have no really bad feelings about the way things have evolved > (though I have to admit that it is hard to accept that 2+ years of work > are being abandoned in 30 minutes - but that is life and it is better to > abandon things than to create things that nobody uses [hint: rfc > 3195;)]. I only fear that we will work another 2+ years, just to arrive > where we are right now. If we do not solve the discrepancy between > on-list and off-list concensus, anything we do can strongly be > questioned. First problem: RFC 3195 looks incredibly complex, so rather than try and understand it, people ignore it. I think that people, as a result, tend to be less interested in getting involved, looking at that. What happened here was a lack of good protocol engineering. What the group attempted to do was solve "world hunger" and as a result, we gave birth to something that few people see any benefit in and it is easier for them to do their own thing since that RFC seems to be largely irrelevant. So, I think going forward, this group needs to be more cogniscent of what the world *really* wants and find a way to deliver that rather than something we think they need and in actuality, don't want. > So my big question is: how did this come? Was there a totally different > set of people in the meeting (I noticed some quite uninformed comments > in the notes)? Were these folks on the list and just not speaking up? Probably :) > What can we do to prevent this in the future? Please speak up NOW if you > are just lurking ;) Get better and more critical reviews on what the group is doing and do not pass on documents that do not have this. I suspect the problem here is finding interested and qualified people who have the time. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter revision
Chris, What I'd like to see happen is for 3195 to be broken up into 2 or more new RFCs, one (or more) which cover the protocol and one which defines their use over BEEP. i.e. One which covers the COOKED profile, one which covers a RAW profile and one which covers one or both of these over BEEP. We may also choose to add a BSD profile (which is syslog-protocol or an enhanced version of 3164.) That nails down the protocol. Next we move on to defining how the protocol is used. So we describe syslog (COOKED/RAW/BSD) over BEEP/ssh/TLS/UDP/TCP. I think if we evolve that way there is a much better chance of aligning ourselves with what people are doing and want to do without rendering what we've done to the scrap heap completely. It may also be worth taking input from those who have developed or deployed 3195 to understand if there are components of it that did/didn't work. When we get close to getting all of that documentation done, I'd be for advocating that 3195 be moved to "experimental" status, rather than obsolete. For example, chosing this path gives us a syslog-BSD/tcp that should be close enough to what people are doing today with this, bringing together most of these implementations as being RFC compliant. I expect work will be required on both sides to evolve it a little to get there, but I think there's considerable advantage for us and developers if a little work on the part of each party results in RFC compliant software. Sam, do you have any comments on taking this approach with the syslog protocols by the working group ? Cheers, Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter revision / WG obsolete?
Hi all, > If I get the essence in Darren's message right, > what he is proposing is to create a layered architecture for syslog. Yes, by using what's gone before us as the way to start doing that. > Please face it: on the WG mailing list, we are pressing for ever and > ever change. More and more new things. At least in the last meeting, we > are trying to conserve as much as possible (which I personally like). > This won't go together. What I think the WG is lacking is a good long term focus of objectives. I believe this is largely because the group has been meandering along. I think we need to refocus by looking at where people are going with developing syslog protocols and evolve what exists today to meet that. > Obviously, I am not participating > in the meetings for a reason: I simply can not justify traveling around > the world for a 30 minute time slot even without a strong business case. > I thought that personal participance is not a absolute must in IETF work > (though I clearly understand its importance). Which is why those who attend the meetings are often involved in more than a single WG. .. > - we ignore running code and rough consenus existing in practice > (syslog/tcp) My hope is that if we pursue a layered approach will allow us to easily document a protocol that covers the existing practice in this area as well as provide a path for future design. > Please do not misunderstand me: of course, I am a bit frustrated about > that this WG has fundamental problems. I personally doubt it makes sense > to continue without solving them. Where I think we've gone wrong and I hear indications of "going wrong" are with people who want to solve their own pet problem - we've lost sight of the big picture. For example, the different message format to allow bit-banging for indicate this or that has happened to the message. For most people, it does nothing. As too with XML - I'm sure there is a large contingent of developers out there who balk at any document that mentions XML, even if its optional. I think the WG should remain and has a purpose. At the meeting Sam Hartman mentioned that we were going nowhere fast and in danger of being shut down. Apparently this isn't uncommon but I think that although there problems that they aren't beyond fixing. I think the key to achieving a good result has got to be thinking that it is ok to have lots of small documents rather than just one big document. If nothing else, it should make the work required to produce a single one down and therefore more attractive. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter revision / WG obsolete?
> As one of the many lurkers on this list, I have been monitoring this > WG's activities and I'm a bit concerned with the recent posts. I had > high hopes that some form of logging standardization might materialize, > but that now seems to be in question. That is outside the scope of this WG. We're trying to concentrate on the protocol used to convey log information - that's all. > Recent regulations within the U.S. (e.g., SOX, HIPAA, SEC, FDA, etc.) > and other countries are forcing organizations to implement > "accountability" measures. Audit logging (as well as authentication and > authorization) is a critical element of these accountability measures. > Seems to me that this WG might want to step up and standardize the way > this gets handled. If nothing else, it could give the WG a little more > focus. That information _may_ be placed in syslog messages but the scope of what you're talking about includes much more than just sending data between daemons. For now, we have other more basic problems to solve and as tempting as it is to try and solve these too, it would just be a distraction and stop the WG from achieving what it needs to achieve. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] formal Consultation prior to concluding the working group
> Hi WG, > > in order to provide feedback to Sam, I would like to know what you > current view of syslog-protocol is. I am asking especially those people > that objected it in the meeting. Please share your concerns with us, > because only this allows us to drive that thing forward. I have > absolutely no problem with changes, but we need to know that people > think there is need to change. > > So, please let the WG know any concerns you might have with > syslog-protocol and/or the work we have carried out so far. I've been asleep on here and not reading the drafts for too long. syslog-protocol is trying to do bit-banging it text, a-la "RAW" from 3195. This leads me to believe that the protocol is badly designed. Looking at it, it seems to be a cross between COOKED and RAW mode from 3195. Maybe the fault of this is this "structured data" that seems to be pervasive in the IETF at present. What you might call a poor man's XML. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] formal Consultation prior to concluding the working group
> > 2) Is there another charter under which the working group would better >be able to make progress? I believe the answer to this is yes. There is very relevant work this group could do and should do. If you look at what the community at large has done with implementing syslog in recent years, the only conclusion that you can draw is that what it has been doing, apart from 3164, has been quite distant from what this should have been doing. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] New direction and proposed charter
> David, > > I think your words have cut through the confusion on this. I agree with > your proposed changes. > > Many thanks, > Chris For what it's worth, I also agree with these proposed changes. Darren (on the road again for a few weeks) ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] New direction and proposed charter
> WG, > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG I would put the SD-IDs after the message. The SD-IDs and detailed bits of meaning to the MSG and without the MSG, are irrelevant. The exception being a language marker. > - replace NUL with an escape sequence upon reception (e.g. <00>) Why not \0 ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] New direction and proposed charter
.. > If we go for framing, we must use byte-couting, because we have not > outruled any sequence. If we go for octet-stuffing, we must define an > escape mechanism. Any of this would be helpful for plain tcp syslog, but > that is definitely a big departure from current syslog. Please note that > currently many syslogds do octet-stuffing and the message TRAILER is LF. That's unfortunate :( In nearly all IETF protocols, the message trailer or EOL marker is CR-LF. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] New direction and proposed charter
> > > WG, > > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG > > > > I would put the SD-IDs after the message. > > This raises the question of what terminates the MSG part ;) Using the above syntax, how do you distinguish between [] at the start of the message from actualy SD-ID data? I think what's missing from the above, is a ':' and the syntax should be: VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]: MSG The protocol document needs to outlaw ':' being in any field before the MSG. If you mark "VERSION", "PROCID" and "SD-ID" data as all being optional then the format comes back to being very close to what's in use today. > That would > mean we would need to introduce byte-counting, at least I think so. Well, without the ':' to say where the MSG starts, I'd have argued "How do you tell where SD-ID ends and MSG starts?" vs there just being a string of bad SD-ID data following some good SD-ID data. As for "but the SD has important information and the MSD does not", that's simply a matter of how you structure the message. > > > - replace NUL with an escape sequence upon reception (e.g. <00>) > > > > Why not \0 ? > > That's another good choice. It's also how data gets escaped, in general, in Internet stuff. > That was my main message. Is it better to live > with that or introduce a CLR on not allowing NUL? I'd like to see NUL outlawed from messages. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Do we have a new charter?
Before we get lost in discussions about the technical merits of message formats, do we have consensus on what the new charter should be ? Chris, can you post what the latest charter is so we can all take a look and provide any last comments ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RE: Message format
> To all, > > The view that syslog must only be used to transport "human readable > syslog messages" is disturbing. Is this the view of the syslog > community? At present what we're concerned with is a logging facility that does generate and consume human readable messages. At some point in the future, when we have agreement on the human readable version, then we can consider what to do with messages that aren't human readable. So while I accept your assertion, addressing it is out of scope for the current discussion. We have smaller fish to fry, first, before attempting the big ones. Trying to solve "all the problems" is what got this group into the situation we are in now. We need to take a step back and focus on resolving smaller and more well defined problems before looking at a "grand unified logging protocol" (GULP). Nothing lasts forever, not even standards. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RE: Message format
> I think this is a valid use case. Syslog traditionally has not only > focussed on network management but has always been used for > application-layer event notifications. I think what John asks for is > within our charter and doesn't even require any change to what we have > been discussing so far. So long as XML in the message can be satisfied by saying it is part of the "MSG" section, then yes. I don't believe there are any planned restrictions on what the text content of "MSG" can be. Otherwise we're just going back down the road of 3195. If John wanted to see XML in syslog formalised, then my vote would for it to be a follow on draft that documented a particular SD-ID as the means for indicating the MSG was expected to be XML. But I cannot emphasise strongly enough that it is not appropriate for this group to take on syslog and XML, beyond what exists in 3195, at the present time. We need to focus on the charter and achieve a basic set of goals first before moving on to things like this. This isn't to say that it won't be addressed, but not here and now. If this puts you, John, in uncertain land for the time being then I think that has to just be accepted with an understanding that it can be redressed at some point in the future, even if it doesn't make our current charter. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Null character
> > Rainer, > > FWIIW, I've seen Netscreen, NetGear and some LinkSys devices send a Null > character at the end of each message. Not all versions of the firmware would > include the Null at the end which leads me to believe it may be a bug in > some releases of the firmware. > > When sending syslog over TCP, Netscreen firewalls will delimit each message > with LF NULL. > > This probably won't have any impact on the 'CLR' since it is the very last > character in the message, but I thought I would raise the issue with you as > a real-life case of a Null character being used. Buggy software does not equate to a "real-life case". But to judge whether or not it is a bug requires knowing what their protocol spec is. In this case, it is a delimeter and that is not something that requires escaping. In fact, it would be a bug to escape it if it were being used in this manner. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
[ Charset ISO-8859-1 unsupported, converting... ] > [tp] Strange, I was thiinking quite the opposite, that we had a fragile > consensus which disappeared in > Vancouver and has not been refound. Looking back at the messages posted > in the past few days, about what should be in the header in what order, > I was thinking, > what now? because I see no consensus, rather the re-emergence of many > different points of view. > > So while the proposed charter looks ok, because it does not go into that > detail, I do not see how we progress any further, into the next level of > technical detail, of what and how should be in the header. So long as everyone wants to solve every problem in one single RFC, we will go nowhere. For those people I say "go use 3195" and stop bothering the group with yoru quibbles. All this nonsense about NUL characters and message lengths, XML, structured data, etc. Too many people here have a pet peeve they want to see the first draft solve and seem determined to overload it with that so that they're covered/happy. This is not a way forward but a way backward. We need to evolve the syslog protocol and we need to do that starting with the basic protocol that has been used for years, build upon that in a structured manner and conquer one piece of the problem at a time. If one thing is clear from this, it won't be possible to write a single document that makes good all of the evolutions of the syslog protocol. Some are going to have to be put in the "bad basket." If that happens to be yours, or mine, stiff. We're all going to need to make sacrifices and changes if anything useful is going to be achieved. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
Chris, Let me have a go at rewriting the charter... > The goal of this working group is to address the security and integrity > problems, and to standardize the syslog protocol, transport, and a select > set of mechanisms in a manner that considers the ease of migration between > and the co-existence of existing versions and the standard. The goal of this working group is to address the security and integrity concerns about individual messages, as well as to standardise the message format and the mechanisms used to transport those messages. A primary requirement of this work is to make it accept the traditional BSD format syslog message. > syslog has traditionally been transported over UDP and this WG has already > defined RFC 3195 for the reliable transport for the syslog messages. The > WG will separate the UDP transport from the protocol so that others may > define additional transports in the future. In RFC 3164, this WG documented the historical syslog protocol over UDP. The WG then proceeded to develop a reliable transport for syslog messages and this can be found in RFC 3195. Using this work, we intend to develop a number of documents that evolve the syslog protocol and provide a series of seperate documents showing how it is used over various transports (eg. UDP, TCP, ssh, etc.) - A document will be produced that describes how syslog works, its architecture, relaying, security issues, plans going forward, etc. Information in RFC 3164 will form he basis of this document. - A document will be produced that describes a modern syslog message format that is based upon what was presented in RFC 3164. The message format in this document will be backward compatible with RFC 3164. - A document will be produced that describes a standardized (plain) UDP transport for modern modern syslog messages. (i.e. syslog/udp) - A document will be produced that describes a standardized (plain) TCP transport for syslog messages. (i.e. syslog/tcp) - A document will be produced that describes transporting moden syslog messages over for the purpose of secrecy and/or integrity. (i.e. syslog/ssh) - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. (i.e. syslog-sign) If in doing some of the above we place the format of some vendor messages (such as netscreen) outside of that documented and accepted by the IETF then so be it. We should not be about trying to come up with something that we can shoehorn everything that exists into but rather something that makes good technical sense. If a vendor ends up with a format in existing products that doesn't interoperate, so be it. They've have to issue a patch if they want to comply. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
[ Charset ISO-8859-1 unsupported, converting... ] > Based on the discussions of the past few days, the one detail that I would add > to the charter is about and backward compatability, something along the > lines of > > While compatability with existing syslog systems is desirable, research shows > that these are so diverse that there is nothing in common amongst them apart > from so that whilst that field will be retained, other fields may not > be. > > added to the paragraph on syslog protocol. Why ? The charter shouldn't be mentioning any specifics of the protocol(s) that the group intends to work on. The charter should be as relatively open ended as possible with respect to the actual specifics delivered. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
Why? Because the community implementing syslog protocol things seems to be ignoring what the group has been doing. This may be because they're unaware of the work or because it is being regarded as a "WTF?!" and doing their own thing. Most people seem to be ignoring 3195. Lets learn from that experience and try to develop something that'll be what people want to use rather than what we think they need. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Consensus?
Rainer, I've put some comments about your list below. If you repost this, you might want to re-order ... there are a few dependencies within this list. > #1 testing and code review has shown that there is no point >in trying to preserve more than ; RFC 3164 provides >a false impression of common behaviour. > > This is controversal, but the facts are suggesting this is the way it > is. > We should try to reach consensus on this. A catch here is that extending the format to be: VERSION may produce unexpected results with various syslog daemons. > #2 The max message length issue resurfaces. There seems to be a >fragile consensus that we can life with the compromise in >syslog-protocol and eventualy open a debate if we (ever) go to >a TCP transport. > > Again, controversal, too. This should be defined by each of the syslog/transport documents. It shouldn't be documented in syslog-protocol because it is largely dependent on the implementation. > #3 There is a question if NUL octets are to be supported in >the MSG content. > > No consensus yet. Why not just use '\' as the escape character to quote any value outside of 32-126 ? Isn't this close enough to a defacto-standard to use? > #4 There seems to be a fragile consensus that MSG should >primarily contain textual data, including XMLified content. >On the contrary, pure binary data should not be used. > > This is somewhat controversal. I don't think this should be discussed. It's data that fits #3. End of story, as far as I'm concerned :) > #5 Character encoding in MSG: due to my proof-of-concept >implementation, I have raised the (ugly) question if we need >to allow encodings other than UTF-8. Please note that this >question arises from needs introduced by e.g. POSIX. So we >can't easily argue them away by whishful thinking ;) > > Not even discussed yet. This has implications for #3 & #4 and is possibly dependent on #10. > #6 field order > > This is related to #1 and can, I think, quickly be fixed once #1 is > settled. This needs the header fields (#7, #10) to be accepted, as well, before it can be settled. > #7 Header fields: there seems to be a fragile consensus that >MSGID, PROCID, APP-NAME, and VERSION should be in the header >and TRUNCATE should not be in it. > > This needs to be finalized, but I think we are very close. We should consider how to make them optional, too. > #8 MSG-octet counting and/or trailer is resurfacing. I think >this item is not well understood and well discussed. > > We need to discuss it. By trailer do you mean an End of Message (EOM) or EOR marker ? Or something else ? > #9 I have found some minor items not already discussed during >my proof-of-concept implementation (like "drop requirements" >and such). These are not absolutely vital, but should be >considered before a final text is issued (or even the next >revision). > > This needs to be discussed. As it is new, I have no idea what the > discussion may lead to. Are you referring to implementation details, here, with things like "drop requirements" ? If so, this is part of what would be a different document again, syslog-implementation. > #10 STRUCTURED-DATA: there has been surprisingly few discussion > about STRUCTURED-DATA. I conclude that this is non-controversal. Is this mean to be a header field? Examples posted, so far, suggest that it is. To explain that comment, I'm considering everything prior to MSG as a header. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
> I see it the other way round. If the charter can be specific, it should > be, to keep the subsequent discussion focussed on the more contentious > areas. Based on the > post-Vancouver discussion, I see no alternative > to including and if that is the case, then we should nail that > down now. > > I am, implicitly, agreeing with Rainer's list of 10 items; if we can > agree a charter, then the items he says need discussing are the ones > we then focus on, leaving the rest of -15 unchanged.. We don't re-charter every time that there is a disagreement on focus, just when we need to change direction. Tieing the charter down to details will require us to change it when details change. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #1 - RFC3164, was: Consensus?
> Darren,
..
> Please let us know which actual syslog deamons you mean (at best with
> platform and version information).
>
> I would also appreciate if you could do a quick test with them and post
> the results. If possible, please send two messages to them. One as such:
>
> "<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on
> /dev/pts/8"
>
> the other one
>
> "<148>1 2003-10-11T22:14:15.003Z mymachine.example.com su 4711 MSGID -
> 'su root' failed for lonvick on /dev/pts/9"
>
> I would appreciate if you could let us know the resulting format both in
> log files as well as when relaying.
>
> Information about the extend of message distortion will probably help us
> to determine the importance of this issue.
Why not just read the source code ?
Also, read down and observe what ^ is used for.
This has been forgotten in RFC 3164...
printline()
{
..
/* test for special codes */
pri = DEFUPRI;
p = msg;
if (*p == '<') {
pri = 0;
while (isdigit(*++p))
pri = 10 * pri + (*p - '0');
if (*p == '>')
++p;
}
if (pri &~ (LOG_FACMASK|LOG_PRIMASK))
pri = DEFUPRI;
/* don't allow users to log kernel messages */
if (LOG_FAC(pri) == LOG_KERN)
pri = LOG_MAKEPRI(LOG_USER, LOG_PRI(pri));
q = line;
while ((c = *p++) != '\0' &&
q < &line[sizeof(line) - 2]) {
c &= 0177;
if (iscntrl(c))
if (c == '\n')
*q++ = ' ';
else if (c == '\t')
*q++ = '\t';
else {
*q++ = '^';
*q++ = c ^ 0100;
}
else
*q++ = c;
}
*q = '\0';
logmsg(pri, line, hname, 0);
}
logmsg()
{
..
msglen = strlen(msg);
if (msglen < 16 || msg[3] != ' ' || msg[6] != ' ' ||
msg[9] != ':' || msg[12] != ':' || msg[15] != ' ')
flags |= ADDDATE;
..
}
On top of this, source code exists to map LF to "\n" and use the
\377 format for non-ASCII characters.
It would seem to me that some of our issues have been "solved" by
some vendors that need to be wide-character set savvy...
Darren
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #1 - RFC3164, was: Consensus?
[ Charset ISO-8859-1 unsupported, converting... ] > Which system is this source from? BSD > On Solaris, if you send \r\n characters, you will see "^M\n" in the log. Yes and Solaris allows for non-ascii data through the use of escaping. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #5 - character encoding (was: Consensus?)
> Hi Rainer, > > Why don't we look at it from the other direction? We could state that any > encoding is acceptable - for ease-of-use/migration with existing syslog > implementations. It is RECOMMENDED that UTF-8 be used. When it is > used, an SD-ID element will be REQUIRED. e.g. - [enc="utf-8" lang="en"] > > Thoughts? I think this is a very sensible approach. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Consensus on Charter?
Are we happy to recharter when these are done to cover TCP ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #2, max message size
> Hi WG, > > I have not heared back on this topic. So I conclude that it is consensus > that the message size specification be left as it currently is in > syslog-protocol-15. We might put further limits in the transport > mappings. > If someone objects to this view, please do it now as I plan to update > the I-D in the not so distant future. The only place a message size limit should be specified is in a transport mapping. If it's in -15 then it should be removed. Limits of all sizes and types do nothing but contribute to aging of a protocol. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
> Hi WG, > > I have received notes via private mail telling me there seem to be some > existing (and eventually soon upcoming) valid use cases for binary data > in syslog. I think there is no point in arguing whether that's fortunate > or not. It simply looks like that's the way it is. I do not like the > idea of breaking existing use cases for syslog (because that will only > lead to implementors ignoring the spec and the story of syslog > inconsistencies continues...). As such, I think we need to provide at > least some minimal support for it (aka "not outlaw it"). .. This is the wrong approach to take. Furthermore, if 3164 is anything to go by, conveying of control characters by the existing protocol is not well documented at present. I think it is incumbant upon the WG to convey the message to implementors that while it will listen to their needs and plans for implementation, it is not up to them to choose which way this group proceeds merely because they decide to provide a particular implementation. .. > Chris proposal for #5 (character encoding) also provides an elegant > solution for binary data. We can use something like: > > [enc="binary"] > > or > > [enc="base-64"] > > I do NOT intend to specify this - I think it should be in the scope of a > separate document specifying the use of binary data. Then would also be > the right time to discuss all issues that arise out of it. For now, I > just would like to keep the door open. > > Finally, I propose to extend Chris format so that the message size can > be conveyed. This has been brought up several times and I think a clean > solution is now obvious: > > [enc="utf-8" lang="en" size="MSG-size-in-octets"] > > MSG-size-in-octets would be the size of the MSG part (just that!) in > octets. Counting just the MSG part is sufficient, as the rest of the > message consists of fields properly delimited. The size is probably most > useful for binary data. What happens if the message is truncated? What value is the message size really providing here? If we have a natural EOR marker, LF, what do we need the size for? Given that a syslog message is a single record, I don't believe that it makes any sense to include a "size" parameter. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
> Andrew, > > > Also, if we are to transport syslog over TCP at some stage, > > we need to keep > > a delimiter character free from use in the message. Again, a > > LF would be a > > good choice for this delimiter. > > Here, I disagree. I think we can not set aside a character for this. If > we go for TCP, let's do octet-couting. Its reliable, efficient and > proven. Anyhow, we are not yet doing a TCP mapping, so I suggest we save > this discussion until later. Why not use LF? It will work. There are syslogd implementations about that use LF as a record delimeter. In other emails you're saying "we must support binary because some people are going to use this". Now we've got people that support LF as a record delimeter already but you don't want to take this into account. Why does what one vendor is going to do mean more than what other vendors are already doing ? Is there bias here somewhere ? Do you have any particular preference based on work you've done or through some sort of affiliation ? If you want to discount use of LF as a record delimeter then there is no reason we must support use of binary because what vendors are doing is obviously irrelevant. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #2, max message size
> Darren, > > > The only place a message size limit should be specified is in > > a transport > > mapping. If it's in -15 then it should be removed. Limits > > of all sizes > > and types do nothing but contribute to aging of a protocol. > > -protocol-15 is a compromise after a very long discussion. It says: > > - >A receiver MUST be able to accept messages up to and including 480 >octets in length. For interoperability reasons, all receiver >implementations SHOULD be able to accept messages up to and including >2,048 octets in length. > >If a receiver receives a message with a length larger than 2,048 >octets, or larger than it supports, the receiver MAY discard the >message or truncate the payload. > - > > I think this text is useful. It keeps the door open for any size > messages while still allowing it to be restricted by the transport > mappings and individual implementations (e.g. on low-end embedded > devices). It cautions implementors against being too verbose but also > sets a lower limit that each implementation can assume to be received. > > I think we should continue to use this text. Do you agree? No. That text doesn't belong in this draft. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
> Darren, .. > So why this gap between 3164 and practice? I have come > to the conclusion that after Eric invented it, other folks have redone > his work on other platforms (e.g. Linux, Windows and of course embedded > devices). While all of these implementors had Eric's ideas on their > mind, there was no spec to follow. Thus, each one introduced subtle > differences and finally even BSD syslogd was modified in subtle ways. At > the time 3164 was defined, nobody went to the lab and verified the > results. Nor did I when I started with syslog-protocol. We all were so > convinced that when Eric agreed to the document, it must be right. I > think we do not need to put finger at anyone. .. I agree with the summary here. > In general, I agree. But I think we should support the currently > existing use cases for syslog. After all, was this effort not put on > hold because it was said it is not backwards-compatible enough? Indeed. But I think there were (or are) protocol subtlties that many people are unaware of. Maybe in your testing of syslog messages you should include sending a message that is 255 characters long 0x1 - 0xff and see what comes out the other end. I'd also recommend that you include Solaris (preferably Solaris 10) in your test suite if you can't include any of HP-UX or AIX. It's probably the most common commercial Unix and people who deploy it are loathe to replace system components with open source bits. Solaris 10 for x86 is a free download. > > > MSG-size-in-octets would be the size of the MSG part (just that!) in > > > octets. Counting just the MSG part is sufficient, as the rest of the > > > message consists of fields properly delimited. The size is > > probably most > > > useful for binary data. > > > > What happens if the message is truncated? > > Good question. I'd say the size would need to be adjusted. What happens if/when the SD data is truncated and either the MSG size is lost or truncated half way through ? I believe there is very little added value of having the message size as part of SD data - or at least not enough to warrant it being treated as a mandatory/required field to include. > > What value is the message size really providing here? > > If we have a natural EOR marker, LF, what do we need the size for? > > We do NOT have a EOR marker. As of the current draft, LF is just a > regular character like any other. We explicitely wanted the capability > to surface, now we have it. I even think its not bad to have it. I do > NOT like the idea to re-iterate that long discussion of whether or not > full UTF-8 should be supported. Please review the mailing list archive > for that. Allowing LF inside a native message is bad, now that I think of it. Supporting UTF-8 doesn't impact what we use as an EOR marker unless we are going to say that the wire format must not be changed from the message supplied by the application. If we're going to be backwards compatible with the use of ^ (and I think we should and continue to use this) then this already points to the on-wire content of the message being different to what is supplied by an application. I can't see any reason why the on-wire format of the message needs to be the same as that supplied by the application. It's not like we use tcpdump or ethereal to do our loging. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #2, max message size
> John, > > the issue is the simplex nature of syslog. With syslog (other than with > almost all other protocols), you send a message and need to *hope* that > the recipient can receive it. There is also no negotiation phase. So you > need to send it blindly. What you're failing to grasp here is that syslog-protocol, by itself, does not define how it is to be used. All it is doing is defining a message format. With a layered approach to defining syslog we need to split out documentation that is specific to an implementation (such as the maximum message size) from the definition of the protocol messages themselves. In your charter you have a "syslog-protocol over UDP". So any talk in syslog-protocol about maximum message size is going to be redundant for UDP. Using syslog-protocol over TCP is not yet on the radar so anyone making assumptions about maximum size is doing so at their own risk. If they choose 4K or 8K or 1K as the maximum size, that's up to them. If you really want to get back to basics, I'd not accept any maximum message size that was bigger than 490 bytes (576-14-64-8) as this is the largest frame size that IPv4 is *required* to reassemble. Either you remove the maximum message size from syslog-protocol or drop it to 490 but leave it open to refining by transport definitions. Yes, I'm well aware of 490 being "too small" for some practical purposes but you're not thinking clearly if you want any sort of maximum size in syslog-protocol and this needs to be reinforced. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
> Darren, > > > > > Also, if we are to transport syslog over TCP at some stage, > > > > we need to keep > > > > a delimiter character free from use in the message. Again, a > > > > LF would be a > > > > good choice for this delimiter. > > > > > > Here, I disagree. I think we can not set aside a character > > for this. If > > > we go for TCP, let's do octet-couting. Its reliable, efficient and > > > proven. Anyhow, we are not yet doing a TCP mapping, so I > > suggest we save > > > this discussion until later. > > > > Why not use LF? > > Because we - the WG - have said we want to have the full character > set available in the message. Search the archive. Read the drafts. I am > tired of doing (re)search for you. I have better things to do than to > support your lazyness. I don't see why having a full character set available in a message means that you can't chose to select a particular character for an EOR marker. Protocols everywhere use special characters for this or that yet there are no restrictions on what messages they convey. Maybe I'm confusing implementation detail with protocol specification by asking for LF be used as a EOR marker. So, you're right, we shouldn't set aside any particular character to mean EOR in syslog-protocol, that should be left up to the construction of syslog over each protocol. Do you agree on that? > My preference is to finish *this* work. It doesn't help to restart this > discussion. May I provide a quote from Marshall T. Rose in a similar > situation in this WG: Marshall T Rose is responsible for 3195 and that could be considered to be a failure by many. > How about you and your experience and affiliation? I was the focal point of a lot of people wanting to do work on the syslog protocol before the WG formed. At the first syslog IETF BOF I gave a small presentation on the work I'd done to implement syslog over TCP, including using SSL as the transport with the transfer of hashes and storing them on disk. At the first BOF there was a large room full of a lot of people, a far cry from the numbers in Vancouver. The syslog replacement I wrote over 5 years ago was the basis of the work that has resulted in syslog-ng for Linux, even though today it no longer even closely resembles what I did originally. I, like many I suspect, became disenchanted with the direction of the group when it started to go down the road that led to 3195 and I just lost interest for a long time because I did not have the energy to put into fighitng it. In this group, I represent myself. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #7 field order
> WG, > > there has not been much discussion about the header fields and their > order recently. I think this is a sign the issue has been settled. To > make sure I got the right understanding of the resulting consensus, I > propose that we use the following format: > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP > [SD-ID]s SP MSG > > That is the format that also proven to be quite useful during my > proof-of-concept implementation. > > If somebody objects, please do that now. In your other email, you say that "-" is for a missing field - I was curious about whether all fields were mandatory or what was to be done if you wanted to miss one out, but you've answered that. The "HOSTNAME" field should be constrained, in its definition, to match that accepted for FQDNs. "PRINTUSASCII" is too wide. I believe you need to read RFC 1035. Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be less than the entire character set. A contradiction in syslog-protocol is allowing PRINTUSASCII for fields but a field of "-" is used to indicate it is not there. The only thing I would like to see considered is keeping a ':' to mark end of headers and start of message. Or is this pointless ? I'm thinking from a perspective of parsing them with awk/grep. If, for example, I can search for either ']: ' or '-: ' and know that what follows would be the messageis that sensible ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #2, max message size - Need to resolve this
> I think there is general agreement to specify minimum msg size, not > maximum msg size in syslog-protocol. FWIW, I think this is a much better idea. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #2, max message size
[ Charset ISO-8859-1 unsupported, converting... ] > > Of course, specifying a minimum required support in each transport > mapping is also appropriate. In fact, syslog-transport-udp sets two > separate minimums: for IPv4 and IPv6. If we did not specify a minimum > in syslog-protocol, one can infer the minimum based on the least > common denominator of transport protocol used. That's fair. But I just > don't see a harm in what was done in the current draft (after very > long discussions I might add). I can only a see a very hypothetical > scenario where some future transport protocol has MTU smaller than the > what IPv4 and IPv6 uses. In this case a minimum requirement may be > problematic. How much lower than 480 octets can it go with a > ~100-octet syslog header? I think you mean network protocol, not transport protocol. IPv6 has a larger minimum packet size than IPv4 and unless there is a new IETF backed network layer protocol that has a smaller protocol header than IPv4, I can't see the minimum MTU getting any smaller. Are you suggeting something like syslog over ATM or syslog over PPP as an example ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #2, max message size
Anton, Please look into getting your email program to do word wrapping before 80 columns. Everyone else on the list seems to be able to do this. Replying to an email where you have to manually reformat every line of quoted text is no fun. Thanks. > There is NO maximum message size defined in syslog-protocol draft! .. Then why has there been any discussion, at all, on a maximum message size ? Seems like a waste of time and effort on everyone's behalf, including Rainer's for listing it in the first place. Cheers, Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RE: syslog-protocol draft
> :-) Just a comment on the list: it is my observation that sometimes > discussion peeks and at other times there is virtually none. For the > time being, I think everything that needed to be said is said and so > folks are waiting if I manage to come up with the right text to cover > the consensus [I hope I will...]. I don't think the silence is > indication of missing interest. Well, there were a few technical issues I raised with...#7(?) that you never seemed to address. Things like how the hostname and other fields are all described. The grammar you use in the document is incorrect. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RE: syslog-protocol draft
> Darren, > > I have seen nobody backing your position, so I think it was consensus to > ignore these comments. And nobody decrying them either. So are you saying, you need "me too's" on comments before you'll make any replies to issues people bring up ? It shouldn't take everyone to speak out about an issue for it to be valid, it should only take one. If 5 people came back with 5 different issues each, would you ignore all 25 because none of them brought up the same one ? This is meant to be the value in peer revue and if you start ignoring comments that only get brought up once, you're undermining the efforts and effectiveness of this group. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RE: syslog-protocol draft
> Darren, > > an "I would like to see this too" is a good indication that a > controversal feature is required. I have honestly posted what I think so > that all others can jump in. For the rest, see the archive ;) Well, I don't want to disappoint you, but if someone else comes up with something, I'm not going to "me too" it unless you actively disagree with it. Sorry if that spoils your party. Most of us have better things to do than send and receive "me too" emails unless they are a vote. Back to the issue at hand...for #7, field order...or field details The "HOSTNAME" field should be constrained, in its definition, to match that accepted for FQDNs. "PRINTUSASCII" is too wide. I believe you need to read RFC 1035. Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be less than the entire character set. A contradiction in syslog-protocol is allowing PRINTUSASCII for fields but a field of "-" is used to indicate it is not there. ..I can imagine some people would like to consider that the HOSTNAME field should be unrestricted to allow for extended character set names. Allowing and supporting that should come when & if the IETF decides to go that way. Otherwise the comment about "-" is that your grammar is wrong because you define various fields to be PRINTUSASCII*256 (or whatever the length is), which specifically includes "-" as being a valid field name. It isn't. You document it as representing the absence of any meaningful data for that field. If you don't understand the difference here, I think the fields need to be defined something like this: field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 missing ::= "-" Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RE: syslog-protocol draft
> > Darren, > > > > an "I would like to see this too" is a good indication that a > > controversal feature is required. I have honestly posted what I think so > > that all others can jump in. For the rest, see the archive ;) > > Well, I don't want to disappoint you, but if someone else comes up > with something, I'm not going to "me too" it unless you actively > disagree with it. Sorry if that spoils your party. Most of us have > better things to do than send and receive "me too" emails unless they > are a vote. > > Back to the issue at hand...for #7, field order...or field details > > The "HOSTNAME" field should be constrained, in its definition, to > match that accepted for FQDNs. "PRINTUSASCII" is too wide. > I believe you need to read RFC 1035. > > Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be > less than the entire character set. A contradiction in syslog-protocol > is allowing PRINTUSASCII for fields but a field of "-" is used to > indicate it is not there. > > .I can imagine some people would like to consider that the HOSTNAME > field should be unrestricted to allow for extended character set names. > Allowing and supporting that should come when & if the IETF decides to > go that way. > > Otherwise the comment about "-" is that your grammar is wrong because > you define various fields to be PRINTUSASCII*256 (or whatever the > length is), which specifically includes "-" as being a valid field name. > It isn't. You document it as representing the absence of any meaningful > data for that field. > > If you don't understand the difference here, I think the fields need > to be defined something like this: > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > missing ::= "-" And as someone else pointed out to me, PRINTUSASCII includes the space charactr (0x20), which is used as the field delimeter. This needs to be fixed too. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #7, field order
> > > data for that field. > > > > > > If you don't understand the difference here, I think the fields need > > > to be defined something like this: > > > > > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > > missing ::= "-" > > > > And as someone else pointed out to me, PRINTUSASCII includes the space > > charactr (0x20), which is used as the field delimeter. This needs to > > be fixed too. > > If you would look at the ABNF, you would find > > PRINTUSASCII= %d33-126 *shrug* I'm just repeating what someone else thought was an issue. > As another technical comment, "-" for me is proper field content. It is > just a special value which indicates a void value and these semantics > are clearly described in the text. I have to admit I do not know any way > how I could add such semantics to the grammer - your grammer above does > the same as my grammer with the exception that it is more verbose. The > resulting parser will be the same (because you obviously allow "-" by > 'missing | ...'). You want to use "-" to mean that there is no value for that field present, therefore you must make the grammar support the distinction between having a value there and not having a value there. > On the HOSTNAME, I am refering to STD 13, which I consider to be > sufficient. Take note that IP V6 representations must be allowed. Right. So look at what your definitition allows and then compare that with STD 13 (which is RFC 1035 that I was referring to.) RFC 3490 deals with internationalising domain names. I'd suggest reading section 2.3.1 of STD 13 more closely, along with the section in 3.1 around where it says "strongly recommend". I think you are far better off just saying 'See RFC ' or 'See IETF for latest hostname specification' than trying to nail it here. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Sec 6.1: Truncation
[ Charset ISO-8859-1 unsupported, converting... ] > Rainer and all: .. > "Receivers SHOULD follow this order of preference when it comes to truncation: > > 1) No truncation > 2) Truncation by dropping SD-ELEMENTs > 3) If 2) not sufficient, truncate MSG" > > I don't think that this is a good recommendation. Is this likely to be how people implement truncation ? I'm more inclined to believe that truncation will happen when the incoming message is too big for a buffer, so you start reading in data (and dropping it) until you reach the end of the buffer. The above requirement forces everyone to accept all maximum length messages before deciding one is too big. > I also think, in general it is useful to put more important data first, Agreed. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
> On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: > > I would say that addressing the security concerns at the transport level > is way easier management and implementation wise than implementing > syslog-sign. I disagree with the statement about management as the problem is the same for using a secure protocol at either transport or application level. > 1) transport level implements security mechanisms on a per hop-by-hop > basis, the message itself is not authenticated, each of the relay > stations can modify the message > > 2) syslog-sign implements per-message, end-to-end authenticity where the > relay hosts cannot modify messages as they are individually signed by > their origin. > > So I'd go with using TLS/DTLS on the transport first and then possibly > adapting syslog-sign when the transport issues are resolved. (1) and (2) are complimentary and one do not exclude the other from being necessary. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Sec 6.1: Truncation
> Anton and all, > > I have now changed section 6.1 to: > > ### > 6.1. Message Length > .. Well written and very sensible. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Sec 6.1: Truncation
[ Charset ISO-8859-1 unsupported, converting... ] > Truncation of UTF-8 is actually slightly worse than has been described. > > It is possible to determine from the UTF-8 octets where one coded > character ends and another begins. But because Unicode contains > combining characters, with no limit on how many of these there can > be, and these modify the meaning of previous or later coded characters, > it is not possible to determine where one 'symbol' ends. So truncation > at a UTF-8 boundary could subtlety change the meaning of a message, > even breach security. Not something we can guard against > but should mention. The above seems a little confused to me. How can there be a problem if a message is truncated on the boundary of complex character ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Sec 6.1: Truncation
Is the truncation of a message on a UTF-8 boundary rather than within an extended character something that syslog daemons SHOULD do rather than MUST do ? (To use the RFC words.) Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Re: Threat model and charter
Chris, > I'm still not seeing too many responses about how TLS is authenticated. > Only Baszi has said that full X.509 certificates should be used - similar > to how they are used in stunnel. Is this acceptable to the WG? Should > the WG also consider using PSKs as proposed in RFC 4279? > > Having authenticated TLS will address many of the threats described in RFC > 3164. Is this how the Working Group wants to proceed? I'd like to hear > from more people on this. I think supporting TLS and all of its authentication options is what we should do in our documentation. Or to put it another way, we shouldn't worry ourselves with restricting use of TLS to a particular authentication model, be it PSK or X.509 or something else. What we should be doing is letting systems people use whatever they feel comfortable with and are already deploying...which makes me think, we need to be saying "authentiation style(s) X must be included", to set a minimum level of interoperability between all implementations. I believe that minimum level should be PSK as anything certificate orientated can quickly become complicated, not just for management but initial use. So to express this in RFC terms, TLS PSK MUST be supported, TLS SHOULD be supported, TLS .. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Other syslog-tls Issues---Issue 1 and 2
> On Tue, 2006-03-21 at 18:00 +0800, Miao Fuyou wrote: > > So we either leave the SSL certificate binding undefined for the > operators to decide, or we need to clarify how certificate is to be > validated. How much of this is an operational matter that varies from site to site with local policies on such things ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Call for David Harrington to resign from syslog as co-chair
As someone who works fr the offending company, I might point out that the lodged IPR statement does not accurately reference the draft at all. It talks about "section IV" and "section V". The current draft has no "section IV" or "section V". The draft does have sections labelled "section 4" and "section 5". If you know anything of legal documents and messages then you will understand that they need to be accurate. Ask your lawyer for more information on this. Given your role as chair and that you are employed by the company involved, I would like to ask you to resign your role as co-chair here because I believe your commercial interests are compromising the direction and role of this group. If you do not wish to voluntarily resign I will ask the group to take a vote on this matter. As it stands, there are a number of people who do not like this move and I can imagine any number of them would feel betrayed by it. Darren > Hi, > > As co-chair it is my responsibility to make the WG aware that there > has been a disclosure that an unpublished pending patent application > might be infringed by the implementation of the specifications in > draft-ietf-syslog-transport-tls-01.txt. > > The disclosure can be found at > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > co-chair, Syslog WG > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Call for David Harrington to resign from syslog as co-chair
[ Charset ISO-8859-1 unsupported, converting... ] > Darren, > .. > > I would also like to voice that I am very happy that David is co-charing > this group. The current discussion has shown how professional and ethical > his leadership of the WG is. There is nothing that would justify to step > back from this position. > > I also think that you are exaggerating the situation. No, I'm not. And other people I've raised this subject with who have a long history of IETF involvement also believed the co-chair should be stepping down. Having him as co-chair removes transparency from the group. He has a clear financial involvement with the group's progress, now, so it is harder to believe any direction he might give would be without bias. The WG needs to be transparent in its operation and its direction must be beyond reproach in terms of conflicts of interest. It is good that David has stayed out of this discussion but if he is to continue with his professionalism, then he must step down as co-chair. I don't mind if he stays involved, but this WG cannot continue if one of the co-chairs belongs to a company that is involved in IPR action regarding the output of this WG. So I suppose that's the other option, dissolve the group if David doesn't or refuses to step down. It needs to be plainly obvious that this group is about developing technology for the Internet and not for any particular company. David's continued involvement as co-chair calls that into question. Given that Huawei has undoubtedly spent $X in this IPR action it is highly unlikely for them to change course and it would be a waste of our time and effort trying to get them to do so. > While I do not like the move by Huawei (and have voiced that), I also > think there is nothing evil per s? in this move. IMHO Huawei is simply > using an abusive patent system. This is a difference to someone abusing > non-abusive system. The primary thing to do is fight the abusive system > itself - as we in Europe try to avoid an US-like patent system over here. > As far as I know, even the US is reconsidering the current patent system. > I do not know about China, Australia and Japan, but my uninformed Having been involved with the patent process in Australia, I can tell you that if your patent lawyers are decent then you have significant obstacles to overcome to convince them that what you're doing is worthwhile. For starters, they will require it to be "novel" (i.e not obvious) and to be inventive, rather than just evolutionary. Whether the patent office itself is liek that, I don't know - this just might be the lawyers trying to stop you patenting something that is rubbish and will get thrown out later. > Back to this case: I still see lack of an innovation. Agreed. > The thing also smells bad if I look at the timing. Agreed. > Having said all this, please let me repeat that I prefer to have no > syslog RFC than to have one that is taken hostage by a nonsense patent > claim. Agreed. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] IESG secure transport requirement can be quicklysolved...
> Hi, > > [speaking as co-chair] Please resign as co-chair. Your company is involed with IPR action regarding the work of this group and until your company gives up this path, we cannot accept any direction or input from you as co-chair. I ask all those in this working group to ignore any email from David Harrington in his role as co-chair as it compromises the abililty of this working group to produce free, open standards. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] IESG secure transport requirement can be quicklysolved...
> Hi, > > As a co-chair looking for a way forward, I was considering asking for .. Please resign as co-chair. Your company is involed with IPR action regarding the work of this group and until your company gives up this path, we cannot accept any direction or input from you as co-chair. I ask all those in this working group to ignore any email from David Harrington in his role as co-chair as it compromises the abililty of this working group to produce free, open standards. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Secure transport alternatives
David, Your actions as co-chair of this group represent a conflict of interest for so long as Huawei maintains it has an intellectual property claim with respect to its work. I would request that you either step down as co-chair of the group, cease employment with Huawei or convince Huawei to cease the IPR action. Of course the latter two of these are not what I would call reasonable demands to make of anyone given that there are financial issues (and more) involved, but I would request that you step down as co-chair of this group. I would also ask Darren Moffat (and others within this IETF group) to ignore this request and others coming from you, regardless of their relevance to the IPR, because your involvement with Huawei makes you unfit for this role within the syslog IETF group. If you do not wish to step down then the best we can do is to ignore your attempts to continue to function in this role and continue to apply pressure for it to be resolved. This group needs to develop open standards, not IP for Huawei. Your involvement as co-chair and Huawei's IPR claim cast that shadow over this group. I'm sure we all would welcome your continued involvement with the group, just not as co-chair. If Chris is having difficulties with managing the IETF side of things by himself then I'm sure we can find someone else to fill in for you. In no way am I implying you are doing a bad role now or in the past, just that your current association makes you ineligable for being co-chair. Cheers, Darren > Hi Darren, > > I don't know them well enough to comment. > Are you willing to write one or two drafts proposing these as possible > solutions so the WG can evaluate them as alternatives? > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 22, 2006 6:14 AM > > To: Miao Fuyou > > Cc: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] > > Subject: Re: [Syslog] Secure transport alternatives > > > > Miao Fuyou wrote: > > > real "general" security mechanisms(except IPsec, but it is not > > > application-friendly). So, IMHO the primary criteria for > > selection is: is it > > > convenient for the application to invoke the security > > service provided by > > > the security protocol? > > > > That to me sounds like GSSAPI or SASL. > > > > Any reason these aren't being considered ? > > > > -- > > Darren J Moffat > > > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Decisions to make about the Huawei IPR claim
Chris, The approach I'd like to take is to see what Balazs Scheidler can come up with, that is different to the proposed approach, to make syslog function over a TLS transport in syslog-ng and look at turning that into an i-d. While it may not guarantee us any better situation with respect to patents, etc, I have more faith working on documenting something that is written to be open and free than involving people who have a financial interest in the protocol going in certain diretions. I suppose this is a get working code first and then refine/ document it. Thoughts? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
