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
