idnits 2.17.1 draft-wierzbicki-cidss-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1541. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2, 2008) is 5714 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '10' is defined on line 1335, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1339, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1347, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-idwg-idmef-xml-11 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Common Intrusion Detection Signatures A. Wierzbicki 2 Standard (CIDSS) J. Kalinski 3 T. Kruszona 4 Internet Draft Polish-Japanese Institute 5 of Information Technology 6 Intended status: Informational September 2, 2008 7 Expires: March 2009 9 Common Intrusion Detection Signatures Standard 10 draft-wierzbicki-cidss-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on March 2, 2009. 38 Abstract 40 The purpose of the Common Intrusion Detection Signatures Standard 41 (CIDSS) is to define a common data format for storing signatures from 42 different intrusion detection systems. 44 This Internet-Draft describes a common data format to represent 45 information contained in signatures of intrusion detection systems, 46 and explains the rationale for using this common format. The proposed 47 format is a dialect of the Extensible Markup Language (XML). An XML 48 Document Type Definition is developed, and examples are provided. 50 Table of Contents 52 1. Introduction................................................2 53 1.1. About CIDSS............................................2 54 1.2. Potential Applications of CIDSS.........................3 55 2. XML CIDSS Signatures.........................................4 56 2.1. Structure of a CIDSS document...........................5 57 2.2. Structure of a CIDSS signature..........................5 58 2.3. Data types used by the Pattern_Content element...........6 59 2.4. Logical expressions used in CIDSS signature definitions..6 60 2.5. XML elements and attributes used in CIDSS...............7 61 2.5.1. Signatures.........................................7 62 2.5.2. Signature.........................................8 63 2.5.3. Protocols.........................................9 64 2.5.4. Sources..........................................15 65 2.5.5. Destinations......................................17 66 2.5.6. Patterns.........................................18 67 2.5.7. Session..........................................22 68 3. Conventions used in this document...........................29 69 4. Security Considerations.....................................29 70 5. IANA Considerations........................................29 71 6. Acknowledgments............................................29 72 7. References.................................................30 73 7.1. Normative References...................................30 74 7.2. Informative References.................................30 75 APPENDIX A: XML CIDSS Document Example.........................32 76 APPENDIX B: The schema of CIDSS - cidss.xsd....................35 78 1. Introduction 80 1.1. About CIDSS 82 Common Intrusion Detection Signatures Standard is intended to be a 83 standard format of signatures used widely in Network Intrusion 84 Detection Systems (NIDS). An IDS is controlled by a set of decision 85 rules. A decision rule of an IDS is composed of two components: a 86 description of specific characteristics of an intrusion attempt (a 87 signature) and an action that has to be carried out when the data 88 provided by IDS sensors matches the signature. This document focuses 89 on the remaining part of an IDS decision rule: the IDS signature. 91 Currently, every IDS uses a different format of signatures. CIDSS 92 defines a common format of signatures that attempts to express all 93 information contained in signatures of various IDS. The CIDSS 94 signature format is based on XML to facilitate the adaptation and 95 applications of the proposed standard. The CIDSS signature format is 96 designed to be extensible, and therefore it SHOULD be simple to 97 incorporate features of future and current IDS systems that have not 98 been taken into account in the first design. 100 The main goal of CIDSS is to enable administrators of IDS systems to 101 share, compare, evaluate and criticize signatures used to detect 102 intrusion events. The increasingly dynamic, global, and frequent 103 nature of intrusion attempts is a trend that forces administrators to 104 greater efforts to protect increasingly valuable information. The 105 possibility to disseminate knowledge and experience about IDS 106 systems' operation would be enhanced by the introduction of a common 107 signature format. Therefore the use of a common IDS signature format 108 SHOULD lead to a greater security of information. Other possible 109 applications of CIDSS will be discussed in the next section. 111 CIDSS Homepage: http://cidss.b59.net 113 1.2. Potential Applications of CIDSS 115 One of the main applications of CIDSS is the translation of 116 signatures between various IDS. The ability to translate a signature 117 of an IDS into the common data format and to carry out a reverse 118 translation implies that it SHOULD be possible to translate 119 signatures of different IDS using the common data format as an 120 intermediate form. The development of this standard has been carried 121 out in parallel with the development of an IDS signature translator. 122 Currently, the translator is able to translate signatures of Snort 123 [4] and Dragon [6] IDS into the common format, and among the three 124 systems. It's also partially tested with: Shoki [7], ISS 125 RealSecure(TM) [8], and Cisco NetRanger(TM) [9]. 127 The IDS translator is developed under the GNU General Public License 128 and is available from http://translator.b59.net. 130 Another possible application of CIDSS would be the creation and 131 maintenance of signature databases by independent providers of IDS 132 signatures. The use of XML as a base for the common signature format 133 enables a simple integration of collections of signatures into a 134 database. This SHOULD improve the searching and management of a 135 signature collection. The business model of an independent signature 136 provider could be the delivery of up-to-date, comprehensive signature 137 collections to increase security of specific services, systems and 138 platforms. 140 +-----------------------------------+ 141 | First part of a signature | 142 | ... |<----|--| 143 | ... |<----|--| 144 | ... |<----|--| 145 | ... |<----|--| 146 +-----------------------------------+ | | 147 +-----------------------------------------+ | | 148 | Second part of a signature | | | 149 | | | | 150 | ... | | | 151 | ... | | | 152 | | | | 153 | ... | | | 154 | | | | 155 | ...|-- | 156 | | | 157 | ... |------ 158 | | 159 | | 160 +-----------------------------------------+ 161 Figure 1 The main components and logical structure of a CIDSS 162 signature 164 2. XML CIDSS Signatures 166 This section describes the logical and structural rules for creating 167 signatures in CIDSS format. Each XML element and attribute used in 168 the CIDSS format are described and explained on examples. In appendix 169 A, a full CIDSS signature is provided that has been used to provide 170 the examples used in this section. 172 CIDSS meets XML ver. 1.0 requirements [2]. CIDSS is defined as a 173 dialect of XML using the XML Schema Definition (XSD). The schema of 174 CIDSS is an appendix to this document (see appendix B: CIDSS XSD 175 schema. cidss.xsd) 177 2.1. Structure of a CIDSS document 179 A CIDSS document is a collection of signatures. Each signature is 180 independent, and can be stored in a separate CIDSS document or 181 together with other signatures. The main XML element of a CIDS 182 document is the "Signatures" element. 184 2.2. Structure of a CIDSS signature 186 A CIDSS signature is composed of several XML elements, contained in a 187 common "Signature" element. A signature can be divided into two 188 basic, logical parts. The first part, that includes (among others) 189 the elements "Sources", "Destinations", "Protocols" and "Patterns", 190 is used to define building blocks of a signature definition. These 191 blocks are combined in the second part of a signature, and are kept 192 separate in order to shorten the signature definition and avoid 193 redundancy. For instance, the definition of relevant information 194 about the TCP protocol might be kept inside the "Protocols" element 195 and might be later combined with several patterns (defined inside the 196 "Patterns" element). Rather than repeat the definition of the TCP 197 protocol each time a new pattern is used, the signature definition 198 will refer to the information kept inside the "Protocols" element. 200 The second part of a signature contains information on how to use the 201 building blocks defined in the first part. The main XML element of 202 the second part of a signature is the "Session" element. A "Session" 203 element defines the main signature behavior. A signature MAY use 204 state managed by the IDS for a certain flow of packets (or session). 205 However, it is possible to create stateless signatures, by omitting 206 information REQUIRED for the state mechanisms to work. Then, the 207 information contained in a "Session" element defines the conditions 208 that MUST be fulfilled by sensor data in order to trigger the 209 signature. 211 In the second part of a signature, the information contained in the 212 first part is combined using logical expressions. Each element in the 213 first part of a signature that contains a "building block" for the 214 signature definition MUST have an identifier that is unique in the 215 signature (not necessarily in the CIDSS document that contains the 216 signature). This identifier can be used in the second part of a 217 signature to refer to the "building block" defined by this element. 218 The building blocks MAY be combined using logical expressions that 219 are constructed by the "AND" and "OR" operators. The logical 220 expressions are contained in special tags, and are treated as strings 221 by the XML parser. CIDSS logical expressions are described in section 222 2.4. 224 When the content of element contain "<" (less then), ">" (greater 225 then), "&" (ampersand), "'" (apostrophe) or """ (quotation mark) 226 signs, it MUST be put into CDATA section. A CDATA section starts with 227 "". 229 Only the characters "<" and "&" are strictly illegal in XML. 230 Apostrophes, quotation marks and greater than signs are legal, but it 231 is a good habit to replace them. 233 Note: A CDATA section cannot contain the string "]]>" 235 2.3. Data types used by the Pattern_Content element 237 The data types used in CIDSS signatures are compatible with the XML 238 [2] and XML Schema (XSD) [3] specification. The following data types 239 are supported: 240 - String value 242 You MUST use encoding defined by "encoding" attribute (e.g. ). UTF-8 RECOMMENDED. Refer to 244 Appendix A and Appendix B 245 - Hexadecimal values 246 - Decimal values 248 2.4. Logical expressions used in CIDSS signature definitions 250 Some elements in the CIDSS signature contain information that 251 describes how other elements MUST be combined in the signature 252 definitions. The content of these elements is a String value that 253 contains a logical expression. A translating software MUST be able to 254 process these expressions. 256 CIDSS logical expressions MUST use operators "AND", "OR", and "NOT" 257 (uppercase). The operators are interpreted as follows: 258 - AND - logical conjunction 259 - OR - logical alternative 260 - NOT - logical negation 262 The operator precedence in CIDSS logical expressions MUST be 263 interpreted as follows: NOT precedes AND precedes OR. 265 CIDSS logical expressions MAY contain ordinary braces "(" or ")" that 266 are interpreted as in logical expressions. 268 Apart from braces and operators, CIDSS logical expressions MUST 269 contain unique identifiers of other XML elements in the CIDSS 270 signature definition that MAY be used in logical expressions. 272 2.5. XML elements and attributes used in CIDSS 274 In this section, all XML elements defined by the CIDSS standard SHALL 275 be introduced. Each element will be defined using a common template 276 to simplify a presentation. This template is explained below: 278 Element name 279 Element description. 280 Presence: [mandatory | optional, single | multiple] 281 Location: element name 282 Attributes: attribute name [type [, unique]] 283 Contained elements: element names 285 mandatory - means that the element MUST exist in the signature 287 optional - the element MAY exist in the signature 289 single - if the element exists in the signature, then this element 290 MUST exist in exactly one instance 292 multiple - if the element exists in the signature, then this element 293 MAY exist many instances 295 unique - value of the element MUST NOT be repeated as value of the 296 same element in other place 298 2.5.1. Signatures 300 A root element of a CIDSS XML document. 302 Presence: mandatory, single 303 Location: root element 304 Contained elements: Signature [multiple, mandatory] 306 Example: 308 311 where "" SHOULD be replaced by the filename of the 312 XSD schema file (e.g. cidss.xsd) 314 2.5.2. Signature 316 This element contains all information about a signature. Describes 317 conditions required to identify traffic as suspicious and to take an 318 action. 320 Presence: mandatory 321 Location: element Signatures 322 Attributes: SID [type: integer, single, mandatory, unique] 323 Contained elements: Enabled [single, mandatory], Sig_Source [single, 324 optional], Description [single, optional], Action [single, optional], 325 Protocols [single, mandatory], Sources [single, mandatory], 326 Destinations [single, mandatory], Patterns [single, mandatory], 327 Logged_Packets [single, optional], Message [single, mandatory], 328 Comment [multiple, optional], Session [single, mandatory] 329 Example: See Appendix A 331 Enabled 333 Defines a current signature state. Setting this to true, the 334 signature will be analyzed by the IDS. Otherwise the signature SHOULD 335 be skipped. 337 Presence: mandatory 338 Type: Boolean 339 Default value: true 340 Location: element Signature 341 Example: true 343 Sig_Source 345 Optional element for use in translators. Specifies the IDS from which 346 the signature was translated or ported. This element SHOULD contain 347 string that identifies a signature source. 349 Presence: optional, single 350 Type: String 351 Location: element Signature 352 Example: Snort 353 Description 355 This element MAY contain a simple description of the signature. 357 Presence: optional 358 Type: String 359 Location: element Signature 360 Example: Try to get passwd file using ftp 362 Action 364 This MAY define actions performed by an IDS after intrusion 365 detection. 366 Suggested values: drop, allow, alert, and warning 368 Presence: optional, single 369 Type: String 370 Location: element Signature 371 Example: alert 373 2.5.3. Protocols 375 This element contains description of multiple protocols used in 376 potential attack. 378 Location: Signature 379 Presence: mandatory, multiple 380 Attributes: ID[integer,unique] 382 Protocol 384 The element used to describe the network protocol. Options of the 385 protocol used in this element depend on a protocol type. 387 The Proto_ID attribute is used for identification in the Proto_Logic 388 element - it is REQUIRED only when there is more than one Protocol in 389 the Protocols element. 391 Presence: mandatory, multiple. 392 Type: String 393 Attributes: Proto_ID [integer, unique], Type [enum: tcp, udp, ip, 394 icmp, application] 395 Location: element Signature 396 Contained elements: TCP_Ack [single, optional], TCP_State [single, 397 optional], TCP_Seq [single, optional], TCP_Dsize [single, optional], 398 TCP_Flags [single, optional], TCP_Window [single, optional], 399 UDP_Dsize [single, optional], ICMP_Dsize [single, optional], 400 ICMP_Icmp_Id [single, optional], ICMP_Icmp_Seq [single, optional], 401 ICMP_Icode [single, optional], ICMP_Itype [single, optional], IP_Ttl 402 [single, optional], IP_Tos [single, optional], IP_Ipopts [single, 403 optional], IP_Fragbits [single, optional], IP_Id [single, optional], 404 IP_Ip_Proto [single, optional], IP_Dsize [single, optional], Isdataat 405 [single, optional], Rpc [single, optional] 407 Isdataat 409 Checks that the data fields in the packet are in the specified 410 offset. When the content of this element contain "<" and ">" signs, 411 it MUST be put into section. In other way it MAY 412 contain CDATA section, but it is not REQUIRED. 414 Allowed values: Integer or integer (more than a given value) 416 Location: Protocol 417 Presence: single, optional 418 Example: 420 Rpc 422 This element specifies the RPC application, version, and procedure 423 numbers in SUNRCP call requests. It MUST contain a string in the 424 following format: 426 Allowed format: , [|*], 427 [|*]> 428 Location: Protocol, Type=="Application" 429 Presence: single, optional 430 Type: String 431 Example: 100000,*,3 433 TCP_Ack 435 Checks the specific TCP ack number 437 Location: Protocol, Type=="TCP" 438 Presence: single, optional 439 Type: integer 440 Example: 0 442 TCP_Seq 444 Checks the specific TCP seq number 445 Location: Protocol, Type=="TCP" 446 Presence: single, optional 447 Type: integer 448 Example: TCP_Seq>0 450 TCP_State 452 Describes current protocol state e.g. established, stateless 454 Location: Protocol, Type=="TCP" 455 Allowed values: [established|stateless] 456 Presence: single, optional 457 Type: string 458 Example: established 460 TCP_Flags 462 Check if the specific TCP Flags are present 464 Location: Protocol, Type=="TCP" 465 Allowed values: [!|*|+][FSRPAU120,] 467 Values description: F-FIN, S-SYN, R-RST, P-PSH, A-ACK, U-URG, 1- 468 Reserved bit 1, 2-Reserved bit 2, 0-No Flags set. 469 Modifiers description: + - match on the specific bits, plus any 470 others, * - match if any of the specified bits are set, ! - match if 471 specified bits are not set 473 Presence: single, optional 474 Type: String 475 Example: +SA 477 TCP_Window 479 Checks value of the TCP window size 481 Location: Protocol, Type=="TCP" 482 Presence: single, optional 483 Type: integer 484 Example: 34000 486 TCP_Dsize 488 Checks the packet data field size in TCP protocol. When the content 489 of this element contain "<" and ">" signs, it MUST be put into 490 section. In other way it MAY contain CDATA section, 491 but it is not REQUIRED. 493 Allowed signs: <, >, <=, >=, number 494 Location: Protocol, Type=="TCP" 495 Presence: single, optional 496 Type: String 497 Example: 499 UDP_Dsize 501 Checks packet data field size in UDP protocol. When the content of 502 this element contain "<" and ">" signs, it MUST be put into 503 section. In other way it MAY contain CDATA section, 504 but it is not REQUIRED. 506 Allowed signs: <, >, <=, >=, number 507 Location: Protocol, Type=="UDP" 508 Presence: single, optional 509 Type: String 510 Example: 512 ICMP_Dsize 514 Checks the packet data field size in ICMP protocol. When the content 515 of this element contain "<" and ">" signs, it MUST be put into 516 section. In other way it MAY contain CDATA section, 517 but it is not REQUIRED. 519 Allowed signs: <, >, <=, >=, number 520 Location: Protocol, Type=="ICMP" 521 Presence: single, optional 522 Type: String 523 Example: =64]]> 525 ICMP_Icmp_Id 527 Checks the value of specific ICMP ID 529 Location: Protocol, Type=="ICMP" 530 Presence: single, optional 531 Type: integer 532 Example: 0 534 ICMP_Icmp_Seq 536 Checks the value of ICMP sequence 538 Location: Protocol, Type=="ICMP" 539 Presence: single, optional 540 Type: integer 541 Example: 0 543 ICMP_Icode 545 Checks the value of specific ICMP code. When the content of this 546 element contain "<" and ">" signs, it MUST be put into 547 section. In other way it MAY contain CDATA section, 548 but it is not REQUIRED. 550 Allowed signs: <, >, number 551 Location: Protocol, Type=="ICMP" 552 Presence: single, optional 553 Type: String 554 Example: 25]]> 556 ICMP_Itype 558 Checks the value of specified ICMP type. When the content of this 559 element contain "<" and ">" signs, it MUST be put into 560 section. In other way it MAY contain CDATA section, 561 but it is not REQUIRED. 563 Allowed signs: <, >, number 564 Location: Protocol, Type=="ICMP" 565 Presence: single, optional 566 Type: String 567 Example: 25]]> 569 IP_Ttl 571 Specifies IP time-to-live value. When the content of this element 572 contain "<" and ">" signs, it MUST be put into 573 section. In other way it MAY contain CDATA section, but it is not 574 REQUIRED. 576 Allowed signs: <, >, <=, >=,-, number 577 Location: Protocol, Type=="IP" 578 Presence: single, optional 579 Type: string 580 Example: 6-8 - values between 6 and 8 582 IP_Tos 584 Check the IP ToS field for specified value 585 Location: Protocol, Type=="IP" 586 Presence: single, optional 587 Type: integer 588 Example: 2 590 IP_Fragbits 592 Checks fragmentations bits for the specified value 594 Location: Protocol, Type=="IP" 595 Presence: single, optional 596 Type: String 597 Example: DM+ 599 IP_Id 601 Checks ID field in IP protocol for the specified value 603 Location: Protocol, Type=="IP" 604 Presence: single, optional 605 Type: integer 606 Example: 34222 608 IP_Ipopts 610 This element checks if the specified IP option is present. 612 Allowed values: rr - Record route, eol - end of list, nop - no op, ts 613 - Time Stamp, sec - IP security option, lsrr - Loose source routing, 614 ssrr - Strict source routing, satid - Stream identifier, any - any IP 615 options are set 617 Location: Protocol, Type=="IP" 618 Presence: single, optional 619 Type: String 620 Example: lsrr 622 IP_Dsize 624 Checks size of packet data field. When the content of this element 625 contain "<" and ">" signs, it MUST be put into 626 section. In other way it MAY contain CDATA section, but it is not 627 REQUIRED. 629 Allowed signs: <, >, <=, >=, number 630 Location: Protocol, Type=="IP" 631 Presence: single, optional 632 Type: String 633 Example: 34000 635 IP_Ip_Proto 637 Checks IP protocol header for the specified value. When the content 638 of this element contain "<" and ">" signs, it MUST be put into 639 section. In other way it MAY contain CDATA section, 640 but it is not REQUIRED. 642 Allowed signs: <, >, <=, >=, number, name 643 Location: Protocol, Type=="IP" 644 Presence: single, optional 645 Type: String 646 Example: igmp 648 Proto_Logic 650 This element describes logical rules to combine the information in 651 Protocol elements contained in one Protocols element. Logical 652 operators in Proto Logic element are described in section 2.4. 654 Presence: optional, single 655 Location: element Protocols 656 Example: 1 OR (2 AND 3) 658 2.5.4. Sources 660 This element contains information that describes properties of a 661 source of network communications. If Sources occurs more then once, 662 then every Sources MUST have an unique id (attribute) used in 663 Src_Logic that defines logical dependences between each of them. 665 Presence: mandatory, single 666 Location: element Signature 667 Attributes: ID 668 Contained elements: Source[multiple, mandatory], Src_Logic [single, 669 optional] 670 Example: See Appendix A 672 Source 674 This element contains descriptions of source hosts. Src_ID attribute 675 is local (in one Sources element) id for use with the Src_Logic 676 element. 678 Presence: mandatory, multiple 679 Location: element Sources 680 Attributes: Src_ID [presence: mandatory if more than one Source_ in 681 one Sources element, type: integer, unique] 682 Contained elements: Source_IP[single, mandatory], Source_Port[single, 683 optional] 684 Example: See Appendix A 686 Source_IP 688 This element MUST contain an IPv4 or IPv6 network address in any 689 notation. The value "any" means that all addresses will be considered 690 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the 691 value of Neg attribute is "true", then the values specified in the 692 Source_IP element are interpreted as addresses that MUST NOT match 693 the source address in order for the signature to apply. Mask 694 attribute defines IPv4 or IPv6 mask for the specified IP address. 696 Allowed values: Any string 697 Attributes: Neg [presence: mandatory, type: boolean, allowed values: 698 true|false, default: false], Mask [presence: mandatory, type: string, 699 allowed values: mask in octet or bit notation] 700 Presence: mandatory, single 701 Type: String 702 Location: element Source 703 Example: $EXTERNAL_NET 704 Variable $EXTERNAL_NET is defined in an IDS. (e.g. 705 $EXTERNAL_NET=1.2.3.4) 707 Source_Port 709 The value of this element is a port number or range of ports 710 expressed by two port numbers divided with a ":" sign. The "135:139" 711 expression means that all ports between 135 and 139 will be 712 considered, accounting ports 135 and 139. The value "any" means that 713 all ports will be considered. 715 Attributes: Neg [presence: optional, type: boolean, allowed values: 716 true|false, default: false] 717 Presence: If Protocol Type is set to tcp, udp or ip then mandatory, 718 if Protocol Type value is icmp then MUST NOT be set. 719 Type: String 720 Location: element Source 721 Example: any 723 Src_Logic 724 Defines logical dependences between each Source description. Logical 725 operators: (, ), AND, OR 727 Location: Sources 728 Example: 2 OR (1 AND 3) 730 2.5.5. Destinations 732 This element contains information that describes properties of a 733 destination of network communications. If Destinations occurs more 734 then once, then every Destination MUST have an unique id (attribute) 735 used in Dst_Logic to define logical dependences between each of them. 737 Presence: mandatory, single 738 Location: element Signature 739 Contained elements: Destination [multiple, mandatory] 740 Example: See Appendix A 742 Destination 744 This element contains descriptions of destination hosts. Dst_ID 745 attribute is local (in one Destinations element) id for use with the 746 Dst_Logic element. 748 Presence: mandatory, multiple 749 Location: element Destinations 750 Attributes: Dst_ID [presence: mandatory if more than one Destination_ 751 in one Destinations element, type: integer, unique] 752 Contained elements: Destination_IP [single, mandatory], 753 Destination_Port [single, optional] 754 Example: See Appendix A 756 Destination_IP 758 This element MUST contain an IPv4 or IPv6 network address in any 759 notation. The value "any" means that all addresses will be considered 760 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the 761 value of Neg attribute is "true", then the values specified in the 762 Destination_IP element are interpreted as addresses that MUST NOT 763 match the destination address in order for the signature to apply. 764 Mask attribute defines IPv4 or IPv6 mask for the specified IP 765 address. 767 Allowed values: Any string 768 Attributes: Neg [presence: mandatory, type: boolean, allowed values: 770 true|false, default: false], Mask [presence: mandatory, type: string, 771 allowed values: mask in octet or bit notation] 772 Presence: mandatory, single 773 Type: String 774 Location: element Destination 775 Example: Similar as in Source_IP element 777 Destination_Port 779 The value of this element is a port number or range of ports 780 expressed by two port numbers divided with a ":" sign. The "135:139" 781 expression means that all ports between 135 and 139 will be 782 considered, accounting ports 135 and 139. The value "any" means that 783 all ports will be considered. 785 Attributes: Neg [presence: optional, type: boolean, allowed values: 786 true|false, default: false] 787 Presence: If Protocol Type value is set to tcp, udp or ip then 788 mandatory, if Protocol Type value is icmp then MUST NOT be set. 789 Type: String 790 Location: element Destination 791 Example: 445 793 Dst_Logic 795 Defines logical dependences between each Destination description. 796 Logical operators: (, ), AND, OR 798 Location: Destinations 799 Example: 1 AND 2 801 2.5.6. Patterns 803 This element contains multiple Pattern elements. 805 Presence: single, mandatory (if Protocol is to tcp, udp, ip or 806 application than element is present) 807 Location: element Signature 808 Contained elements: Pattern [multiple, optional] 809 Attributes: ID[integer, unique] 810 Example: See Appendix A 812 Pattern 813 This element contains information about the content of a packet that 814 is considered as potentially dangerous. Attribute Pat_ID is used in 815 Pat_Logic element to define logical expressions using multiple 816 Pattern elements 818 Presence: mandatory, multiple 819 Location: element Patterns 820 Contained elements: Pattern_Type [single, mandatory], Pattern_Content 821 [single, optional], Pattern_Depth [single, optional], 822 Pattern_Uricontent [single, optional], Pattern_Offset [single, 823 optional], Pattern_Within [single, optional], Pattern_Distance 824 [single, optional] 825 Attributes: Pat_ID [integer, unique] 826 Example: See Appendix A 828 Pattern_Type 830 Using CIDSS you can specify patterns in hexadecimal, decimal, string, 831 or using PCRE [5] expressions. 833 Presence: mandatory 834 Type: String 835 Location: element Pattern 836 Permitted values: "hex", "dec", "string", "pcre" 837 Default value: "string" 838 Example: string 840 Pattern_Content 842 Defines packet content that is interpreted as an intrusion and 843 considered dangerous. To define the content, regular expressions can 844 be used in the Pattern_Content element. Regular expression MUST be in 845 the PCRE format (Perl Compatible Regular Expressions) [5]. If 846 Rawbytes attribute value is "true" it means pattern is searched in 847 raw packets ignoring decoding that was done by preprocessors. If Neg 848 attribute is true, it means pattern MUST NOT contain specified value. 850 If the content of this element contain "<" and ">" signs, it MUST be 851 put into section. In other way it MAY contain CDATA 852 section, but it is not REQUIRED. 854 Presence: mandatory, single 855 Attributes: CaseSensitive [allowed values: true|false, default value: 856 true], Rawbytes [allowed values: true|false, default value: false], 857 Neg [allowed values: true|false, default: false] 858 Type: Same as value of Pattern_Type 859 Location: element Pattern 860 Example: RETR 861 passwd 863 Pattern_Pcre_Flags 865 Contains standard Perl Compatible_Regular_Expressions modifiers and 866 Perl compatible modifiers or Snort modifiers (used for Snort 867 compatibility) 869 Presence: optional, single 870 Location: element Pattern 871 Type: string 872 Example: iRm 874 Pattern_Depth 876 Defines how many bytes of the packet MUST be searched in order to 877 find the content defined in the Pattern_Content element that is 878 contained by the same Pattern element as this element. 880 Presence: optional, single 881 Location: element Pattern 882 Type: Integer 883 Example: 10 885 Pattern_Uricontent 887 This element describes content of packet in URI format. If this 888 element contains restricted characters (as described in section 2.2) 889 it MUST be put into section. In other way it MAY 890 contain CDATA section, but it is not REQUIRED. 892 Type: string 893 Location: Pattern 894 Presence: optional, single 895 Example: 896 899 Pattern_Offset 901 Specifies offset in bytes from beginning of packet to search for the 902 pattern. 904 Type: integer 905 Location: Pattern 906 Presence: optional, single 907 Example: 5 909 Pattern_Within 911 Used to describe how many packets MUST be at most between two 912 patterns. 914 Type: integer 915 Location: Pattern 916 Presence: optional, single 917 Example: 4 919 Pattern_Distance 921 Defines how far the IDS SHOULD look into a packet for the specified 922 pattern relative to last match. 924 Type: integer 925 Location: Pattern 926 Presence: optional, single 927 Example: 3 929 Pat_Logic 931 This element describes logical rules to combine the information in 932 Pattern elements contained in one Patterns element. Logical operators 933 in Pat_Logic expressions SHOULD be: OR, AND, NOT (as described in 934 section 2.4). 936 Presence: optional, single 937 Location: element Patterns 938 Example: (NOT 1 AND 2) OR 3 940 Logged_Packets 942 Number of packets logged when the system detects an intrusion 944 Presence: optional, single 945 Location: element Signature 946 Type: Integer 947 Example: 0 949 Message 951 Contains the message generated by the IDS when a packet described by 952 this signature was detected. If the content of this element contain 953 "<" and ">" signs, it MUST be put into section. In 954 other way it MAY contain CDATA section, but it is not REQUIRED. 956 Presence: mandatory, single 957 Location: element Signature 958 Type: String 959 Example: FTP password file GET request 961 Comment 963 This element MAY be used for additional comments and information 964 about the signature. The element MAY contain additional information 965 about signature vendor, vulnerability description, http links etc. If 966 the content of this element contains "<" and ">" signs, it MUST be 967 put into section. In other way it MAY contain CDATA 968 section, but it is not REQUIRED. 970 Presence: optional, multiple 971 Location: element Signature 972 Type: String 973 Example: Vendor: Arachnids 975 2.5.7. Session 977 Defines a session that could be identified by the signature if the 978 state mechanisms of an IDS could be used. Otherwise, the information 979 contained in this element describes the conditions that MUST be 980 satisfied by the sensor data in order to trigger the signature. 982 Location: Signature 983 Presence: single, mandatory 984 Contained elements: Session_Filter [single, optional], Session_Start 985 [single, optional], Session_End [single, optional], 986 Session_Identification [single, optional], Session_Instructions 987 [single, optional] 989 Session_Filter 991 Contains IDs of Source, Destination, Protocol and Pattern elements, 992 combined using logical expressions in the format described in section 993 2.4. The information contained in this element specifies the 994 conditions that MUST be met by sensor data so that the packet will be 995 included in this session. 997 Location: Session 998 Presence: single, optional 999 Allowed values: CIDSS logical expressions. 1001 Session_Start 1003 Contains IDs of Source, Destination, Protocol or Pattern elements, 1004 combined using logical expressions in the format described in section 1005 2.4. The information contained in this element specifies the 1006 conditions that MUST be met by sensor data so that the packet will 1007 define the beginning of a new session. All session state MUST be 1008 reset by the IDS when a new session begins. 1010 Location: Session 1011 Presence: single, optional 1012 Allowed values: CIDSS logical expressions. 1014 Session_End 1016 Contains IDs of Source, Destination, Protocol or Pattern elements, 1017 combined using logical expressions in the format described in section 1018 2.4. The information contained in this element specifies the 1019 conditions that MUST be met by sensor data so that the packet will 1020 define the beginning of a new session. 1022 Instead of or in addition to conditions for sensor data, this element 1023 MAY include the element Session_Timeout, that specifies a timeout for 1024 the session or MAY include Session_Pckt_Count, that defines maximum 1025 number of packets considered in current session. When both conditions 1026 are specified, then the one that is fulfilled first will terminate 1027 the session. 1029 Location: Session 1030 Presence: single, mandatory if the Session_Start element is present 1031 Contained elements: Session_Timeout [single, optional], 1032 Session_Pckt_Count [single, optional] 1034 Session_Pckt_Count 1036 Defines maximum number of packets that are considered during session. 1038 Presence: single, optional 1039 Location: Session_End 1040 Type: Integer 1041 Example: 5 1043 Session_Timeout 1044 Defines a timeout for the session. The time MUST be specified in the 1045 format: an integer and a single character (the character MUST be one 1046 of: ms,s,m,h - milliseconds, seconds, minutes, hours). 1048 Presence: optional, single 1049 Type: String 1050 Location: Session_End 1051 Example: 10s 1052 Example description: The timeout for the session is 10 seconds. 1054 Session_Identification 1056 Defines additional conditions that MUST be met by sensor data so that 1057 a packet will be included in this session. These conditions apply 1058 after a session has started. For instance, a TCP session will include 1059 only the packets that have the same source and destination as the 1060 source and destination of packets that started the session. The 1061 conditions are specified by including special elements in this 1062 element. 1064 Location: Session 1065 Presence: single, mandatory if the Session_Start attribute is present 1066 Contained elements: Same_Source_IP [single, optional], 1067 Same_Source_Port [single, optional], Same_Destination_IP [single, 1068 optional], Same_Destination_Port [single, optional], Same_Protocol 1069 [single, optional], Same_Direction [single, optional] 1071 Same_Source_IP 1073 If this element is present in Session_Identification, packets that 1074 will be included in the session MUST have the same source IP address 1075 as the starting packet. 1077 Type: Boolean 1078 Presence: single, optional 1079 Location: Session_Identification 1081 Same_Source_Port 1083 If this element is present in Session_Identification, packets that 1084 will be included in the session MUST have the same source port as the 1085 starting packet. 1087 Type: Boolean 1088 Presence: single, optional 1089 Location: Session_Identification 1090 Same_Destination_IP 1092 If this element is present in Session_Identification, packets that 1093 will be included in the session MUST have the same destination IP 1094 address as the starting packet. 1096 Type: Boolean 1097 Presence: single, optional 1098 Location: Session_Identification 1100 Same_Destination_Port 1102 If this element is present in Session_Identification, packets that 1103 will be included in the session MUST have the same destination port 1104 as the starting packet. 1106 Type: Boolean 1107 Presence: single, optional 1108 Location: Session_Identification 1110 Same_Protocol 1112 If this element is present in Session_Identification, packets that 1113 will be included in the session MUST be of the same protocol as the 1114 starting packet. 1116 Type: Boolean 1117 Presence: single, optional 1118 Location: Session_Identification 1120 Same_Direction 1122 If this element is present in Session_Identification, packets that 1123 will be included in the session MUST have been sent in the same 1124 direction as the starting packet. 1126 Type: Boolean 1127 Presence: single, optional 1128 Location: Session_Identification 1130 Session_Instructions 1132 This element works like a switch statement for the state mechanism of 1133 an IDS. The information contained in this element defines the 1134 statefull behavior of an IDS for this session. The element contains 1135 several Session_Case elements that include conditions for the case to 1136 apply, as well as instructions to be carried out if the case applies. 1138 For efficiency reasons, it is assumed that all conditions for state 1139 instructions will be brought down into a conjunctive normal form (a 1140 logical expression that includes alternatives only at the highest 1141 level). That means that in every case element, all case conditions 1142 are treated as a logical conjunction (logical AND). This ought to 1143 simplify the processing of these instructions. 1145 Location: Session 1146 Presence: single, optional 1147 Contained elements: Session_Case [multiple] 1149 Session_Case 1151 This element contains the conditions and instructions of a case in 1152 the switch statement that is defined by the containing 1153 Session_Instructions element. For readability, the conditions are 1154 split up into three groups: additional conditions for sensor data 1155 that MUST be satisfied so that the packet will apply to this case, 1156 the direction of the packet, and the conditions that MUST be 1157 satisfied by the state variables of a session in order for the case 1158 to apply. The instructions of a case are contained in the mandatory 1159 Case_State_Instructions element. 1161 Location: Session_Instructions 1162 Presence: multiple 1163 Contained elements: Case_Filter [single, optional], Direction 1164 [single, optional], Case_State_Condition [single, optional], 1165 Case_State_Instructions [single, mandatory] 1167 Case_Filter 1169 Contains IDs of Source, Destination, Protocol or Pattern elements, 1170 combined using logical expressions in the format described in section 1171 2.4. The information contained in this element specifies the 1172 conditions that MUST be met by sensor data so that the packet will 1173 apply to this case. 1175 Location: Session_Case 1176 Presence: single, optional 1177 Allowed values: CIDSS logical expressions. 1179 Direction 1181 Defines a direction of network traffic, once a source and destination 1182 of traffic are specified (e.g. after the start of a session). Allowed 1183 values are: "sd" and "ds". If direction value is "sd" it means that 1184 the packet has been sent from source to destination. If the value of 1185 this element is "ds" it means that traffic goes from destination to 1186 source. 1188 Allowed values: sd|ds 1189 Default value: sd 1190 Location: Session_Case 1191 Presence: single, optional 1193 Case_State_Condition 1195 This element contains conditional state expressions that MUST all be 1196 satisfied (evaluate to a boolean value of "true") in order for the 1197 case to apply. These instructions MAY check the values of state 1198 variables stored by the IDS for this session. 1200 Location: Session_Case 1201 Presence: single, optional 1202 Contained elements: Isset_Var, Compare_Var 1204 Case_State_Instructions 1206 This element contains state instructions that MUST all be 1207 sequentially carried out by the IDS if the case applies. These 1208 instructions MAY set, unset or modify the values of state variables 1209 stored by the IDS for this session. 1211 Location: Session_Case 1212 Presence: single, optional 1213 Contained elements: Set_Var, Unset_Var, Isset_Var, Isnotset_Var, 1214 Compare_Var, Toggle_Var 1216 Isset_Var 1218 A conditional state expression that evaluates to a boolean value of 1219 "true" if the variable of a name that is specified in the "var" 1220 attribute is set in the state of this session. 1222 Location: Case_State_Condition 1223 Presence: multiple, optional 1224 Attributes: var [type: string; single, mandatory] 1226 Isnotset_Var 1228 A conditional state expression that evaluates to a boolean value of 1229 "true" if the variable of a name that is specified in the "var" 1230 attribute is not set in the state of this session. 1232 Location: Case_State_Condition 1233 Presence: multiple, optional 1234 Attributes: var [type: string; single, mandatory] 1236 Compare_Var 1238 Location: Case_State_Condition 1239 Presence: multiple, optional 1240 Attributes: var [type: string; single, mandatory], value [type: 1241 string; single, mandatory] 1243 Set_Var 1245 Sets value of "var" attribute in state of particular session. 1247 Location: Case_State_Instructions 1248 Presence: multiple, optional 1249 Attributes: var [type: string; single, mandatory], value [type: 1250 string; single, mandatory] 1252 Unset_Var 1254 Nullifies value of "var" used in this session. 1256 Location: Case_State_Instructions 1257 Presence: multiple, optional 1258 Attributes: var [type: string; single, mandatory] 1260 Toggle_Var 1262 Toggle value of "var" attribute in state of particular session. Set 1263 the specified state if the state is unset, otherwise unsets the state 1264 if the state is set. 1266 Location: Case_State_Instructions 1267 Presence: multiple, optional 1268 Attributes: var [type: string; single, mandatory], value [type: 1269 string; single, mandatory] 1271 3. Conventions used in this document 1273 In examples, "C:" and "S:" indicate lines sent by the client and 1274 server respectively. 1276 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1277 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1278 document are to be interpreted as described in RFC-2119 [1]. 1280 4. Security Considerations 1282 This Internet Draft describes the CIDSS format for storing 1283 information about IDS signatures. The applications of this standard 1284 can raise security concerns, but there is no security concerns 1285 related strictly to the document format. 1287 It is RECOMMENDED that a system for storing CIDSS data SHOULD be 1288 protected against unauthorized access and unauthorized use. The means 1289 for achieving this protection are outside the scope of this document. 1291 5. IANA Considerations 1293 There are no IANA issues in this document. 1295 The RFC Editor may remove this section prior to publication. 1297 6. Acknowledgments 1299 This document was prepared using 2-Word-v2.0.template.dot. 1301 7. References 1303 7.1. Normative References 1305 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1306 Levels", BCP 14, RFC 2119, March 1997. 1308 [2] Markup Language (XML) 1.0, Third Edition, 1309 http://www.w3.org/TR/2004/REC-xml-20040204/ 1311 [3] XML Schema - Specifications and Development, 1312 http://www.w3.org/XML/Schema#dev 1314 [4] Roesch Martin, Green Chris, "Snort Users Manual", 2.3.0, 1315 January 2005, http://www.snort.org 1317 [5] PCRE - Perl Compatible Regular Expressions, 1318 http://www.pcre.org/ 1320 7.2. Informative References 1322 [6] Dragon. Intrusion Detection System. Topics on Writing 1323 Signatures" Enterasys Networks, 2002, 1324 http://dragon.enterasys.com 1326 [7] Shoki, "Shoki User's Guide", Release 0.3.0, 1327 http://shoki.sourceforge.net/ 1329 [8] ISS - Internet Security Systems, Documentation, 1330 http://www.iss.net/support/documentation/ 1332 [9] Cisco - NetRanger, Documentation, 1333 http://www.cisco.com/univercd/cc/td/doc/product/iaabu/netrangr/ 1335 [10] Curry D., Lynch Merrill, Debar H., "The Intrusion Detection 1336 Message Exchange Format", Internet Draft draft-ietf-idwg-idmef- 1337 xml-11, January 2004, expires July 2004 1339 [11] McLaughlin Brett, Java & XML, 2nd Edition, 1340 ISBN: 0-596-00197-5 1342 [12] K. Miakisz, "Translator i wspolny jezyk sygnatur systemow 1343 wykrywania wlaman (Translator and Common Intrusion Detection 1344 Systems Language)", Bachelor thesis, Polish-Japanese Institute 1345 of Information Technology, 2003 1347 [13] arachNIDS - Whitehats Network Security Resource, 1348 http://whitehats.com/ids/ 1350 APPENDIX A: XML CIDSS Document Example 1352 Here we present a sample signature in CIDSS format. Elements of this 1353 signature have been used as examples in the previous sections. 1355 1356 1358 1359 true 1360 snort 1361 alert 1362 NETBIOS SMB-DS DCERPC Remote Activation bind attempt; 1363 sid=2252 1364 NETBIOS SMB-DS DCERPC Remote Activation bind 1365 attempt 1366 reference: cve,CAN-2003-0528 1367 reference: cve,CAN-2003-0605 1368 reference: cve,CAN-2003-0715 1369 reference: 1370 url,www.microsoft.com/technet/security/bulletin/MS03- 1371 039.mspx 1372 1373 1374 any 1375 any 1376 1377 1378 10.0.0.0 1379 any 1380 1381 1382 192.168.1.0 1383 any 1384 1385 1 AND 2 AND 3 1386 1387 1388 1389 any 1390 445 1391 1392 1393 192.168.1.0 1395 445 1396 1397 1398 10.0.0.0 1400 445 1401 1402 1 AND 2 AND 3 1403 1404 1405 1406 established 1407 1408 1 1409 1410 1411 1412 string 1413 1415 5 1416 4 1417 1418 1419 string 1420 1422 2 1423 56 1424 1425 1426 string 1427 |5C 1428 00|P|00|I|00|P|00|E|00 5C 00| 1429 12 1430 5 1431 1432 1433 hex 1434 05 1435 1 1436 1437 1438 hex 1439 0B 1440 1 1441 1 1442 1443 1444 string 1445 |B8|J|9F|M|1C|}|CF 11 1446 86 1E 00| |AF|n|7C|W 1447 16 1448 29 1449 1450 1 AND 2 AND 3 AND 4 AND 5 AND 6 1451 1452 1453 (SRC_1 AND SRC_2 AND SRC_3) AND (DST_1 AND 1454 DST_2 AND DST_3) AND PROTO_1 AND (PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 1455 AND PAT_5 AND PAT_6) 1456 1457 5 1458 1459 1460 1461 1463 APPENDIX B: The schema of CIDSS - cidss.xsd 1465 Available at http://translator.b59.net/docs/cidss.xsd 1467 Author's Addresses 1469 dr Adam Wierzbicki 1470 Polish-Japanese Institute of Information Technology 1471 Koszykowa 86 1472 02-008 Warsaw, Poland 1473 Email: adamw@pjwstk.edu.pl 1475 Jacek Kalinski 1476 Rechniewskiego 6/24 1477 03-980 Warsaw, Poland 1478 Email: jacek@dyski.one.pl 1480 Tomasz Kruszona 1481 Garwolinska 9/83 1482 04-348 Warsaw, Poland 1483 Email: t.kruszona@b59.net 1485 Comments to: 1487 dr Adam Wierzbicki 1488 Polish-Japanese Institute of Information Technology 1489 Koszykowa 86 1490 02-008 Warsaw, Poland 1491 Email: adamw@pjwstk.edu.pl 1493 Full Copyright Statement 1495 Copyright (C) The IETF Trust (2008). 1497 This document is subject to the rights, licenses and restrictions 1498 contained in BCP 78, and except as set forth therein, the authors 1499 retain all their rights. 1501 This document and the information contained herein are provided on an 1502 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1503 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1504 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1505 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1506 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1507 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1509 Disclaimer of Validity 1511 This document and the information contained herein are provided on an 1512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1514 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1515 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1516 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1519 Intellectual Property Statement 1521 The IETF takes no position regarding the validity or scope of any 1522 Intellectual Property Rights or other rights that might be claimed to 1523 pertain to the implementation or use of the technology described in 1524 this document or the extent to which any license under such rights 1525 might or might not be available; nor does it represent that it has 1526 made any independent effort to identify any such rights. Information 1527 on the procedures with respect to rights in RFC documents can be 1528 found in BCP 78 and BCP 79. 1530 Copies of IPR disclosures made to the IETF Secretariat and any 1531 assurances of licenses to be made available, or the result of an 1532 attempt made to obtain a general license or permission for the use of 1533 such proprietary rights by implementers or users of this 1534 specification can be obtained from the IETF on-line IPR repository at 1535 http://www.ietf.org/ipr. 1537 The IETF invites any interested party to bring to its attention any 1538 copyrights, patents or patent applications, or other proprietary 1539 rights that may cover technology that may be required to implement 1540 this standard. Please address the information to the IETF at 1541 ietf-ipr@ietf.org.