idnits 2.17.1 draft-ietf-syslog-transport-udp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 445. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 5, 2007) is 6077 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2460 (ref. '4') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 3164 (ref. '8') (Obsoleted by RFC 5424) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 syslog Working Group A. Okmianski 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track September 5, 2007 5 Expires: March 8, 2008 7 Transmission of syslog messages over UDP 8 draft-ietf-syslog-transport-udp-12 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 8, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes the transport for syslog messages over UDP/ 42 IPv4 or UDP/IPv6. The syslog protocol layered architecture provides 43 for support of any number of transport mappings. However, for 44 interoperability purposes, syslog protocol implementers are required 45 to support this transport mapping. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 51 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. One Message Per Datagram . . . . . . . . . . . . . . . . . 3 53 3.2. Message Size . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.3. Source and Target Ports . . . . . . . . . . . . . . . . . 4 55 3.4. Source IP Address . . . . . . . . . . . . . . . . . . . . 4 56 3.5. UDP/IP Structure . . . . . . . . . . . . . . . . . . . . . 5 57 3.6. UDP Checksums . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Reliability Considerations . . . . . . . . . . . . . . . . . . 5 59 4.1. Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Message Corruption . . . . . . . . . . . . . . . . . . . . 5 61 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 5.1. Sender Authentication and Message Forgery . . . . . . . . 6 65 5.2. Message Observation . . . . . . . . . . . . . . . . . . . 7 66 5.3. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.4. Unreliable Delivery . . . . . . . . . . . . . . . . . . . 7 68 5.5. Message Prioritization and Differentiation . . . . . . . . 8 69 5.6. Denial of Service . . . . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . . 8 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 Intellectual Property and Copyright Statements . . . . . . . . . . 10 79 1. Introduction 81 The informational RFC 3164 [8] describes the syslog protocol as it 82 was observed in existing implementations. It describes both the 83 format of syslog messages and a UDP [1] transport. Subsequently, a 84 standards-track syslog protocol has been defined in the RFC-protocol 85 [2]. 87 The RFC-protocol specifies a layered architecture that provides for 88 support of any number of transport layer mappings for transmitting 89 syslog messages. This document describes the UDP transport mapping 90 for the syslog protocol. 92 The transport described in this document can be used for transmitting 93 syslog messages over both IPv4 [3] and IPv6 [4]. The IPv4 version of 94 this transport mapping is REQUIRED for all syslog protocol 95 implementations on devices supporting IPv4. The IPv6 version of this 96 transport mapping is REQUIRED for all syslog protocol implementations 97 on IPv6-only devices, and RECOMMENDED for dual-stack devices. These 98 requirements are mandated for interoperability purposes. 100 Network administrators and architects should be aware of the 101 significant reliability and security issues of this transport, which 102 stem from the use of UDP. They are documented in this specification. 103 However, this transport is lightweight and is built upon the existing 104 popular use of UDP for syslog. 106 2. Conventions Used in This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [5]. 112 3. Transport Protocol 114 3.1. One Message Per Datagram 116 Each syslog UDP datagram MUST contain only one syslog message, which 117 MAY be complete or truncated. The message MUST be formatted and 118 truncated according to the RFC-protocol [2]. Additional data MUST 119 NOT be present in the datagram payload. 121 3.2. Message Size 123 This transport mapping supports transmission of syslog messages up to 124 65535 octets minus the UDP header length. This limit stems from the 125 maximum supported UDP size of 65535 octets specified in the RFC 768 126 [1]. For IPv4, the maximum payload size is 65535 octets minus the 127 UDP header and minus the IP header because IPv4 has a 16-bit length 128 field that also includes the header length. 130 IPv4 syslog receivers MUST be able to receive datagrams with message 131 size up to and including 480 octets. IPv6 syslog receivers MUST be 132 able to receive datagrams with message size up to and including 1180 133 octets. All syslog receivers SHOULD be able to receive datagrams 134 with messages size of up to 2048 octets. The ability to receive 135 larger messages is encouraged. 137 The above restrictions and recommendations establish a baseline for 138 interoperability. The minimum required message size support was 139 determined based on the minimum MTU size that Internet hosts are 140 required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6 141 [4]. Datagrams that conform to these limits have the greatest chance 142 of being delivered because they do not require fragmentation. 144 It is RECOMMENDED that syslog senders restrict message sizes such 145 that IP datagrams do not exceed the smallest MTU of the network in 146 use. This avoids datagram fragmentation and possible issues 147 surrounding fragmentation such as incorrect MTU discovery. 148 Fragmentation can be undesirable because it increases the risk of the 149 message being lost due to loss of just one datagram fragment. Syslog 150 has no acknowledgment facility, and therefore there is no effective 151 way to handle retransmission. This makes it impossible for syslog to 152 utilize packetization layer path MTU discovery [9]. When network MTU 153 is not known in advance, the safest assumption is to restrict 154 messages to 480 octets for IPv4 and 1180 octets for IPv6. 156 3.3. Source and Target Ports 158 Syslog receivers MUST support accepting syslog datagrams on the well- 159 known UDP port 514, but MAY be configurable to listen on a different 160 port. Syslog senders MUST support sending syslog message datagrams 161 to the UDP port 514, but MAY be configurable to send messages to a 162 different port. Syslog senders MAY use any source UDP port for 163 transmitting messages. 165 3.4. Source IP Address 167 The source IP address of the UDP datagrams SHOULD NOT be interpreted 168 as the identifier for the host that originated the syslog message. 169 The entity sending the syslog message could be merely a relay. The 170 syslog message itself contains the identifier of the originator of 171 the message. 173 3.5. UDP/IP Structure 175 Each UDP/IP datagram sent by the transport layer MUST completely 176 adhere to the structure specified in the UDP RFC 768 [1] and either 177 IPv4 RFC 791 [3] or IPv6 RFC 2460 [4] depending on which protocol is 178 used. 180 3.6. UDP Checksums 182 Syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders 183 SHOULD use UDP checksums when sending messages. Note that RFC 2460 184 [4] mandates the use of UDP checksums when sending UDP datagrams over 185 IPv6. 187 Syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog 188 receivers SHOULD check UDP checksums and they SHOULD accept a syslog 189 message with a zero checksum. Note that RFC 2460 [4] mandates the 190 use of checksums for UDP over IPv6. 192 4. Reliability Considerations 194 The UDP is an unreliable low-overhead protocol. This section 195 discusses reliability issues inherent in UDP that implementers and 196 users should be aware of. 198 4.1. Lost Datagrams 200 This transport mapping does not provide any mechanism to detect and 201 correct loss of datagrams. Datagrams can be lost in transit due to 202 congestion, corruption, or any other intermittent network problem. 203 IP fragmentation exacerbates this problem because loss of a single 204 fragment will result in the entire message being discarded. 206 4.2. Message Corruption 208 The UDP/IP datagrams can get corrupted in transit due to software, 209 hardware, or network errors. This transport mapping specifies use of 210 UDP checksums to enable corruption detection in addition to checksums 211 used in IP and Layer 2 protocols. However, checksums do not 212 guarantee corruption detection, and this transport mapping does not 213 provide for message acknowledgement or retransmission mechanism. 215 4.3. Congestion Control 217 Because syslog can generate unlimited amounts of data, transferring 218 this data over UDP is generally problematic, because UDP lacks 219 congestion control mechanisms. Congestion control mechanisms that 220 respond to congestion by reducing traffic rates and establish a 221 degree of fairness between flows that share the same path are vital 222 to the stable operation of the Internet [6]. This is why the syslog 223 TLS transport [7] is REQUIRED to implement and RECOMMENDED for 224 general use. 226 The only environments where the syslog UDP transport MAY be used as 227 an alternative to the TLS transport are managed networks, where the 228 network path has been explicitly provisioned for UDP syslog traffic 229 through traffic engineering mechanisms, such as rate limiting or 230 capacity reservations. In all other environments, the TLS transport 231 [7] SHOULD be used. 233 4.4. Sequenced Delivery 235 The IP transport used by the UDP does not guarantee that the sequence 236 of datagram delivery will match the order in which the datagrams were 237 sent. The time stamp contained within each syslog message can serve 238 as a rough guide in establishing sequence order, but it will not help 239 in cases when multiple messages were generated during the same time 240 slot, the sender cannot generate a time stamp, or messages originated 241 from different hosts whose clocks are not synchronized. The order of 242 syslog message arrival via this transport SHOULD NOT be used as an 243 authoritative guide in establishing an absolute or relative sequence 244 of events on the syslog sender hosts. 246 5. Security Considerations 248 Using this specification on an unsecured network is NOT RECOMMENDED. 249 Several syslog security considerations are discussed in RFC-protocol 250 [2]. This section focuses on security considerations specific to the 251 syslog transport over UDP. Some of the security issues raised in 252 this section can be mitigated through the use of IPsec as defined in 253 RFC 4301 [10]. 255 5.1. Sender Authentication and Message Forgery 257 This transport mapping does not provide for strong sender 258 authentication. The receiver of the syslog message will not be able 259 to ascertain that the message was indeed sent from the reported 260 sender, or whether the packet was sent from another device. This can 261 also lead to a case of mistaken identity if an inappropriately 262 configured machine sends syslog messages to a receiver representing 263 itself as another machine. 265 This transport mapping does not provide protection against syslog 266 message forgery. An attacker can transmit syslog messages (either 267 from the machine from which the messages are purportedly sent or from 268 any other machine) to a receiver. 270 In one case, an attacker can hide the true nature of an attack amidst 271 many other messages. As an example, an attacker can start generating 272 forged messages indicating a problem on some machine. This can get 273 the attention of the system administrators, who will spend their time 274 investigating the alleged problem. During this time, the attacker 275 could be able to compromise a different machine or a different 276 process on the same machine. 278 Additionally, an attacker can generate false syslog messages to give 279 untrue indications of the status of systems. As an example, an 280 attacker can stop a critical process on a machine, which could 281 generate a notification of exit. The attacker can subsequently 282 generate a forged notification that the process had been restarted. 283 The system administrators could accept that misinformation and not 284 verify that the process had indeed not been restarted. 286 5.2. Message Observation 288 This transport mapping does not provide confidentiality of the 289 messages in transit. If syslog messages are in clear text, this is 290 how they will be transferred. In most cases passing clear-text 291 human-readable messages is a benefit to the administrators. 292 Unfortunately, an attacker could also be able to observe the human- 293 readable contents of syslog messages. The attacker could then use 294 the knowledge gained from these messages to compromise a machine. It 295 is RECOMMENDED that no sensitive information be transmitted via this 296 transport mapping or that transmission of such information be 297 restricted to properly secured networks. 299 5.3. Replaying 301 Message forgery and observation can be combined into a replay attack. 302 An attacker could record a set of messages that indicate normal 303 activity of a machine. At a later time, an attacker could remove 304 that machine from the network and replay the syslog messages with new 305 time stamps. The administrators could find nothing unusual in the 306 received messages, and their receipt would falsely indicate normal 307 activity of the machine. 309 5.4. Unreliable Delivery 311 As was previously discussed in the Reliability Considerations 312 section, the UDP transport is not reliable, and packets containing 313 syslog message datagrams can be lost in transit without any notice. 314 There can be security consequences to the loss of one or more syslog 315 messages. Administrators could be unaware of a developing and 316 potentially serious problem. Messages could also be intercepted and 317 discarded by an attacker as a way to hide unauthorized activities. 319 5.5. Message Prioritization and Differentiation 321 This transport mapping does not mandate prioritization of syslog 322 messages on the wire or when processed on the receiving host based on 323 their severity. Unless some prioritization is implemented by sender, 324 receiver and/or network, the security implication of such behavior is 325 that the syslog receiver or network devices could get overwhelmed 326 with low-severity messages and be forced to discard potentially high- 327 severity messages. 329 5.6. Denial of Service 331 An attacker could overwhelm a receiver by sending more messages to it 332 than could be handled by the infrastructure or the device itself. 333 Implementers SHOULD attempt to provide features that minimize this 334 threat such as optionally restricting reception of messages to a set 335 of know source IP addresses. 337 6. IANA Considerations 339 This transport uses UDP port 514 for syslog, as recorded in the IANA 340 port-numbers registry. 342 7. Notice to RFC Editor 344 This is a notice to the RFC editor. This ID is submitted along with 345 ID draft-ietf-syslog-protocol and draft-ietf-syslog-transport-tls. 346 The document cross-reference each other. When RFC numbers are 347 determined for each of these IDs, please replace all references to 348 "RFC-protocol" and "RFC-transport-tls" in this document with the RFC 349 number of draft-ietf-syslog-protocol ID. Also, please update the 350 date, size and URL fields in the section referencing the new RFC. 351 Please remove this section after editing. 353 8. Acknowledgements 355 The author gratefully acknowledges the contributions of: Chris 356 Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert 357 Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova, 358 Devin Kowatch, Richard Graveman, and all others who have commented on 359 the various versions of this proposal. 361 9. References 363 9.1. Normative References 365 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 366 August 1980. 368 [2] Gerhards, R., "The syslog Protocol", RFC RFC-protocol, 369 January 2007. 371 [3] Postel, J., "Internet Protocol", STD 5, RFC 791, 372 September 1981. 374 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 375 Specification", RFC 2460, December 1998. 377 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 378 Levels", BCP 14, RFC 2119, March 1997. 380 [6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, 381 September 2000. 383 [7] Miao, F. and Y. Ma, "TLS Transport Mapping for Syslog", 384 RFC RFC-transport-tls, May 2007. 386 9.2. Informative References 388 [8] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. 390 [9] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 391 November 1990. 393 [10] Kent, S. and K. Seo, "Security Architecture for the Internet 394 Protocol", RFC 4301, December 2005. 396 Author's Address 398 Anton Okmianski 399 Cisco Systems, Inc. 400 1414 Massachusetts Ave 401 Boxborough, MA 01719-2205 402 USA 404 Phone: +1-978-936-1612 405 Email: aokmians@cisco.com 407 Full Copyright Statement 409 Copyright (C) The IETF Trust (2007). 411 This document is subject to the rights, licenses and restrictions 412 contained in BCP 78, and except as set forth therein, the authors 413 retain all their rights. 415 This document and the information contained herein are provided on an 416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 418 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 419 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 420 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 423 Intellectual Property 425 The IETF takes no position regarding the validity or scope of any 426 Intellectual Property Rights or other rights that might be claimed to 427 pertain to the implementation or use of the technology described in 428 this document or the extent to which any license under such rights 429 might or might not be available; nor does it represent that it has 430 made any independent effort to identify any such rights. Information 431 on the procedures with respect to rights in RFC documents can be 432 found in BCP 78 and BCP 79. 434 Copies of IPR disclosures made to the IETF Secretariat and any 435 assurances of licenses to be made available, or the result of an 436 attempt made to obtain a general license or permission for the use of 437 such proprietary rights by implementers or users of this 438 specification can be obtained from the IETF on-line IPR repository at 439 http://www.ietf.org/ipr. 441 The IETF invites any interested party to bring to its attention any 442 copyrights, patents or patent applications, or other proprietary 443 rights that may cover technology that may be required to implement 444 this standard. Please address the information to the IETF at 445 ietf-ipr@ietf.org. 447 Acknowledgment 449 Funding for the RFC Editor function is provided by the IETF 450 Administrative Support Activity (IASA).