Subject: [Syslog] Issue 14 - Unreliable Delivery

From: Chris Lonvick <[email-masked]>
Date: Fri, 18 Jun 2010 20:41:47 -0700 (PDT)

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?

Thanks,
Chris

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 20 Jun 2010 21:47:38 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Chris Lonvick (clonvick)
> Sent: Friday, June 18, 2010 8:42 PM
> To: [email-masked]
> Subject: [Syslog] Issue 14 - Unreliable Delivery
> 
[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-masked]
> https://www.ietf.org/mailman/listinfo/syslog

---

From: "David Harrington" <[email-masked]>
Date: Mon, 21 Jun 2010 08:22:20 -0400

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 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joseph Salowey 
> (jsalowey)
> Sent: Monday, June 21, 2010 12:48 AM
> To: Chris Lonvick (clonvick); [email-masked]
> Subject: Re: [Syslog] Issue 14 - Unreliable Delivery
> 
> 
> 

> > 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.
> > 
> > (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
> > should be using tls/tcp as their transport.  From that, 
> it's probably
> best
> 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

---

From: Jon Callas <[email-masked]>
Date: Mon, 21 Jun 2010 09:07:25 -0700

> 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?

I think a note somewhere reminding people that DTLS is unreliable, and that syslog-sign protects both reliable and unreliable transports is reasonable, but I wouldn't spend more than a sentence on each.

	Jon