idnits 2.17.1 draft-gerhards-syslog-plain-tcp-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (February 11, 2012) is 4451 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gerhards 3 Internet-Draft Adiscon GmbH 4 Intended status: Historic C. Lonvick 5 Expires: August 14, 2012 Cisco Systems, Inc. 6 February 11, 2012 8 Transmission of Syslog Messages over TCP 9 draft-gerhards-syslog-plain-tcp-14.txt 11 Abstract 13 There have been many implementations and deployments of legacy syslog 14 over TCP for many years. That protocol has evolved without being 15 standardized and has proven to be quite interoperable in practice. 16 This memo describes how TCP has been used as a transport for syslog 17 messages. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 14, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Statement by the IESG . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 56 4. Message Transmission . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Character Encoding Scheme . . . . . . . . . . . . . . . . 5 58 4.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.3. Session Initiation . . . . . . . . . . . . . . . . . . . . 6 60 4.4. Message Transfer . . . . . . . . . . . . . . . . . . . . . 6 61 4.4.1. Octet Counting . . . . . . . . . . . . . . . . . . . . 7 62 4.4.2. Non-Transparent-Framing . . . . . . . . . . . . . . . 7 63 4.4.3. Method Change . . . . . . . . . . . . . . . . . . . . 8 64 4.5. Session Closure . . . . . . . . . . . . . . . . . . . . . 8 65 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 69 9. Notes to the RFC Editor and Change Log . . . . . . . . . . . . 10 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Statement by the IESG 77 The IESG does not recommend implementing or deploying syslog over 78 plain tcp, which is described in this document, because it lacks the 79 ability to enable strong security [RFC3365]. 81 The TLS transport [RFC5425] is recommended for implementation so that 82 appropriate security features are available to operators who want to 83 deploy secure syslog. Similarly, those security features can be 84 turned off for those who do not want them. 86 2. Introduction 88 The standards track documents in the syslog series recommend using 89 the syslog protocol [RFC5424] with the TLS transport [RFC5425] for 90 all event messages. The authors of this document wholeheartedly 91 support that position and only offer this document to describe what 92 has been observed with legacy syslog over TCP, which appears to still 93 be widely used. 95 Two primary format options have been observed with legacy syslog 96 being transported over TCP. These have been called non-transparent- 97 framing and octet-counting. The non-transparent-framing mechanism 98 has some inherent problems. 100 Diagram 1 shows how all of these syslog transports relate to each 101 other. In this diagram three originators are seen, labeled A, B, and 102 C, along with one collector. Originator A is using the TCP transport 103 which is described in this document. Originator B is using the UDP 104 transport, which is described in [RFC5426]. Originator C is using 105 the TLS transport, which is described in [RFC5425]. The collector is 106 shown with the capability to accept all three transports. 108 +---------------------+ 109 | Originator A | 110 |---------------------| 111 | syslog application | 112 | | 113 |---------------------| 114 | syslog transport | 115 | TCP | 116 |---------------------| 117 v 118 | 119 / +---------------------+ 120 / | Originator B | 121 / |---------------------| 122 / +----------------------+ | syslog application | 123 / | Collector | | | 124 | |----------------------| |---------------------| 125 | | syslog application | | syslog transport | 126 | | | | UDP | 127 | |----------------------| |---------------------| 128 | | syslog transport | v 129 | | TCP | TLS | UDP | | 130 | |----------------------| | 131 | ^ ^ ^ | 132 | | | | | 133 \ / | \ / 134 --------- | ------------------ 135 | 136 | 137 | +---------------------+ 138 | | Originator C | 139 | |---------------------| 140 | | syslog application | 141 | | | 142 | |---------------------| 143 | | syslog transport | 144 | | TLS | 145 | |---------------------| 146 | v 147 \ / 148 --------------- 150 Diagram 1. Syslog Layers 152 3. Conventions Used in This Document 154 The terminology defined in Section 3 of [RFC5424] is used throughout 155 this specification. The reader should be familiar with that to 156 follow this discussion. 158 This document also references devices that use the syslog message 159 format as described in [RFC3164]. Devices that continue to use that 160 message format (regardless of transport) will be described as "legacy 161 syslog devices". Similarly, devices that use the message format as 162 described in [RFC5424] will be described as "standardized syslog 163 devices". 165 4. Message Transmission 167 Syslog is simplex in nature. It has been observed that 168 implementations of syslog over TCP also do not use any backchannel 169 mechanism to convey information to the transport sender, and 170 consequently do not use any application-level acknowledgement for 171 syslog receiver to sender signaling. Message receipt 172 acknowledgement, reliability, and flow control are provided by the 173 capabilities of TCP. 175 4.1. Character Encoding Scheme 177 Syslog over TCP messages contain no indication of the coded character 178 set (e.g., [US-ASCII] or [UNICODE] ) or character encoding scheme 179 (e.g., so-called "7-bit ASCII" or UTF-8 [RFC3629]) in use. In these 180 messages, the predominant approach has been to include characters 181 only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using 182 the "Network Virtual Terminal" (NVT) encoding [RFC5198]. 184 The message header usually contains characters only from the ASCII 185 repertoire, in the NVT encoding. This has been observed even in 186 cases where a different encoding (e.g., UTF-8) has been used for the 187 MSG part. However, characters outside the ASCII range have been seen 188 inside the header. In that case, some syslog applications have been 189 known to experience problems processing those messages. 191 In some cases, it has been observed that characters outside of the 192 ASCII range are often being transformed by receivers in an effort to 193 "escape control characters". Some receiver implementations simply 194 drop those characters. This is considered to be a poor practice as 195 it causes problems with coded character sets other than ASCII and 196 character encodings other than NVT, most notably the UTF-8 encoding 197 of Unicode. 199 It has also been observed that relays will forward messages using the 200 character encoding schemes of messages they receive. In the case 201 where two different senders are using different character encoding 202 schemes, the relay will forward each message to a collector in that 203 character encoding. The collector of these messages will have to be 204 prepared to receive messages from the same relay with different 205 encodings. 207 4.2. Session 209 Like most other protocols, the syslog transport sender is the TCP 210 host that initiates the TCP session. After initiation, messages are 211 sent from the transport sender to the transport receiver. No 212 application-level data is transmitted from the transport receiver to 213 the transport sender. The roles of transport sender and receiver 214 seem to be fixed once the session is established. 216 When it has been observed, if an error occurs that cannot be 217 corrected by TCP, the host detecting the error gracefully closes the 218 TCP session. There have been no application level messages seen that 219 were sent to notify the other host about the state of the host syslog 220 application. 222 4.3. Session Initiation 224 The TCP host acting as a syslog transport receiver listens to a TCP 225 port. The TCP transport sender initiates a TCP session to the syslog 226 transport receiver as specified in [RFC0793]. 228 This protocol has no standardized port assignment. In practice, 229 network administrators generally choose something that they feel will 230 not conflict with anything else active in their networks. This has 231 most often been either TCP/514, which is actually allocated to 232 another protocol, or some variant of adding 514 to a multiple of 233 1000. Please see Section 5 for more information about this. 235 4.4. Message Transfer 237 Syslog over TCP has been around for a number of years. Just like 238 legacy syslog over UDP, different implementations exist. The older 239 method of non-transparent-framing has problems. The newer method of 240 octet-counting is reliable and has not been seen to cause problems 241 noted with the non-transparent-framing method. 243 In both of these methods, during the message transfer phase, the 244 syslog transport sender sends a stream of messages to the transport 245 receiver. These are sent in sequence and one message is encapsulated 246 inside each TCP frame. Either of the TCP hosts may initiate session 247 closure at any time as specified in Section 3.5 of [RFC0793]. In 248 practice, this is often seen after a prolonged period of inactivity. 250 4.4.1. Octet Counting 252 This framing allows for the transmission of all characters inside a 253 syslog message and is similar to the method used in [RFC5425]. A 254 transport receiver uses the defined message length to delimit a 255 syslog message. As noted in [RFC3164] the upper limit for a legacy 256 syslog message length is 1024 octets. That length has been expanded 257 for standardized syslog. 259 It can be assumed that octet-counting framing is used if a syslog 260 frame starts with a digit. 262 All syslog messages can be considered to be TCP "data" as per 263 Transmission Control Protocol [RFC0793]. The syslog message stream 264 has the following ABNF [RFC5234] definition: 266 TCP-DATA = *SYSLOG-FRAME 268 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG ; Octet-counting 269 ; method 271 MSG-LEN = NONZERO-DIGIT *DIGIT 273 NONZERO-DIGIT = %d49-57 275 SYSLOG-MSG is defined in the syslog protocol [RFC5424] and may 276 also be considered to be the payload in [RFC3164] 278 MSG-LEN is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME. 280 4.4.2. Non-Transparent-Framing 282 The non-transparent-framing method inserts a syslog message into a 283 frame and terminates it with a TRAILER character. The TRAILER has 284 usually been a single character and most often is ASCII LF (%d10). 285 However, other characters have also been seen, with ASCII NUL (%d00) 286 being a prominent example. Some devices have also been seen to emit 287 a two-character TRAILER, which is usually CR and LF. 289 The problem with non-transparent-framing comes from the use of a 290 TRAILER character. In that, the traditional trailer character is not 291 escaped within the message, which causes problems for the receiver. 292 For example, a message in the style of [RFC3164] containing one or 293 more LF characters may be misinterpreted as multiple messages by the 294 receiving syslog application. 296 The ABNF for this is shown here: 298 TCP-DATA = *SYSLOG-FRAME 300 SYSLOG-FRAME = SYSLOG-MSG TRAILER ; non-transparent-framing 301 ; method 303 TRAILER = LF / APP-DEFINED 305 APP-DEFINED = 1*2OCTET 307 SYSLOG-MSG is defined in the syslog protocol [RFC5424] and may 308 also be considered to be the payload in [RFC3164] 310 A transport receiver can assume that non-transparent-framing is used 311 if a syslog frame starts with the ASCII character "<" (%d60). 313 4.4.3. Method Change 315 It has been observed in legacy implementations that the framing may 316 change on a frame-by-frame basis. This is probably not a good idea, 317 but it's been seen. 319 4.5. Session Closure 321 The syslog session is closed when one of the TCP hosts decides to do 322 so. It then initiates a local TCP session closure. Following TCP 323 [RFC0793] it doesn't need to notify the remote TCP host of its 324 intention to close the session, nor does it accept any messages that 325 are still in transit. 327 5. Applicability Statement 329 Again it must be emphasized that the standards track documents in the 330 syslog series recommend using the TLS transport [RFC5425] to 331 transport syslog messages. This document does not recommend that new 332 implementations or deployments use syslog over TCP except for the 333 explicit purpose of interoperating with existing deployments. 335 One of the major problems with interoperability with this protocol is 336 that there is no consistent TCP port assigned. Most of the 337 successful implementations have made the selection of a port a user- 338 configurable option. The most frequently observed port for this has 339 been TCP/514, which is actually assigned to the Shell protocol. 341 Operators must carefully select which port to use in their deployment 342 and be prepared to encounter different default port assignments in 343 implementations. 345 There are several advantages to using TCP: flow control, error 346 recovery, and reliability, to name a few. These reasons and the ease 347 of programming have lead people to use this transmission protocol to 348 transmit syslog. 350 One potential disadvantage is the buffering mechanism used by TCP. 351 Ordinarily, TCP decides when enough data has been received from the 352 application to form a segment for transmission. This may be adjusted 353 through timers but still, some application data may wait in a buffer 354 for a relatively long time. Syslog data is not normally time- 355 sensitive but if this delay is a concern, the syslog transport sender 356 may utilize the PUSH Flag as described in [RFC0793] to have the 357 sending TCP immediately send all buffered data. 359 6. Security Considerations 361 This protocol makes no meaningful provisions for security. It lacks 362 authentication, integrity checking, and privacy. It makes no 363 provision for flow control or end-to-end confirmation of receipt, 364 relying instead on the underlying TCP implementations to approximate 365 these functions. It should not be used if deployment of [RFC5425] on 366 the systems in question is feasible. 368 7. IANA Considerations 370 There are no requests for IANA actions in this document. 372 8. Acknowledgments 374 The authors wish to thank David Harrington, Tom Petch, Richard 375 Graveman, and all other people who commented on various versions of 376 this proposal. We would also like to thank Peter Saint-Andre for 377 clarifying character encodings. 379 The authors would also like to thank Randy Presuhn for being our 380 reviewer and document shepherd, and a special thanks to Dan Romascanu 381 for his support and guidance. 383 9. Notes to the RFC Editor and Change Log 385 These are notes to the RFC editor. Please delete this section after 386 the notes have been followed. 388 Version -14 addresses the final few IESG requests. It was submitted 389 in February of 2012. 391 Version -13 addressed the IESG reviews and is changed to Historic. 392 It was submitted in January of 2012. 394 Version -12 addressed AD Review comments as well as GENART comments. 395 It was submitted in December of 2011. 397 Version -11 fixed the ABNF and was submitted in October of 2011. 399 Version -10 was put together based on Randy Presuhn's feedback as 400 shepherd. A section on character sets has been added. The term 401 "octet-stuffing" was incorrectly used and has been replaced by "non- 402 transparent-framing". The security considerations section has been 403 simplified. It was submitted in October of 2011. 405 Version -09 was put together based on IESG member feedback. The 406 appendixes were removed and things were consolidated to be more 407 appropriate for an informational document. It was submitted in 408 August of 2011. Dan Romascanu is actually the IESG member who will 409 watch this document. 411 Version -08 included a reference to vulnerabilities of TCP. It was 412 submitted in February of 2011. 414 Version -07 was submitted in January, 2011. This clarified what was 415 really expected from what was optional. Appendix B was added for 416 further clarification. Additionally, the security Considerations 417 section was edited to include a discussion about transport layer 418 issues. 420 Version -06 was submitted in October, 2010. The 2119 language was 421 removed. Also, we compared notes and couldn't find any 422 implementations that stacked multiple messages in a frame in the 423 octet-counting method. That paragraph was removed. 425 Version -05 was submitted in September, 2010 to address some items 426 that David Harrington noted as he is becoming the document shepherd. 428 Version -04 was submitted in April, 2010 to clean up some items. 430 Version -03 was submitted in April, 2010 based upon further review 431 comments from Tom Petch. 433 Version -02 was submitted in March, 2010 based upon review comments 434 from Tom Petch. 436 Version -01 was submitted based upon review comments from David 437 Harrington. 439 Version -00 was created in November, 2009. 441 10. References 443 10.1. Normative 445 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 446 RFC 793, September 1981. 448 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 449 Engineering Task Force Standard Protocols", BCP 61, 450 RFC 3365, August 2002. 452 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 453 Interchange", RFC 5198, March 2008. 455 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 456 Specifications: ABNF", STD 68, RFC 5234, January 2008. 458 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 460 [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer 461 Security (TLS) Transport Mapping for Syslog", RFC 5425, 462 March 2009. 464 [US-ASCII] 465 ANSI, "Coded Character Set -- 7-bit American Standard Code 466 for Information Interchange, ANSI X3.4-1986", 1968. 468 10.2. Informative 470 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 471 August 2001. 473 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 474 10646", STD 63, RFC 3629, November 2003. 476 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 477 RFC 5426, March 2009. 479 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 480 6.0"", 2010, 481 . 483 Authors' Addresses 485 Rainer Gerhards 486 Adiscon GmbH 487 Mozartstrasse 21 488 Grossrinderfeld, BW 97950 489 Germany 491 Email: rgerhards@adiscon.com 493 Chris Lonvick 494 Cisco Systems, Inc. 495 12515 Research Blvd. 496 Austin, TX 78759 497 USA 499 Email: clonvick@cisco.com