Chris:
Thanks for feedback. Attached is the latest draft for final review by the
group before I send it out officially. One follow up question below...
> The dates need updating. Copyright should be dated 2005.
Done.
> Spaces are needed before the reference bracket.
> The informational RFC 3164[7] originally described the
> syslog should be
> The informational RFC 3164 [7] originally described the syslog
Done.
> The following paragraph is part of the Introduction but
> should be in a separate section "Conventions Used in This Document".
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119[5]. The
> words 'byte' and 'octet' are used interchangeably in this
> specification.
> The last sentence should be a separate paragraph.
Done.
> Section 2 "One Message Per Datagram" contains:
> Each syslog UDP datagram MUST contain one and only one syslog
> message. The message MUST be formatted according to the RFC-
> protocol[2]. Additional data MUST NOT be present in the datagram
> payload.
> Doesn't this go against the rules of fragmentation where a
> single udp datagram may contain less than one syslog message?
> (I know what Anton is trying to say here but I don't think
> it's coming out exactly right.)
I changed this to:
"Each syslog UDP datagram MUST contain only one syslog message, which
can be complete or truncated. The message MUST be formatted and
truncated according to the RFC-protocol [2]. Additional data MUST
NOT be present in the datagram payload."
Does this look ok?
> Section 7 "UDP Checksums" needs to have the cases of keywords changed.
> Use of UDP checksums was defined as optional in RFC
> 768[1]. IPv6 has
> subsequently made UDP checksums required in RFC 2460[4].
> Should be
> Use of UDP checksums was defined as OPTIONAL in RFC 768
> [1]. IPv6 has
> subsequently made UDP checksums REQUIRED in RFC 2460 [4].
Done.
> Also, there seems to be a problem with this.
> It seems to state that sending IPv4 hosts don't have to send
> accurate udp checksums but that recieveing IPv4 hosts must
> discard datagrams with inaccurate udp checksums.
This is correct. I don't see a problem with that. There is a way to distinguish
accurate checksum from one that was not computed at all.
> Use of UDP checksums was defined as optional in RFC 768[1].
> and
> Syslog senders SHOULD use UDP checksums when sending
> messages over IPv4.
> but then
> Syslog receivers MUST check the checksums whenever they are present
> and discard messages with incorrect checksums.
As stated in the last sentence, the receivers must only check the checksums
whenever they are present. So, if the checksum is 0, it indicates the sender
did not compute the checksum per UDP RFC. In this case, we do not require the
receiver to discard the message. But if checksums are there, the receiver MUST
validate them.
> Can we get this addressed? (Probably the section should say
> that it is RECOMMENDED that both senders and receivers use
> the checksums. It's probably worth a comment in the Security
> Considerations section as well.)
I could go for that, it you still think it is needed. Or could just clarify the
requirement further. However, I think given a requirement on Internet hosts to
support UDP checksums (if not always enabled), it is a good idea to take
advantage of that feature for syslog to ensure better robustness. What do you
think?
> Grammar in Section 8.2 "Message Corruption"
> implementation itself. For example, several earlier UDP
> implementations defaulted to a buffer size of less than 65536 bytes
> and truncated larger payloads upon reception [9]. By
> following the The last sentece should be:
> and truncated larger payloads upon receipt [9]. By following the
Done.
Thanks,
Anton.
syslog Working Group A. Okmianski
Internet-Draft Cisco Systems, Inc.
Expires: January 7, 2006 July 6, 2005
Transmission of syslog messages over UDP
draft-ietf-syslog-transport-udp-05
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the transport for syslog messages over UDP/
IPv4 or UDP/IPv6. The syslog protocol layered architecture provides
for support of any number of transport mappings. However, for
interoperability purposes, syslog protocol implementors are required
to support this transport protocol.
Okmianski Expires January 7, 2006 [Page 1]
Internet-Draft syslog udp transport July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . 3
3. One Message Per Datagram . . . . . . . . . . . . . . . . . . 3
4. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Source and Target Ports . . . . . . . . . . . . . . . . . . 4
6. Source IP Address . . . . . . . . . . . . . . . . . . . . . 4
7. UDP/IP Structure . . . . . . . . . . . . . . . . . . . . . . 4
8. UDP Checksums . . . . . . . . . . . . . . . . . . . . . . . 4
9. Reliability Considerations . . . . . . . . . . . . . . . . . 5
9.1 Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 5
9.2 Message Corruption . . . . . . . . . . . . . . . . . . . . 5
9.3 Congestion Control . . . . . . . . . . . . . . . . . . . . 5
9.4 Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . 6
10.1 Sender Authentication . . . . . . . . . . . . . . . . . 6
10.2 Message Forgery . . . . . . . . . . . . . . . . . . . . 6
10.3 Message Observation . . . . . . . . . . . . . . . . . . 7
10.4 Replaying . . . . . . . . . . . . . . . . . . . . . . . 7
10.5 Unreliable Delivery . . . . . . . . . . . . . . . . . . 7
10.6 Message Prioritization and Differentiation . . . . . . . 7
10.7 Denial of Service . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
12. Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . 8
13. Working Group . . . . . . . . . . . . . . . . . . . . . . . 8
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
15.1 Normative References . . . . . . . . . . . . . . . . . . 9
15.2 Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
Okmianski Expires January 7, 2006 [Page 2]
Internet-Draft syslog udp transport July 2005
1. Introduction
The informational RFC 3164 [7] originally described the syslog
protocol as it was observed in existing implementations. It
described both the format of syslog messages and a UDP [1] transport.
Subsequently, the syslog protocol has been formally defined in the
standards track RFC-protocol [2].
The RFC-protocol specified a layered architecture that provided for
support of any number of transport layer protocols for transmitting
syslog messages. This standards track RFC describes the UDP
transport for the syslog protocol.
This protocol can be used for transmitting syslog messages over both
IPv4 [3] and IPv6 [4]. This transport protocol is REQUIRED for all
syslog protocol implementations for interoperability purposes.
Network administrators and architects should be aware of the
significant reliability and security issues of this protocol, which
stem from the use of UDP. They are documented in this specification.
However, this protocol is lightweight and is built upon the existing
popular use of UDP for syslog.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
The words 'byte' and 'octet' are used interchangeably in this
document.
3. One Message Per Datagram
Each syslog UDP datagram MUST contain only one syslog message, which
can be complete or truncated. The message MUST be formatted and
truncated according to the RFC-protocol [2]. Additional data MUST
NOT be present in the datagram payload.
4. Message Size
This protocol supports transmission of syslog messages up to 65536
bytes in size. This limit stems from the maximum supported UDP
payload of 65536 kilobytes specified in the RFC 768 [1].
IPv4 syslog receivers MUST be able to receive datagrams with message
size up to and including 480 bytes. IPv6 syslog receivers MUST be
able to receive datagrams with message size up to and including 1180
Okmianski Expires January 7, 2006 [Page 3]
Internet-Draft syslog udp transport July 2005
bytes. All syslog receivers SHOULD be able to receive datagrams with
messages size of at least 2048 bytes.
The above restrictions and recommendations establish a baseline for
interoperability. The minimum required message size support was
determined based on the minimum MTU size that internet hosts are
required to support: 576 bytes for IPv4 [3] and 1280 bytes for IPv6
[4]. Datagrams that fall within these limits have the greatest
chance of being delivered because they do not require fragmentation.
It is RECOMMENDED that application developers restrict message sizes
such that IP datagrams do not exceed the smallest MTU of the network
in use. This avoids datagram fragmentation and possible issues
surrounding fragmentation such as incorrect MTU discovery.
Fragmentation may be undesirable because it increases the risk of the
message being lost due to loss of just one datagram fragment. When
network MTU is not known in advance and cannot be reliably determined
using path MTU discovery [8], the safest assumption is to restrict
messages to 480 bytes for IPv4 and 1180 bytes for IPv6.
5. Source and Target Ports
Syslog receivers MUST support accepting syslog datagrams on a well-
known UDP port 514, but MAY be configurable to listen on a different
port. Syslog senders MUST support sending syslog message datagrams
to the UDP port 514, but MAY be configurable to send messages to a
different port. Syslog senders MAY use any source UDP port for
transmitting messages.
6. Source IP Address
The source IP address of the UDP datagrams SHOULD NOT be interpreted
as the identifier for the host that originated the syslog message.
The entity sending the syslog message may be merely a relay. The
syslog message itself contains the identifier of the originator of
the message.
7. UDP/IP Structure
Each UDP/IP datagram sent by the transport layer MUST completely
adhere to the structure specified in the UDP RFC 768 [1] and either
IPv4 RFC 791 [3] or IPv6 RFC 2640 [4] depending on which protocol is
used.
8. UDP Checksums
Use of UDP checksums was defined as OPTIONAL in RFC 768 [1]. IPv6
has subsequently made UDP checksums REQUIRED in RFC 2460 [4].
Okmianski Expires January 7, 2006 [Page 4]
Internet-Draft syslog udp transport July 2005
Syslog senders MUST use valid UDP checksums when sending messages
over IPv6. Syslog senders SHOULD use UDP checksums when sending
messages over IPv4.
Syslog receivers MUST check the checksums whenever they are present
and discard messages with incorrect checksums. Note that this is
typically accomplished by the UDP layer implementation, and some UDP
implementations allow for checksum validation to be enabled or
disabled.
9. Reliability Considerations
The UDP is an unreliable low-overhead protocol. This section
discusses reliability issues inherent in UDP that implementers and
users MUST be aware of.
9.1 Lost Datagrams
This transport protocol does not provide any mechanism to detect and
correct loss of datagrams. Datagrams may be lost in transit due to
congestion, corruption, or any other intermittent network problem.
IP fragmentation exacerbates this problem because loss of a single
fragment will result in the entire message being discarded.
In some circumstances the sender may receive an ICMP error message or
other indication of a transmission problem. If the sender receives a
reasonable indication that a datagram may have been lost, it MAY
retransmit the datagram.
9.2 Message Corruption
The UDP/IP datagrams may get corrupted in transit due to software,
hardware, or network errors. This protocol specifies use of UDP
checksums to enable corruption detection in addition to checksums
used in IP and Layer 2 protocols. However, checksums do not
guarantee corruption detection, and this protocol does not provide
for message retransmission when a corrupt message is detected.
A special case of corruption is corruption introduced by the UDP
implementation itself. For example, several earlier UDP
implementations defaulted to a buffer size of less than 65536 bytes
and truncated larger payloads upon receipt [9]. By following the
message size recommendations of this protocol, application developers
can significantly reduce the risk of this type of error.
9.3 Congestion Control
The UDP does not provide for congestion control. Any network host or
Okmianski Expires January 7, 2006 [Page 5]
Internet-Draft syslog udp transport July 2005
router can discard UDP packets when it is overloaded, and it may or
may not provide an ICMP error to indicate this. One or multiple
syslog senders can maliciously or inadvertently overload the receiver
or the network infrastructure and cause loss of syslog messages.
9.4 Sequenced Delivery
The IP transport used by the UDP does not guarantee that the sequence
of datagram delivery will match the order in which the datagrams were
sent. The time stamp contained within each syslog message may serve
as a rough guide in establishing sequence order, but it will not help
in cases when multiple messages were generated during the same time
slot, the sender cannot generate a time stamp, or messages originated
from different hosts whose clocks are not synchronized. The order of
syslog message arrival via this transport SHOULD NOT be used as an
authoritative guide in establishing an absolute or relative sequence
of events on the syslog sender hosts.
10. Security Considerations
Several syslog security considerations are discussed in RFC-protocol
[2]. This section focuses on security considerations specific to the
syslog transport over UDP.
10.1 Sender Authentication
This transport protocol does not provide for strong sender
authentication. The receiver of the syslog message will not be able
to ascertain that the message was indeed sent from the reported
sender, or whether the packet was sent from another device. This may
also lead to a case of mistaken identity if a misconfigured machine
sends syslog messages to a receiver representing itself as another
machine.
10.2 Message Forgery
This transport protocol does not provide protection against syslog
message forgery. An attacker may transmit syslog messages (either
from the machine from which the messages are purportedly sent or from
any other machine) to a receiver.
In one case, an attacker may hide the true nature of an attack amidst
many other messages. As an example, an attacker may start generating
forged messages indicating a problem on some machine. This may get
the attention of the system administrators, who will spend their time
investigating the alleged problem. During this time, the attacker
may be able to compromise a different machine or a different process
on the same machine.
Okmianski Expires January 7, 2006 [Page 6]
Internet-Draft syslog udp transport July 2005
Additionally, an attacker may generate false syslog messages to give
untrue indications of the status of systems. As an example, an
attacker may stop a critical process on a machine, which may generate
a notification of exit. The attacker may subsequently generate a
forged notification that the process had been restarted. The system
administrators may accept that misinformation and not verify that the
process had indeed not been restarted.
10.3 Message Observation
This transport protocol does not provide confidentiality of the
messages in transit. If syslog messages are in clear text, this is
how they will be transferred. In most cases passing clear-text
human-readable messages is a benefit to the administrators.
Unfortunately, an attacker may also be able to observe the human-
readable contents of syslog messages. The attacker may then use the
knowledge gained from these messages to compromise a machine. It is
RECOMMENDED that no sensitive information be transmitted via this
transport protocol or that transmission of such information be
restricted to properly secured networks.
10.4 Replaying
Message forgery and observation can be combined into a replay attack.
An attacker may record a set of messages that indicate normal
activity of a machine. At a later time, an attacker may remove that
machine from the network and replay the syslog messages with new time
stamps. The administrators may find nothing unusual in the received
messages, and their receipt would falsely indicate normal activity of
the machine.
10.5 Unreliable Delivery
As was previously discussed in the Reliability Considerations
section, the UDP transport is not reliable, and packets containing
syslog message datagrams can be lost in transit without any notice.
There can be security consequences to the loss of one or more syslog
messages. Administrators may not become aware of a developing and
potentially serious problem. Messages may also be intercepted and
discarded by an attacker as a way to hide unauthorized activities.
10.6 Message Prioritization and Differentiation
This transport protocol does not mandate prioritization of syslog
messages on the wire or when processed on the receiving host based on
their severity. The security implication of such behavior is that
the syslog receiver or network devices may get overwhelmed with low-
severity messages and be forced to discard potentially high-severity
Okmianski Expires January 7, 2006 [Page 7]
Internet-Draft syslog udp transport July 2005
messages. High-severity messages may contain an indication of
serious security problems, but they will not get a higher priority.
10.7 Denial of Service
An attacker may overwhelm a receiver by sending more messages to it
than can be handled by the infrastructure or the device itself.
Implementers SHOULD attempt to provide features that minimize this
threat such as optionally restricting reception of messages to a set
of know source IP addresses.
11. IANA Considerations
IANA must reserve UDP port 514 for this transport.
12. Notice to RFC Editor
This is a notice to the RFC editor. This ID is submitted along with
ID draft-ietf-syslog-protocol and they cross-reference each other.
When RFC numbers are determined for each of these IDs, please replace
all references to "RFC-protocol" with the RFC number of
draft-ietf-syslog-protocol ID. Please remove this section after
editing.
13. Working Group
The working group can be contacted via the mailing list:
[email protected]
The current Chair of the Working Group may be contacted at:
Chris Lonvick
Cisco Systems
Email: [EMAIL PROTECTED]
14. Acknowledgements
The author gratefully acknowledges the contributions of: Chris
Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert
Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova,
Devin Kowatch, Richard Graveman, and all others who have commented on
the various versions of this proposal.
15. References
Okmianski Expires January 7, 2006 [Page 8]
Internet-Draft syslog udp transport July 2005
15.1 Normative References
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[2] Gerhards, R., "The syslog Protocol", RFC RFC-protocol.
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
15.2 Informative References
[7] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[8] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[9] Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.",
January 1994.
Author's Address
Anton Okmianski
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719-2205
USA
Phone: +1-978-936-1612
Email: [EMAIL PROTECTED]
Okmianski Expires January 7, 2006 [Page 9]
Internet-Draft syslog udp transport July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[EMAIL PROTECTED]
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Okmianski Expires January 7, 2006 [Page 10]
_______________________________________________
Syslog-sec mailing list
[email protected]
http://www.employees.org/mailman/listinfo/syslog-sec
