Hi Bazsi, Pardon me for not putting comments in-line but I'd like to summarize and see where this discussion is going. As I see it, various people have said:
- 3195 is too heavy - a minimal implementation (just say 'no') of 3195 may be light enough - there are many tcp-based implementations to transport syslog but none of them interoperate - a simple tcp-based implementation would need all of the aspects of BEEP to optionally call the security features that are desired (reliable transport, confidentiality, device authentication) - BEEP channels can be a good thing (Did I miss any other thoughts?) I'm still not seeing what features/functions are missing from 3195, or what features/functions a simple tcp-based syslog would fill. I don't see that documenting any/all of the old methods would serve a purpose either. I'll keep this discussion open to see if we can get a clear reason for a simple reliable tcp protocol. Thanks, Chris On Fri, 20 Dec 2002, Balazs Scheidler wrote: > Ccing to syslog-sec. > > On Fri, Dec 20, 2002 at 09:40:57AM -0800, Darren New wrote: > > Balazs Scheidler wrote: > >> I know I can do that, but there's no need. I wanted to explain that > >> currently deployed syslog implementations don't do negotiation. > > > >Yes, I know that. > > > >The point is that there *is* a need, yes. What you meant to say is *you* > >don't have that need. Which is fine, which is why it can be hardcoded in > >*your* implementation. Others, making more generic implementations, need > >to know whether the other side wants encryption, whether the other side > >is using better timestamps, whether the other side is a creator of > >messages or a relay or both, etc. > > > >> Look, there are implementations of syslog-over-TCP. There was a couple > >> listed in another mail. > > > >So use them. > > I do. I want to get router logs on TCP, PIX does that fine (probably because > of its CC audit), but other routers don't. Probably because there's no > document on the protocol. > > >> You tell us that everything can be done in BEEP as > >> well, that's true. But what are the _benefits_ of adding BEEP over the > >> already implemented TCP transport? > > > >The ability to negotiate TLS, SASL, raw vs cooked, and the ability to > >tunnel through firewalls to get your messages out. Did you attend any of > >the meetings where the requirements were discussed? Did you read the > >mailing list archives? > > Yes, I followed the mailing list, I even contributed to the RFC3164 effort. > And no, I didn't attend any meetings because the meetings were held on a > different continent. > > >> The problem is that those TCP implementations does not necessarily > >> interoperate, > > > >Right. In part because they lack any negotiation. > > No, because there's no RFC on syslog over TCP, and everybody did it on its > own. > > > > I'd argue that BEEP is viable if interoperation is the only benefit. > > > > It's not the only benefit. How would you, for example, implement a > > syslog-over-TCP that could log into a firewall, authenticate itself, > > then have the firewall pass that connection through to the collector on > > the other side of the firewall, then have the device and collector > > negotiate TLS so the firewall (if broken into) cannot see the messages > > going thru it, in the current implementations of > > syslog-over-TCP-without-negotiation? > > So BEEP can use TLS on one of its subchannels? Last I heard it was only > possible to wrap the whole BEEP stream into TLS, thus the whole argument is > void as you'd need to use two BEEP streams (one ended on the > firewall, the other on the collector), the same can be done using two > independent TCP streams. > > Firewall authentication (e.g. authentication to cross the firewall) can be > implemented in two different ways: > * inband or inline auth where the authentication is hacked into the protocol > (as implemented by fwtk for instance where you have to auth twice in FTP: > first to the firewall, then to the server) > * outband auth: when the authentication is based on a completely separate > channel > > The latter is something that you have in SASL defined as "external" method. > This can mean many things: IPSec VPN, SSL wrapping, special outband protocol > (this is also called session authentication in CheckPoint, or satyr > authentication in Zorp) > > If you want automatic authentication on the firewall you either wrap the > stream twice (first wrap is decrypted on the firewall, the second at the > collector) > > > > > > For this it uses its own windowing, has its own channel control messages > > > > > etc. This does not mean too much to syslog right now either. We can use > > > > > several TCP streams if we need to. > > > > > > > > The overhead of handling these messages when there's only one window is > > > > trivial. > > > > > > It is trivial, but is overhead (in both run-time and development time) which > > > gives us nothing. > > > > Except that it doesn't give you nothing. It gives you the ability to do > > more in the future. I'm sure when folks did syslog-over-UDP, they said > > things like "TCP gives us overead we don't need." > > ... and we are left in the cold while BEEP based products are developed. > I'm not arguing that BEEP is cool and is not necessary. I'd like to extend > RFC3164 (or syslog-sign) with TCP transport. > > I might propose some text but I'd first like to be sure that it would be > accepted. > > Chris, would proposed updates to syslog/sign be accepted? > > > > Certainly there are implementations of syslog-over-TCP. > > > > Right. But they don't do what you need. If they do what you need, great, > > use em. If they're not interoperable enough for you, propose a new RFC. > > Write it up and send it to the right WG. You know how the process works. > > :-) > > Is this the right WG? > > > > I have implemented a syslog implementation, and also deployed it in > > > demanding environments. Those implementations work *right* now. > > > > So explain again what the problem is? > > That there are some other plain TCP implementations, and as there's no RFC > on this matter I'd doubt they interoperate. If they do without an RFC, it > would still be wise to document it, just like it was the first > accomplishment of this WG to release RFC3164. > > > > We *have* implementations, or implementations that are trivial to make > > > RFC conformant. > > > > Um, trivially conformant to what RFC? Did I do all this syslog-over-TCP > > RFC work for nothing? Is there another syslog-over-TCP RFC already > > approved? > > I don't know about any. I meant that if there was an RFC which defined plain > TCP transport (messages going one way, '\n' terminated lines which should be > in the format that was described in rfc3164), _then_ many of the current > implementations could be trivially modified to match that RFC. > > -- > Bazsi > PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 > >
