[Syslog] Issue 14 - Unreliable Delivery
Chris Lonvick <clonvick@cisco.com> Sat, 19 June 2010 03:41 UTC
Return-Path: <clonvick@cisco.com>
X-Original-To: syslog@core3.amsl.com
Delivered-To: syslog@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52223A6934 for <syslog@core3.amsl.com>; Fri, 18 Jun 2010 20:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.871
X-Spam-Level:
X-Spam-Status: No, score=-9.871 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsqDf-IIqCcT for <syslog@core3.amsl.com>; Fri, 18 Jun 2010 20:41:41 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D82703A6933 for <syslog@ietf.org>; Fri, 18 Jun 2010 20:41:41 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuMGADbZG0yrR7H+/2dsb2JhbACScQEBjCNxqAOaLYUbBINU
X-IronPort-AV: E=Sophos;i="4.53,442,1272844800"; d="scan'208";a="547211123"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2010 03:41:47 +0000
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5J3flWT027821 for <syslog@ietf.org>; Sat, 19 Jun 2010 03:41:47 GMT
Date: Fri, 18 Jun 2010 20:41:47 -0700
From: Chris Lonvick <clonvick@cisco.com>
To: syslog@ietf.org
Message-ID: <Pine.GSO.4.63.1006181711000.13308@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: [Syslog] Issue 14 - Unreliable Delivery
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Jun 2010 03:41:42 -0000
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
- [Syslog] Issue 14 - Unreliable Delivery Chris Lonvick
- Re: [Syslog] Issue 14 - Unreliable Delivery Joseph Salowey (jsalowey)
- Re: [Syslog] Issue 14 - Unreliable Delivery David Harrington
- Re: [Syslog] Issue 14 - Unreliable Delivery Jon Callas