Subject: I-D ACTION:draft-ietf-syslog-protocol-12.txt

From: [email-masked]
Date: Wed, 01 Jun 2005 16:07:06 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.

	Title		: The syslog Protocol
	Author(s)	: R. Gerhards
	Filename	: draft-ietf-syslog-protocol-12.txt
	Pages		: 45
	Date		: 2005-6-1
	
This document describes the syslog protocol, which is used to convey
   event notification messages.  This protocol utilizes a layered
   architecture, which allows the use of any number of transport
   protocols for transmission of syslog messages.  It also provides a
   message format that allows vendor-specific extensions to be provided
   in a structured way.

   This document has been written with the spirit of RFC 3164 [14] in
   mind.  The reason for a new layered specification has arisen because
   standardization efforts for reliable, and secure syslog extensions
   suffer from the lack of a standards-track and transport independent
   RFC.  Without this document, each other standard needs to define its
   own syslog packet format and transport mechanism, which over time
   will introduce subtle compatibility issues.  This document tries to
   provide a foundation that syslog extensions can build on.  The
   layered architecture also provides a solid basis that allows code to
   be written once instead of multiple times, once for each syslog
   feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-12.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-syslog-protocol-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-syslog-protocol-12.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------------------------------------------------------------------
CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
-------------------------------------------------------------------------
In order to maintain computing infrastructure integrity, Cisco Systems
Enterprise Messaging Services and InfoSec teams have set a mail policy
disallowing executable attachments in email.

This message contained an executable attachment type that is prohibited 
by this policy. The attachment has been removed from this message and 
copied to quarantine by our systems. It will be held in quarantine for
seven days in the event that the content needs to be retrieved.

Please be aware many viruses attempt to look like legitimate email or 
notifications from anti-virus systems. We will clearly mark a seperation
between our notifications and the original email as follows:

  "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"

For further reference information about viruses and email antivirus 
efforts within Cisco, please visit:

http://wwwin.cisco.com/it/ems/services/antiviral

If your concern isn't addressed by the information in this notification 
or the above web page, you may open a support request:

http://wwwin.cisco.com/support/

Select "Messaging", "Email-Related", "Mail Routing"

Please include in the text of your case the following information:

* Full headers of the message. Documentation on displaying the full 
headers is available at this URL:

http://wwwin.cisco.com/support/library/faqs/solution002471.html 

* This unique quarantine identifier: j51KKw55026300

If the matter is urgent, you may follow up by calling one of the below 
referenced numbers. Please make every effort to provide the above 
requested information via the support web tool prior to calling as it 
will greatly aid the resolution of your issue.

Americas:
1 408 526 8888

Asiapac
+61 2 8446 8888

EMEA
+31 20 485 4888

Japan
+81 3 5549 6888

US (Toll Free)
1| 800| 888| 8187| (ext.68888)

Thank you for your cooperation,

Enterprise Messaging Services
Cisco Systems, Inc
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Didier DALMASSO <[email-masked]>
Date: Fri, 3 Jun 2005 11:51:13 +0200

Hi,

I've noticed some inaccuracies for the truncation at the initial
sender. I suggest several modifications :

in section 6
---------
<
      TRUNCATE        = "0" / "1" / "2" / "3"
      TRUNCATE        = "0" / "1" / "2" / "3" / "5" / "6" / "7"
---------

in section 6.1 Message Lentgh
---------
<
   Receivers SHOULD follow this order of preferrence when it comes to
   truncation:
   If a sender have a message with a length larger than 2,048 octets, the
   sender MAY send it complete or truncate the payload before send it.

   This order of preferrence SHOULD be follow when it comes to
   truncation:
---------
<
When a receiver truncates a message, the TRUNCATE field
(Section 6.2.4) MUST be updated.  Please note that this will break
eventually existing digital signatures.
When a receiver or initial sender truncates a message, the TRUNCATE
field (Section 6.2.4) MUST be updated.  In the case of a receiver,
please note that this will break eventually existing digital
signatures.
---------

in section 6.2.4  TRUNCATE
---------
<
   The TRUNCATE field is used to indicate if the message has been
   truncated since it was sent.  Such a truncation might happen on any
   receiver, including receivers on interim systems (relays).  Values in
   the TRUNCATE field are made up of bits.  Each of this bits has been
   assigned a specific value so that there is no doubt about bit
   ordering.  The following values MUST be used:

            VALUE     Meaning
              1       all or some SD-ELEMENTs were truncated
              2       all or part of MSG was truncated
              4       truncation occured at the initial sender

   If the initial sender truncates a message, this MUST be inidicated by
   setting the "truncation occured at the initial sender" bit (value 4).
   The TRUNCATE field is used to indicate if the message has been
   truncated since it was sent or generated by an application.
   Such a truncation might happen on the initial sender and any
   receiver, including receivers on interim systems (relays).  Values in
   the TRUNCATE field are made up of bits.  Each of this bits has been
   assigned a specific value so that there is no doubt about bit
   ordering.  The following values MUST be used:

            VALUE     Meaning
              1       all or some SD-ELEMENTs were truncated
              2       all or part of MSG was truncated
              4       truncation occurred at the initial sender

   The value in the TRUNCATE field is the ASCII representation of these
   ORed bits. If the initial sender truncates a message, this MUST be
   indicated by setting the "truncation occured at the initial sender"
   bit (value 4). In the case of the truncation occured at the initial
   sender and at a receiver (relay or collector), he MUST unset the third
   bit (value 4). This allows to detect the signature is invalid.
---------

and for the next paragraph:

---------
Some examples: If no truncation occured, TRUNCATE MUST have a value
of 0.  If SD-ELEMENTs were truncated on the receiver, TRUNCATE MUST
have a value of 1.  If they were truncated on the initial sender,
TRUNCATE must have the value of 5.  If structured data and MSG were
truncated on an interim system, TRUNCATE MUST have the value 3.  If
only MSG was truncated on the initial sender, TRUNCATE MUST have the
value 6.
---------

s/must have the value of 5/MUST have the value of 5/

Thanks,

-- 
          Didier Dalmasso
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec