Re: [Syslog] [OPSAWG] Syslog message to Remote Rerver

"ietfdbh" <> Mon, 25 February 2013 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C80521F91E2 for <>; Sun, 24 Feb 2013 22:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.416
X-Spam-Status: No, score=-100.416 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nw4oONanSckq for <>; Sun, 24 Feb 2013 22:54:43 -0800 (PST)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:227]) by (Postfix) with ESMTP id 1015421F91E1 for <>; Sun, 24 Feb 2013 22:54:42 -0800 (PST)
Received: from ([]) by with comcast id 4Wui1l0011YDfWL5CWuirZ; Mon, 25 Feb 2013 06:54:42 +0000
Received: from JV6RVH1 ([]) by with comcast id 4Wuh1l00J3Ecudz3gWuhUZ; Mon, 25 Feb 2013 06:54:42 +0000
From: "ietfdbh" <>
To: "'Aditya Dogra \(addogra\)'" <>, <>, <>
References: <>
In-Reply-To: <>
Date: Mon, 25 Feb 2013 01:54:14 -0500
Message-ID: <004301ce1324$ecb29500$c617bf00$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01CE12FB.03DF4C20"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFvPKhnBeHB2YGabgDQ3u8+JIZqvJlHx4eA
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1361775282; bh=dDuDpSKuPGBlqh8DxXeK3xj5R6NSQmluCJjosfC5WOA=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=LuzRyoS8t2CRci30ix+HdfTzgmyaA+TXTfDCssOmtbgC7DtPXuu2mcxR5wMEiodlI QWNZoIZ4VVR86qD2EtNafvIFuAMFCxujXwERspZ48Uzd3bJXt9JL+1k6itRdvo1+NW YOI0kFxfuyjQjxHbCxaUBth6r90e7y96Eu2PnTpLa29g+GJ5k7szmxoee1gKDqBWTP D9ZdlXZpv+IVLwFQpJGeg6/U05bdsan7rR/WXDZrqWj8dzs6CvFViDWnSksHlAkovO l6qUnCoc/izqBYCMbKRR3r05QYS0BEJo0ULdrAQpIIT/uFSwwUy67YihUSgB/LyCfJ qjIDnvUdY201w==
Subject: Re: [Syslog] [OPSAWG] Syslog message to Remote Rerver
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Issues in Network Event Logging <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Feb 2013 06:54:56 -0000



From: [] On Behalf Of
Aditya Dogra (addogra)
Sent: Thursday, February 21, 2013 11:25 AM
Subject: [OPSAWG] Syslog message to Remote Rerver


Hi All ,


Currently syslog messages collected locally on the network device are
transmitted to the remote syslog servers as per RFC 5424 (UDP protocol used
for transmission) and RFC 3195 (TCP protocol used for transmission) 


[dbh>] RFC5424 defines the IETF version of the syslog protocol message
format (not the UDP transport).

RFC5424 RECOMMENDS using a TLS-based transport (RFC5425) rather than a
UDP-based or plain-TCP-based transport for syslog.


If you use a UDP-based transport for interoperability, it should probably
follow RFC5426.

The IETF standard for syslog over UDP (RFC5426) states:

"   Network administrators and architects should be aware of the

   significant reliability and security issues of this transport, which

   stem from the use of UDP."


Note that RFC6587 (plain TCP transport for syslog) is Historic, and contains
an IESG Note:


   The IESG does not recommend implementing or deploying syslog over

   plain tcp, which is described in this document, because it lacks the

   ability to enable strong security [RFC3365].


   Implementation of the TLS transport [RFC5425] is recommended so that

   appropriate security features are available to operators who want to

   deploy secure syslog.  Similarly, those security features can be

   turned off for those who do not want them.



However, we have observed that increasingly, customers are using syslog
messages archived in the remote server for business logic .


[dbh>] If customers are using archived messages, they might want to consider
using signing syslog messages.

       RFC5848, Signed syslog,  describes a mechanism to add origin

   message integrity, replay resistance, message sequencing, and

   detection of missing messages to the transmitted syslog messages.

Signed syslog helps ensure integrity of messages both in-transit and in
archived storage.

I think that would be a valuable feature in support of business logic.


David Harrington


co-chair, syslog WG


In some networks, it is possible that some of the syslog messages may be
dropped due to link failure or other network conditions. 

However, the customers are expecting much higher resiliency for the syslog


The questions we seek clarification are: 


a)         What are the expectations from the external syslog delivery? 


b)         Should we rely on syslog's alone ? Please note that SNMP traps
functionality for network management is also there.?




Your thoughts and suggestions much appreciated. 




Aditya dogra