Miao, technically, I agree with you. HOWEVER, I need to point out that your company is the root cause of the problem. The IPR rights claimed on your transport-tls document have taken it hostage. Even though the licensing terms seem reasonable (which needs to be prooven in undisclosed detail), there honestly is nothing novel in the draft. Your legal department is not even telling us which section is claimed to have been invented by Huawei. The simplest and most productive way to solve the current issue is make your legal department drop the patent claim. My understanding is that it can be easily challenged (for those with big legal departments...) so it will probably be without substance, too.
You should also talk to your legal department and superiors that Huawei's peformance in this WG is costing Huawei a lot of its goodwill in the community and probably even in the end-user space. For example, the largest German IT-Site (Heise press[1]) has carried a story about Huawei's move and Huawei has not made a good picture in the user feedback. I also promise that I personally will try to get more press coverage of this move. It is one thing to secure one's intellectual property. It is another thing to be a patent troll. And it is yet another thing to be a patent troll who steals other people's work. I have to admit that I consider Huawei (as far as the syslog WG is concerned) to be part of the third camp. Get *that IPR issue* solved and the technical issue is solved, too. In the mean time, we try to provide an open standard. RFC 3195bis seems to be the most appropriate choice here, because it can't be taken hostage by another abusive patent claim as it bases on well-defined prior art (RFC 3195). Far more important standardization efforts have been brought to a hold by IPR claims (think: SPAM). Claiming IPR where there are none is of no utility. Huawei needs to learn this. [1] http://www.heise.de/newsticker/meldung/74342 (in German) Rainer > -----Original Message----- > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 7: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 > > > 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 > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
