Re: [Syslog] Issue 14

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: syslog-bounces@ietf.org 
> [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey 
> (jsalowey)
> Sent: Monday, June 21, 2010 12:48 AM
> To: Chris Lonvick (clonvick); syslog@ietf.org
> Subject: Re: [Syslog] Issue 14 - Unreliable Delivery
> 
> 
> 
> > -----Original Message-----
> > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On
> Behalf
> > Of Chris Lonvick (clonvick)
> > Sent: Friday, June 18, 2010 8:42 PM
> > To: syslog@ietf.org
> > 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
> > Syslog@ietf.org
> > https://www.ietf.org/mailman/listinfo/syslog
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog