I am not sure RFC 3195 is completely market-abandoned. Cisco has some interest in it. Although I cannot comment on any product roadmaps.
Anton. > -----Original Message----- > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 1:49 AM > To: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] > Subject: RE: [Syslog] Secure transport alternatives > > > Hi, > > IMO, most current security protocols(TLS, DTLS, SSH, IPsec) > provide similiar > security service for application, such as confidentiality, integrity, > anti-replay and peer identity authentication. In the same > time, most of the > applications share similiar security threats, such as hijacking, MITM, > falsification, eveasdropping etc. So, it may does make much > sense to invest > too much effort on evaluating/matching security threats and > service. In the > same time, most current security protocols come from security > mechanisms > specific to some applications. For example, SSL was designed > to secure HTTP, > SSH is an application protocol for interactive shell command. > They are not > 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? > > Taking convenience in mind: the order may be: DTLS -> TLS -> > SSH -> BEEP(?) > -> IPsec > > >From an implementer's perspective, I think DTLS costs the > least effort to > implement, TLS second. I have not much idea on how much SSH > and BEEP take, > but I believe it cost more than DTLS/TLS. There is few RFC3195 > implementation, it sounds bad to revive an market-abandoned > solution to just > satisfy IESG. IPsec? It costs the specifcation and program developer > nothing, but it costs too much to provision, never a good solution for > Syslog. > > My 1 cent! > > Miao > > -----Original Message----- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 22, 2006 1:58 AM > > To: 'Rainer Gerhards'; [EMAIL PROTECTED] > > Subject: [Syslog] Secure transport alternatives > > > > 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 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. > > > > 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? > > > > 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? > > > > 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 > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
