David, > Hi, > > [Posting as a contributor] > > I am involved in a number of NM and Security WGs, and I can make these > observations: > > Running an NM protocol over SSH has been done in both netconf and > ISMS. I suspect it would be fairly easy to adapt the netconf-over-SSH > draft to work for syslog-over-SSH. I suspect it would take a week or > so to write a syslog-over-SSH draft since most could be cut-and-paste > from the netconf-over-SSH draft.
I have gone throught the netconf-over-ssh draft with syslog on my mind. I agree, it should be fairly easy to adapt. > > I am the author of the ISMS drafts, and I adapted the netconf/SSH > draft for ISMS purposes. Syslog and netconf seem to be closer in their > requirements than syslog and ISMS. ISMS has this whole model of access > control to deal with that is not part of the threat model for syslog > or for netconf at this time. > > There is a parallel discussion of running syslog messages over > netconf. As Rainer has pointed out to Phil, having a consistent > terminology would be very helpful. I think having a consistent > security solution would probably be helpful in that situation as well. > > I have concerns about 3195bis as the only alternative we consider, > because I have not seen much interest in RFC3195 yet, nor has there > been much expresseed interest in netconf over BEEP. I agree it is questionable if RFC 3195 will succeed. I have seen some companies (also at least one of the big guys) make investment in 3195. I am not sure if it simply is too early to abandon it. If we do not want to abandon it, we need to create a 3195bis, because 3195 will not be usable together with syslog-protocol (because it mandates a different format). > > Since there may be delay involved in this WG no matter what, would > somebody be willing to volunteer to write a syslog-over-SSH draft, so > the WG can compare the three approaches? After my review, I think I am able to do that. So I volunteer. > > There are other possibilities as well (and I am being serious here, > not "let's make this absurd by proposing a whole slew of alteratives > documents"). > 1) Tom mentioned DTLS, which might be a viable alternative given > syslog's UDP roots. Tom would you, or somebody else, be willing to > write a proposal for syslog/DTLS? > 2) Andy Bierman observed that if syslog messages are going to be > transported over netconf, then why not simply use syslog/netconf and > let netconf deal with the security issues. That could be an > alternative proposal. Is anybody willing to write a draft proposing > that as a syslog secure transport solution? I, too, think this is an option. Wouldn't it be sufficient to adopt draft-shafer-netconf-syslog-00.txt as a WG document? (Provided Phil would be happy with that...). I guess that would obviously involve some coordination between the syslog and netconf WG, which I hope is not a big problem. Rainer > > My $.02 as a contributor, > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 20, 2006 9:44 AM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] IESG secure transport requirement can be > > quickly solved... > > > > Hi all, > > > > I propose to update RFC 3195 in the spirit of syslog-protocol > > to satisfy > > the IESG secure transport requirement (I will call this > > derivative work > > RFC3195bis below). I sincerely believe that this option would > > enable us > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a > few > > weeks. > > > > My reasoning for this proposal is as follows: > > > > We all know that 3195 has limited acceptance in the community and > very > > few implementations. However, it satisfies all IESG criteria > > we have in > > our charter. Also, it *is* something that can be used in practice > and > > implementing it becomes easier as support libraries become visible. > I > > know it is not an optimal choice. On the other hand, we have > > syslog-transport-tls, which has been encrumbered by a patent claim. > As > > it looks, this will need months to solve. RFC3195bis can not be > taken > > hostage by any patent claims, because there is well-defined > > prior art in > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > mission and finsh work that is in the queue for many years > > now. I think > > this is urgently needed. We might even put the netconf WG with their > > syslog gateway on hold (because syslog-protocol can not be published > > without resolving the secure transport). Or netconf might > > choose to drop > > syslog-protocol in order to publish. > > > > And the good news is that 3195bis can definitely very quickly > > be done. I > > am saying this on the assumption that we do not revisit the basics > of > > 3195 but just adopt it to syslog-protocol. I've gone through > > 3195 today > > and the changes are absolutely minimal: > > > > Section 2: > > Most of it simply needs to be removed because the entity roles are > > defined in syslog-protocol. > > > > Section 3: > > - the message samples must be upgraded to -protocol-format > > - syslog-framing in section 3.3 must be changed (could be > > octet-counting > > or disallow of multiple messages per ANS, what I recommend) > > > > Section 4: > > 4.4.2 > > - needs to be updated with the new HEADER fields and > STRUCTURED-DATA > > - some work on "deviceFQDN" and "deviceIP" needed > > - some transformation rules (page 15) need to be removed > > - handling of invalid message formatting must be removed (no longer > a > > concern) > > - samples must be adjusted > > > > 4.4.3 > > - sample on page 24 (top) must be checked and/or adjusted > > > > Section 7: > > - DTD needs to be adjusted > > > > Section 9: > > - new URIs for 3195bis (also in some other places) > > [we can reuse well-known port 601 for -protocol] > > > > Overall > > References to 3164 must be changed to -syslog-protocol. This > > seems quite > > trivial, because the references are easy to spot and do not touch > any > > substance (except outlined above). > > > > Other than these minor things, there are *NO* other changes > necessary. > > I'd expect that an initial version of 3195bis can be created within > a > > single working day. Add some quick review and a very limited number > of > > edits to change discovered nits - and we have something to publish > by > > summer. > > > > I find this extremely tempting. It breaks the deadlock > > situation we are > > currently in. Especially as we have planned to do 3195bis some time > > later anyhow. I don't know if the authors of 3195 would > > volunteer to do > > the edit. But I hope so. > > > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > > > > Comments are appreciated. > > Thanks, > > Rainer > > > > _______________________________________________ > > 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
