idnits 2.17.1 draft-ietf-syslog-reliable-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 38 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1223 has weird spacing: '... code mea...' -- 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 (July 24, 2001) is 8310 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) == Missing Reference: '141' is mentioned on line 328, but not defined == Missing Reference: '0' is mentioned on line 620, but not defined -- Looks like a reference, but probably isn't: 'RFC-1034' on line 1146 ** Downref: Normative reference to an Informational draft: draft-ietf-syslog-syslog (ref. '1') ** Obsolete normative reference: RFC 1766 (ref. '7') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2831 (ref. '8') (Obsoleted by RFC 6331) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. New 2 Internet-Draft M. Rose 3 Expires: January 22, 2002 Invisible Worlds, Inc. 4 July 24, 2001 6 Reliable Delivery for syslog 7 draft-ietf-syslog-reliable-12.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 22, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 The syslog protocol [1] describes a number of service options related 39 to propagating event messages. This memo describes two mappings of 40 the syslog protocol to TCP connections, both useful for reliable 41 delivery of event messages. The first provides a trivial mapping 42 maximizing backward compatibility. The second provides a more 43 complete mapping. Both provide a degree of robustness and security 44 in message delivery that is unavailable to the usual UDP-based syslog 45 protocol, by providing encryption and authentication over a 46 connection-oriented protocol. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. The Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. The RAW Profile . . . . . . . . . . . . . . . . . . . . . . 7 53 3.1 RAW Profile Overview . . . . . . . . . . . . . . . . . . . . 7 54 3.2 RAW Profile Identification and Initialization . . . . . . . 9 55 3.3 RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 10 56 3.4 RAW Profile Message Semantics . . . . . . . . . . . . . . . 10 57 4. The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 11 58 4.1 COOKED Profile Overview . . . . . . . . . . . . . . . . . . 11 59 4.2 COOKED Profile Identification and Initialization . . . . . . 11 60 4.3 COOKED Profile Message Syntax . . . . . . . . . . . . . . . 11 61 4.4 COOKED Profile Message Semantics . . . . . . . . . . . . . . 12 62 4.4.1 The IAM Element . . . . . . . . . . . . . . . . . . . . . . 12 63 4.4.2 The ENTRY Element . . . . . . . . . . . . . . . . . . . . . 14 64 4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 19 65 5. Additional Provisioning . . . . . . . . . . . . . . . . . . 25 66 5.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . 25 67 5.2 Message Replay . . . . . . . . . . . . . . . . . . . . . . . 25 68 5.3 Message Integrity . . . . . . . . . . . . . . . . . . . . . 25 69 5.4 Message Observation . . . . . . . . . . . . . . . . . . . . 26 70 5.5 Summary of Recommended Practices . . . . . . . . . . . . . . 26 71 6. Initial Registrations . . . . . . . . . . . . . . . . . . . 27 72 6.1 Registration: The RAW Profile . . . . . . . . . . . . . . . 27 73 6.2 Registration: The COOKED Profile . . . . . . . . . . . . . . 27 74 7. The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 28 75 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . 32 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 77 9.1 Registration: BEEP Profiles . . . . . . . . . . . . . . . . 33 78 9.2 Registration: The System (Well-Known) TCP port number for 79 syslog-reliable . . . . . . . . . . . . . . . . . . . . . . 33 80 10. Security Considerations . . . . . . . . . . . . . . . . . . 34 81 References . . . . . . . . . . . . . . . . . . . . . . . . . 35 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35 83 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 84 Full Copyright Statement . . . . . . . . . . . . . . . . . . 38 86 1. Introduction 88 The syslog protocol [1] presents a spectrum of service options for 89 provisioning an event-based logging service over a network. Each 90 option has associated benefits and costs. Accordingly, the choice as 91 to what combination of options is provisioned is both an engineering 92 and administrative decision. This memo describes how to realize the 93 syslog protocol when reliable delivery is selected as a required 94 service. It is beyond the scope of this memo to argue for, or 95 against, the use of reliable delivery for the syslog protocol. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [2]. 101 2. The Model 103 The syslog service supports three roles of operation: device, relay, 104 and collector. 106 Devices and collectors act as sources and sinks, respectively, of 107 syslog entries. In the simplest case, only a device and collector 108 are present. E.g., 110 +--------+ +-----------+ 111 | Device | -----> | Collector | 112 +--------+ +-----------+ 114 The relationship between devices and collectors is potentially many- 115 to-many. I.e., a device might communicate with many collectors; 116 similarly, a collector might communicate with many devices. 118 A relay operates in both modes, accepting syslog entries from devices 119 and other relays and forwarding those entries to collectors and other 120 relays. 122 For example, 124 +--------+ +-------+ +-------+ +-----------+ 125 | Device | ---> | Relay | -...-> | Relay | ---> | Collector | 126 +--------+ +-------+ +-------+ +-----------+ 128 As shown, more than one relay may be present between any particular 129 device and collector. 131 A relay may be necessary for administrative reasons. For example, a 132 relay might run as an application proxy on a firewall. Also, there 133 might be one relay per company department, which authenticates all 134 the devices in the department, and which in turn authenticates itself 135 to a company-wide collector. 137 A relay can also serve to filter messages. For example, one relay 138 may collect the syslog information from an entire web server farm, 139 summarizing hit counts for report generation, forwarding "page not 140 found" messages (indicating a possible broken link) to a collector 141 that presents it to the webmaster, and sending more urgent messages 142 (such as hardware failure reports) to a collector that gateways them 143 to a pager. A relay may also be used to convert formats from a 144 device's output to a collector's input. 146 It should be noted that a role of device, relay, or collector is 147 relevant only to a particular BEEP channel (q.v., below). A single 148 server can serve as a device, a relay, and a collector, all at once, 149 if so configured. It can even serve as a relay and a collector to 150 the same device at the same time using different BEEP channels over 151 the same connection-oriented session; this might be useful to collect 152 status yet relay urgent error messages. 154 To provide reliable delivery when realizing the syslog protocol, this 155 memo defines two BEEP profiles. BEEP [3] is a generic application 156 protocol framework for connection-oriented, asynchronous 157 interactions. Within BEEP, features such as authentication, privacy, 158 and reliability through retransmission are provided. There are two 159 profiles defined in this memo: 161 o The RAW profile is designed to provide a high-performance, low- 162 impact footprint, using essentially the same format as the 163 existing UDP-based syslog service. 165 o The COOKED profile is designed to provide a structured entry 166 format, in which individual entries are acknowledged (either 167 positively or negatively). 169 Note that both profiles run over BEEP. BEEP defines "transport 170 mappings," specifying how BEEP messages are carried over the 171 underlying transport technologies. At the time of this writing, only 172 one such transport is defined, in [4], which specifies BEEP over TCP. 173 All transport mappings are required to support enough reliability and 174 sequencing to allow all BEEP messages on a given channel to be 175 delivered reliably and in order. Hence, both the RAW and COOKED 176 profile provide reliable delivery of their messages. 178 The choice of profile is independent of the operational roles 179 discussed above. 181 For example, in 183 +--------+ +-------+ +-----------+ 184 | Device | -----> | Relay | -----> | Collector | 185 +--------+ +-------+ +-----------+ 187 the device-to-relay link could be configured to use the RAW profile, 188 while the relay-to-collector link could be configured to use the 189 COOKED profile. (For example, the relay may be parsing the RAW 190 syslog messages from the device, knowing the details of their 191 formats, before passing them to a more generic collector.) Indeed, 192 the same device may use different profiles, depending on the 193 collector to which it is sending entries. 195 Devices and relays MAY discover relays and collectors via the DNS SRV 196 algorithm [5]. If so configured, the service used is "syslog" and 197 the protocol used is "tcp". This allows for central administration 198 of addressing, fallback for failed relays and collectors, and static 199 load balancing. Security policies and hardware configurations may be 200 such that device configuration is more secure than the DNS server. 201 Hardware devices may be of such limited resources that DNS SRV access 202 is inappropriate. Firewalls and other restrictive routing mechanisms 203 may need to be dealt with before a reliable syslog connection can be 204 established. In these cases, DNS might not be the most appropriate 205 configuration mechanism. 207 3. The RAW Profile 209 3.1 RAW Profile Overview 211 The RAW profile is designed for minimal implementation effort, high 212 efficiency, and backwards compatibility. It is appropriate 213 especially in cases where legacy syslog processing will be applied. 215 It should be noted that even though the RAW profile uses the same 216 format for message payloads as the UDP version of syslog uses, 217 delivery is reliable. The RAW syslog profile is a profile of BEEP 218 [3], and BEEP guarantees ordered reliable delivery of messages within 219 each individual channel. 221 When the profile is started, no piggyback data is supplied. All BEEP 222 messages in the RAW profile are specified as having a MIME Content- 223 Type [6] of application/octet-stream. Once the channel is open, the 224 listener (not the initiator) sends a MSG message indicating it is 225 ready to act as a syslog sink. (Refer to [3]'s Section 2.1 for a 226 discussion of roles that a BEEP peer may perform, including 227 definitions of the terms "listener", "initiator", "client", and 228 "server".) 230 The initiator uses ANS replies to supply one or more syslog entries 231 in the current UDP format, as specified in [1]'s Section 3. When the 232 initiator has no more entries to send, it finishes with a NUL reply 233 and closes the channel. 235 An example might appear as follows: 237 L: 238 I: 239 L: RPY 0 0 . 0 201 240 L: Content-type: application/beep+xml 241 L: 242 L: 243 L: 245 L: 246 L: 247 L: END 248 I: RPY 0 0 . 0 52 249 I: Content-type: application/beep+xml 250 I: 251 I: 252 I: END 253 I: MSG 0 1 . 52 133 254 I: Content-type: application/beep+xml 255 I: 256 I: 257 I: 258 I: 259 I: END 260 L: RPY 0 1 . 201 100 261 L: Content-type: application/beep+xml 262 L: 263 L: 264 L: END 265 L: MSG 1 0 . 0 50 266 L: 267 L: Central Services. This has not been a recording. 268 L: END 269 I: ANS 1 0 . 0 61 0 270 I: 271 I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END 272 I: ANS 1 0 . 61 58 1 273 I: 274 I: <29>Oct 27 13:22:15 ductwork imxpd[141]: Contact Tuttle.END 275 I: NUL 1 0 . 119 0 276 I: END 277 L: MSG 0 3 . 301 70 278 L: Content-Type: application/beep+xml 279 L: 280 L: 281 L: END 282 I: RPY 0 3 . 185 46 283 I: Content-Type: application/beep+xml 284 I: 285 I: 286 I: END 287 I: MSG 0 4 . 231 72 288 I: Content-Type: application/beep+xml 289 I: 290 I: 291 I: END 292 L: RPY 0 4 . 371 46 293 L: Content-type: application/beep+xml 294 L: 295 L: 296 L: END 297 L: 298 I: 299 L: 301 Here we see a BEEP session established, followed by the use of the 302 RAW profile. The initiator is a device, while the listener is a 303 collector. The initiator opens the channel, but the listener sends 304 the first MSG. This allows the initiator to send any number of ANS 305 replies carrying syslog event messages. The initiator sends a NUL 306 reply to indicate it is finished. Upon receiving the NUL, the 307 listener closes the RAW channel. The initiator has the choice of 308 closing the entire BEEP session or opening a new syslog channel (RAW 309 or COOKED) for more transfers. In this example, the initiator 310 chooses to close the entire BEEP session. 312 The overhead for one ANS frame is about thirty octets, once the 313 initial handshakes have been exchanged. If this overhead is too 314 high, then messages are likely being generated at a high rate. In 315 this case, multiple syslog messages can be aggregated into a single 316 ANS frame, each separated by a CRLF sequence from the preceding. The 317 final message still MUST NOT end with a CRLF. 319 For example, 321 L: MSG 1 0 . 0 50 322 L: 323 L: Central Services. This has not been a recording. 324 L: END 325 I: ANS 1 0 . 0 119 0 326 I: 327 I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency. 328 I: <29>Oct 27 13:21:09 ductwork imxpd[141]: Contact Tuttle.END 329 I: NUL 1 0 . 119 0 330 I: END 332 3.2 RAW Profile Identification and Initialization 334 The RAW syslog profile is identified as 335 http://xml.resource.org/profiles/syslog/RAW 336 in the BEEP "profile" element during channel creation. 338 No data is piggybacked during channel creation. 340 3.3 RAW Profile Message Syntax 342 All BEEP messages in this profile have a MIME content-type of 343 application/octet-stream. The listener's first BEEP message is 344 ignored and indeed may be empty except for headers; hence, any syntax 345 is acceptable. 347 The ANS replies the initiator sends in response MUST be formatted 348 according to Section 4 of [1]. In particular, If the receiver is 349 acting as a relay, then it MUST follow the rules as laid out in 350 Section 4.2.2 of [1]. 352 If multiple syslog messages are included in a single ANS reply, each 353 is separated from the preceding with a CRLF. There is no ending 354 delimiter, but each syslog event message body length MUST be 1024 355 bytes or less, excluding BEEP framing overhead. Note that there MUST 356 NOT be a CRLF between the text of the final syslog event message and 357 the "END" marking the trailer of the BEEP frame. 359 3.4 RAW Profile Message Semantics 361 The listener's opening BEEP MSG message has no semantics. (It is a 362 good place to put in an identifying greeting.) The initiator's ANS 363 replies MUST specify a facility, severity, and textual message, as 364 described in [1]. 366 4. The COOKED Profile 368 4.1 COOKED Profile Overview 370 The COOKED profile is designed for new implementations of syslog 371 protocol handlers. It provides a much finer grain of information 372 tagging, allowing a better degree of automation in processing. 373 Naturally, it includes more overhead as well in support of this. 375 The COOKED profile supports three elements of interest: 377 o The "iam" element identifies the sender to the receiver, allowing 378 each peer to name itself for the other, and specifying the roles 379 (device, relay, or collector) each is taking on. 381 o The "entry" element provides a parsed version of the syslog entry, 382 with the various fields of interest broken out. 384 o The "path" element identifies a list of relays through which a 385 tagged collection of "entry" elements has passed, along with a set 386 of flags indicating what assurances of security have been in 387 effect throughout its delivery. 389 4.2 COOKED Profile Identification and Initialization 391 The COOKED syslog profile is identified as 392 http://xml.resource.org/profiles/syslog/COOKED 393 in the BEEP "profile" element during channel creation. 395 During channel creation, the corresponding "profile" element in the 396 BEEP "start" element may contain an "iam" element. If channel 397 creation is successful, then before sending the corresponding reply, 398 the BEEP peer processes the "iam" element and includes the resulting 399 response in the reply. This response will be an "ok" element or an 400 "error" element. The choice of which element is returned is 401 dependant on local provisioning of the recipient. Including an "iam" 402 in the initial "start" element has exactly the same semantics as 403 passing it as the first MSG message on the channel. 405 4.3 COOKED Profile Message Syntax 407 All BEEP messages in this profile have a MIME Content-Type [6] of 408 application/beep+xml. The syntax of the individual elements is 409 specified in Section 7. 411 4.4 COOKED Profile Message Semantics 413 Initiators issue two elements: "iam" and "entry", each using a "MSG" 414 message. The listener issues "ok" in "RPY" messages and "error" in 415 "ERR" messages. (See [3]'s Section 2.3.1 for the definitions of the 416 "error" and "ok" elements.) 418 4.4.1 The IAM Element 420 The "iam" element serves to identify a device, relay, or collector at 421 one end of the BEEP channel to the device, relay, or collector at the 422 other end of the channel. The "iam" element includes the type of 423 peer (device, relay, or collector), the fully qualified domain name 424 of the peer, and an IP address of the peer. (The IP address chosen 425 SHOULD be the IP address associated with the underlying transport 426 protocol carrying the channel.) The character data of the element is 427 free-form human-readable text. It may be used to further identify 428 the peer, such as by describing the physical location of the machine. 430 An "iam" element may be sent by the initiator of the channel at any 431 time. The listener responds to an "iam" element with an "ok" 432 (indicating acceptance), or an "error" (indicating rejection). The 433 identity and role in effect is specified by the most recent "iam" 434 answered with an "ok". 436 An "iam" could be rejected (with an "error" element) by the listener 437 if the privacy or authentication that has been negotiated is 438 inadequate or if the authenticated user does not have authorization 439 to serve in the specified role. It is expected that most 440 installations will require an "iam" from the peer before accepting 441 any "entry" messages. 443 For example, a successful creation might look like this: 445 I: MSG 0 10 . 1832 259 446 I: Content-type: application/beep+xml 447 I: 448 I: 449 I: 451 I: ]]> 453 I: 454 I: 455 L: END 456 L: RPY 0 10 . 704 138 457 L: Content-type: application/beep+xml 458 L: 459 L: 460 L: ]]> 461 L: 462 L: END 464 A creation with an embedded "iam" that fails might look like this: 466 C: MSG 0 12 . 1832 259 467 C: Content-type: application/beep+xml 468 C: 469 C: 470 C: 472 C: ]]> 474 C: 475 C: 476 C: END 477 S: RPY 0 12 . 704 241 478 S: Content-type: application/beep+xml 479 S: 480 S: 481 S: User 'buttle.example.com' not allowed 483 S: to "iam" for 'tuttle.example.com' ]]> 484 S: 485 S: END 487 In this case, the error code indicates that the user 488 "buttle.example.com" has logged in via some SASL profile, but the 489 syslog COOKED profile implementation is claiming to be 490 "tuttle.example.com", a mismatch that the server is disallowing. 492 4.4.2 The ENTRY Element 494 The "entry" element carries the details of a single syslog entry. 495 The attributes of an "entry" element include "facility", "severity", 496 "timestamp", "hostname", and "tag". "Facility" and "severity" have 497 the semantics defined in [1]'s 4.1. The other attributes have the 498 semantics as in Sections 4.2.1 and 4.2.3 of [1]. An "entry" element 499 can also contain a "pathID" attribute, described below. 501 If the client is a relay, the "entry" SHOULD also contain the 502 attributes "deviceFQDN" and "deviceIP", specifying the FQDN and IP 503 address of the device that originally created the entry. These 504 attributes may be added by either the relay or the originating 505 device. If possible, the device SHOULD add these entries, referring 506 to the interface most closely associated with the syslog entry. 507 Before a relay forwards an entry from a device that does not carry 508 these attributes, it SHOULD add them based on the "iam" element it 509 has received from the device, or based on the underlying transport 510 connection address. A relay MUST NOT add these fields if they are 511 missing and an "iam" element on the channel has indicated that 512 messages are coming from another relay. 514 The "pathID" attribute indicates the path over which this entry has 515 travelled, from device through relays to the final collector. 516 Syntactically, its value is a string of digits that must match the 517 "pathID" attribute of a "path" element sent earlier over the current 518 channel. Semantically, it indicates that the list of relays and 519 flags indicated in that earlier "path" element apply to this "entry" 520 element. 522 The character data for the element is the unstructured syslog event 523 message being logged. If the original device delivers the message 524 for the first time via the COOKED profile, it may have any structure 525 inside the CDATA. However, for maximum compatibility, the device 526 SHOULD format the CDATA of the message in accordance with Sections 527 4.2.1 through 4.2.3 of [1]. 529 In the message is being relayed, "tag" SHOULD be those of the 530 original device generating the entry (unless the device cannot supply 531 a tag). The "timestamp" SHOULD be that of the original entry 532 generation time, rather than the time the entry was passed outward 533 from the relay. The "hostname" SHOULD be the host name or IP address 534 by which the device knows itself; this MUST follow the rules 535 established in Sections 4.2.1 through 4.2.3 of [1]. The original 536 contents of the syslog message MUST be preserved in the CDATA of the 537 "entry" element; this includes preservation of exact content during 538 translation from the UDP or RAW formats. In particular, the 539 timestamps MUST NOT be rewritten in the CDATA of the "entry" element, 540 the tag MUST NOT be removed from the CDATA even if presented in the 541 "entry" attributes as well, and so on. 543 To be consistent with the spirit of [1], a relay receiving a message 544 that does not contain a valid priority, timestamp or hostname will 545 follow the same general rules as desscribed in section 4.2.2 of [1] 546 while including the exact contents of the received syslog packet as 547 the CDATA. The values of the facility and severity will be construed 548 to be 8 and 6 respectively and will be placed into the appropriate 549 attributes of the "entry" element. The hostname will be the name of 550 the device as it is known to the relay and will also be inserted into 551 the "entry" element's attributes. The timestamp would be set to the 552 received time, inserted only into the attributes of the "entry" 553 element. As an example, consider this message received on UDP port 554 514 and interpreted as a traditional syslog message, assuming the 555 underlying IP source address is that of the "pipeworks" machine: 556 <.....eeeek! 558 To be relayed, it must be modified as follows: 560 C: MSG 1 0 . 2079 156 561 C: Content-Type: application/beep+xml 562 C: 563 C: <.....eeeek! 567 C: END 568 S: RPY 1 0 . 933 45 569 S: Content-Type: application/beep+xml 570 S: 571 S: 572 S: END 574 As another example, consider a message being received that does not 575 properly adhere to the conventions described in Section 4.2.2 of [1]. 576 In particular, the timestamp has a year, making it a nonstandard 577 format: 578 <166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM! 580 This would be relayed as follows: 582 C: MSG 1 0 . 2235 242 583 C: Content-Type: application/beep+xml 584 C: 585 C: <166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM! 590 C: END 591 S: RPY 1 0 . 978 45 592 S: Content-Type: application/beep+xml 593 S: 594 S: 595 S: END 597 Note that the tag value was not readily apparent from the received 598 message (due to the failed parsing of the timestamp), so it was not 599 included in the "entry" element. 601 It is explicitly permitted for a relay to parse raw messages in a 602 more sophisticated way, but all implementations MUST be able to parse 603 messages presented in the format described in [1]. A more 604 sophisticated relay could have recognised the year and completely 605 parsed out the correct time, tag, and hostname, but such additional 606 parsing capability is OPTIONAL. 608 Consider the following example, in contrast: 609 <166> Oct 22 01:00:00 bomb tick[0]: BOOM! 611 This conformant message would be relayed as follows: 613 C: MSG 1 0 . 2477 248 614 C: Content-Type: application/beep+xml 615 C: 616 C: <166> Oct 22 01:00:00 bomb tick[0]: BOOM! 621 C: END 622 S: RPY 1 0 . 1023 45 623 S: Content-Type: application/beep+xml 624 S: 625 S: 626 S: END 628 In this case, the tag is detected and the timestamp represents the 629 message generation time rather than the message reception time. 631 Finally, the "entry" element may also contain an "xml:lang" 632 attribute, indicating the language in which the CDATA content of the 633 tag is presented, as described in [7]. 635 The "entry" element is answered with either an empty "ok" element if 636 everything was successful, or a standard "error" element if there was 637 a problem. An "entry" element can be rejected if no "iam" element 638 has been accepted by the listener. It can also be rejected if the 639 user authenticated on the BEEP session (if any) does not have the 640 authority to generate (as a device) or relay that entry. An error is 641 also possible if the "pathID" attribute refers to an unknown (or 642 rejected) "path" element. 644 A successful exchange of an "entry" element may look like this: 646 C: MSG 1 0 . 2725 173 647 C: Content-Type: application/beep+xml 648 C: 649 C: 652 C: No 27B/6 available 653 C: END 654 S: RPY 1 0 . 1068 45 655 S: Content-Type: application/beep+xml 656 S: 657 S: 658 S: END 660 Here, the device IP address and FQDN are taken from the "iam" 661 element, if any, or from the underlying connection information. 663 An example where an "entry" element is rejected with an "error" 664 element: 666 C: MSG 1 2 . 2898 223 667 C: Content-Type: application/beep+xml 668 C: 669 C: 672 C: Replacement device found in nostril. 673 C: 674 C: END 675 S: ERR 1 2 . 1113 111 676 S: Content-Type: application/beep+xml 677 S: 678 S: Not allowed to relay for 679 S: jack.example.net 680 S: END 682 Here, the client attempts to relay an entry on behalf of 683 jack.example.com, but the entry is refused by the collector for 684 administrative reasons. This may occur, for example, if 685 lowry.example.com is in a different department than jack.example.com. 687 4.4.3 The PATH Element 689 The "path" element serves to describe a list of the relays through 690 which that element has passed, along with a set of flags that 691 indicate the properties that all links from the device to the relay 692 have shared in common. Each "path" element contains either another 693 "path" element or is empty. An empty "path" element identifies a 694 device, while a "path" element with a nested "path" element 695 identifies a relay. Each "path" element names a FQDN and IP address 696 of the interface that sent the element. Each "path" element also 697 names a FQDN and IP address for the interface that received the 698 element. Each "path" element also carries a "linkprops" attribute, 699 specifying the properties of the link it describes. 701 Each "path" element has a "pathID" attribute which must be unique for 702 all "path" elements sent on this channel since its inception. 703 Syntactically, the "pathID" attribute is a string of digits. 704 Semantically, it serves to identify one "path" element out of many, 705 and it serves to link a "path" element with one or more "entry" 706 elements. Any "pathID" attribute is unrelated to any "pathID" 707 attribute in nested "path" elements or on other channels. 709 Each "path" element has a "fromFQDN" attribute and an "fromIP" 710 attribute. The "fromFQDN" attribute SHOULD be the fully qualified 711 domain name of the interface over which the "path" element was sent. 712 (The "fromFQDN" can be omitted if that interface has no DNS entry.) 713 Similarly, the "fromIP" attribute MUST be the IP address of the 714 interface over which the "path" element was sent. 716 Each "path" element has a "toFQDN" attribute and an "toIP" attribute. 717 The "toFQDN" attribute SHOULD be the fully qualified domain name of 718 the interface over which the "path" element was received. (The 719 "toFQDN" can be omitted if that interface has no DNS entry.) 720 Similarly, the "toIP" attribute MUST be the IP address of the 721 interface over which the "path" element was received. 723 Finally, each "path" element carries a "linkprops" attribute. This 724 is syntactically a string of individual characters, each indicating 725 one property of the channel over which this "path" element is being 726 carried. Note that outer "path" elements may have stronger 727 guarantees than inner "path" elements; care should be taken in the 728 interpretation of flags. The semantics of each possible character in 729 this string are as follows: 731 o When present, "o" indicates that weak privacy has been negotiated 732 over this link, weakly protecting from observation the content of 733 entries associated with this "path" element. (Weak privacy is 734 encryption with less than 80 bits of key.) 736 O When present, "O" indicates that strong privacy has been negotiated 737 over this link, strongly protecting from observation the content 738 of entries associated with this "path" element. (Strong privacy 739 is encryption with 80 bits or more of key, or a transfer mechanism 740 that is otherwise impossible to eavesdrop upon.) 742 U When present, "U" indicates that a valid user has been 743 authenticated (via SASL or TLS) and an "iam" element has been 744 accepted. 746 A When present, "A" indicates that this link has been protected by an 747 authentication layer, authenticating the source of every "entry" 748 associated with this path. 750 R When present, "R" indicates that this link has been protected 751 against message replay. 753 I When present, "I" indicates that this link has been protected 754 against modifications of messages in passing. ("I" stands for 755 message Integrity.) 757 L When present, "L" indicates that this link has been protected 758 against loss of messages. That is, this is a reliable delivery 759 link. 761 D When present, "D" indicates that the "from" side of this link is a 762 device. If this is not present on the innermost "path" element, 763 "entry" elements associated with this path have not been carried 764 by the COOKED profile for their entire lifetime. 766 Upon receiving a "path" element, the peer MUST perform the following 767 checks: 769 o The "fromFQDN" and "fromIP" must match the underlying transport 770 connection. 772 o The flags in the "linkprops" attribute must match the attributes 773 of the session. 775 o The "toFQDN" and "toIP" must match the underlying transport 776 connection. 778 o The "pathID" attribute must be unique with respect to all other 779 "path" elements received on this channel. 781 If all these checks pass, the "path" element is accepted with an "ok" 782 element. Otherwise, an "error" element is generated with an 783 appropriate code. In addition, if any of the nested "path" elements 784 refer to the machine receiving the element, it may indicate a routing 785 loop in the configuration for the so-identified path, and appropriate 786 measures should be taken. 788 If the peer receiving an "entry" element is receiving it directly 789 from a device via either syslog-reliable profile, and the device has 790 not generated a "path" element, the receiver may itself generate an 791 appropriate "path" element, either to be recorded in the logs (if 792 this peer is a collector) or passed to the next peer (if this peer is 793 a relay). If a peer receives a syslog message via UDP, it may 794 optionally generate an appropriate "peer" element based on any 795 cryptographic information provided in the message itself. 797 When a peer receives a "path" element, it remembers it for future 798 use. A collector will store it in the log for later reference. A 799 relay will remember it. When an "entry" arrives referencing the 800 received "path" element, and that entry needs to be forwarded to 801 another relay or collector, and no appropriate "path" element has 802 already been generated, an appropriate "path" element is generated 803 and sent over the outbound channel before the entry is forwarded. An 804 appropriate "path" element is created by taking the received "path" 805 element, wrapping it in a new "path" element with the appropriate 806 attributes, and assigning it a new "pathID" attribute. When future 807 "entry" elements arrive with the same incoming "pathID" attribute, 808 and they need to be forwarded to a channel over which an appropriate 809 "pathID" attribute has already been sent, only the "pathID" attribute 810 of the "entry" element needs to be rewritten to refer to the "path" 811 element on the outgoing channel. 813 It should be noted that the majority of the complexity in managing 814 "path" elements arises only in relays. In particular, devices never 815 need to generate "path" elements and collectors need only verify 816 them, log them, and possibly use them in displays and reports. 817 Collectors do not need to generate "path" elements or rewrite "entry" 818 elements. Hence, only in complex configurations (where they are most 819 useful) do complex "path" configurations occur. 821 For example, here is a path element sent from 822 lowry.records.example.com to kurtzman.records.example.com. It 823 indicates that entries from lowry to kurtzman tagged with 824 pathID='173' originated from screen.lowry.records.example.com. It 825 indicates that screen.lowry.records.example.com is believed by 826 lowry.records.example.com to be the originating device, and that 827 entries over this path are delivered without loss and without 828 modification, although messages might be replayed or observed. The 829 link between lowry and kurtzman, however, avoids replay attacks, lost 830 messages, and modifications to messages. While 831 screen.lowry.records.example.com has not authenticated itself to 832 lowry.records.example.com, lowry claims to have authenticated itself 833 to kurtzman. 835 C: MSG 2 1 . 3121 426 836 C: Content-type: application/beep+xml 837 C: 838 C: 844 C: 850 C: 851 C: 852 C: END 853 S: ERR 2 1 . 1224 114 854 S: Content-type: application/beep+xml 855 S: 856 S: linkprops includes 'U' 857 S: but no 'iam' received 858 S: END 860 However, kurtzman.records.example.com rejects the "path" element, 861 since the "linkprops" attribute claims that lowry has authenticated 862 itself, but kurtzman disagrees, not having received an "iam" element. 864 In a second example, this "path" element informs 865 collector.example.com that the records department's firewall will be 866 forwarding "entry" elements with a "pathID" attribute whose value is 867 "17". These "entry" elements will be coming in on the "10.0.0.2" 868 interface of the firewall, to be forwarded out the "134.130.74.56" 869 interface of the firewall. The final hop has all possible 870 guarantees, although the entries transferred within the records 871 department (behind the firewall) may have been observed in passing. 873 C: MSG 2 2 . 3547 813 874 C: Content-type: application/beep+xml 875 C: 876 C: 882 C: 888 C: 894 C: 900 C: 901 C: END 902 S: RPY 2 2 . 1338 45 903 S: Content-type: application/beep+xml 904 S: 905 S: 906 S: END 908 As a final example, an "entry" element from Lowry's screen arrives at 909 the firewall. The "path" attribute is rewritten, and it is forwarded 910 on to the collector. 912 The entry arrives on the 10.0.0.2 interface: 914 C: MSG 2 3 . 4360 250 915 C: Content-Type: application/beep+xml 916 C: 917 C: 923 C: Job paused - Boss watching. 924 C: 925 C: END 926 S: RPY 2 3 . 1383 45 927 S: Content-Type: application/beep+xml 928 S: 929 S: 930 S: END 932 It is forwarded out the 134.130.74.56 interface: 934 C: MSG 7 9 . 9375 276 935 C: Content-Type: application/beep+xml 936 C: 937 C: 1090 %SYSLOG; 1091 --> 1093 1108 1115 1117 1119 %BEEP; 1121 1140 1167 1168 1169 1170 1171 1172 1174 1182 1183 1188 1192 1193 1203 1208 1209 1217 1219 8. Reply Codes 1221 The following error codes are used in the protocol: 1223 code meaning 1224 ==== ======= 1225 200 success 1227 421 service not available 1229 451 requested action aborted 1230 (e.g., local error in processing) 1232 454 temporary authentication failure 1234 500 general syntax error 1235 (e.g., poorly-formed XML) 1237 501 syntax error in parameters 1238 (e.g., non-valid XML) 1240 504 parameter not implemented 1242 530 authentication required 1244 534 authentication mechanism insufficient 1245 (e.g., too weak, sequence exhausted, etc.) 1247 535 authentication failure 1249 537 action not authorized for user 1251 538 authentication mechanism requires encryption 1253 550 requested action not taken 1254 (e.g., no requested profiles are acceptable) 1256 553 parameter invalid 1258 554 transaction failed 1259 (e.g., policy violation) 1261 9. IANA Considerations 1263 9.1 Registration: BEEP Profiles 1265 If the IESG approves this memo for publication, then the IANA 1266 registers the profiles specified in Section 6, and selects IANA- 1267 specific URIs, e.g., "http://iana.org/beep/SYSLOG/RAW" and 1268 "http://iana.org/beep/SYSLOG/COOKED". 1270 9.2 Registration: The System (Well-Known) TCP port number for syslog- 1271 reliable 1273 A single well-known port is allocated to syslog-reliable. In-band 1274 negotiation determines whether COOKED or RAW syslog-reliable is in 1275 use. 1277 Protocol Number: TCP 1279 Message Formats, Types, Opcodes, and Sequences: See Section 3.3 and 1280 Section 4.4. 1282 Functions: See Section 3.4 and Section 4.4. 1284 Use of Broadcast/Multicast: none 1286 Proposed Name: Reliable syslog service 1288 Short name: syslog-reliable 1290 Contact Information: See the "Authors' Addresses" section of this 1291 memo 1293 10. Security Considerations 1295 Consult Section 6 of [1] for a discussion of security issues for the 1296 syslog service. In addition, since the RAW and COOKED profiles are 1297 defined using the BEEP framework, consult [3]'s Section 8 for a 1298 discussion of BEEP-specific security issues. 1300 BEEP is used to provide communication security but not object 1301 integrity. In other words, the messages "on the wire" can be 1302 protected, but a compromised device may undetectably generate 1303 incorrect messages, and relays and collectors can modify, insert, or 1304 delete messages undetectably. Other techniques must be used to 1305 assure that such compromises are detectable. 1307 References 1309 [1] Lonvick, C., "The BSD Syslog Protocol", draft-ietf-syslog- 1310 syslog-12 (work in progress), May 2001. 1312 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1313 Levels", BCP 14, RFC 2119, March 1997. 1315 [3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 1316 3080, March 2001. 1318 [4] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 1319 2001. 1321 [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1322 specifying the location of services (DNS SRV)", RFC 2782, 1323 February 2000. 1325 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1326 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1327 1996. 1329 [7] Alvestrand, H., "Tags for the Identification of Languages", RFC 1330 1766, March 1995. 1332 [8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 1333 Mechanism", RFC 2831, May 2000. 1335 Authors' Addresses 1337 Darren New 1338 Invisible Worlds, Inc. 1339 131 Stony Circle 1340 Suite 500 1341 Santa Rosa, CA 95401 1342 US 1344 Phone: +1 707 578 2350 1345 EMail: dnew@invisible.net 1346 URI: http://invisible.net/ 1347 Marshall T. Rose 1348 Invisible Worlds, Inc. 1349 131 Stony Circle 1350 Suite 500 1351 Santa Rosa, CA 95401 1352 US 1354 Phone: +1 707 578 2350 1355 EMail: mrose@invisible.net 1356 URI: http://invisible.net/ 1358 Appendix A. Acknowledgements 1360 The authors gratefully acknowledge the contributions of Christopher 1361 Calabrese, Keith McCloghrie, Balazs Scheidler, and David Waitzman. 1363 Full Copyright Statement 1365 Copyright (C) The Internet Society (2001). All Rights Reserved. 1367 This document and translations of it may be copied and furnished to 1368 others, and derivative works that comment on or otherwise explain it 1369 or assist in its implementation may be prepared, copied, published 1370 and distributed, in whole or in part, without restriction of any 1371 kind, provided that the above copyright notice and this paragraph are 1372 included on all such copies and derivative works. However, this 1373 document itself may not be modified in any way, such as by removing 1374 the copyright notice or references to the Internet Society or other 1375 Internet organizations, except as needed for the purpose of 1376 developing Internet standards in which case the procedures for 1377 copyrights defined in the Internet Standards process must be 1378 followed, or as required to translate it into languages other than 1379 English. 1381 The limited permissions granted above are perpetual and will not be 1382 revoked by the Internet Society or its successors or assigns. 1384 This document and the information contained herein is provided on an 1385 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1386 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1387 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1388 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1389 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1391 Acknowledgement 1393 Funding for the RFC Editor function is currently provided by the 1394 Internet Society.