idnits 2.17.1 draft-ietf-syslog-syslog-06.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 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 -- 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 (February 2001) is 8470 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 section? '1' on line 238 looks like a reference -- Missing reference section? '2' on line 339 looks like a reference -- Missing reference section? '3' on line 341 looks like a reference -- Missing reference section? '4' on line 696 looks like a reference -- Missing reference section? '5' on line 583 looks like a reference -- Missing reference section? '10' on line 983 looks like a reference -- Missing reference section? '0' on line 712 looks like a reference -- Missing reference section? '6' on line 729 looks like a reference -- Missing reference section? '7' on line 981 looks like a reference -- Missing reference section? '8' on line 929 looks like a reference -- Missing reference section? '9' on line 982 looks like a reference -- Missing reference section? '11' on line 1022 looks like a reference -- Missing reference section? '12' on line 1068 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Lonvick 2 Document: draft-ietf-syslog-syslog-06.txt Cisco Systems 3 Expires: August, 2001 February 2001 5 Syslog Protocol 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 This work is a product of the IETF syslog Working Group. More 28 information about this effort may be found at 29 http://www.ietf.org/html.charters/syslog-charter.html 30 Comments about this draft should be directed to the syslog working 31 group at the mailing list of syslog-sec@employees.org. 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119. 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 Abstract 43 This draft describes the observed behavior of the syslog protocol. 44 This protocol has been used for the transmission of event 45 notification messages across networks for many years. 47 syslog Protocol February 2001 49 Table of Contents 51 Status of this Memo................................................1 52 Copyright Notice...................................................1 53 Abstract...........................................................1 54 1. Introduction....................................................3 55 1.1 Events and Generated Messages..................................4 56 1.2 Operations of the Message Receivers............................5 57 2. Transport Layer Protocol........................................5 58 3. Definitions and Architecture....................................6 59 4. Packet Format and Contents......................................8 60 4.1 PRI Part of a syslog Packet....................................8 61 4.2 MSG Part of a syslog Packet...................................10 62 4.2.1 Original syslog Packets.....................................11 63 4.2.2 Relayed syslog Packets......................................11 64 4.2.3 Formats of the Fields in the MSG............................12 65 5. Conventions....................................................13 66 5.1 Dates and Times...............................................13 67 5.2 Domain Name and Address.......................................13 68 5.3 Originating Process Information...............................14 69 5.4 Examples......................................................14 70 6. Security Considerations........................................16 71 6.1 Packet Parameters.............................................16 72 6.2 Message Authenticity..........................................17 73 6.3 Sequenced Delivery............................................18 74 6.3.1 Single Source to a Destination..............................18 75 6.3.2 Multiple Sources to a Destination...........................19 76 6.3.3 Multiple Sources to Multiple Destinations...................19 77 6.3.4 Replaying...................................................19 78 6.4 Reliable Delivery.............................................20 79 6.5 Message Integrity.............................................20 80 6.6 Message Observation...........................................20 81 6.7 Message Prioritization and Differentiation....................20 82 6.8 Misconfiguration..............................................22 83 6.9 Forwarding Loop...............................................22 84 6.10 Load Considerations..........................................22 85 7. Conclusion and Other Efforts...................................22 86 Acknowledgements..................................................23 87 References........................................................24 88 Author's Addresses................................................24 89 Full Copyright Statement..........................................25 90 syslog Protocol February 2001 92 1. Introduction 94 Since the beginning, life has relied upon the transmission of 95 messages. For the self-aware organic unit, these messages can relay 96 many different things. The messages may signal danger, the presence 97 of food or the other necessities of life, and many other things. In 98 many cases, these messages are informative to other units and 99 require no acknowledgement. As people interacted and created 100 processes, this same principle was applied to societal 101 communications. As an example, severe weather warnings may be 102 delivered through any number of channels - a siren blowing, warnings 103 delivered over television and radio stations, and even through the 104 use of flags on ships. The expectation is that people hearing or 105 seeing these warnings would realize their significance and take 106 appropriate action. In most cases, no responding acknowledgement of 107 receipt of the warning is required or even desired. Along these 108 same lines, operating systems, processes and applications were 109 written to send messages of their own status, or messages to 110 indicate that certain events had occurred. These event messages 111 generally had local significance to the machine operators. As the 112 operating systems, processes and applications grew ever more 113 complex, systems were devised to categorize and log these diverse 114 messages and allow the operations staff to more quickly 115 differentiate the notifications of problems from simple status 116 messages. The syslog process was one such system that has been 117 widely accepted in many operating systems. Flexibility was designed 118 into this process so the operations staff have the ability to 119 configure the destination of messages sent from the processes 120 running on the device. In one dimension, the events that were 121 received by the syslog process could be logged to different files 122 and also displayed on the console of the device. In another 123 dimension, the syslog process could be configured to forward the 124 messages across a network to the syslog process on another machine. 125 The syslog process had to be built network-aware for some modicum of 126 scalability since it was known that the operators of multiple 127 systems would not have the time to access each system to review the 128 messages logged there. The syslog process running on the remote 129 devices could therefore be configured to either add the message to a 130 file, or to subsequently forward it to another machine. 132 In its most simplistic terms, the syslog protocol provides a 133 transport to allow a machine to send event notification messages 134 across IP networks to event message collectors -also known as syslog 135 servers. Since each process, application and operating system was 136 written somewhat independently, there is little uniformity to the 137 content of syslog messages. For this reason, no assumption is made 138 upon the formatting or contents of the messages. The protocol is 139 simply designed to transport these event messages. In all cases, 140 there is one device that originates the message. The syslog process 141 on that machine may send the message to a collector. No 142 acknowledgement of the receipt is made. 144 syslog Protocol February 2001 146 One of the fundamental tenants of the syslog protocol and process is 147 its simplicity. No stringent coordination is required between the 148 transmitters and the receivers. Indeed, the transmission of syslog 149 messages may be started on a device without a receiver being 150 configured, or even actually physically present. Conversely, many 151 devices will most likely be able to receive messages without 152 explicit configuration or definitions. This simplicity has greatly 153 aided the acceptance and deployment of syslog. 155 1.1 Events and Generated Messages 157 The writers of the operating systems, processes and applications 158 have had total control over the circumstances that would generate 159 any message. In some cases, messages are generated to give status. 160 These can be either at a certain period of time, or at some other 161 interval such as the invocation or exit of a program. In other 162 cases, the messages may be generated due to a set of conditions 163 being met. In those cases, either a status message or a message 164 containing an alarm of some type may be generated. It was 165 considered that the writers of the operating systems, processes and 166 applications would quantify their messages into one of several broad 167 categories. These broad categories generally consist of the 168 facility that generated them, along with an indication of the 169 severity of the message. This was so that the operations staff 170 could selectively filter the messages and be presented with the more 171 important and time sensitive notifications quickly, while also 172 having the ability to place status or informative messages in a file 173 for later perusal. Other options for displaying or storing 174 messages have been seen to exist as well. 176 Devices MUST be configured with rules for displaying and/or 177 forwarding the event messages. The rules that have been seen are 178 generally very flexible. An administrator may want to have all 179 messages stored locally as well as to have all messages of a high 180 severity forwarded to another device. They may find it appropriate 181 to also have messages from a particular facility sent to some or all 182 of the users of the device and displayed on the system console. 183 However the administrator decides to configure the disposition of 184 the event messages, the process of having them sent to a syslog 185 collector generally consists of deciding which facility messages and 186 which severity levels will be forwarded, and then defining the 187 remote receiver. For example, an administrator may want all 188 messages that are generated by the mail facility to be forwarded to 189 one particular event message collector. Then the administrator may 190 want to have all kernel generated messages sent to a different 191 syslog receiver while, at the same time, having the critically 192 severe messages from the kernel also sent to a third receiver. It 193 may also be appropriate to have those messages displayed on the 194 system console as well as being mailed to some appropriate people, 195 while at the same time, being sent to a file on the local disk of 196 the device. Conversely, it may be appropriate to have messages from 197 a locally defined process only displayed on the console but not 198 syslog Protocol February 2001 200 saved or forwarded from the device. In any event, the rules for 201 this will have to be generated on the device. Since the 202 administrators will then know which types of messages will be 203 received on the collectors, they should then make appropriate rules 204 on those syslog servers as well. 206 The contents of a message have also been at the discretion of its 207 creator. It has been considered to be good form to write the 208 messages so that they are informative to the person who may be 209 reading them. It has also been considered good practice to include 210 a timestamp and some indication of the sending device and the 211 process that originated it in the messages. However, none of those 212 are stringently required. 214 It should be assumed that any process on any device might generate 215 an event message. This may include processes on machines that do 216 not have any local storage - e.g. printers, routers, hubs, switches, 217 and diskless workstations. In that case, it may be imperative that 218 event messages are transported to a collector so that they may be 219 recorded and hopefully viewed by an operator. 221 1.2 Operations of the Message Receivers 223 It is beyond the scope of this Internet Draft to specify how event 224 messages should be processed when they are received. Like the 225 operations described in Section 1.1, they generally may be displayed 226 to the appropriate people, saved onto disk, further forwarded, or 227 any combination of these. The rules for determining the disposition 228 of received messages have been seen to be identical to the rules for 229 determining the disposition of locally generated messages. 231 As a very general rule, there are usually many devices sending 232 messages to relatively fewer collectors. This fan-in process allows 233 an administrator to aggregate messages into relatively few 234 repositories. 236 2. Transport Layer Protocol 238 syslog uses the user datagram protocol (UDP) [1] as its underlying 239 transport layer mechanism. The UDP port that has been assigned to 240 syslog is 514. It is RECOMMENDED that the source port also be 514 241 to indicate that the message is from the syslog process of the 242 sender, but there have been cases seen where valid syslog messages 243 have come from a sender with a source port other than 514. If the 244 sender uses a source port other than 514 then it is RECOMMENDED and 245 has been considered to be good form that subsequent messages are 246 from a single consistent port. 248 syslog Protocol February 2001 250 3. Definitions and Architecture 252 The following definitions will be used in this document. 254 A machine that can generate a message will be called a 255 "device". 257 A machine that can receive the message and forward it to 258 another machine will be called a "relay". 260 A machine that receives the message and does not relay it to 261 any other machines will be called a "collector". This has been 262 commonly known as a "syslog server". 264 Any device or relay will be known as the "sender" when it sends 265 a message. 267 Any relay or collector will be known as the "receiver" when it 268 receives the message. 270 The architecture of the devices may be summarized as follows: 272 Devices send messages to relays or collectors with no knowledge 273 of whether it is a collector or relay. 275 Devices and relays may be configured to send the same message 276 to multiple receivers. 278 syslog Protocol February 2001 280 The following architectures shown in Diagram 1 are valid while the 281 first one has been known to be the most prevalent. Other 282 arrangements of these examples are also acceptable. 284 +------+ +---------+ 285 |Device|---->----|Collector| 286 +------+ +---------+ 288 +------+ +-----+ +---------+ 289 |Device|---->----|Relay|---->----|Collector| 290 +------+ +-----+ +---------+ 292 +------+ +-----+ +-----+ +---------+ 293 |Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector| 294 +------+ +-----+ +-----+ +---------+ 296 +------+ +-----+ +---------+ 297 |Device|---->----|Relay|---->----|Collector| 298 | |-\ +-----+ +---------+ 299 +------+ \ 300 \ +-----+ +---------+ 301 \-->--|Relay|---->----|Collector| 302 +-----+ +---------+ 304 +------+ +---------+ 305 |Device|---->----|Collector| 306 | |-\ +---------+ 307 +------+ \ 308 \ +-----+ +---------+ 309 \-->--|Relay|---->----|Collector| 310 +-----+ +---------+ 312 +------+ +-----+ +---------+ 313 |Device|---->----|Relay|---->-------|Collector| 314 | |-\ +-----+ /--| | 315 +------+ \ / +---------+ 316 \ +-----+ / 317 \-->--|Relay|-->--/ 318 +-----+ 320 Diagram 1. Some Possible syslog Architectures 321 syslog Protocol February 2001 323 4. Packet Format and Contents 325 The syslog packet has two parts. The first part is the PRI and the 326 second part is the MSG. The PRI has three, four, five, or six 327 characters. The MSG will fill the remainder of the syslog packet. 328 There is no ending delimiter but the total length of the packet MUST 329 be 1024 bytes or less. There is no minimum length of the MSG 330 although sending a syslog packet with no contents is worthless and 331 SHOULD NOT be done. The MSG part of the packet has additional 332 fields that are described in Section 4.2 below. 334 4.1 PRI Part of a syslog Packet 336 The PRI part starts with a leading "<" ('less-than' character), 337 followed by a number, which is followed by a ">" ('greater-than' 338 character). The code set used in this part MUST be seven-bit ASCII 339 in an eight-bit field as described in RFC 2234 [2]. These are the 340 ASCII codes as defined in "USA Standard Code for Information 341 Interchange" [3]. In this, the "<" character is defined as the 342 Augmented Backus-Naur Form (ABNF) %d60, and the ">" character has 343 ABNF value %d62. The number contained within these angle brackets 344 is known as the Priority code and represents both the Facility and 345 Severity as described below. The Priority code consists of one, 346 two, or three decimal integers (ABNF DIGITS) using values of %d48 347 (for "0") through %d57 (for "9"). 349 syslog Protocol February 2001 351 The Facilities and Severities of the messages are numerically coded 352 with decimal values. The operating system and some of the daemons 353 and processes have been assigned a Facility parameter. Processes 354 and applications that have not been assigned a Facility, or that 355 have not been configured to use one of the "local use" Facilities 356 SHOULD use the "user" Facility which has the numerical Facility code 357 of decimal 8. All Facilities are shown in the following table along 358 with their numerical code values. 360 Numerical Facility 361 Code 363 0 kernel messages 364 8 user-level messages 365 16 mail system 366 24 system daemons 367 32 security/authorization messages (note 1) 368 40 messages generated internally by syslogd 369 48 line printer subsystem 370 56 network news subsystem 371 64 UUCP subsystem 372 72 clock daemon (note 2) 373 80 security/authorization messages (note 1) 374 88 FTP daemon 375 96 NTP subsystem 376 104 log audit (note 1) 377 112 log alert (note 1) 378 120 clock daemon (note 2) 379 128 local use 0 (local0) 380 136 local use 1 (local1) 381 144 local use 2 (local2) 382 152 local use 3 (local3) 383 160 local use 4 (local4) 384 168 local use 5 (local5) 385 176 local use 6 (local6) 386 184 local use 7 (local7) 388 Table 1. syslog Message Facilities 390 Note 1 - Various operating systems have been found to utilize 391 Facilities 32, 80, 104 and 112 for security/authorization, 392 audit and alert messages which seem to be similar. 393 Note 2 - Various operating systems have been found to utilize 394 both Facilities 72 and 120 for clock (cron/at) messages. 396 syslog Protocol February 2001 398 Each message Priority also has a decimal Severity level indicator. 399 These are described in the following table along with their 400 numerical values. 402 Numerical Severity 403 Code 405 0 Emergency: system is unusable 406 1 Alert: action must be taken immediately 407 2 Critical: critical conditions 408 3 Error: error conditions 409 4 Warning: warning conditions 410 5 Notice: normal but significant condition 411 6 Informational: informational messages 412 7 Debug: debug-level messages 414 Table 2. syslog Message Severities 416 The Priority code is calculated by summing the numerical values of 417 the codes of the Facility and Severity. For example, a kernel 418 message with a Severity of Emergency would have a Priority code of 419 0, while a "local use 4" message with a Severity of Notice would 420 have a Priority code of 165. In the PRI part of a syslog message, 421 these values would be placed between the angle brackets as <0> and 422 <165> respectively. 424 4.2 MSG Part of a syslog Packet 426 The MSG part of the syslog packet MUST contain visible (printing) 427 characters. The code set traditionally and most often used has also 428 been seven-bit ASCII in an eight-bit field like that used in the PRI 429 part. In this code set, the only allowable characters are the ABNF 430 VCHAR values (%d33-126) and spaces (SP value %d32). However, no 431 indication of the code set used within the MSG is required, nor is 432 it expected. Other code sets MAY be used as long as the characters 433 used in the MSG are exclusively visible characters and spaces 434 similar to those described above. The selection of a code set used 435 in the MSG SHOULD be made with thoughts of the intended receiver. A 436 message containing characters in a code set that cannot be viewed by 437 a recipient will yield no information of value to an operator or 438 administrator looking at it. 440 syslog Protocol February 2001 442 Any device receiving a syslog packet MUST check that the packet 443 conforms to a specific format. If the format is apparent and the 444 fields valid, then the relay SHALL NOT make any changes to the 445 received packet before sending it onwards. However, if the format 446 is not apparent or if the fields are invalid, then the relay SHALL 447 change the format of the MSG before retransmitting it but only in 448 ways specified in section 4.2.2. 450 4.2.1 Original syslog Packets 452 A device SHOULD compose a syslog packet with the PRI and the MSG. 453 There are no set requirements on the contents of the MSG as it is 454 originally sent from a device. It is RECOMMENDED that the MSG have 455 the following fields: TIMESTAMP, HOSTNAME, TAG and then the CONTEXT. 456 Space characters MUST follow the TIMESTAMP and HOSTNAME fields. The 457 contents of these fields are described here and their formats are 458 detailed in Section 4.2.3. 460 If the originally formed message has a TIMESTAMP, then it is the 461 local time of the device. 463 If the originally formed message has a HOSTNAME field, then it will 464 contain the hostname, as it knows itself. If it does not have a 465 hostname, then it will contain its own IP address. If a device has 466 multiple IP addresses, then it has been seen to usually use the IP 467 address from which the message is transmitted. 469 If the originally formed message has a TAG value, then that will be 470 the name of the program or process that generated the message. 472 The CONTEXT contains the details of the message. This has 473 traditionally been a freeform message that gives some detailed 474 information of the event. 476 4.2.2 Relayed syslog Packets 478 When a relay receives a packet, it will check for a valid PRI. If 479 the first character is not a less-than sign, the relay MUST assume 480 that the packet does not contain a valid PRI. If the 3rd, 4th, or 481 5th character is not a greater-than sign, the relay again MUST 482 assume that the PRI is not valid. If the relay has been configured 483 to forward packets with a Priority value of 14 (User Facility=8 and 484 Informational Severity=6) then the relay MUST insert a PRI with a 485 Priority value of 14 as well as a MSG as described below. The 486 contents of the received packet will be treated as the CONTEXT of 487 the MSG and appended. This new packet will be sent to the next 488 relay or collector. 490 If the relay finds a valid PRI then it will check its internal 491 configuration. Relays MUST be configured to forward syslog packets 492 on the basis of their Priority value. If the relay finds that it is 493 syslog Protocol February 2001 495 configured to forward the received packet, then it MUST check for a 496 valid TIMESTAMP as the first field in the MSG. If it finds a valid 497 TIMESTAMP, then it MUST relay the entire packet unchanged. However, 498 if it does not find a valid TIMESTAMP, then it MUST add a TIMESTAMP 499 followed by a space character. It SHOULD additionally add a 500 HOSTNAME and a space character. These fields are described here and 501 detailed in Section 4.2.3. The remainder of the received packet 502 MUST be treated as the CONTEXT field of the MSG and appended. Since 503 the relay would have no way to determine the originating process 504 from the device that originated the message, the TAG value cannot be 505 determined and will not be included. 507 The TIMESTAMP will be the current local time of the relay. 509 The HOSTNAME will be the name of the device, as it is known by the 510 relay. If the name cannot be determined, the IP address of the 511 device will be used. The Domain Name MUST NOT be included in the 512 HOSTNAME field. 514 If the relay adds a TIMESTAMP and HOSTNAME at the front of the MSG 515 then it MUST check that the total length of the packet is still 1024 516 bytes or less. If the packet has been expanded beyond 1024 bytes, 517 then the relay MUST truncate the packet to be 1024 bytes. This may 518 cause the loss of vital information from the end of original packet. 519 It is for this reason that it is RECOMMENDED that the PRI and MSG 520 parts of originally generated syslog packets contain the values and 521 fields documented in Section 4.2.1. 523 4.2.3 Formats of the Fields in the MSG 525 The TIMESTAMP field is in the format of "Mmm dd hh:mm:ss" (without 526 the quote marks) where: 528 Mmm is the English language abbreviation for the month of the 529 year with the first character in uppercase and the other two 530 characters in lowercase. The following are the only acceptable 531 values: 532 Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec 534 dd is the day of the month. If the day of the month is less 535 than 10, then it MUST be represented as a space and then the 536 number. 538 hh:mm:ss is the local time. The hour (hh) is represented in a 539 24-hour format. Valid entries are between 00 and 23, 540 inclusive. The minute (mm) and second (ss) entries are between 541 00 and 59 inclusive. 543 A space character MUST follow the TIMESTAMP field. 545 syslog Protocol February 2001 547 The HOSTNAME field MUST contain the hostname of the device as 548 specified in STD-13 [4]. A space character MUST also follow the 549 hostname to terminate this field. 551 The TAG is a string of ABNF alphanumeric characters that MUST NOT 552 exceed 32 characters. Any non-alphanumeric character will terminate 553 the TAG field and will be assumed to be the starting character of 554 the CONTEXT field. Most commonly, the first character of the 555 CONTEXT field that signifies the conclusion of the TAG field has 556 been seen to be the left square bracket character ("["), a colon 557 character (":"), or a space character. This is explained in more 558 detail in Section 5.3. 560 The CONTEXT field may fill the remainder of the MSG field. 562 5. Conventions 564 Although Section 4 of this document specifies all requirements for 565 the syslog protocol format and contents, certain conventions have 566 come about over time for the inclusion of additional information 567 within the syslog message. It must be plainly stated that these 568 items are not mandated but may be included for completeness and to 569 give the recipient some additional clues of their origin and nature. 571 5.1 Dates and Times 573 It has been found that some network administrators like to archive 574 their syslog messages over long periods of time. For the 575 convenience of these people and for automated message parsers, a 576 more explicit time stamp has been seen to have been added to some 577 messages. Some devices will send an original syslog message with a 578 2 character or 4 character year field immediately after the space 579 terminating the TIMESTAMP. This is not consistent with the original 580 intent of the order and format of the fields. If implementers wish 581 to contain a more specific date and time stamp within the message, 582 it should be within the CONTEXT field. Implementers may wish to 583 utilize the ISO 8601 [5] date and time formats if they want to 584 include more explicit date and time information. 586 5.2 Domain Name and Address 588 To readily identify the device that originated the message, it may 589 be a good practice to include its fully qualified domain name (FQDN) 590 and its IP address within the CONTEXT field. Traditionally, 591 however, only the hostname has been included in the HOSTNAME field. 593 syslog Protocol February 2001 595 5.3 Originating Process Information 597 It has also been considered to be a good practice to include some 598 information about the process on the device that generated the 599 message - if that concept exists. This is usually the process name 600 and process id (often known as the "pid") for robust operating 601 systems. The process name is commonly displayed in the TAG field. 602 Quite often, additional information is included at the beginning of 603 the CONTEXT field. The format of "TAG[pid]:" - without the quote 604 marks - is common. The left square bracket is used to terminate the 605 TAG field in this case and is then the first character in the 606 CONTEXT field. If the process id is immaterial, it may be left off. 607 In that case, a colon and a space character usually follow the TAG. 608 This would be displayed as "TAG: " without the quotes. In that 609 case, the colon is the first character in the CONTEXT field. 611 5.4 Examples 613 As examples, these are valid messages as they may be observed on the 614 wire between two devices. In the following examples, each message 615 starts with the less-than character but has been indented, with line 616 breaks inserted in this document for readability. 618 Example 1 620 <34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick 621 on /dev/pts/8 623 This example shows an authentication error in an attempt to acquire 624 additional privileges. It also shows the command attempted and the 625 user attempting it. This was recorded as an original message from 626 the device called mymachine. A relay receiving this would not make 627 any changes before sending it along as it contains a properly 628 formatted PRI part and TIMESTAME field in the MSG part. The TAG 629 value in this example is the process "su". The colon has terminated 630 the TAG field and is the first character of the CONTEXT field. In 631 this case, the process id (pid) would be considered transient and 632 anyone looking at this syslog message would gain no useful 633 information from knowing the pid. It has not been included so the 634 first two characters of the CONTEXT field are the colon and a space 635 character. 637 Example 2 639 <14>Use the BFG! 641 While this is a valid message, it has extraordinarily little useful 642 information. It does not contain a timestamp or any indication of 643 the source of the message. Since it is a user-generated message, it 644 is consistent that it is not associated with a process and may 645 syslog Protocol February 2001 647 therefor not have a TAG. If this message is stored on paper or 648 disk, subsequent review of the message will not yield anything of 649 value. 651 This example is obviously an original message from a device. A 652 relay MUST make changes to the message as described in Section 4.2.2 653 before forwarding it. The resulting relayed message is shown below. 655 <14>Feb 5 17:32:18 10.0.0.99 Use the BFG! 657 In this relayed message, a TIMESTAMP has been added along with a 658 HOSTNAME in the MSG part. Subsequent relays will not make any 659 further changes to this message. It should be noted in this example 660 that the day of the month is less than 10. Since single digits in 661 the date (5 in this case) are preceded by a space in the TIMESTAMP 662 format, there are two spaces following the month in the TIMESTAMP 663 before the day of the month. Also, the relay appears to have no 664 knowledge of the host name of the device sending the message so it 665 has inserted the IP address of the device into the HOSTNAME field. 667 Example 3 669 <165>Aug 24 05:34:00 CST 1987 mymachine myproc[10]: %% It's 670 time to make the do-nuts. %% Ingredients: Mix=OK, Jelly=OK # 671 Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport: 672 Conveyer1=OK, Conveyer2=OK # %% 674 This message does have a valid PRI part with a Priority value 675 indicating that it came from a locally defined facility (local4) 676 with a severity of Notice. The MSG part has a proper TIMESTAMP 677 field in the message. A relay will not modify this message before 678 sending it. However, the HOSTNAME and TAG fields are not consistent 679 with the definitions in Section 4.2.1. The HOSTNAME field would be 680 construed to be "CST" and the TAG value would be "1987". 682 It should be noted that the information contained in the CONTEXT of 683 this example is not telemetry data, nor is it supervisory control or 684 data acquisition information. Due to the security concerns listed 685 in Section 6 of this document, information of that nature should 686 probably not be conveyed across this protocol. 688 Example 4 690 <0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3 691 sched[0]: That's All Folks! 693 This example has a lot of extraneous information throughout. A 694 human or sufficiently adaptable automated parser would be able to 695 determine the date and time information as well as a fully qualified 696 domain name (FQDN) [4] and IP address. The information about the 697 nature of the event is, however, limited. Due to the indicated 698 syslog Protocol February 2001 700 severity of the event, the process may not have been able to gather 701 or send anything more informative. It may have been fortunate to 702 have generated and sent this message at all. 704 This example is obviously an original message from a device. Since 705 the first field in the MSG part is not a TIMESTAMP in the format 706 defined in Section 4.2.3, it MUST be modified by a relay. A relay 707 will add a TIMESTAMP and HOSTNAME as follows and will treat the 708 entire received MSG part from the original packet as the CONTEXT 709 field of the new MSG part. 711 <0>Oct 22 10:52:12 scapegoat 1990 Oct 22 10:52:01 TZ-6 712 scapegoat.dmz.example.org 10.1.2.3 sched[0]: That's All Folks! 714 6. Security Considerations 716 An odor may be considered to be a message that does not require any 717 acknowledgement. People tend to avoid bad odors but are drawn to 718 odors that they associate with good food. The acknowledgement of 719 the receipt of the odor or scent is not required and indeed it may 720 be the height of discretion to totally ignore some odors. On the 721 other hand, it is usually considered good civility to acknowledge 722 the prowess of the cook merely from the ambiance wafting from the 723 kitchen. Similarly, various species have been found to utilize 724 odors to attract mates. One species of moths use this scent to find 725 each other. However, it has been found that bolas spiders can mimic 726 the odor of the female moths of this species. This scent will then 727 attract male moths, which will follow it with the expectation of 728 finding a mate. Instead, when they arrive at the source of the 729 scent, they will be eaten. [6] This is a case of a false message 730 being sent out with inimical intent. 732 In its local use, the syslog process places event notification 733 messages into files on that system. This relies upon the integrity 734 of the system for the protection of the messages. The subsequent 735 configuration of the syslog process to use the syslog protocol to 736 transport the messages to another collector was an extension of the 737 delivery of event notification messages and it exhibits the same 738 trust of the network. One of the consequences of the fundamental 739 simplicity of syslog is that any device can generate any syslog 740 message and send it to any other machine through the syslog 741 protocol. As such there are some concerns about the applicability 742 of this protocol in situations that require robust delivery. Along 743 the lines of the analogy, computer event messages may be sent 744 accidentally, erroneously and even maliciously. At the time of this 745 writing, however, there have not been any reports of any machine 746 consuming any other machine. 748 6.1 Packet Parameters 749 syslog Protocol February 2001 751 As was described above, the message length MUST NOT exceed 1024 752 bytes. Attacks have seen where syslog messages are sent to a 753 receiver that have message lengths greater than 1024 bytes. In some 754 older versions of syslog, the receipt of syslog packets that had a 755 message greater than 1024 bytes caused problems. syslog message 756 receivers must not malfunction upon the receipt of packets where the 757 message length is greater than 1024 bytes. If a message receiver 758 does receive a message whose length is greater than 1024 bytes, it 759 may log all of, or the source address and some of the contents of 760 the message, or it may discard the message altogether. Devices MUST 761 NOT retransmit messages whose received length exceeds 1024 bytes. 763 Similarly, the receiver must rigidly enforce the correctness of the 764 message body. syslog collectors must not malfunction if received 765 messages do not have the less-than and greater-than characters 766 around a valid Priority value. They MUST treat these messages as 767 the unformatted CONTEXT as was described in Section 4.2.2 if they 768 relay it. 770 Also, received messages must contain printable text in the message 771 as was described throughout Section 4. Devices must not malfunction 772 if they receive a message containing characters other than the 773 characters described above. 775 6.2 Message Authenticity 777 The syslog delivery mechanism does not strongly associate the 778 message with the message sender. The receiver of that packet will 779 not be able to ascertain that the message was indeed sent from the 780 reported sender, or if the packet was sent from another device. It 781 should be noted here that the message receiver does not need to 782 verify that the HOSTNAME in the MSG part match the name of the IP 783 address contained in the Source Address field of the IP packet. 785 One possible consequence of this is that a misconfigured machine may 786 send syslog messages to a collector representing itself as another 787 machine. The administrative staff may become confused that the 788 status of the supposed sender of the messages may not be accurately 789 reflected in the received messages. The administrators may not be 790 able to readily discern that there are two or more machines 791 representing themselves as the same machine. 793 It should also be noted that some cases of filling the HOSTNAME 794 field in the MSG part might only have local significance and that 795 may only be ephemeral. If the device had obtained an IP address from 796 a DHCP pool, then any association between an identifier and an 797 actual source would not always hold true. The inclusion of a fully 798 qualified domain name in the CONTEXT may give the administrators the 799 best chance of identifying the source of each message if it can 800 always be associated with an IP address or if it can always be 801 associated with a unique machine. 803 syslog Protocol February 2001 805 Malicious exploits of this vulnerability have also been noted. An 806 attacker may transmit syslog messages (either from the machine that 807 the messages purport from which to be sent or from any other 808 machine) to a collector. The attacks that have been noted run along 809 these lines: 811 An attacker may hide the true nature of an attack amidst many 812 other messages. As an example, an attacker may start 813 generating messages indicating a problem on some machine. This 814 may get the attention of the system administrators who will 815 spend their time investigating the alleged problem. During 816 this time, the attacker may be able to compromise a different 817 machine, or a different process on the same machine. 819 An attacker may generate false syslog messages to give untrue 820 indications of status or of events. As an example, an attacker 821 may stop a critical process on a machine, which may generate a 822 notification of exit. The attacker may subsequently generate a 823 false notification that the process had been restarted. The 824 system administrators may accept that misinformation and not 825 verify that the process had indeed been restarted. 827 6.3 Sequenced Delivery 829 As a general rule, the forensics of a network anomaly rely upon 830 reconstructing the sequence of events. In a perfect world, the 831 messages would be received on the syslog collector in the order of 832 their generation from the other devices and anyone looking at these 833 records would have an accurate picture of the sequence of events. 834 Unfortunately, the syslog process and protocol do not ensure ordered 835 delivery. This section details some of the problems that may be 836 encountered from this. 838 6.3.1 Single Source to a Destination 840 The syslog records are usually presented (placed in a file, 841 displayed on the console, etc.) in the order in which they are 842 received. This is not always in accordance with the sequence in 843 which they were generated. As they are transported across an IP 844 network, some out of order receipt should be expected. This may 845 lead to some confusion as messages may be received that would 846 indicate that a process has stopped before it was started. This may 847 be somewhat rectified if the originating process had timestamped or 848 numbered each of the messages before transmission. In this, the 849 sending device should utilize an authoritative time source. It 850 should be remembered, however, that not all devices are capable of 851 receiving time updates, and not all devices can timestamp their 852 messages. 854 syslog Protocol February 2001 856 6.3.2 Multiple Sources to a Destination 858 In syslog, there is no concept of unified event numbering. Single 859 devices are free to include a sequence number within the CONTEXT but 860 that can hardly be coordinated between multiple devices. In such 861 cases, multiple devices may report that each one is sending message 862 number one. Again, this may be rectified somewhat if the sending 863 devices utilize a timestamp from an authoritative source in their 864 messages. As has been noted, however, even messages from a single 865 device to a single collector may be received out of order. This 866 situation is compounded when there are several devices configured to 867 send their syslog messages to a single collector. Messages from one 868 device may be delayed so the collector receives messages from 869 another device first even though the messages from the first device 870 were generated before the messages from the second. If there is no 871 timestamp or coordinated sequence number, then the messages may be 872 presented in the order in which they were received which may give an 873 inaccurate view of the sequence of actual events. 875 6.3.3 Multiple Sources to Multiple Destinations 877 The plethora of configuration options available to the network 878 administrators may further skew the perception of the order of 879 events. It is possible to configure a group of devices to send the 880 status messages -or other informative messages- to one collector, 881 while sending messages of relatively higher importance to another 882 collector. Additionally, the messages may be sent to different 883 files on the same collector. If the messages do not contain 884 timestamps from the source, it may be difficult to order the 885 messages if they are kept in different places. An administrator may 886 not be able to determine if a record in one file occurred before or 887 after a record in a different file. This may be somewhat alleviated 888 by placing marking messages with a timestamp into all destination 889 files. If these have coordinated timestamps, then there will be 890 some indication of the time of receipt of the individual messages. 892 6.3.4 Replaying 894 Without any sequence indication or timestamp, messages may be 895 recorded and replayed at a later time. An attacker may record a set 896 of messages that indicate normal activity of a machine. At a later 897 time, that attacker may remove that machine from the network and 898 replay the syslog messages to the collector. Even with a TIMESTAMP 899 field in the MSG part, an attacker may record the packets and could 900 simply modify them to reflect the current time before retransmitting 901 them. The administrators may find nothing unusual in the received 902 messages and their receipt would falsely indicate normal activity of 903 the machine. 905 syslog Protocol February 2001 907 6.4 Reliable Delivery 909 As there is no mechanism within either the syslog process or the 910 protocol to ensure delivery, and since the underlying transport is 911 UDP, some messages may be lost. They may either be dropped through 912 network congestion, or they may be maliciously intercepted and 913 discarded. The consequences of the drop of one or more syslog 914 messages cannot be determined. If the messages are simple status 915 updates, then their non-receipt may either not be noticed, or it may 916 cause an annoyance for the system operators. On the other hand, if 917 the messages are more critical, then the administrators may not 918 become aware of a developing and potentially serious problem. 919 Messages may also be intercepted and discarded by an attacker as a 920 way to hide unauthorized activities. 922 6.5 Message Integrity 924 Besides being discarded, syslog messages may be damaged in transit, 925 or an attacker may maliciously modify them. In the case of a packet 926 containing a syslog message being damaged, there are various 927 mechanisms built into the link layer as well as into the IP [7] and 928 UDP protocols which may detect the damage. An intermediary router 929 may discard a damaged IP packet [8]. Damage to a UDP packet may be 930 detected by the receiving UDP module, which may silently discard it. 931 In any case, the original contents of the message will not be 932 delivered to the collector. Additionally, if an attacker is 933 positioned between the sender and collector of syslog messages, they 934 may be able to intercept and modify those messages while in-transit 935 to hide unauthorized activities. 937 6.6 Message Observation 939 While there are no strict guidelines pertaining to the event message 940 format, most syslog messages are generated in human readable form 941 with the assumption that capable administrators should be able to 942 read them and understand their meaning. Neither the syslog protocol 943 nor the syslog application have mechanisms to provide 944 confidentiality of the messages in transit. In most cases passing 945 clear-text messages is a benefit to the operations staff if they are 946 sniffing the packets off of the wire. The operations staff may be 947 able to read the messages and associate them with other events seen 948 from other packets crossing the wire to track down and correct 949 problems. Unfortunately, an attacker may also be able to observe 950 the human-readable contents of syslog messages. The attacker may 951 then use the knowledge gained from those messages to compromise a 952 machine or do other damage. 954 6.7 Message Prioritization and Differentiation 955 syslog Protocol February 2001 957 While the processes that create the messages may signify the 958 importance of the events through the use of the message Priority 959 value, there is no distinct association between this value and the 960 importance of delivery of the packet. As an example of this, 961 consider an application that generates two event messages. The 962 first is a normal status message but the second could be an 963 important message denoting a problem with the process. This second 964 message would have an appropriately higher Severity value associated 965 with the importance of that event. If the operators had configured 966 that both of these messages be transported to a syslog collector 967 then they would, in turn, be given to UDP for transmission. Under 968 normal conditions, no distinction would be made between them and 969 they would be transmitted in their order. 971 Again, under normal circumstances, the receiver would accept syslog 972 messages as they are received. If many devices are transmitting 973 normal status messages, but one is transmitting an important event 974 message, there is no inherent mechanism within the syslog protocol 975 to prioritize the important message over the other messages. 977 On a case-by-case basis, device operators may find some way to 978 associate the different levels with the quality of service 979 identifiers. As an example, the operators may elect to define some 980 linkage between syslog messages that have a specific Priority value 981 with a specific value to be used in the IPv4 Precedence field [7], 982 the IPv6 Traffic Class octet [9], or the Differentiated Services 983 field [10]. In the above example, the operators may have the 984 ability to associate the status message with normal delivery while 985 associating the message indicating a problem with a high 986 reliability, low latency queue as it goes through the network. This 987 would have the affect of prioritizing the essential messages before 988 the normal status messages. Even with this hop-by-hop 989 prioritization, this queuing mechanism could still lead to head of 990 line blocking on the transmitting device as well as buffer 991 starvation on the receiving device if there are many near- 992 simultaneous messages being sent or received. This behavior is not 993 unique to syslog but is endemic to all operations that transmit 994 messages serially. 996 There are security concerns for this behavior. Head of line 997 blocking of the transmission of important event messages may 998 relegate the conveyance of important messages behind less important 999 messages. If the queue is cleared appropriately, this may only add 1000 seconds to the transmission of the important message. On the other 1001 hand, if the queue is not cleared, then important messages may not 1002 be transmitted. Also at the receiving side, if the syslog receiver 1003 is suffering from buffer starvation due to large numbers of messages 1004 being received near-simultaneously, important messages may be 1005 dropped indiscriminately along with other messages. While these are 1006 problems with the devices and their capacities, the protocol 1007 security concern is that there is no prioritization of the 1008 relatively more important messages over the less important messages. 1010 syslog Protocol February 2001 1012 6.8 Misconfiguration 1014 Since there is no control information distributed about any messages 1015 or configurations, it is wholly the responsibility of the network 1016 administrator to ensure that the messages are actually going to the 1017 intended recipient. Cases have been noted where devices were 1018 inadvertently configured to send syslog messages to the wrong 1019 receiver. In many cases, the inadvertent receiver may not be 1020 configured to receive syslog messages and it will probably discard 1021 them. In certain other cases, the receipt of syslog messages has 1022 been known to cause problems for the unintended recipient. [11] If 1023 messages are not going to the intended recipient, then they cannot 1024 be reviewed or processed. 1026 6.9 Forwarding Loop 1028 As it is shown in Figure 1, machines may be configured to relay 1029 syslog messages to subsequent relays before reaching a collector. 1030 In one particular case, an administrator found that he had 1031 mistakenly configured two relays to forward messages with certain 1032 Priority values to each other. When either of these machines either 1033 received or generated that type of message, it would forward it to 1034 the other relay. That relay would, in turn, forward it back. This 1035 cycle did cause degradation to the intervening network as well as to 1036 the processing availability on the two devices. Network 1037 administrators must take care to not cause such a death spiral. 1039 6.10 Load Considerations 1041 Network administrators must take the time to estimate the 1042 appropriate size of the syslog receivers. An attacker may perform a 1043 Denial of Service attack by filling the disk of the collector with 1044 false messages. Placing the records in a circular file may 1045 alleviate this but that has the consequence of not ensuring that an 1046 administrator will be able to review the records in the future. 1047 Along this line, a receiver or collector must have a network 1048 interface capable of receiving all messages sent to it. 1050 Administrators and network planners must also critically review the 1051 network paths between the devices, the relays, and the collectors. 1052 Generated syslog messages should not overwhelm any of the network 1053 links. 1055 7. Conclusion and Other Efforts 1057 The syslog protocol may be effectively used to transport event 1058 notification messages across a network. It is highly recommended 1059 that the network operators who choose to use this understand the 1060 characteristics of the protocol and its security implications. 1062 syslog Protocol February 2001 1064 There have been attempts in the past to standardize the format of 1065 the syslog message. The most notable attempt culminated in a BOF at 1066 the Fortieth Internet Engineering Task Force meeting in 1997. This 1067 was the Universal Logging Protocol (ulp) BOF and the minutes of 1068 their meeting are on-line at the IETF Proceedings web site. [12] 1069 Many good thoughts came from that effort and interested implementers 1070 may want to find some of the notes or papers produced from that 1071 effort. 1073 At the time of this writing, efforts are underway to allow the usage 1074 of international character sets in applications that have been 1075 traditionally thought of as being text-only. The HOSTNAME and 1076 TIMESTAMP fields described above are representative of this. Also, 1077 the entire CONTEXT field has traditionally been printing characters 1078 and spaces in the code set known as US-ASCII. It is hoped that the 1079 proponents of these internationalization efforts will find a 1080 suitable way to allow the use of international character sets within 1081 syslog messages without being disruptive. It should also be hoped 1082 that implementers will allow for the future acceptance of additional 1083 code sets and that they may make appropriate plans. Again, it must 1084 be cautioned that the simplicity of the existing system has been a 1085 tremendous value to its acceptance. Anything that lessens that 1086 simplicity may diminish that value. 1088 Acknowledgements 1090 The following people provided content feedback during the writing of 1091 this draft: 1092 Jon Knight 1093 Magosanyi Arpad 1094 Balazs Scheidler 1095 Jon Callas 1096 Eliot Lear 1097 Petter Reinholdtsen 1098 Darren Reed 1099 Alfonso De Gregorio 1100 Eric Allman 1101 Andrew Ross 1103 Eric Allman is the original inventor and author of the syslog daemon 1104 and protocol. The author of this draft and the community at large 1105 would like to express their appreciation for this work and for the 1106 usefulness that it has provided over the years. 1108 A large amount of additional information about this de-facto 1109 standard operating system feature may usually be found in the 1110 syslog.conf file as well as in the man pages for syslog.conf, 1111 syslog, syslogd, and logger, of many Unix and Unix-like devices. 1113 syslog Protocol February 2001 1115 References 1117 1 Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1118 USC/Information Sciences Institute, August 1980 1120 2 Crocker, D., and P. Overell, "Augmented BNF for Syntax 1121 Specifications: ABNF", RFC 2234, November, 1997 1123 3 USA Standard Code for Information Interchange, USASI X3.4-1968 1125 4 Mockapetris, P.V., "Domain names - concepts and facilities", RFC 1126 1034, STD 13, Nov 1987 1128 5 Data elements and interchange formats - Information exchange - 1129 Representation of dates and times, International Organization for 1130 Standardization, Reference number ISO 8601 : 1988 (E), 1988 1132 6 Stowe, M., et al, "Chemical Mimicry: Bolas Spiders Emit 1133 Components of Moth Prey Species Sex Pheromones", Science, 1987 1135 7 Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information 1136 Sciences Institute, September 1981 1138 8 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1139 1995 1141 9 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1142 Specification", RFC 2460, December 1998 1144 10 Nichols, K., S. Blake, F. Baker, D. Black, "Definition of the 1145 Differentiated Services Field (DS Field) in the IPv4 and IPv6 1146 Headers", RFC 2474, December 1998 1148 11 Cisco Systems Product Security Incident Response Team (PSIRT), 1149 "Field Notice: Cisco IOS(r) Syslog Crash", January 11, 1999 1150 http://www.cisco.com/warp/public/707/advisory.html 1152 12 Walker, D., IETF Secretariat, "Proceedings of the Fortieth 1153 Internet Engineering Task Force, Washington, DC, USA, December 8-12, 1154 1997 1155 http://www.ietf.org/proceedings/97dec/index.html 1157 Author's Addresses 1159 Chris Lonvick 1160 Cisco Systems 1161 12515 Research Blvd. Phone: +1.512.378.1182 1162 Austin, TX, USA Email: clonvick@cisco.com 1163 syslog Protocol February 2001 1165 Full Copyright Statement 1167 Copyright (C) The Internet Society (2001). All Rights Reserved. 1169 This document and translations of it may be copied and furnished to 1170 others, and derivative works that comment on or otherwise explain it 1171 or assist in its implementation may be prepared, copied, published 1172 and distributed, in whole or in part, without restriction of any 1173 kind, provided that the above copyright notice and this paragraph 1174 are included on all such copies and derivative works. However, this 1175 document itself may not be modified in any way, such as by removing 1176 the copyright notice or references to the Internet Society or other 1177 Internet organizations, except as needed for the purpose of 1178 developing Internet standards in which case the procedures for 1179 copyrights defined in the Internet Standards process must be 1180 followed, or as required to translate it into languages other than 1181 English. 1183 The limited permissions granted above are perpetual and will not be 1184 revoked by the Internet Society or its successors or assigns. 1186 This document and the information contained herein is provided on an 1187 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1188 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1189 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1190 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1191 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.