RE: Transport draft preview
"Anton Okmianski" <aokmians@cisco.com> Mon, 10 May 2004 23:16 UTC
Date: Mon, 10 May 2004 19:16:18 -0400
From: Anton Okmianski <aokmians@cisco.com>
Subject: RE: Transport draft preview
X-Message-ID:
Message-ID: <20140418112206.2560.51865.ARCHIVE@ietfa.amsl.com>
Devin: If we limit syslog over UDP to somewhere in the area of 512 bytes and say that larger messages have to be transported via other transport(s), are we going to then say that implementation of this other transport is also required? I think it would be pretty tough to proposition to require people to implement both transports and it would be an operational risk to run a mixed environment. Or should we just say that 512 bytes for IPv4 (and if we want ~1190 for IPv6) is the max size of syslog message. Period. If we think of syslog as a mechanism to provide notifications only and not a general logging mechanism it is perfectly acceptable. The details of the error could be in the application's log files, state, etc. After all transmitting an OS core file over syslog while could be helpful is probably a wrong thing to do. And I think syslog is not a replacement for logging to a local file. So, my example of a large crash diagnostic message that one of our applications logs would be the case of something that SHOULD NOT go over syslog. Instead only a notification of a crash with a possible basic reason why and possible a mention of where extra details can be found should be in a syslog message. I am not thrilled at all about supporting fragmentation for UDP transport. But I don't like the idea of a mixed environment either. I am also curious about what people think about how syslog compares with SNMP notifications (informs - acknowledged and secure, and traps - - unacknowledged and unreliable). If syslog is a mechanism to notify of state changes, then what's its role vis-à-vis SNMP notifications? Thanks, Anton. > -----Original Message----- > From: Devin Kowatch [mailto:devink@sdsc.edu] > Sent: Monday, May 10, 2004 5:56 PM > To: Anton Okmianski > Cc: syslog-sec@employees.org > Subject: Re: Transport draft preview > > > On Mon, May 10, 2004 at 03:26:14PM -0400, Anton Okmianski wrote: > > Devin: > > > > > There is one point which I'm not completely clear on. What > > > happens to a fragmented message when one ore more parts of > > > that message get dropped? > > > > Just like with IP fragmentation, the whole message (all other > > fragments) gets discarded. It is mentioned in the Message > Reassembly > > section. A couple other sections (Avoiding Fragmentation and Lost > > Datagrams) imply it. But since you are not the first person to ask > > this, I will make sure to put this more prominently > somewhere in the > > draft. > > > > Of course we should not prevent the implementation from logging the > > received fragments of an incomplete message somewhere for > debugging. > > So, I am not clear if a putting a MUST is a good idea. > > Okay, thanks. > > > > > One other suggestion ... why not just limit UDP packets to > > > 1024 bytes, whith no fragmentation? > > > > With IPv4, transferring UDP datagrams of that size may not > be reliable > > to my knowledge (well less reliable than it is UDP usually is :)). > > Most UDP protocols restrict the size to a much smaller > size. I don't > > know of popular UDP-based protocols that allow 1024 bytes UDP > > datagrams. If there are some they could serve as sufficient > proof that > > this datagram size in UDP is acceptable. See discussion of packets > > sizes in Appendix A of my draft. > > I chose 1024 becasue that was the size limit specified in > RFC3164 (section 4.1). Most of the log messages I have seen > (under unix) are less than 300 bytes though. > > > > > > For large syslog > > > messages, require a reliable transport layer (TCP) which > > > means you can just properly frame the message and send it (or > > > use something like BEEP which already deals with > > > fragmentation) ... > > > > I am not sure if it is a good idea to require different transport > > depending on a message size. > > My biggest argument for doing so, is that it seems eaiser to > support large messages over a reliable transport ... But I > see you mostly agree with that sentiment (last sentence of > the next paragraph). > > > > > I am also not sure if 1024 bytes is sufficient. I know one > product I > > work on at Cisco which has a crash diagnostic message which > consists > > of about 1000-1500 lines. So, it is about 80-130K. Even > bigger than > > the 65K MUST-support size I proposed for udp-transport. I > just think > > transferring huge fragmented messages over unreliable > transport is not > > a good idea. Hence, larger size are not a requirement, but a > > recommendation. > > On the other hand a 1024 byte limit or ever 512 byte limit > won't leave us much worse off than we are with RFC3164, and > is sufficient for most purposes (under unix at least). Then > use a reliable transport to send larger messages (good > encouragement for people to switch too). > > > > > As far as using TCP, I am actually thinking more along the lines of > > UDP with acknowledgements (like in TFTP) for a future protocol. It > > would still be lighter and the acknowledgments would be more high > > level. For example, a receiver can acknowledge the message after it > > persisted it to disk instead of like in TCP, where a stack > > acknowledges the message as it is received by the host (and if the > > systems crashes an the message is lost, oh well). Using TCP often > > results in additional higher-level protocol acknowledgements being > > sent. > > Ummm... you've heard the saying about thoes who don't > understand TCP are doomed to reimplement it, badly? Not > saying that's the case here ... just seemed like a good time > to rememeber it. > > I've looked at this (for my own syslog deamon), and I believe > that it's simpler to build application level ACKS on top of > TCP than it is to build a reliable network protocol on top of > UDP. Also, building on TCP allows a vastly simpler > implementation if the application level ACK is either skipped > or sent back as soon as the message is received, which isn't > a bad thing all the time. Pushing back the application level > ACK to a point where the message is on disk could be a more > advanced feature (and is more difficult to implement correctly). > > > > > I was thinking about putting a MessageId field into every message > > (including basic header) such that adding acknowledgements > later would > > not change the format of the message, but I bailed out on that as I > > think this increases scope. If people think that this may not be a > > bad idea, I can put it in there. > > > > Thanks, > > Anton. > > > > > > > > > > > > On Fri, May 07, 2004 at 04:36:25PM -0400, Anton Okmianski wrote: > > > > Hi! > > > > > > > > I am about to publish the new UDP syslog transport draft. I > > thought > > > > I'd show it this forum first before making it publicly > > > available to a wider audience. In particular, I want to make > > > sure we have rough consensus on support for fragmentation > > > feature. I have specified the header format using ASCII > > > encoding as was suggested by Rainer and Andrew. > > > > > > > > I plan on submitting this as an official draft next week. > > > One area I > > > > am not quite sure about yet is what minimum size of messages > > should > > > > implementations be forced to support. It definitely can't > > > be the full > > > > allowed size of 16MB as some hardware won't support it. > > > Right now it > > > > is set at 65k, which means implementations are forced to support > > > > fragmentation. I wonder if reducing it to the size where > > > > fragmentation would be optional (507 bytes for IPv4 and > > > 1911 for IPv6) > > > > would increase the adoption of the protocol without sacrificing > > too > > > > much of interoperability. Fragmentation feature adds orders of > > > > magnitude more complexity than non-fragmented syslog > > > transport. Any > > > > opinions? > > > > > > > > Thanks, > > > > Anton. > > > > > > > > > > > > > > > > > > > syslog Working Group > > > A. Okmianski > > > > Internet-Draft Cisco > > > Systems, Inc. > > > > Expires: November 5, 2004 > > > May 7, 2004 > > > > > > > > > > > > Transmission of syslog messages over UDP > > > > draft-ietf-syslog-transport-udp-01 > > > > > > > > Status of this Memo > > > > > > > > This document is an Internet-Draft and is in full > > > conformance with > > > > all provisions of Section 10 of RFC2026. > > > > > > > > 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 November 5, 2004. > > > > > > > > Copyright Notice > > > > > > > > Copyright (C) The Internet Society (2004). All > Rights Reserved. > > > > > > > > Abstract > > > > > > > > This document describes the transport for the syslog message > > over > > > > UDP/IPv4 or UDP/IPv6. While several transport mappings > > > are envisioned > > > > for the syslog protocol, syslog protocol implementors > > > are required to > > > > support the transport mapping described in this > document. This > > > > transport specification overcomes limitations of UDP/IP > > > datagram size > > > > by introducing support for fragmentation of large messages > > using > > > > multiple datagrams. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 1] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > Table of Contents > > > > > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . > > > . . . . . 3 > > > > 2. Transport Protocol Overview . . . . . . . . . . . . > > > . . . . . 4 > > > > 2.1 Definitions and Architecture . . . . . . . . . . > > > . . . . . 4 > > > > 2.2 Required Transport Protocol . . . . . . . . . . > > > . . . . . 4 > > > > 2.3 Encapsulation Layers . . . . . . . . . . . . . . > > > . . . . . 4 > > > > 3. Message Format . . . . . . . . . . . . . . . . . . . > > > . . . . . 6 > > > > 3.1 Basic Header Format . . . . . . . . . . . . . . > > > . . . . . 6 > > > > 3.2 Extended Header Format . . . . . . . . . . . . . > > > . . . . . 7 > > > > 3.2.1 Message Identifier . . . . . . . . . . . . . > > > . . . . . 7 > > > > 3.2.2 Total Length . . . . . . . . . . . . . . . . > > > . . . . . 7 > > > > 3.2.3 Fragment Offset . . . . . . . . . . . . . . > > > . . . . . 8 > > > > 3.2.4 Extended Header Example . . . . . . . . . . > > > . . . . . 8 > > > > 3.3 Payload . . . . . . . . . . . . . . . . . . . . > > > . . . . . 9 > > > > 3.4 Supported Message Length . . . . . . . . . . . . > > > . . . . . 9 > > > > 4. UDP/IP Layer Considerations . . . . . . . . . . . . > > > . . . . . 10 > > > > 4.1 Target Port . . . . . . . . . . . . . . . . . . > > > . . . . . 10 > > > > 4.2 Source Port . . . . . . . . . . . . . . . . . . > > > . . . . . 10 > > > > 4.3 Source IP Address . . . . . . . . . . . . . . . > > > . . . . . 10 > > > > 4.4 UDP/IP Headers . . . . . . . . . . . . . . . . . > > > . . . . . 10 > > > > 5. Fragmentation and Reassembley . . . . . . . . . . . > > > . . . . . 12 > > > > 5.1 Message Fragmentation . . . . . . . . . . . . . > > > . . . . . 12 > > > > 5.2 Message Reassembley . . . . . . . . . . . . . . > > > . . . . . 12 > > > > 5.3 Avoiding Fragmentation . . . . . . . . . . . . . > > > . . . . . 13 > > > > 6. Reliability Considerations . . . . . . . . . . . . . > > > . . . . . 14 > > > > 6.1 Lost Datagrams . . . . . . . . . . . . . . . . . > > > . . . . . 14 > > > > 6.2 Message Corruption and Checksums . . . . . . . . > > > . . . . . 14 > > > > 6.3 Congestion Control . . . . . . . . . . . . . . . > > > . . . . . 14 > > > > 6.4 Sequenced Delivery . . . . . . . . . . . . . . . > > > . . . . . 14 > > > > 6.5 Sender Authentication . . . . . . . . . . . . . > > > . . . . . 15 > > > > 7. Security Considerations . . . . . . . . . . . . . . > > > . . . . . 16 > > > > 7.1 Message Authenticity . . . . . . . . . . . . . . > > > . . . . . 16 > > > > 7.2 Message Forgery . . . . . . . . . . . . . . . . > > > . . . . . 16 > > > > 7.3 Message Observation . . . . . . . . . . . . . . > > > . . . . . 16 > > > > 7.4 Replaying . . . . . . . . . . . . . . . . . . . > > > . . . . . 17 > > > > 7.5 Unreliable Delivery . . . . . . . . . . . . . . > > > . . . . . 17 > > > > 7.6 Message Prioritization and Differentiation . . . > > > . . . . . 17 > > > > 7.7 Denial of Service . . . . . . . . . . . . . . . > > > . . . . . 18 > > > > 8. IANA Considerations . . . . . . . . . . . . . . . . > > > . . . . . 19 > > > > 9. Notice to RFC Editor . . . . . . . . . . . . . . . . > > > . . . . . 20 > > > > 10. Authors and Working Group Chair . . . . . . . . . > > > . . . . . 21 > > > > 11. Acknowledgements . . . . . . . . . . . . . . . . . > > > . . . . . 22 > > > > 12. References . . . . . . . . . . . . . . . . . . . . > > > . . . . . 22 > > > > Author's Address . . . . . . . . . . . . . . . . . . > > > . . . . . 23 > > > > A. Rational For Transport Message Size Restrictions . . > > > . . . . . 24 > > > > Intellectual Property and Copyright Statements . . . > > > . . . . . > > > > 26 > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 2] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 1. Introduction > > > > > > > > The original syslog protocol has been described in an > > > informational > > > > RFC 3164 [1] as it has been observed in existing > > > implementations. It > > > > describes both the semantics of syslog message format as > > > well as a > > > > UDP transport. Subsequently, the syslog protocol has > > > been formally > > > > defined in a standards track RFC-protocol [2]. > > > > > > > > The RFC-protocol [2] has provided for support of any > number of > > > > transport layer protocols for transmitting syslog > > > messages and left > > > > it to subsequent RFCs to specify transport protocols. > > > This standards > > > > track RFC describes the UDP transport for the syslog > > > protocol. This > > > > transport protocol is REQUIRED for all syslog protocol > > > > implementations. > > > > > > > > This transport protocol was designed to work on top of > > > UDP [3] over > > > > both IPv4 [4] and IPv6 [5]. This protocol overcomes the data > > size > > > > restrictions of the UDP protocol by introducing message > > > fragmentation > > > > feature. > > > > > > > > As we will show in this specification, this protocol has > > > significant > > > > reliability and security issues stemming from the use of UDP. > > > > However, this protocol is lightweight and extends on the > > existing > > > > popular use of UDP for syslog. Network administrators > > > and architects > > > > should be aware of the shortcomings of this protocol and plan > > > > accordingly. > > > > > > > > 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 [6]. > > The > > > > words 'byte' and 'octet' are used interchangeably in this > > > > specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 3] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 2. Transport Protocol Overview > > > > > > > > 2.1 Definitions and Architecture > > > > > > > > The following definitions will be used in this document: > > > > o An application that can generate syslog messages will > > > be referred > > > > to as a "sender"; > > > > o An application that can receive syslog messages will > > > be referred > > > > to as a "receiver". > > > > > > > > An application can function in dual capacity. For > > > example, a syslog > > > > relay may receive and forward messages. A single system > > > can host any > > > > number of syslog senders. Only one syslog receiver can > > > be hosted on a > > > > single system using the standard listening port. > > > > > > > > 2.2 Required Transport Protocol > > > > > > > > This document describes the UDP transport layer protocol for > > the > > > > syslog protocol RFC-protocol [2]. Every syslog sender > > > and receiver > > > > implementation which adheres to the RFC-protocol [2] > MUST fully > > > > implement the transport protocol specified in this document. > > > > Implementations does not have to support both IPv4 and > > > IPv6 if it is > > > > designed to be used over only one of these protocols. > > > > > > > > 2.3 Encapsulation Layers > > > > > > > > Syslog UDP transport carries syslog messages as > generic payload > > > > encapsulated with a syslog transport header, UDP > header and an > > IP > > > > header. Below is a summary of syslog UDP/IP packet > > > structure as used > > > > this transport protocol: > > > > > > > > > > > > +--------------------------------+ > > > > | IPv4 or IPv6 Header | > > > > | (20 or more bytes) | > > > > +--------------------------------+ > > > > | UDP Header | > > > > | (8 bytes) | > > > > +--------------------------------+ > > > > | Syslog Transport Header | > > > > | (5 or 32 bytes) | > > > > +--------------------------------+ > > > > | Syslog Message Payload | > > > > | (1 to 1191 bytes) | > > > > +--------------------------------+ > > > > > > > > Small syslog messages are transmitted using one UDP/IP > > > datagram per > > > > message. However, syslog protocol [2] allows > messages as large > > as > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 4] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 16777216 bytes, while UDP/IP datagram cannot exceed a > > > total size of > > > > 65526 bytes [3] and most existing protocols restrict the > > > size of UDP > > > > data to much less. In order to support transmitting > > > large messages > > > > over UDP/IP, this transport protocol supports > > > fragmentation of large > > > > syslog messages into multiple UDP/IP datagrams for > > > transmission and > > > > reassembley on the receiving end. > > > > > > > > Each syslog UDP/IP datagram MUST contain one and only > > > one complete > > > > syslog message or one fragment of a message. > > > Transmitting multiple > > > > messages or multiple fragments of different messages in > > > a single UDP > > > > datagram is not supported by this protocol. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 5] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 3. Message Format > > > > > > > > The syslog transport message consist of a transport > header and > > a > > > > syslog message payload. The format of the transport header is > > > > different for fragmented and non-fragmented messages. Basic > > > > transport header is used for non-fragmented messages and > > extended > > > > transport header is used for fragmented messages. > > > > > > > > An ASCII-based encoding was chosen for the syslog > transport for > > > > consistency with the RFC-protocol [2]. Syslog transport > > > datagrams > > > > without required UDP and IP headers have the following > > > format in ABNF > > > > [7] notation: > > > > > > > > > > > > SyslogTransportMessage = ( BasicHeader / ExtendedHeader ) > > > > SP Payload > > > > > > > > BasicHeader = Version SP "0" > > > > Version = %d118 1*3DIGIT ; "v1" in this version > > > > > > > > ExtendedHeader = Version SP "1" SP MessageId > > > > SP TotalLength SP FragmentOffset > > > > > > > > MessageId = 1*8DIGIT ; 0 to 16777215 > > > > TotalLength = 1*8DIGIT ; 1 to 16777216 > > > > FragmentOffset = 1*8DIGIT ; 0 to 16777215 > > > > Payload = 1*1191OCTET > > > > > > > > OCTET = %d00-255 > > > > DIGIT = %d48-57 > > > > SP = %d32 > > > > > > > > > > > > 3.1 Basic Header Format > > > > > > > > When no fragmentation is used and the entire syslog > message is > > > > transferred as a single UDP/IP datagram, a basic syslog > > transport > > > > header MUST be used. The version for this protocol is > > > "1". It must > > > > be followed by one space and a "0" to indicate that this > > > is a basic > > > > header. Therefore, the only possible value for the > > > basic header in > > > > this protocol is as follows: > > > > > > > > > > > > "v1 0 " > > > > > > > > Example of a syslog message without the transport header > > > (message is > > > > wrapped for display): > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 6] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com > > > > dns: configuration error" > > > > > > > > Example of the same message with the transport > header (message > > is > > > > wrapped for display): > > > > > > > > > > > > "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com > > > > dns: configuration error" > > > > > > > > > > > > 3.2 Extended Header Format > > > > > > > > When syslog message is fragmented by the sender, multiple UDP > > > > datagrams must be used and each datagram MUST contain an > > extended > > > > syslog transport header. The version for this protocol > > > is "1". The > > > > version field MUST be followed by a single space and a "1" to > > > > indicate that this is an extended header. Thus, an > > > extended header > > > > MUST always begin with "v1 1 ", but MUST also have > > > additional fields > > > > which aid in fragmentation. > > > > > > > > The MessageId, TotalLength and FragmentOffset fields are > > > used solely > > > > for fragmentation of long messages and reassembley. > > > They SHOULD NOT > > > > be used for other purposes. > > > > > > > > 3.2.1 Message Identifier > > > > > > > > The MessageId field (along with the source UDP port > and the IP > > > > address) is used to identify the message such that > fragments of > > a > > > > single syslog message can be reassembled by the > receiver into a > > > > complete message. The MessageId field MUST be a numeric > > > value in the > > > > range of 0 to 16777215. Leading zeros MUST not be present in > > the > > > > MessageId field. > > > > > > > > Each syslog sender process MUST choose a random > MessageId value > > > > within the supported range for its first message. > > > Subsequent messages > > > > generated by the same process MUST each increment the > > > MessageId by 1 > > > > up to 16777215 and then continue at 0. Using random value for > > the > > > > first MessageId helps reduce the possibility of > > > potential errors in > > > > message reassembley. Refer to discussion about message > > > reassembley > > > > (Section 5.2) for more details. > > > > > > > > All datagrams which represent parts of a given fragmented > > syslog > > > > message MUST have the same MessageId value. > > > > > > > > 3.2.2 Total Length > > > > > > > > The TotalLength field MUST be a numeric value in the > > > range of 1 to > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 7] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 16777216. It MUST indicate the length of a complete > > > syslog message > > > > before it was fragmented and before it was encapsulated with > > > > transport headers. The same TotalLength field value > > > MUST be present > > > > in all UDP datagrams which represent fragments of the same > > syslog > > > > message. Leading zeros MUST not be present in the TotalLength > > > > field. > > > > > > > > Note that in IPv4 the "total length" field identifies > > > the length of a > > > > single packet. In this protocol, the TotalLength field > > > is used to > > > > identify the total length of a complete syslog message, which > > is > > > > transmitted using multiple fragments and multiple > > > datagram packets. > > > > The fragment length is not specified in the transport > > > header because > > > > it can be inferred from the size of the IP packet > > > containing the UDP > > > > datagram. > > > > > > > > 3.2.3 Fragment Offset > > > > > > > > The FragmentOffset field MUST be a numeric value in the > > > range of 0 to > > > > 16777215. It MUST indicate the byte offset of the > > > fragment data in > > > > the complete syslog message. The offset index starts at 0 for > > the > > > > first fragment. For example, if an 700 byte syslog message is > > > > fragmented into 480 and 220 byte parts, the FragmentOffset in > > the > > > > first message will be 0 and in the second - 480. Note > > > that fragments > > > > don't have to be the same size. Leading zeros MUST not > > > be present in > > > > the FragmentOffset field. > > > > > > > > 3.2.4 Extended Header Example > > > > > > > > The following is an example of a syslog message without > > > the transport > > > > header (message is wrapped for display): > > > > > > > > > > > > "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com > > > > dns: configuration error" > > > > > > > > Suppose this message had to be fragmented by transport > > > layer into two > > > > parts at an arbitrary point. This would result in two > > > separate UDP > > > > datagrams being sent - one for each fragment. Below is > > > the content of > > > > each of the syslog transport UDP messages with > syslog transport > > > > headers but without UDP/IP headers: > > > > > > > > > > > > "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z > > > host.dom" > > > > > > > > "v1 1 45612221 74 42 ain.com dns: configuration error" > > > > > > > > In the above example, the leading "v1" is the version of the > > > > transport protocol, "1" indicates that this is an extended > > header > > > > (fragmentation in use), "45612221" is the MessageId, "74" is > > the > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 8] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > TotalLength of the message, while "0" and "42" are > > FragmentOffset > > > > fields. Everything following the FragmentOffset and a > > > space is a the > > > > Payload of each respective message. > > > > > > > > 3.3 Payload > > > > > > > > The Payload field of the syslog UPD transport message is > > > an entire > > > > syslog message or one fragment. The maximum Payload size > > > depends on > > > > the IP protocol used and the type header that is used. > > > > > > > > Maximum Payload size: > > > > > > > > With IPv4 and basic header: 507 bytes > > > > With IPv4 and extended header: 480 bytes > > > > > > > > With IPv6 and basic header: 1191 bytes > > > > With IPv6 and extended header: 1164 bytes > > > > > > > > The Payload size restrictions above effectively mean > > > that the largest > > > > syslog message that can be sent non-fragmented is > 507 bytes for > > > > transport via IPv4 and 1191 bytes for transport via IPv6. > > > > > > > > For a discussion of the relational behind the above size > > > restrictions > > > > please refer to Appendix A. > > > > > > > > 3.4 Supported Message Length > > > > > > > > The maximum syslog message length supported by this > > > protocol is the > > > > maximum value of the TotalLength field, which is 16777216 > > bytes. > > > > However, not all deployment scenarios for syslog will be on > > hosts > > > > with hardware capable of supporting the maximum length > > > of messages > > > > supported by this protocol. Additionally, extremely > > > large messages > > > > may not be needed in many environments. Therefore, > > > implementations > > > > are NOT REQUIRED to support the maximum message > length allowed > > by > > > > this protocol. > > > > > > > > All implementations MUST support sending and receiving syslog > > > > messages up to and including 65536 bytes in size (syslog > > > transport > > > > and UDP/IP headers are extra). Support for larger messages is > > > > encouraged. Implementors SHOULD clearly state the > > > maximum supported > > > > message size in documentation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 9] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 4. UDP/IP Layer Considerations > > > > > > > > 4.1 Target Port > > > > > > > > Syslog receivers MUST support accepting syslog message > > > datagrams on a > > > > well-known UDP port 514. Syslog senders MUST support > > > sending syslog > > > > message datagrams to the UDP port 514. > > > > > > > > 4.2 Source Port > > > > > > > > Syslog senders can use any source UDP port for > > > transmitting messages. > > > > Senders MAY randomly select a source port, but MUST use > > > the port in > > > > an exclusive fashion. No concurrent port reuse on the > > > same host is > > > > allowed. > > > > > > > > Each syslog sender process MUST attempt to use the same > > > source port > > > > for the life of the the process. If due to an error or other > > > > condition it becomes impossible for the process to > > > continue to use > > > > the same port, it MAY start using a new source port, but it > > MUST > > > > generate a new random MessageId for the first message > > > after changing > > > > the port and then MUST continue incrementing the new > > > MessageId value > > > > for subsequent messages. > > > > > > > > Since source port is used to identify parts of a > > > fragmented message, > > > > the sender MUST use the same port to send all fragments > > > of a given > > > > message. If due to an error or other condition, the > > > sender is unable > > > > to do that, it MUST resend all message fragments using > > > the new port > > > > and a new MessageId field value. > > > > > > > > 4.3 Source IP Address > > > > > > > > The source IP address of the UDP datagrams is one of the data > > > > elements used to identify parts of a fragmented message. > > > Therefore, > > > > a syslog sender MUST attempt to use the same source > IP address > > to > > > > send all fragments of a given syslog message. If due to > > > an error, > > > > reconfiguration or other condition it is unable to do > > > so, the sender > > > > MUST resend all fragments of the syslog message using > > > the new source > > > > IP address and a new MessageId value. > > > > > > > > 4.4 UDP/IP Headers > > > > > > > > Each UDP/IP datagram sent by the transport layer MUST > > completely > > > > adhere to the structure specified in the UDP RFC 768 [3] > > > and either > > > > IPv4 RFC 791 [4] or IPv6 RFC 2640 [5] depending on which > > > protocol is > > > > used. > > > > > > > > Use of UDP checksums was defined as optional in RFC 768 > > > [3]. IPv6 has > > > > subsequently made UDP checksums required [5]. > However, syslog > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 10] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > senders MUST utilize valid UDP checksums when sending > > > messages over > > > > either IPv4 or IPv6. Syslog receivers MUST check for > > > checksums and > > > > discard messages with incorrect checksums. Note that this is > > > > typically accomplished by the UDP layer implementation, and > > some > > > > implementations allow for checksum checks to be enabled or > > > > disabled. > > > > > > > > Enabling use of checksums serves as an extra measure of > > > corruption > > > > detection in addition to checksums performed by IP > and Ethernet > > > > layers. None of the above checksums provide a complete > > > guarantee of > > > > corruption detection. Utilizing checksums on multiple > > > layers reduces > > > > the chance of corruption error not being detected. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 11] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 5. Fragmentation and Reassembley > > > > > > > > 5.1 Message Fragmentation > > > > > > > > The syslog transport layer MUST perform > fragmentation if syslog > > > > message size exceeds the maximum allowed Payload size. > > > Fragmentation > > > > SHOULD NOT be used if message can fit into the > maximum allowed > > > > Payload size. > > > > > > > > Syslog messages SHOULD be fragmented such that all but > > > last message > > > > utilize the Payload to its maximum capacity. For > > > example, when using > > > > IPv4, a 700 byte syslog message SHOULD be fragmented > > > into 480 and 220 > > > > byte parts because the maximum Payload size with IPv4 > > > and extended > > > > header is 480 bytes. > > > > > > > > Each message fragment MUST be sent as a separate UDP/IP > > > datagram with > > > > an extended syslog transport header. The sender MUST > > > use the same > > > > MessageId value, source port and source IP address for > > > all fragments > > > > of a given message. These three field together uniquely > > identify > > > > fragments belonging to a given message. > > > > > > > > On a system with short-lived sender processes, it may be > > possible > > > > that fragments with the same MessageId value, source > > > port and source > > > > IP address will get generated in short time proximity. > > > This can be > > > > possible because a new process may re-use the source > > > port that was > > > > freed up by another process that just dies. Such behavior > > could > > > > confuse the receiver if the datagrams were received out > > > of order or > > > > some datagrams got lost. > > > > > > > > In order to reduce the risk of such mistaken identity > > > errors, section > > > > 3.2.1 specified that each process must start with a > > > random value for > > > > MessageId field. Given a relatively large range of > > > MessageId values > > > > and the unlikely event of a coincidence of having the > > > same MessageId > > > > value combined with re-used source port and UPD errors, > > > the window > > > > for potential mistaken identity errors during message > > > reassembley is > > > > very small and tolerable. The users take a greater risk > > > by using this > > > > protocol due to general UDP reliability issues > discussed later > > in > > > > this specification. > > > > > > > > 5.2 Message Reassembley > > > > > > > > The reassembley process uses the source IP address > from the IP > > > > header, the source port from the UDP header and the > > > MessageId field > > > > value to identify fragments of a given message. It then uses > > data > > > > from TotalLength and FragmentOffset fields to > > > re-assemble fragments > > > > into a complete message. > > > > > > > > Typically, an implementation of fragmentation > > > reassembley involves > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 12] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > allocating a buffer for the message when any fragment with a > > new > > > > combination of source IP address, source port and > MessageId is > > > > received. A timer is used to expire the message > > > reassembley and clean > > > > the buffer if all fragments are not received in certain > > > time period. > > > > As each fragment is received, it is placed into the buffer at > > the > > > > appropriate offset and a check is performed to > determine if all > > > > fragments have been received using additional data > structures. > > > > > > > > The receiver SHOULD make the timeout interval used > for message > > > > reassembley configurable for the administrator. The > > > receiver SHOULD > > > > also be able to limit the total amount of memory used for > > buffers > > > > such that it does not run out of resources under a > > > simple denial of > > > > service attack involving just one message fragment > with a large > > > > TotalLength field value. Degrading the service under > > > heavy load or > > > > attack is better than crashing and potentially making the > > service > > > > completely unavailable. > > > > > > > > 5.3 Avoiding Fragmentation > > > > > > > > Fragmentation and reassembley of messages incurs substantial > > > > processing overhead on both the sender and the > receiver hosts. > > It > > > > also increases the risk of lost messages due to lose of just > > one > > > > fragment. It is RECOMMENDED that syslog senders which > > anticipate > > > > sending messages over this transport protocol attempt to > > > reduce the > > > > number of messages which require fragmentation by > > > restricting them to > > > > the size which does not require fragmentation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 13] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 6. Reliability Considerations > > > > > > > > The UDP is an unreliable low-overhead protocol. This section > > > > discusses reliability issues inherent in the UDP that > > > implementers > > > > and users must be aware of. > > > > > > > > 6.1 Lost Datagrams > > > > > > > > Neither UDP nor syslog protocol 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. > > > > Syslog protocol and IP fragmentation exacerbates the > > > problem because > > > > loss of a single fragment would result in 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 some datagram may have been > > > lost, it MAY > > > > retransmit previously sent messages. > > > > > > > > 6.2 Message Corruption and Checksums > > > > > > > > The UDP/IP datagrams may get corrupted in transit due to > > > software, > > > > hardware or network errors. This protocol specified > use of UDP > > > > checksums to enable corruption detection in addition to > > checksums > > > > utilized in IP and Ethernet layers. However, checksums do not > > > > guarantee corruption detection and this protocol does > > > not provide for > > > > message retransmission when a corrupt message is detected. > > > > > > > > 6.3 Congestion Control > > > > > > > > The UDP does not provide for congestion control. Some > > > systems (hosts > > > > or routers) may generate ICMP source quench error, but > > > they are not > > > > required to do so [8]. Any network host can discard UDP > > > packets when > > > > it is overloaded. Due to lack of congestion control one > > > or multiple > > > > syslog senders can maliciously or inadvertently overload > > > the receiver > > > > or the network infrastructure and cause loss of syslog > > messages. > > > > > > > > 6.4 Sequenced Delivery > > > > > > > > The IP transport utilized by the UDP does not guarantee that > > the > > > > sequence of datagram delivery will match the order > in which the > > > > datagrams have been sent. The time stamp contained > > > within each syslog > > > > message may serve as some guide in establishing sequence > > > order, but > > > > it will not help in cases when multiple messages > were generated > > > > during the same time slot or when messages originated > > > from different > > > > hosts whose clocks are not synchronized. The order of > > > syslog message > > > > arrival via the this syslog transport SHOULD NOT be > used as an > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 14] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > authoritative guide in establishing the sequence of events on > > the > > > > syslog sender hosts. > > > > > > > > 6.5 Sender Authentication > > > > > > > > The UDP syslog transport does not strongly associate the > > > message with > > > > the message sender. The receiver of the syslog message > > > will not be > > > > able to ascertain that the message was indeed sent from > > > the reported > > > > sender, or if the packet was sent from another device. > > > > > > > > One possible consequence of this behavior is that a > > misconfigured > > > > machine may send syslog messages to a receiver > > > representing itself as > > > > another machine. The administrators may not be able > to readily > > > > discern that there are two or more machines representing > > > themselves > > > > as the same machine. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 15] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 7. Security Considerations > > > > > > > > Several syslog security considerations have been discussed in > > > > RFC-protocol [2] and in the original RFC 3164 [1]. > This section > > > > focuses on security considerations specific to the > > > syslog transport > > > > over UDP. > > > > > > > > 7.1 Message Authenticity > > > > > > > > This transport protocol does not strongly authenticate > > > the identity > > > > of the message sender and does not provide any assurance that > > the > > > > message was not modified in transit. The receiver of > the syslog > > > > message will not be able to ascertain that the message was > > indeed > > > > sent from the reported sender, or if the packet was sent > > > from another > > > > device. > > > > > > > > 7.2 Message Forgery > > > > > > > > Syslog messages can be easily forged. 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. > > > > > > > > Additionally, an attacker may generate false syslog > > > messages to give > > > > untrue indications of status or of events. 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 been restarted. > > > > > > > > 7.3 Message Observation > > > > > > > > The 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 those messages to > > > compromise a machine > > > > or do other damage. It is RECOMMENDED that no sensitive > > > information > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 16] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > is transmitted via this transport protocol or that > > > transmission of > > > > such information is restricted to properly secured networks. > > > > > > > > 7.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, that attacker may > > remove > > > > that machine from the network and replay the syslog > > > messages to the > > > > collector 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. > > > > > > > > 7.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. > > > > > > > > 7.6 Message Prioritization and Differentiation > > > > > > > > The transport protocol described in this document does > > > not require > > > > 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 messages. High severity > messages may > > > > contain indication about serious security problems, but > > > they will not > > > > get a higher priority. It is difficult to make sure that high > > > > severities messages get higher end-to-end delivery priority, > > > > especially over an unreliable UDP transport. > > > > > > > > On a case-by-case basis, device operators may find > some way to > > > > associate the different severity levels with the quality > > > of service > > > > identifiers. As an example, the operators may elect to > > > define some > > > > linkage between syslog messages that have a specific > > > Priority value > > > > with a specific value to be used in the IPv4 Precedence > > > field [4], > > > > the IPv6 Traffic Class octet [5], or the Differentiated > > Services > > > > field [9]. However, even with this prioritization on > > > the network, > > > > high load can lead to buffer starvation on the receiving host > > and > > > > result in dropped messages. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 17] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 7.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 only receiving syslog messages from known IP > > > > addresses. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 18] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 8. IANA Considerations > > > > > > > > IANA must reserve UDP port 514 for this transport. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 19] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 9. 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 20] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 10. Authors and Working Group Chair > > > > > > > > The working group can be contacted via the mailing list: > > > > > > > > syslog-sec@employees.org > > > > > > > > The current Chair of the Working Group may be contacted at: > > > > > > > > Chris Lonvick > > > > Cisco Systems > > > > Email: clonvick@cisco.com > > > > > > > > The author of this draft is: > > > > > > > > Anton Okmianski > > > > Email: aokmians@cisco.com > > > > > > > > Phone: (978) 936-1612 > > > > Fax: (978) 936-2225 > > > > > > > > Cisco Systems, Inc > > > > 1414 Massachusetts Ave. > > > > Boxborough, MA 01719-2205 > > > > USA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 21] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > 11. Acknowledgements > > > > > > > > The author wishes to thank Chris Lonvick, Rainer Gerhards, > > David > > > > Harrington, Andrew Ross, Albert Mietus, Bernie Volz, and > > > all others > > > > who have commented on the various versions of this proposal. > > > > > > > > 12 References > > > > > > > > [1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, > > > August 2001. > > > > > > > > [2] Gerhards, R., "The syslog Protocol", RFC RFC-protocol. > > > > > > > > [3] Postel, J., "User Datagram Protocol", STD 6, RFC > > > 768, August > > > > 1980. > > > > > > > > [4] Postel, J., "Internet Protocol", STD 5, RFC 791, > > September > > > > 1981. > > > > > > > > [5] Deering, S. and R. Hinden, "Internet Protocol, > > > Version 6 (IPv6) > > > > Specification", RFC 2460, December 1998. > > > > > > > > [6] Bradner, S., "Key words for use in RFCs to > > > Indicate Requirement > > > > Levels", BCP 14, RFC 2119, March 1997. > > > > > > > > [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax > > > > Specifications: ABNF", RFC 2234, November 1997. > > > > > > > > [8] Stevens, W., "TCP/IP Illustrated Volume 1. The > > Protocols.", > > > > January 1994. > > > > > > > > [9] Nichols, K., Blake, S., Baker, F. and D. Black, > > > "Definition of > > > > the Differentiated Services Field (DS Field) in > > > the IPv4 and > > > > IPv6 Headers", RFC 2474, December 1998. > > > > > > > > [10] Mockapetris, P., "Domain names - implementation and > > > > specification", STD 13, RFC 1035, November 1987. > > > > > > > > [11] Hedrick, C., "Routing Information Protocol", RFC 1058, > > June > > > > 1988. > > > > > > > > [12] Droms, R., "Dynamic Host Configuration Protocol", RFC > > 2131, > > > > March 1997. > > > > > > > > [13] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, > > RFC > > > > 1350, July 1992. > > > > > > > > [14] Braden, R., "Requirements for Internet Hosts - > > > Communication > > > > Layers", STD 3, RFC 1122, October 1989. > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 22] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > [15] Kent, C. and J. Mogul, ""Fragmentation Considered > > Harmful," > > > > Computer Communications Review, vol.17, no.5, > > pp.390-401", > > > > August 1987. > > > > > > > > > > > > Author's Address > > > > > > > > Anton Okmianski > > > > Cisco Systems, Inc. > > > > 1414 Massachusetts Ave > > > > Boxborough, MA 01719-2205 > > > > USA > > > > > > > > EMail: aokmians@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 23] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > Appendix A. Rational For Transport Message Size Restrictions > > > > > > > > This appendix provides the rational behind the Payload size > > > > restrictions for this protocol. The Payload > > > restrictions outlined in > > > > the specification, essentially ensure that the transport > > > message size > > > > does not exceed 512 bytes (without UDP/IP headers) for > > > transport via > > > > IPv4 and does not exceed 1196 bytes for transport via IPv6. > > These > > > > restrictions put an upper boundary on the UDP/IP > > > datagram size for > > > > this protocol, which accomplishes two goals. > > > > > > > > First, they insure interoperability between various UDP/IP > > > > implementations. Even though the maximum IP datagram size is > > > > specified as 65536 bytes, many UDP/IP implementations > > > have been shown > > > > not to work with large datagram sizes [8]. Many established > > > > UDP-based protocols restrict UDP datagram data size to > > > 512 bytes. For > > > > example, DNS [10] and RIP [11] do that. The DHCPv4 [12] > > > restricts the > > > > size to 512 bytes, but allows sides to agree on a > larger value > > > > through the protocol. The TFTP [13] restricts the UDP > > > data size to > > > > 518 bytes, which is slightly larger. > > > > > > > > The second reason for datagram size restrictions is that it > > helps > > > > reduce the likelihood of the IP-layer datagram > > > fragmentation. This > > > > could have potentially resulted in fragmentation on > two levels: > > > > syslog transport protocol and IP layer. Since > fragmentation has > > > > significant overhead for message reassembley, it is best to > > avoid > > > > double fragmentation. The likelihood of IP > fragmentation can be > > > > significantly reduced by sending IP datagrams in sizes which > > all > > > > hosts must be able to process. > > > > > > > > The minimum MTU of a transport protocol determines the > > > minimum size > > > > of packets that hosts must be able to accept. For IPv4, > > > the minimum > > > > MTU is 576 bytes [4] and for IPv6 - 1280 bytes [5]. In > > > both cases, > > > > the maximum message size we chose fits within the MTU of the > > > > transport in all cases except for when extremely large > > > IP headers are > > > > used. IPv4 header can range from 20 to 60 bytes in > > > length and UDP > > > > header is fixed at 8 bytes. Thus, our message size > restrictions > > > > ensure that in all cases except for when the IP header > > > is 56 bytes or > > > > greater, the size of the packet will within the size of > > > the transport > > > > MTU. > > > > > > > > For IPv6, we have left the same amount of padding for > > > UDP/IP headers > > > > as was conventionally done for IPv4 in DNS, RIP and > > > DHCPv4 with an > > > > additional padding of extra 20 bytes to accommodate a larger > > IPv6 > > > > header. This follows the methodology suggested in the IPv6 > > > > specification for calculating upper-layer payload limits [5]. > > > > > > > > Path MTU discovery can generally be used to discover the > > > MTU of the > > > > link. Unfortunately, using path MTU discovery with > UDP is not > > a > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 24] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > reliable option because it depends on routers providing > > > ICMP errors > > > > and hosts doing retransmission, which are not done > > consistently. > > > > Implementors MUST follow the size restrictions outlined > > > above and not > > > > rely on path MTU discovery. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 25] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > Intellectual Property Statement > > > > > > > > The IETF takes no position regarding the validity or scope of > > any > > > > intellectual property 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; neither does it > > > represent that it > > > > has made any effort to identify any such rights. > > > Information on the > > > > IETF's procedures with respect to rights in > standards-track and > > > > standards-related documentation can be found in > BCP-11. Copies > > of > > > > claims of rights made available for publication 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 implementors or users of this > > > specification can > > > > be obtained from the IETF Secretariat. > > > > > > > > The IETF invites any interested party to bring to its > > > attention any > > > > copyrights, patents or patent applications, or other > > proprietary > > > > rights which may cover technology that may be required > > > to practice > > > > this standard. Please address the information to the > > > IETF Executive > > > > Director. > > > > > > > > > > > > Full Copyright Statement > > > > > > > > Copyright (C) The Internet Society (2004). All > Rights Reserved. > > > > > > > > This document and translations of it may be copied and > > > furnished to > > > > others, and derivative works that comment on or > > > otherwise explain it > > > > or assist in its implementation may be prepared, copied, > > > published > > > > and distributed, in whole or in part, without restriction of > > any > > > > kind, provided that the above copyright notice and this > > > paragraph are > > > > included on all such copies and derivative works. > However, this > > > > document itself may not be modified in any way, such as > > > by removing > > > > the copyright notice or references to the Internet > > > Society or other > > > > Internet organizations, except as needed for the purpose of > > > > developing Internet standards in which case the > procedures for > > > > copyrights defined in the Internet Standards process must be > > > > followed, or as required to translate it into languages > > > other than > > > > English. > > > > > > > > The limited permissions granted above are perpetual and > > > will not be > > > > revoked by the Internet Society or its successors or > assignees. > > > > > > > > This document and the information contained herein is > > > provided on an > > > > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET > > > ENGINEERING > > > > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, > > > INCLUDING > > > > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 26] > > > > > > > > > > Internet-Draft syslog udp transport > > > May 2004 > > > > > > > > > > > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES > > OF > > > > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > > > > > > > Acknowledgment > > > > > > > > Funding for the RFC Editor function is currently provided by > > the > > > > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okmianski Expires November 5, 2004 > > > [Page 27] > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > TOC > > > > > > > > syslog Working Group A. Okmianski > > > > Internet-Draft Cisco Systems, Inc. > > > > Expires: November 5, 2004 May 7, 2004 > > > > > > > > Transmission of syslog > > > messages over > > > > UDP > > > > > > > > > > > > draft-ietf-syslog-transport-udp-01 > > > > > > > > Status of this Memo > > > > > > > > This document is an Internet-Draft and is in full > > > conformance with all > > > > provisions of Section 10 of RFC2026. > > > > > > > > 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 > > > > [2]http://www.ietf.org/ietf/1id-abstracts.txt. > > > > > > > > The list of Internet-Draft Shadow Directories can > > > be accessed at > > > > [3]http://www.ietf.org/shadow.html. > > > > > > > > This Internet-Draft will expire on November 5, 2004. > > > > > > > > Copyright Notice > > > > > > > > Copyright (C) The Internet Society (2004). All > Rights Reserved. > > > > > > > > Abstract > > > > > > > > This document describes the transport for the > > > syslog message over > > > > UDP/IPv4 or UDP/IPv6. While several transport mappings > > > are envisioned > > > > for the syslog protocol, syslog protocol implementors > > > are required to > > > > support the transport mapping described in this > > > document. This > > > > transport specification overcomes limitations of UDP/IP > > > datagram size > > > > by introducing support for fragmentation of large > > > messages using > > > > multiple datagrams. > > > > > > > _________________________________________________________________ > > > > > > > > Table of Contents > > > > > > > > [4]1. Introduction > > > > [5]2. Transport Protocol Overview > > > > [6]2.1 Definitions and Architecture > > > > [7]2.2 Required Transport Protocol > > > > [8]2.3 Encapsulation Layers > > > > [9]3. Message Format > > > > [10]3.1 Basic Header Format > > > > [11]3.2 Extended Header Format > > > > [12]3.2.1 Message Identifier > > > > [13]3.2.2 Total Length > > > > [14]3.2.3 Fragment Offset > > > > [15]3.2.4 Extended Header Example > > > > [16]3.3 Payload > > > > [17]3.4 Supported Message Length > > > > [18]4. UDP/IP Layer Considerations > > > > [19]4.1 Target Port > > > > [20]4.2 Source Port > > > > [21]4.3 Source IP Address > > > > [22]4.4 UDP/IP Headers > > > > [23]5. Fragmentation and Reassembley > > > > [24]5.1 Message Fragmentation > > > > [25]5.2 Message Reassembley > > > > [26]5.3 Avoiding Fragmentation > > > > [27]6. Reliability Considerations > > > > [28]6.1 Lost Datagrams > > > > [29]6.2 Message Corruption and Checksums > > > > [30]6.3 Congestion Control > > > > [31]6.4 Sequenced Delivery > > > > [32]6.5 Sender Authentication > > > > [33]7. Security Considerations > > > > [34]7.1 Message Authenticity > > > > [35]7.2 Message Forgery > > > > [36]7.3 Message Observation > > > > [37]7.4 Replaying > > > > [38]7.5 Unreliable Delivery > > > > [39]7.6 Message Prioritization and Differentiation > > > > [40]7.7 Denial of Service > > > > [41]8. IANA Considerations > > > > [42]9. Notice to RFC Editor > > > > [43]10. Authors and Working Group Chair > > > > [44]11. Acknowledgements > > > > [45]§. References > > > > [46]§ Author's Address > > > > [47]A. Rational For Transport Message Size Restrictions > > > > [48]§ Intellectual Property and Copyright Statements > > > > > > > _________________________________________________________________ > > > > > > > > > > > [49] > > > > TOC > > > > > > > > 1. Introduction > > > > > > > > The original syslog protocol has been described in an > > > informational > > > > [50]RFC 3164Lonvick, C., The BSD Syslog Protocol, > > > August 2001.[1] as > > > > it has been observed in existing implementations. It > > > describes both > > > > the semantics of syslog message format as well as a > > > UDP transport. > > > > Subsequently, the syslog protocol has been > > > formally defined in a > > > > standards track [51]RFC-protocolGerhards, R., The > > > syslog Protocol, > > > > .[2]. > > > > > > > > The [52]RFC-protocolGerhards, R., The syslog > > > Protocol, .[2] has > > > > provided for support of any number of transport layer > > > protocols for > > > > transmitting syslog messages and left it to subsequent > > > RFCs to specify > > > > transport protocols. This standards track RFC > > > describes the UDP > > > > transport for the syslog protocol. This transport > > > protocol is REQUIRED > > > > for all syslog protocol implementations. > > > > > > > > This transport protocol was designed to work on > > > top of UDP > > > > [53][3]Postel, J., User Datagram Protocol, August 1980. > > > over both IPv4 > > > > [54][4]Postel, J., Internet Protocol, September > > > 1981. and IPv6 > > > > [55][5]Deering, S. and R. Hinden, Internet Protocol, > > > Version 6 (IPv6) > > > > Specification, December 1998.. This protocol overcomes > > > the data size > > > > restrictions of the UDP protocol by introducing message > > > fragmentation > > > > feature. > > > > > > > > As we will show in this specification, this protocol > > > has significant > > > > reliability and security issues stemming from the use of > > > UDP. However, > > > > this protocol is lightweight and extends on the > > > existing popular use > > > > of UDP for syslog. Network administrators and > > > architects should be > > > > aware of the shortcomings of this protocol and plan > > accordingly. > > > > > > > > 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 > > > [56]RFC 2119Bradner, > > > > S., Key words for use in RFCs to Indicate Requirement > > > Levels, March > > > > 1997.[6]. The words 'byte' and 'octet' are used > > > interchangeably in > > > > this specification. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [57] > > > > TOC > > > > > > > > 2. Transport Protocol Overview > > > > > > > > 2.1 Definitions and Architecture > > > > > > > > The following definitions will be used in this document: > > > > * An application that can generate syslog messages > > > will be referred > > > > to as a "sender"; > > > > * An application that can receive syslog messages > > > will be referred > > > > to as a "receiver". > > > > > > > > An application can function in dual capacity. For > > > example, a syslog > > > > relay may receive and forward messages. A single > > > system can host any > > > > number of syslog senders. Only one syslog receiver can > > > be hosted on a > > > > single system using the standard listening port. > > > > > > > > 2.2 Required Transport Protocol > > > > > > > > This document describes the UDP transport layer > > > protocol for the > > > > syslog protocol [58]RFC-protocolGerhards, R., The > > > syslog Protocol, > > > > .[2]. Every syslog sender and receiver implementation > > > which adheres to > > > > the [59]RFC-protocolGerhards, R., The syslog Protocol, > > > .[2] MUST fully > > > > implement the transport protocol specified in > > > this document. > > > > Implementations does not have to support both IPv4 and > > > IPv6 if it is > > > > designed to be used over only one of these protocols. > > > > > > > > 2.3 Encapsulation Layers > > > > > > > > Syslog UDP transport carries syslog messages as > > > generic payload > > > > encapsulated with a syslog transport header, UDP > > > header and an IP > > > > header. Below is a summary of syslog UDP/IP packet > > > structure as used > > > > this transport protocol: > > > > > > > > +--------------------------------+ > > > > | IPv4 or IPv6 Header | > > > > | (20 or more bytes) | > > > > +--------------------------------+ > > > > | UDP Header | > > > > | (8 bytes) | > > > > +--------------------------------+ > > > > | Syslog Transport Header | > > > > | (5 or 32 bytes) | > > > > +--------------------------------+ > > > > | Syslog Message Payload | > > > > | (1 to 1191 bytes) | > > > > +--------------------------------+ > > > > > > > > Small syslog messages are transmitted using one > > > UDP/IP datagram per > > > > message. However, syslog protocol [60][2]Gerhards, > > > R., The syslog > > > > Protocol, . allows messages as large as 16777216 > > > bytes, while UDP/IP > > > > datagram cannot exceed a total size of 65526 bytes > > > [61][3]Postel, J., > > > > User Datagram Protocol, August 1980. and most > > > existing protocols > > > > restrict the size of UDP data to much less. In > > > order to support > > > > transmitting large messages over UDP/IP, this > > > transport protocol > > > > supports fragmentation of large syslog messages into > > > multiple UDP/IP > > > > datagrams for transmission and reassembley on the receiving > > end. > > > > > > > > Each syslog UDP/IP datagram MUST contain one and > > > only one complete > > > > syslog message or one fragment of a message. > > > Transmitting multiple > > > > messages or multiple fragments of different messages > > > in a single UDP > > > > datagram is not supported by this protocol. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [62] > > > > TOC > > > > > > > > 3. Message Format > > > > > > > > The syslog transport message consist of a > > > transport header and a > > > > syslog message payload. The format of the > > > transport header is > > > > different for fragmented and non-fragmented messages. > > > Basic transport > > > > header is used for non-fragmented messages and > > > extended transport > > > > header is used for fragmented messages. > > > > > > > > An ASCII-based encoding was chosen for the syslog > > > transport for > > > > consistency with the [63]RFC-protocolGerhards, > > > R., The syslog > > > > Protocol, .[2]. Syslog transport datagrams without > > > required UDP and IP > > > > headers have the following format in > > > [64]ABNFCrocker, D. and P. > > > > Overell, Augmented BNF for Syntax Specifications: > > > ABNF, November > > > > 1997.[7] notation: > > > > > > > > SyslogTransportMessage = ( BasicHeader / ExtendedHeader ) > > > > SP Payload > > > > > > > > BasicHeader = Version SP "0" > > > > Version = %d118 1*3DIGIT ; "v1" in this version > > > > > > > > ExtendedHeader = Version SP "1" SP MessageId > > > > SP TotalLength SP FragmentOffset > > > > > > > > MessageId = 1*8DIGIT ; 0 to 16777215 > > > > TotalLength = 1*8DIGIT ; 1 to 16777216 > > > > FragmentOffset = 1*8DIGIT ; 0 to 16777215 > > > > Payload = 1*1191OCTET > > > > > > > > OCTET = %d00-255 > > > > DIGIT = %d48-57 > > > > SP = %d32 > > > > > > > > > > > > 3.1 Basic Header Format > > > > > > > > When no fragmentation is used and the entire > > > syslog message is > > > > transferred as a single UDP/IP datagram, a basic > > > syslog transport > > > > header MUST be used. The version for this protocol is > > > "1". It must be > > > > followed by one space and a "0" to indicate that > > > this is a basic > > > > header. Therefore, the only possible value for the > > > basic header in > > > > this protocol is as follows: > > > > > > > > "v1 0 " > > > > > > > > Example of a syslog message without the transport > > > header (message is > > > > wrapped for display): > > > > > > > > "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com > > > > dns: configuration error" > > > > > > > > Example of the same message with the transport > > > header (message is > > > > wrapped for display): > > > > > > > > "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com > > > > dns: configuration error" > > > > > > > > 3.2 Extended Header Format > > > > > > > > When syslog message is fragmented by the sender, > > > multiple UDP > > > > datagrams must be used and each datagram MUST > > > contain an extended > > > > syslog transport header. The version for this > > > protocol is "1". The > > > > version field MUST be followed by a single space and a > > > "1" to indicate > > > > that this is an extended header. Thus, an extended > > > header MUST always > > > > begin with "v1 1 ", but MUST also have additional > > > fields which aid in > > > > fragmentation. > > > > > > > > The MessageId, TotalLength and FragmentOffset fields > > > are used solely > > > > for fragmentation of long messages and reassembley. They > > > SHOULD NOT be > > > > used for other purposes. > > > > > > > > 3.2.1 Message Identifier > > > > > > > > The MessageId field (along with the source UDP > > > port and the IP > > > > address) is used to identify the message such that > > > fragments of a > > > > single syslog message can be reassembled by the > > > receiver into a > > > > complete message. The MessageId field MUST be a > > > numeric value in the > > > > range of 0 to 16777215. Leading zeros MUST not be > > > present in the > > > > MessageId field. > > > > > > > > Each syslog sender process MUST choose a random > > > MessageId value within > > > > the supported range for its first message. > > > Subsequent messages > > > > generated by the same process MUST each increment the > > > MessageId by 1 > > > > up to 16777215 and then continue at 0. Using random > > > value for the > > > > first MessageId helps reduce the possibility of > > > potential errors in > > > > message reassembley. Refer to discussion about > > > [65]message > > > > reassembleyMessage Reassembley for more details. > > > > > > > > All datagrams which represent parts of a given > > > fragmented syslog > > > > message MUST have the same MessageId value. > > > > > > > > 3.2.2 Total Length > > > > > > > > The TotalLength field MUST be a numeric value in the > > > range of 1 to > > > > 16777216. It MUST indicate the length of a complete > > > syslog message > > > > before it was fragmented and before it was encapsulated > > > with transport > > > > headers. The same TotalLength field value MUST be > > > present in all UDP > > > > datagrams which represent fragments of the same > > > syslog message. > > > > Leading zeros MUST not be present in the TotalLength field. > > > > > > > > Note that in IPv4 the "total length" field identifies > > > the length of a > > > > single packet. In this protocol, the TotalLength > > > field is used to > > > > identify the total length of a complete syslog > > > message, which is > > > > transmitted using multiple fragments and multiple > > > datagram packets. > > > > The fragment length is not specified in the transport > > > header because > > > > it can be inferred from the size of the IP packet > > > containing the UDP > > > > datagram. > > > > > > > > 3.2.3 Fragment Offset > > > > > > > > The FragmentOffset field MUST be a numeric value in the > > > range of 0 to > > > > 16777215. It MUST indicate the byte offset of the > > > fragment data in the > > > > complete syslog message. The offset index starts at 0 > > > for the first > > > > fragment. For example, if an 700 byte syslog message > > > is fragmented > > > > into 480 and 220 byte parts, the FragmentOffset in the > > > first message > > > > will be 0 and in the second - 480. Note that fragments > > > don't have to > > > > be the same size. Leading zeros MUST not be > > > present in the > > > > FragmentOffset field. > > > > > > > > 3.2.4 Extended Header Example > > > > > > > > The following is an example of a syslog message without > > > the transport > > > > header (message is wrapped for display): > > > > > > > > "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com > > > > dns: configuration error" > > > > > > > > Suppose this message had to be fragmented by transport > > > layer into two > > > > parts at an arbitrary point. This would result in > > > two separate UDP > > > > datagrams being sent - one for each fragment. Below is > > > the content of > > > > each of the syslog transport UDP messages with > > > syslog transport > > > > headers but without UDP/IP headers: > > > > > > > > "v1 1 45612221 74 0 v1 888 4 > 2003-10-11T22:14:15.003Z host.dom" > > > > > > > > "v1 1 45612221 74 42 ain.com dns: configuration error" > > > > > > > > In the above example, the leading "v1" is the version of > > > the transport > > > > protocol, "1" indicates that this is an extended header > > > (fragmentation > > > > in use), "45612221" is the MessageId, "74" is the > > > TotalLength of the > > > > message, while "0" and "42" are FragmentOffset > > > fields. Everything > > > > following the FragmentOffset and a space is a the > > > Payload of each > > > > respective message. > > > > > > > > 3.3 Payload > > > > > > > > The Payload field of the syslog UPD transport > > > message is an entire > > > > syslog message or one fragment. The maximum Payload > > > size depends on > > > > the IP protocol used and the type header that is used. > > > > Maximum Payload size: > > > > > > > > With IPv4 and basic header: 507 bytes > > > > With IPv4 and extended header: 480 bytes > > > > > > > > With IPv6 and basic header: 1191 bytes > > > > With IPv6 and extended header: 1164 bytes > > > > > > > > The Payload size restrictions above effectively mean > > > that the largest > > > > syslog message that can be sent non-fragmented is > > > 507 bytes for > > > > transport via IPv4 and 1191 bytes for transport via IPv6. > > > > > > > > For a discussion of the relational behind the above > > > size restrictions > > > > please refer to Appendix A. > > > > > > > > 3.4 Supported Message Length > > > > > > > > The maximum syslog message length supported by this > > > protocol is the > > > > maximum value of the TotalLength field, which is > > > 16777216 bytes. > > > > However, not all deployment scenarios for syslog will be > > > on hosts with > > > > hardware capable of supporting the maximum length > > > of messages > > > > supported by this protocol. Additionally, extremely > > > large messages may > > > > not be needed in many environments. Therefore, > > > implementations are NOT > > > > REQUIRED to support the maximum message length > > > allowed by this > > > > protocol. > > > > > > > > All implementations MUST support sending and receiving > > > syslog messages > > > > up to and including 65536 bytes in size (syslog > > > transport and UDP/IP > > > > headers are extra). Support for larger messages > > > is encouraged. > > > > Implementors SHOULD clearly state the maximum > > > supported message size > > > > in documentation. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [66] > > > > TOC > > > > > > > > 4. UDP/IP Layer Considerations > > > > > > > > 4.1 Target Port > > > > > > > > Syslog receivers MUST support accepting syslog message > > > datagrams on a > > > > well-known UDP port 514. Syslog senders MUST support > > > sending syslog > > > > message datagrams to the UDP port 514. > > > > > > > > 4.2 Source Port > > > > > > > > Syslog senders can use any source UDP port for > > > transmitting messages. > > > > Senders MAY randomly select a source port, but MUST use > > > the port in an > > > > exclusive fashion. No concurrent port reuse on > > > the same host is > > > > allowed. > > > > > > > > Each syslog sender process MUST attempt to use the > > > same source port > > > > for the life of the the process. If due to an error or > > > other condition > > > > it becomes impossible for the process to continue > > > to use the same > > > > port, it MAY start using a new source port, but it MUST > > > generate a new > > > > random MessageId for the first message after > > > changing the port and > > > > then MUST continue incrementing the new MessageId value > > > for subsequent > > > > messages. > > > > > > > > Since source port is used to identify parts of a > > > fragmented message, > > > > the sender MUST use the same port to send all > > > fragments of a given > > > > message. If due to an error or other condition, the > > > sender is unable > > > > to do that, it MUST resend all message fragments > > > using the new port > > > > and a new MessageId field value. > > > > > > > > 4.3 Source IP Address > > > > > > > > The source IP address of the UDP datagrams is one of the > > > data elements > > > > used to identify parts of a fragmented message. > > > Therefore, a syslog > > > > sender MUST attempt to use the same source IP > > > address to send all > > > > fragments of a given syslog message. If due > > > to an error, > > > > reconfiguration or other condition it is unable to do > > > so, the sender > > > > MUST resend all fragments of the syslog message using > > > the new source > > > > IP address and a new MessageId value. > > > > > > > > 4.4 UDP/IP Headers > > > > > > > > Each UDP/IP datagram sent by the transport layer > > > MUST completely > > > > adhere to the structure specified in the UDP [67]RFC > > > 768Postel, J., > > > > User Datagram Protocol, August 1980.[3] and either > > > IPv4 [68]RFC > > > > 791Postel, J., Internet Protocol, September 1981.[4] > > > or IPv6 [69]RFC > > > > 2640Deering, S. and R. Hinden, Internet Protocol, > > > Version 6 (IPv6) > > > > Specification, December 1998.[5] depending on which > protocol is > > > > > > used. > > > > > > > > Use of UDP checksums was defined as optional in [70]RFC > > > 768Postel, J., > > > > User Datagram Protocol, August 1980.[3]. IPv6 has > > > subsequently made > > > > UDP checksums required [71][5]Deering, S. and R. > > > Hinden, Internet > > > > Protocol, Version 6 (IPv6) Specification, December > > > 1998.. However, > > > > syslog senders MUST utilize valid UDP checksums when > > > sending messages > > > > over either IPv4 or IPv6. Syslog receivers MUST check > > > for checksums > > > > and discard messages with incorrect checksums. > > > Note that this is > > > > typically accomplished by the UDP layer > > > implementation, and some > > > > implementations allow for checksum checks to be enabled or > > > > disabled. > > > > > > > > Enabling use of checksums serves as an extra measure > > > of corruption > > > > detection in addition to checksums performed by > > > IP and Ethernet > > > > layers. None of the above checksums provide a > > > complete guarantee of > > > > corruption detection. Utilizing checksums on multiple > > > layers reduces > > > > the chance of corruption error not being detected. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [72] > > > > TOC > > > > > > > > 5. Fragmentation and Reassembley > > > > > > > > 5.1 Message Fragmentation > > > > > > > > The syslog transport layer MUST perform > > > fragmentation if syslog > > > > message size exceeds the maximum allowed Payload size. > > > Fragmentation > > > > SHOULD NOT be used if message can fit into the maximum > > > allowed Payload > > > > size. > > > > > > > > Syslog messages SHOULD be fragmented such that all > > > but last message > > > > utilize the Payload to its maximum capacity. For > > > example, when using > > > > IPv4, a 700 byte syslog message SHOULD be fragmented > > > into 480 and 220 > > > > byte parts because the maximum Payload size with > > > IPv4 and extended > > > > header is 480 bytes. > > > > > > > > Each message fragment MUST be sent as a separate UDP/IP > > > datagram with > > > > an extended syslog transport header. The sender > > > MUST use the same > > > > MessageId value, source port and source IP address for > > > all fragments > > > > of a given message. These three field together > > > uniquely identify > > > > fragments belonging to a given message. > > > > > > > > On a system with short-lived sender processes, it may be > > > possible that > > > > fragments with the same MessageId value, source port > > > and source IP > > > > address will get generated in short time > > > proximity. This can be > > > > possible because a new process may re-use the source > > > port that was > > > > freed up by another process that just dies. Such > > > behavior could > > > > confuse the receiver if the datagrams were received > > > out of order or > > > > some datagrams got lost. > > > > > > > > In order to reduce the risk of such mistaken identity > > > errors, section > > > > 3.2.1 specified that each process must start with a > > > random value for > > > > MessageId field. Given a relatively large range of > > > MessageId values > > > > and the unlikely event of a coincidence of having the > > > same MessageId > > > > value combined with re-used source port and UPD errors, > > > the window for > > > > potential mistaken identity errors during message > > > reassembley is very > > > > small and tolerable. The users take a greater risk > > > by using this > > > > protocol due to general UDP reliability issues discussed > > > later in this > > > > specification. > > > > > > > > 5.2 Message Reassembley > > > > > > > > The reassembley process uses the source IP address from > > > the IP header, > > > > the source port from the UDP header and the MessageId > > > field value to > > > > identify fragments of a given message. It then > > > uses data from > > > > TotalLength and FragmentOffset fields to re-assemble > > > fragments into a > > > > complete message. > > > > > > > > Typically, an implementation of fragmentation > > > reassembley involves > > > > allocating a buffer for the message when any > > > fragment with a new > > > > combination of source IP address, source port and > > > MessageId is > > > > received. A timer is used to expire the message > > > reassembley and clean > > > > the buffer if all fragments are not received in > > > certain time period. > > > > As each fragment is received, it is placed into the > > > buffer at the > > > > appropriate offset and a check is performed to > > > determine if all > > > > fragments have been received using additional data > structures. > > > > > > > > The receiver SHOULD make the timeout interval > > > used for message > > > > reassembley configurable for the administrator. The > > > receiver SHOULD > > > > also be able to limit the total amount of memory used > > > for buffers such > > > > that it does not run out of resources under a simple > > > denial of service > > > > attack involving just one message fragment with a > > > large TotalLength > > > > field value. Degrading the service under heavy > > > load or attack is > > > > better than crashing and potentially making the > > > service completely > > > > unavailable. > > > > > > > > 5.3 Avoiding Fragmentation > > > > > > > > Fragmentation and reassembley of messages > > > incurs substantial > > > > processing overhead on both the sender and the receiver > > > hosts. It also > > > > increases the risk of lost messages due to lose of just > > > one fragment. > > > > It is RECOMMENDED that syslog senders which > > > anticipate sending > > > > messages over this transport protocol attempt to reduce > > > the number of > > > > messages which require fragmentation by restricting > > > them to the size > > > > which does not require fragmentation. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [73] > > > > TOC > > > > > > > > 6. Reliability Considerations > > > > > > > > The UDP is an unreliable low-overhead protocol. This > > > section discusses > > > > reliability issues inherent in the UDP that > > > implementers and users > > > > must be aware of. > > > > > > > > 6.1 Lost Datagrams > > > > > > > > Neither UDP nor syslog protocol 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. > > > > Syslog protocol and IP fragmentation exacerbates the > > > problem because > > > > loss of a single fragment would result in 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 some datagram may have > > > been lost, it MAY > > > > retransmit previously sent messages. > > > > > > > > 6.2 Message Corruption and Checksums > > > > > > > > The UDP/IP datagrams may get corrupted in transit > > > due to software, > > > > hardware or network errors. This protocol > > > specified use of UDP > > > > checksums to enable corruption detection in > > > addition to checksums > > > > utilized in IP and Ethernet layers. However, > > > checksums do not > > > > guarantee corruption detection and this protocol does > > > not provide for > > > > message retransmission when a corrupt message is detected. > > > > > > > > 6.3 Congestion Control > > > > > > > > The UDP does not provide for congestion control. Some > > > systems (hosts > > > > or routers) may generate ICMP source quench error, > > > but they are not > > > > required to do so [74][8]Stevens, W., TCP/IP Illustrated > > > Volume 1. The > > > > Protocols., January 1994.. Any network host can > > > discard UDP packets > > > > when it is overloaded. Due to lack of congestion > > > control one or > > > > multiple syslog senders can maliciously or > > > inadvertently overload the > > > > receiver or the network infrastructure and cause > > > loss of syslog > > > > messages. > > > > > > > > 6.4 Sequenced Delivery > > > > > > > > The IP transport utilized by the UDP does not > > > guarantee that the > > > > sequence of datagram delivery will match the > > > order in which the > > > > datagrams have been sent. The time stamp contained > > > within each syslog > > > > message may serve as some guide in establishing sequence > > > order, but it > > > > will not help in cases when multiple messages were > > > generated during > > > > the same time slot or when messages originated from > > > different hosts > > > > whose clocks are not synchronized. The order of syslog > > > message arrival > > > > via the this syslog transport SHOULD NOT be used as an > > > authoritative > > > > guide in establishing the sequence of events on the > > > syslog sender > > > > hosts. > > > > > > > > 6.5 Sender Authentication > > > > > > > > The UDP syslog transport does not strongly associate > > > the message with > > > > the message sender. The receiver of the syslog > > > message will not be > > > > able to ascertain that the message was indeed sent > > > from the reported > > > > sender, or if the packet was sent from another device. > > > > > > > > One possible consequence of this behavior is that a > > > misconfigured > > > > machine may send syslog messages to a receiver > > > representing itself as > > > > another machine. The administrators may not be able to > > > readily discern > > > > that there are two or more machines representing > > > themselves as the > > > > same machine. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [75] > > > > TOC > > > > > > > > 7. Security Considerations > > > > > > > > Several syslog security considerations have been > > > discussed in > > > > [76]RFC-protocolGerhards, R., The syslog Protocol, > > > .[2] and in the > > > > original [77]RFC 3164Lonvick, C., The BSD Syslog > > > Protocol, August > > > > 2001.[1]. This section focuses on security > > > considerations specific to > > > > the syslog transport over UDP. > > > > > > > > 7.1 Message Authenticity > > > > > > > > This transport protocol does not strongly authenticate > > > the identity of > > > > the message sender and does not provide any assurance > > > that the message > > > > was not modified in transit. The receiver of the > > > syslog message will > > > > not be able to ascertain that the message was indeed > > > sent from the > > > > reported sender, or if the packet was sent from > another device. > > > > > > > > 7.2 Message Forgery > > > > > > > > Syslog messages can be easily forged. 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. > > > > > > > > Additionally, an attacker may generate false syslog > > > messages to give > > > > untrue indications of status or of events. 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 been restarted. > > > > > > > > 7.3 Message Observation > > > > > > > > The 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 those messages to compromise a > > > machine or do > > > > other damage. It is RECOMMENDED that no sensitive > > > information is > > > > transmitted via this transport protocol or that > > > transmission of such > > > > information is restricted to properly secured networks. > > > > > > > > 7.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, that attacker may > > > remove that machine > > > > from the network and replay the syslog messages to the > > > collector 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. > > > > > > > > 7.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. > > > > > > > > 7.6 Message Prioritization and Differentiation > > > > > > > > The transport protocol described in this document > > > does not require > > > > 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 messages. High severity > > > messages may contain > > > > indication about serious security problems, but they > > > will not get a > > > > higher priority. It is difficult to make sure that > > > high severities > > > > messages get higher end-to-end delivery priority, > > > especially over an > > > > unreliable UDP transport. > > > > > > > > On a case-by-case basis, device operators may > > > find some way to > > > > associate the different severity levels with the > > > quality of service > > > > identifiers. As an example, the operators may elect > > > to define some > > > > linkage between syslog messages that have a specific > > > Priority value > > > > with a specific value to be used in the IPv4 > > > Precedence field > > > > [78][4]Postel, J., Internet Protocol, September > > > 1981., the IPv6 > > > > Traffic Class octet [79][5]Deering, S. and R. > > > Hinden, Internet > > > > Protocol, Version 6 (IPv6) Specification, December > > > 1998., or the > > > > Differentiated Services field [80][9]Nichols, K., Blake, > > > S., Baker, F. > > > > and D. Black, Definition of the Differentiated > > > Services Field (DS > > > > Field) in the IPv4 and IPv6 Headers, December 1998.. > > > However, even > > > > with this prioritization on the network, high load can > > > lead to buffer > > > > starvation on the receiving host and result in dropped > > messages. > > > > > > > > 7.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 only receiving syslog messages from known > > > IP addresses. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [81] > > > > TOC > > > > > > > > 8. IANA Considerations > > > > > > > > IANA must reserve UDP port 514 for this transport. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [82] > > > > TOC > > > > > > > > 9. 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. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [83] > > > > TOC > > > > > > > > 10. Authors and Working Group Chair > > > > > > > > The working group can be contacted via the mailing list: > > > > syslog-sec@employees.org > > > > > > > > The current Chair of the Working Group may be contacted > > > at: Chris > > > > Lonvick Cisco Systems > > > > Email: clonvick@cisco.com > > > > > > > > The author of this draft is: > > > > Anton Okmianski > > > > Email: aokmians@cisco.com > > > > > > > > Phone: (978) 936-1612 > > > > Fax: (978) 936-2225 > > > > > > > > Cisco Systems, Inc > > > > 1414 Massachusetts Ave. > > > > Boxborough, MA 01719-2205 > > > > USA > > > > > > > _________________________________________________________________ > > > > > > > > > > > [84] > > > > TOC > > > > > > > > 11. Acknowledgements > > > > > > > > The author wishes to thank Chris Lonvick, Rainer > > > Gerhards, David > > > > Harrington, Andrew Ross, Albert Mietus, Bernie Volz, > > > and all others > > > > who have commented on the various versions of this proposal. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [85] > > > > TOC > > > > > > > > 12 References > > > > > > > > [1] Lonvick, C., "[86]The BSD Syslog Protocol", RFC > > > 3164, August 2001. > > > > [2] Gerhards, R., "[87]The syslog Protocol", RFC > RFC-protocol. > > > > [3] Postel, J., "[88]User Datagram Protocol", STD 6, RFC > > > 768, August > > > > 1980. > > > > [4] Postel, J., "[89]Internet Protocol", STD 5, RFC > > > 791, September > > > > 1981. > > > > [5] [90]Deering, S. and [91]R. Hinden, "[92]Internet > > > Protocol, Version > > > > 6 (IPv6) Specification", RFC 2460, December 1998 > > > ([93]HTML, [94]XML). > > > > [6] [95]Bradner, S., "[96]Key words for use in > > > RFCs to Indicate > > > > Requirement Levels", BCP 14, RFC 2119, March 1997 > > > ([97]HTML, [98]XML). > > > > [7] [99]Crocker, D. and [100]P. Overell, > > > "[101]Augmented BNF for > > > > Syntax Specifications: ABNF", RFC 2234, November 1997. > > > > [8] Stevens, W., "TCP/IP Illustrated Volume 1. > > > The Protocols.", > > > > January 1994. > > > > [9] [102]Nichols, K., [103]Blake, S., [104]Baker, > > > F. and [105]D. > > > > Black, "[106]Definition of the Differentiated > > > Services Field (DS > > > > Field) in the IPv4 and IPv6 Headers", RFC 2474, > > > December 1998 > > > > ([107]HTML, [108]XML). > > > > [10] Mockapetris, P., "[109]Domain names - > > > implementation and > > > > specification", STD 13, RFC 1035, November 1987. > > > > [11] Hedrick, C., "[110]Routing Information Protocol", > > > RFC 1058, June > > > > 1988. > > > > [12] [111]Droms, R., "[112]Dynamic Host Configuration > > > Protocol", RFC > > > > 2131, March 1997 ([113]HTML, [114]XML). > > > > [13] [115]Sollins, K., "[116]The TFTP Protocol > > > (Revision 2)", STD 33, > > > > RFC 1350, July 1992. > > > > [14] [117]Braden, R., "[118]Requirements for > > > Internet Hosts - > > > > Communication Layers", STD 3, RFC 1122, October 1989. > > > > [15] Kent, C. and J. Mogul, ""Fragmentation > > > Considered Harmful," > > > > Computer Communications Review, vol.17, no.5, > > > pp.390-401", August > > > > 1987. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [119] > > > > TOC > > > > > > > > Author's Address > > > > > > > > Anton Okmianski > > > > Cisco Systems, Inc. > > > > 1414 Massachusetts Ave > > > > Boxborough, MA 01719-2205 > > > > USA > > > > EMail: aokmians@cisco.com > > > > > > > _________________________________________________________________ > > > > > > > > > > > [120] > > > > TOC > > > > > > > > Appendix A. Rational For Transport Message Size Restrictions > > > > > > > > This appendix provides the rational behind the > > > Payload size > > > > restrictions for this protocol. The Payload > > > restrictions outlined in > > > > the specification, essentially ensure that the > > > transport message size > > > > does not exceed 512 bytes (without UDP/IP headers) for > > > transport via > > > > IPv4 and does not exceed 1196 bytes for transport > > > via IPv6. These > > > > restrictions put an upper boundary on the UDP/IP > > > datagram size for > > > > this protocol, which accomplishes two goals. > > > > > > > > First, they insure interoperability between > > > various UDP/IP > > > > implementations. Even though the maximum IP datagram > > > size is specified > > > > as 65536 bytes, many UDP/IP implementations have > > > been shown not to > > > > work with large datagram sizes [121][8]Stevens, W., > > > TCP/IP Illustrated > > > > Volume 1. The Protocols., January 1994.. Many > > > established UDP-based > > > > protocols restrict UDP datagram data size to 512 > > > bytes. For example, > > > > DNS [122][10]Mockapetris, P., Domain names - > > > implementation and > > > > specification, November 1987. and RIP > > > [123][11]Hedrick, C., Routing > > > > Information Protocol, June 1988. do that. The DHCPv4 > > > [124][12]Droms, > > > > R., Dynamic Host Configuration Protocol, March 1997. > > > restricts the > > > > size to 512 bytes, but allows sides to agree on a larger > > > value through > > > > the protocol. The TFTP [125][13]Sollins, K., The > > > TFTP Protocol > > > > (Revision 2), July 1992. restricts the UDP data size > > > to 518 bytes, > > > > which is slightly larger. > > > > > > > > The second reason for datagram size restrictions is > > > that it helps > > > > reduce the likelihood of the IP-layer datagram > > > fragmentation. This > > > > could have potentially resulted in fragmentation on two > > > levels: syslog > > > > transport protocol and IP layer. Since fragmentation > > > has significant > > > > overhead for message reassembley, it is best to > > > avoid double > > > > fragmentation. The likelihood of IP fragmentation can be > > > significantly > > > > reduced by sending IP datagrams in sizes which all > > > hosts must be able > > > > to process. > > > > > > > > The minimum MTU of a transport protocol determines the > > > minimum size of > > > > packets that hosts must be able to accept. For IPv4, > > > the minimum MTU > > > > is 576 bytes [126][4]Postel, J., Internet Protocol, > > > September 1981. > > > > and for IPv6 - 1280 bytes [127][5]Deering, S. and R. > > > Hinden, Internet > > > > Protocol, Version 6 (IPv6) Specification, December > > > 1998.. In both > > > > cases, the maximum message size we chose fits within > > > the MTU of the > > > > transport in all cases except for when extremely large > > > IP headers are > > > > used. IPv4 header can range from 20 to 60 bytes in > > > length and UDP > > > > header is fixed at 8 bytes. Thus, our message size > > > restrictions ensure > > > > that in all cases except for when the IP header > > > is 56 bytes or > > > > greater, the size of the packet will within the size of > > > the transport > > > > MTU. > > > > > > > > For IPv6, we have left the same amount of padding for > > > UDP/IP headers > > > > as was conventionally done for IPv4 in DNS, RIP and > > > DHCPv4 with an > > > > additional padding of extra 20 bytes to accommodate > > > a larger IPv6 > > > > header. This follows the methodology suggested > > > in the IPv6 > > > > specification for calculating upper-layer > > > payload limits > > > > [128][5]Deering, S. and R. Hinden, Internet Protocol, > > > Version 6 (IPv6) > > > > Specification, December 1998.. > > > > > > > > Path MTU discovery can generally be used to discover > > > the MTU of the > > > > link. Unfortunately, using path MTU discovery with > > > UDP is not a > > > > reliable option because it depends on routers > > > providing ICMP errors > > > > and hosts doing retransmission, which are not done > > > consistently. > > > > Implementors MUST follow the size restrictions outlined > > > above and not > > > > rely on path MTU discovery. > > > > > > > _________________________________________________________________ > > > > > > > > > > > [129] > > > > TOC > > > > > > > > Intellectual Property Statement > > > > > > > > The IETF takes no position regarding the validity > > > or scope of any > > > > intellectual property 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; neither does it represent that > > > it has made any > > > > effort to identify any such rights. Information > > > on the IETF's > > > > procedures with respect to rights in > > > standards-track and > > > > standards-related documentation can be found in > > > BCP-11. Copies of > > > > claims of rights made available for publication 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 implementors or users of this specification > > > can be obtained > > > > from the IETF Secretariat. > > > > > > > > The IETF invites any interested party to bring to its > > > attention any > > > > copyrights, patents or patent applications, or > > > other proprietary > > > > rights which may cover technology that may be > > > required to practice > > > > this standard. Please address the information to the > > > IETF Executive > > > > Director. > > > > > > > > Full Copyright Statement > > > > > > > > Copyright (C) The Internet Society (2004). All > Rights Reserved. > > > > > > > > This document and translations of it may be copied > > > and furnished to > > > > others, and derivative works that comment on or > > > otherwise explain it > > > > or assist in its implementation may be prepared, copied, > > > published and > > > > distributed, in whole or in part, without > > > restriction of any kind, > > > > provided that the above copyright notice and this > > > paragraph are > > > > included on all such copies and derivative works. > > > However, this > > > > document itself may not be modified in any way, such > > > as by removing > > > > the copyright notice or references to the Internet > > > Society or other > > > > Internet organizations, except as needed for the purpose > > > of developing > > > > Internet standards in which case the procedures for > > > copyrights defined > > > > in the Internet Standards process must be followed, or > > > as required to > > > > translate it into languages other than English. > > > > > > > > The limited permissions granted above are perpetual > > > and will not be > > > > revoked by the Internet Society or its successors or > assignees. > > > > > > > > This document and the information contained herein is > > > provided on an > > > > "AS IS" basis and THE INTERNET SOCIETY AND THE > > > INTERNET ENGINEERING > > > > TASK FORCE DISCLAIMS 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. > > > > > > > > Acknowledgment > > > > > > > > Funding for the RFC Editor function is currently > > > provided by the > > > > Internet Society. > > > > > > > > References > > > > > > > > 1. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 2. http://www.ietf.org/ietf/1id-abstracts.txt > > > > 3. http://www.ietf.org/shadow.html > > > > 4. > > > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#intro > > > > 5. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#TransportProtocolOverview > > > > 6. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#DefinitionsAndArchitecture > > > > 7. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RequiredTransportProtocol > > > > 8. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#EncapsulationLayers > > > > 9. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#MessageFormat > > > > 10. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#BasicHeaderFormat > > > > 11. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#ExtendedHeaderFormat > > > > 12. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#Message Identifier > > > > 13. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#TotalLength > > > > 14. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#FragmentOffset > > > > 15. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#ExtendedHeaderExample > > > > 16. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#Payload > > > > 17. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SupportedMessageLength > > > > 18. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#LowerLayerConsiderations > > > > 19. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#TargetPort > > > > 20. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SourcePort > > > > 21. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SourceIPAddress > > > > 22. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#UDPIPHeader > > > > 23. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > ml#FragmentationAndReassembley > > > > 24. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#MessageFragmentation > > > > 25. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#MessageReassembley > > > > 26. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#AvoidingFragmentation > > > > 27. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#reliability > > > > 28. > > > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#loss > > > > 29. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#corruption > > > > 30. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#overload > > > > 31. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#sequence > > > > 32. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SenderAuthentication > > > > 33. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#security > > > > 34. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SecAuth > > > > 35. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SecForg > > > > 36. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SecObs > > > > 37. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SecReplay > > > > 38. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SecRelDel > > > > 39. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SecPri > > > > 40. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#SecDen > > > > 41. > > > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#iana > > > > 42. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#rfc-editor > > > > 43. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#authors > > > > 44. > > > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#acks > > > > 45. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#rfc.references1 > > > > 46. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#rfc.authors > > > > 47. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#AppendixA > > > > 48. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#rfc.copyright > > > > 49. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 50. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC3164 > > > > 51. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC-protocol > > > > 52. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC-protocol > > > > 53. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC0768 > > > > 54. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC0791 > > > > 55. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC2460 > > > > 56. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC2119 > > > > 57. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 58. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC-protocol > > > > 59. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC-protocol > > > > 60. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC-protocol > > > > 61. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC0768 > > > > 62. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 63. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC-protocol > > > > 64. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC2234 > > > > 65. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#MessageReassembley > > > > 66. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 67. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC0768 > > > > 68. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC0791 > > > > 69. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC2460 > > > > 70. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC0768 > > > > 71. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC2460 > > > > 72. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 73. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 74. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#Stevens > > > > 75. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 76. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC-protocol > > > > 77. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC3164 > > > > 78. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC0791 > > > > 79. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC2460 > > > > 80. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > > ml#RFC2474 > > > > 81. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 82. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 83. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 84. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 85. > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 86. ftp://ftp.isi.edu/in-notes/rfc3164.txt > > > > 87. ftp://ftp.isi.edu/in-notes/rfc3164.txt > > > > 88. ftp://ftp.isi.edu/in-notes/rfc768.txt > > > > 89. ftp://ftp.isi.edu/in-notes/rfc791.txt > > > > 90. mailto:deering@cisco.com > > > > 91. mailto:hinden@iprg.nokia.com > > > > 92. ftp://ftp.isi.edu/in-notes/rfc2460.txt > > > > 93. http://xml.resource.org/public/rfc/html/rfc2460.html > > > > 94. http://xml.resource.org/public/rfc/xml/rfc2460.xml > > > > 95. mailto:sob@harvard.edu > > > > 96. ftp://ftp.isi.edu/in-notes/rfc2119.txt > > > > 97. http://xml.resource.org/public/rfc/html/rfc2119.html > > > > 98. http://xml.resource.org/public/rfc/xml/rfc2119.xml > > > > 99. mailto:dcrocker@imc.org > > > > 100. mailto:paulo@turnpike.com > > > > 101. ftp://ftp.isi.edu/in-notes/rfc2234.txt > > > > 102. mailto:kmn@cisco.com > > > > 103. mailto:slblake@torrentnet.com > > > > 104. mailto:fred@cisco.com > > > > 105. mailto:black_david@emc.com > > > > 106. ftp://ftp.isi.edu/in-notes/rfc2474.txt > > > > 107. http://xml.resource.org/public/rfc/html/rfc2474.html > > > > 108. http://xml.resource.org/public/rfc/xml/rfc2474.xml > > > > 109. ftp://ftp.isi.edu/in-notes/rfc1035.txt > > > > 110. ftp://ftp.isi.edu/in-notes/rfc1058.txt > > > > 111. mailto:droms@bucknell.edu > > > > 112. ftp://ftp.isi.edu/in-notes/rfc2131.txt > > > > 113. http://xml.resource.org/public/rfc/html/rfc2131.html > > > > 114. http://xml.resource.org/public/rfc/xml/rfc2131.xml > > > > 115. mailto:SOLLINS@LCS.MIT.EDU > > > > 116. ftp://ftp.isi.edu/in-notes/rfc1350.txt > > > > 117. mailto:Braden@ISI.EDU > > > > 118. ftp://ftp.isi.edu/in-notes/rfc1122.txt > > > > 119. > > > > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > 120. > > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht > > ml#toc > > > 121. > > > file://localhost/usr/tmp/draft-ietf-syslog-> transport-udp-01.html#Steve > > ns > > > 122. > > > file://localhost/usr/tmp/draft-ietf-syslog-> transport-udp-01.html#RFC10 > > 35 > > > 123. > > > file://localhost/usr/tmp/draft-ietf-syslog-> transport-udp-01.html#RFC10 > > 58 > > > 124. > > > file://localhost/usr/tmp/draft-ietf-syslog-> transport-udp-01.html#RFC21 > > 31 > > > 125. > > > file://localhost/usr/tmp/draft-ietf-syslog-> transport-udp-01.html#RFC13 > > 50 > > > 126. > > > file://localhost/usr/tmp/draft-ietf-syslog-> transport-udp-01.html#RFC07 > > 91 > > > 127. > > > file://localhost/usr/tmp/draft-ietf-syslog-> transport-udp-01.html#RFC24 > > 60 > > > 128. > > > file://localhost/usr/tmp/draft-ietf-syslog-> transport-udp-01.html#RFC24 > > 60 > > > 129. > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc > > > > > > -- > > Devin Kowatch > > devink@sdsc.edu > > -- > Devin Kowatch > devink@sdsc.edu > ------------------------------
- Transport draft preview Anton Okmianski
- RE: Transport draft preview Rainer Gerhards
- RE: Transport draft preview Andrew Ross
- RE: Transport draft preview Anton Okmianski
- RE: Transport draft preview Anton Okmianski
- RE: Transport draft preview Anton Okmianski
- Re: Transport draft preview Devin Kowatch
- Re: Transport draft preview Devin Kowatch
- RE: Transport draft preview Anton Okmianski