Hi, I think that text looks good, except I think you lost the last word. I assume the last sentence was meant to end with "loss".
You also might want to mention syslog-sign by name, not just RFC# dbh > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Joseph Salowey > (jsalowey) > Sent: Monday, June 21, 2010 12:48 AM > To: Chris Lonvick (clonvick); [email protected] > Subject: Re: [Syslog] Issue 14 - Unreliable Delivery > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf > > Of Chris Lonvick (clonvick) > > Sent: Friday, June 18, 2010 8:42 PM > > To: [email protected] > > Subject: [Syslog] Issue 14 - Unreliable Delivery > > > > SECDIR Reviewer comments: > > > > One difference between the security considerations for syslog over > > DTLS and those for syslog over TLS (unnoted in the current Security > > Considerations section) is that DTLS does not provide > retransmission. > > If an attacker can cause a packet to be dropped (especially one > > carrying significant information about an attack), the transport > > receiver may not consider this a significant event and so > the syslog > > server may be completely unaware of the occurrence. This contrasts > > with syslog over TLS where a dropped packet would be retransmitted > > until acknowledged or until the TLS connection goes down > (indicating > > to the transport sender and receiver and perhaps to the > syslog client > > and server that a significant event has occurred). Maybe it > would be a > > good idea to recommend that the transport receiver notice > gaps in the > > DTLS sequence numbers and notify the syslog server. Still, > this is not > > as good from a security standpoint as syslog over TLS since none of > > the client code will be aware that the dropped message was not > > received. At least, there should be a discussion of this > issue in the > > Security Considerations section of this document. > > > > My comments back to the reviewer and the IESG: > > ===vvv=== > > It's discussed in section 5.4 (Unreliable Delivery - in the > Security > > Considerations section) in RFC 5426 and throughout Section 3.1 > > (Loss-Insensitive Messaging) in RFC 4347. I'm thinking > that it would > be > > good to note this in Section 4 (Using DTLS to Secure Syslog) in the > draft. > > > > Overall, the community is comfortable with the loss of > information > as > > they've been using syslog/udp for many years and know the problems > with > > that. RFC 5424 also notes that implementers who wish a lossless > stream > > should be using tls/tcp as their transport. From that, > it's probably > best > > to reference RFC 5848 (referenced as draft-ietf-syslog-sign in the > draft) > > which can also provide an indication of loss of messages. " > > ===^^^^=== > > > > ACTION: I'd like to get some discussion going on this. Do people > think > > that this is good? > > > [Joe] I think it would be good to add a security consideration. How > about: > > "9.x Message Loss > > The transports described in this document are unreliable. It > is possible for messages to be lost or removed by an attacker > without the knowledge of the receiver. [RFC 5424] notes that > implementers who wish a lossless stream should be using > tls/tcp as their transport. In addition, the use of [RFC > 5848] can also provide an indication of message. " > > > > Thanks, > > Chris > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
