« Return to Thread: Issue 14 - Unreliable Delivery

Re: Issue 14 - Unreliable Delivery

by Joseph Salowey (jsalowey) :: Rate this Message:

> -----Original Message-----
> From: syslog-bounces@... [mailto:syslog-bounces@...] On
Behalf

> Of Chris Lonvick (clonvick)
> Sent: Friday, June 18, 2010 8:42 PM
> To: syslog@...
> 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@...
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@...
https://www.ietf.org/mailman/listinfo/syslog

« Return to Thread: Issue 14 - Unreliable Delivery