idnits 2.17.1
draft-wierzbicki-cidss-05.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 1503.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1514.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1521.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1527.
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 4, 2008) is 5707 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: '10' is defined on line 1329, but no explicit
reference was found in the text
== Unused Reference: '11' is defined on line 1333, but no explicit
reference was found in the text
== Unused Reference: '12' is defined on line 1336, but no explicit
reference was found in the text
== Unused Reference: '13' is defined on line 1341, 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 4, 2008
7 Expires: March 2009
9 Common Intrusion Detection Signatures Standard
10 draft-wierzbicki-cidss-05.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 4, 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 - common.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.sourceforge.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://sigtranslator.sourceforge.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
344 Optional element for use in translators. Specifies the IDS from which
345 the signature was translated or ported. This element SHOULD contain
346 string that identifies a signature source.
348 Presence: optional, single
349 Type: String
350 Location: element Signature
351 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
434 Checks the specific TCP ack number
436 Location: Protocol, Type=="TCP"
437 Presence: single, optional
438 Type: integer
439 Example: 0
441 TCP_Seq
443 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
480 Location: Protocol, Type=="TCP"
481 Presence: single, optional
482 Type: integer
483 Example: 34000
485 TCP_Dsize
487 Checks the packet data field size in TCP protocol. When the content
488 of this element contain "<" and ">" signs, it MUST be put into
489 section. In other way it MAY contain CDATA section,
490 but it is not REQUIRED.
492 Allowed signs: <, >, <=, >=, number
493 Location: Protocol, Type=="TCP"
494 Presence: single, optional
495 Type: String
496 Example:
498 UDP_Dsize
500 Checks packet data field size in UDP protocol. When the content of
501 this element contain "<" and ">" signs, it MUST be put into
502 section. In other way it MAY contain CDATA section,
503 but it is not REQUIRED.
505 Allowed signs: <, >, <=, >=, number
506 Location: Protocol, Type=="UDP"
507 Presence: single, optional
508 Type: String
509 Example:
511 ICMP_Dsize
513 Checks the packet data field size in ICMP protocol. When the content
514 of this element contain "<" and ">" signs, it MUST be put into
515 section. In other way it MAY contain CDATA section,
516 but it is not REQUIRED.
518 Allowed signs: <, >, <=, >=, number
519 Location: Protocol, Type=="ICMP"
520 Presence: single, optional
521 Type: String
522 Example: =64]]>
524 ICMP_Icmp_Id
526 Checks the value of specific ICMP ID
527 Location: Protocol, Type=="ICMP"
528 Presence: single, optional
529 Type: integer
530 Example: 0
532 ICMP_Icmp_Seq
534 Checks the value of ICMP sequence
536 Location: Protocol, Type=="ICMP"
537 Presence: single, optional
538 Type: integer
539 Example: 0
541 ICMP_Icode
543 Checks the value of specific ICMP code. When the content of this
544 element contain "<" and ">" signs, it MUST be put into
545 section. In other way it MAY contain CDATA section,
546 but it is not REQUIRED.
548 Allowed signs: <, >, number
549 Location: Protocol, Type=="ICMP"
550 Presence: single, optional
551 Type: String
552 Example: 25]]>
554 ICMP_Itype
556 Checks the value of specified ICMP type. When the content of this
557 element contain "<" and ">" signs, it MUST be put into
558 section. In other way it MAY contain CDATA section,
559 but it is not REQUIRED.
561 Allowed signs: <, >, number
562 Location: Protocol, Type=="ICMP"
563 Presence: single, optional
564 Type: String
565 Example: 25]]>
567 IP_Ttl
569 Specifies IP time-to-live value. When the content of this element
570 contain "<" and ">" signs, it MUST be put into
571 section. In other way it MAY contain CDATA section, but it is not
572 REQUIRED.
574 Allowed signs: <, >, <=, >=,-, number
575 Location: Protocol, Type=="IP"
576 Presence: single, optional
577 Type: string
578 Example: 6-8 - values between 6 and 8
580 IP_Tos
582 Check the IP ToS field for specified value
584 Location: Protocol, Type=="IP"
585 Presence: single, optional
586 Type: integer
587 Example: 2
589 IP_Fragbits
591 Checks fragmentations bits for the specified value
593 Location: Protocol, Type=="IP"
594 Presence: single, optional
595 Type: String
596 Example: DM+
598 IP_Id
600 Checks ID field in IP protocol for the specified value
602 Location: Protocol, Type=="IP"
603 Presence: single, optional
604 Type: integer
605 Example: 34222
607 IP_Ipopts
609 This element checks if the specified IP option is present.
611 Allowed values: rr - Record route, eol - end of list, nop - no op, ts
612 - Time Stamp, sec - IP security option, lsrr - Loose source routing,
613 ssrr - Strict source routing, satid - Stream identifier, any - any IP
614 options are set
616 Location: Protocol, Type=="IP"
617 Presence: single, optional
618 Type: String
619 Example: lsrr
620 IP_Dsize
622 Checks size of packet data field. When the content of this element
623 contain "<" and ">" signs, it MUST be put into
624 section. In other way it MAY contain CDATA section, but it is not
625 REQUIRED.
627 Allowed signs: <, >, <=, >=, number
628 Location: Protocol, Type=="IP"
629 Presence: single, optional
630 Type: String
631 Example: 34000
633 IP_Ip_Proto
635 Checks IP protocol header for the specified value. When the content
636 of this element contain "<" and ">" signs, it MUST be put into
637 section. In other way it MAY contain CDATA section,
638 but it is not REQUIRED.
640 Allowed signs: <, >, <=, >=, number, name
641 Location: Protocol, Type=="IP"
642 Presence: single, optional
643 Type: String
644 Example: igmp
646 Proto_Logic
648 This element describes logical rules to combine the information in
649 Protocol elements contained in one Protocols element. Logical
650 operators in Proto Logic element are described in section 2.4.
652 Presence: optional, single
653 Location: element Protocols
654 Example: 1 OR (2 AND 3)
656 2.5.4. Sources
658 This element contains information that describes properties of a
659 source of network communications. If Sources occurs more then once,
660 then every Sources MUST have an unique id (attribute) used in
661 Src_Logic that defines logical dependences between each of them.
663 Presence: mandatory, single
664 Location: element Signature
665 Attributes: ID
666 Contained elements: Source[multiple, mandatory], Src_Logic [single,
667 optional]
668 Example: See Appendix A
670 Source
672 This element contains descriptions of source hosts. Src_ID attribute
673 is local (in one Sources element) id for use with the Src_Logic
674 element.
676 Presence: mandatory, multiple
677 Location: element Sources
678 Attributes: Src_ID [presence: mandatory if more than one Source_ in
679 one Sources element, type: integer, unique]
680 Contained elements: Source_IP[single, mandatory], Source_Port[single,
681 optional]
682 Example: See Appendix A
684 Source_IP
686 This element MUST contain an IPv4 or IPv6 network address in any
687 notation. The value "any" means that all addresses will be considered
688 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the
689 value of Neg attribute is "true", then the values specified in the
690 Source_IP element are interpreted as addresses that MUST NOT match
691 the source address in order for the signature to apply. Mask
692 attribute defines IPv4 or IPv6 mask for the specified IP address.
694 Allowed values: Any string
695 Attributes: Neg [presence: mandatory, type: boolean, allowed values:
696 true|false, default: false], Mask [presence: mandatory, type: string,
697 allowed values: mask in octet or bit notation]
698 Presence: mandatory, single
699 Type: String
700 Location: element Source
701 Example: $EXTERNAL_NET
702 Variable $EXTERNAL_NET is defined in an IDS. (e.g.
703 $EXTERNAL_NET=1.2.3.4)
705 Source_Port
707 The value of this element is a port number or range of ports
708 expressed by two port numbers divided with a ":" sign. The "135:139"
709 expression means that all ports between 135 and 139 will be
710 considered, accounting ports 135 and 139. The value "any" means that
711 all ports will be considered.
713 Attributes: Neg [presence: optional, type: boolean, allowed values:
714 true|false, default: false]
715 Presence: If Protocol Type is set to tcp, udp or ip then mandatory,
716 if Protocol Type value is icmp then MUST NOT be set.
717 Type: String
718 Location: element Source
719 Example: any
721 Src_Logic
723 Defines logical dependences between each Source description. Logical
724 operators: (, ), AND, OR
726 Location: Sources
727 Example: 2 OR (1 AND 3)
729 2.5.5. Destinations
731 This element contains information that describes properties of a
732 destination of network communications. If Destinations occurs more
733 then once, then every Destination MUST have an unique id (attribute)
734 used in Dst_Logic to define logical dependences between each of them.
736 Presence: mandatory, single
737 Location: element Signature
738 Contained elements: Destination [multiple, mandatory]
739 Example: See Appendix A
741 Destination
743 This element contains descriptions of destination hosts. Dst_ID
744 attribute is local (in one Destinations element) id for use with the
745 Dst_Logic element.
747 Presence: mandatory, multiple
748 Location: element Destinations
749 Attributes: Dst_ID [presence: mandatory if more than one Destination_
750 in one Destinations element, type: integer, unique]
751 Contained elements: Destination_IP [single, mandatory],
752 Destination_Port [single, optional]
753 Example: See Appendix A
755 Destination_IP
756 This element MUST contain an IPv4 or IPv6 network address in any
757 notation. The value "any" means that all addresses will be considered
758 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the
759 value of Neg attribute is "true", then the values specified in the
760 Destination_IP element are interpreted as addresses that MUST NOT
761 match the destination address in order for the signature to apply.
762 Mask attribute defines IPv4 or IPv6 mask for the specified IP
763 address.
765 Allowed values: Any string
766 Attributes: Neg [presence: mandatory, type: boolean, allowed values:
767 true|false, default: false], Mask [presence: mandatory, type: string,
768 allowed values: mask in octet or bit notation]
769 Presence: mandatory, single
770 Type: String
771 Location: element Destination
772 Example: Similar as in Source_IP element
774 Destination_Port
776 The value of this element is a port number or range of ports
777 expressed by two port numbers divided with a ":" sign. The "135:139"
778 expression means that all ports between 135 and 139 will be
779 considered, accounting ports 135 and 139. The value "any" means that
780 all ports will be considered.
782 Attributes: Neg [presence: optional, type: boolean, allowed values:
783 true|false, default: false]
784 Presence: If Protocol Type value is set to tcp, udp or ip then
785 mandatory, if Protocol Type value is icmp then MUST NOT be set.
786 Type: String
787 Location: element Destination
788 Example: 445
790 Dst_Logic
792 Defines logical dependences between each Destination description.
793 Logical operators: (, ), AND, OR
795 Location: Destinations
796 Example: 1 AND 2
798 2.5.6. Patterns
800 This element contains multiple Pattern elements.
802 Presence: single, mandatory (if Protocol is to tcp, udp, ip or
803 application than element is present)
804 Location: element Signature
805 Contained elements: Pattern [multiple, optional]
806 Attributes: ID[integer, unique]
807 Example: See Appendix A
809 Pattern
811 This element contains information about the content of a packet that
812 is considered as potentially dangerous. Attribute Pat_ID is used in
813 Pat_Logic element to define logical expressions using multiple
814 Pattern elements
816 Presence: mandatory, multiple
817 Location: element Patterns
818 Contained elements: Pattern_Type [single, mandatory], Pattern_Content
819 [single, optional], Pattern_Depth [single, optional],
820 Pattern_Uricontent [single, optional], Pattern_Offset [single,
821 optional], Pattern_Within [single, optional], Pattern_Distance
822 [single, optional]
823 Attributes: Pat_ID [integer, unique]
824 Example: See Appendix A
826 Pattern_Type
828 Using CIDSS you can specify patterns in hexadecimal, decimal, string,
829 or using PCRE [5] expressions.
831 Presence: mandatory
832 Type: String
833 Location: element Pattern
834 Permitted values: "hex", "dec", "string", "pcre"
835 Default value: "string"
836 Example: string
838 Pattern_Content
840 Defines packet content that is interpreted as an intrusion and
841 considered dangerous. To define the content, regular expressions can
842 be used in the Pattern_Content element. Regular expression MUST be in
843 the PCRE format (Perl Compatible Regular Expressions) [5]. If
844 Rawbytes attribute value is "true" it means pattern is searched in
845 raw packets ignoring decoding that was done by preprocessors. If Neg
846 attribute is true, it means pattern MUST NOT contain specified value.
848 If the content of this element contain "<" and ">" signs, it MUST be
849 put into section. In other way it MAY contain CDATA
850 section, but it is not REQUIRED.
852 Presence: mandatory, single
853 Attributes: CaseSensitive [allowed values: true|false, default value:
854 true], Rawbytes [allowed values: true|false, default value: false],
855 Neg [allowed values: true|false, default: false]
856 Type: Same as value of Pattern_Type
857 Location: element Pattern
858 Example: RETR
859 passwd
861 Pattern_Pcre_Flags
863 Contains standard Perl Compatible_Regular_Expressions modifiers and
864 Perl compatible modifiers or Snort modifiers (used for Snort
865 compatibility)
867 Presence: optional, single
868 Location: element Pattern
869 Type: string
870 Example: iRm
872 Pattern_Depth
874 Defines how many bytes of the packet MUST be searched in order to
875 find the content defined in the Pattern_Content element that is
876 contained by the same Pattern element as this element.
878 Presence: optional, single
879 Location: element Pattern
880 Type: Integer
881 Example: 10
883 Pattern_Uricontent
885 This element describes content of packet in URI format. If this
886 element contains restricted characters (as described in section 2.2)
887 it MUST be put into section. In other way it MAY
888 contain CDATA section, but it is not REQUIRED.
890 Type: string
891 Location: Pattern
892 Presence: optional, single
893 Example:
895
898 Pattern_Offset
900 Specifies offset in bytes from beginning of packet to search for the
901 pattern.
903 Type: integer
904 Location: Pattern
905 Presence: optional, single
906 Example: 5
908 Pattern_Within
910 Used to describe how many packets MUST be at most between two
911 patterns.
913 Type: integer
914 Location: Pattern
915 Presence: optional, single
916 Example: 4
918 Pattern_Distance
920 Defines how far the IDS SHOULD look into a packet for the specified
921 pattern relative to last match.
923 Type: integer
924 Location: Pattern
925 Presence: optional, single
926 Example: 3
928 Pat_Logic
930 This element describes logical rules to combine the information in
931 Pattern elements contained in one Patterns element. Logical operators
932 in Pat_Logic expressions SHOULD be: OR, AND, NOT (as described in
933 section 2.4).
935 Presence: optional, single
936 Location: element Patterns
937 Example: (NOT 1 AND 2) OR 3
939 Logged_Packets
941 Number of packets logged when the system detects an intrusion
942 Presence: optional, single
943 Location: element Signature
944 Type: Integer
945 Example: 0
947 Message
949 Contains the message generated by the IDS when a packet described by
950 this signature was detected. If the content of this element contain
951 "<" and ">" signs, it MUST be put into section. In
952 other way it MAY contain CDATA section, but it is not REQUIRED.
954 Presence: mandatory, single
955 Location: element Signature
956 Type: String
957 Example: FTP password file GET request
959 Comment
961 This element MAY be used for additional comments and information
962 about the signature. The element MAY contain additional information
963 about signature vendor, vulnerability description, http links etc. If
964 the content of this element contains "<" and ">" signs, it MUST be
965 put into section. In other way it MAY contain CDATA
966 section, but it is not REQUIRED.
968 Presence: optional, multiple
969 Location: element Signature
970 Type: String
971 Example: Vendor: Arachnids
973 2.5.7. Session
975 Defines a session that could be identified by the signature if the
976 state mechanisms of an IDS could be used. Otherwise, the information
977 contained in this element describes the conditions that MUST be
978 satisfied by the sensor data in order to trigger the signature.
980 Location: Signature
981 Presence: single, mandatory
982 Contained elements: Session_Filter [single, optional], Session_Start
983 [single, optional], Session_End [single, optional],
984 Session_Identification [single, optional], Session_Instructions
985 [single, optional]
986 Session_Filter
988 Contains IDs of Source, Destination, Protocol and Pattern elements,
989 combined using logical expressions in the format described in section
990 2.4. The information contained in this element specifies the
991 conditions that MUST be met by sensor data so that the packet will be
992 included in this session.
994 Location: Session
995 Presence: single, optional
996 Allowed values: CIDSS logical expressions.
998 Session_Start
1000 Contains IDs of Source, Destination, Protocol or Pattern elements,
1001 combined using logical expressions in the format described in section
1002 2.4. The information contained in this element specifies the
1003 conditions that MUST be met by sensor data so that the packet will
1004 define the beginning of a new session. All session state MUST be
1005 reset by the IDS when a new session begins.
1007 Location: Session
1008 Presence: single, optional
1009 Allowed values: CIDSS logical expressions.
1011 Session_End
1013 Contains IDs of Source, Destination, Protocol or Pattern elements,
1014 combined using logical expressions in the format described in section
1015 2.4. The information contained in this element specifies the
1016 conditions that MUST be met by sensor data so that the packet will
1017 define the beginning of a new session.
1019 Instead of or in addition to conditions for sensor data, this element
1020 MAY include the element Session_Timeout, that specifies a timeout for
1021 the session or MAY include Session_Pckt_Count, that defines maximum
1022 number of packets considered in current session. When both conditions
1023 are specified, then the one that is fulfilled first will terminate
1024 the session.
1026 Location: Session
1027 Presence: single, mandatory if the Session_Start element is present
1028 Contained elements: Session_Timeout [single, optional],
1029 Session_Pckt_Count [single, optional]
1031 Session_Pckt_Count
1032 Defines maximum number of packets that are considered during session.
1034 Presence: single, optional
1035 Location: Session_End
1036 Type: Integer
1037 Example: 5
1039 Session_Timeout
1041 Defines a timeout for the session. The time MUST be specified in the
1042 format: an integer and a single character (the character MUST be one
1043 of: ms,s,m,h - milliseconds, seconds, minutes, hours).
1045 Presence: optional, single
1046 Type: String
1047 Location: Session_End
1048 Example: 10s
1049 Example description: The timeout for the session is 10 seconds.
1051 Session_Identification
1053 Defines additional conditions that MUST be met by sensor data so that
1054 a packet will be included in this session. These conditions apply
1055 after a session has started. For instance, a TCP session will include
1056 only the packets that have the same source and destination as the
1057 source and destination of packets that started the session. The
1058 conditions are specified by including special elements in this
1059 element.
1061 Location: Session
1062 Presence: single, mandatory if the Session_Start attribute is present
1063 Contained elements: Same_Source_IP [single, optional],
1064 Same_Source_Port [single, optional], Same_Destination_IP [single,
1065 optional], Same_Destination_Port [single, optional], Same_Protocol
1066 [single, optional], Same_Direction [single, optional]
1068 Same_Source_IP
1070 If this element is present in Session_Identification, packets that
1071 will be included in the session MUST have the same source IP address
1072 as the starting packet.
1074 Type: Boolean
1075 Presence: single, optional
1076 Location: Session_Identification
1078 Same_Source_Port
1079 If this element is present in Session_Identification, packets that
1080 will be included in the session MUST have the same source port as the
1081 starting packet.
1083 Type: Boolean
1084 Presence: single, optional
1085 Location: Session_Identification
1087 Same_Destination_IP
1089 If this element is present in Session_Identification, packets that
1090 will be included in the session MUST have the same destination IP
1091 address as the starting packet.
1093 Type: Boolean
1094 Presence: single, optional
1095 Location: Session_Identification
1097 Same_Destination_Port
1099 If this element is present in Session_Identification, packets that
1100 will be included in the session MUST have the same destination port
1101 as the starting packet.
1103 Type: Boolean
1104 Presence: single, optional
1105 Location: Session_Identification
1107 Same_Protocol
1109 If this element is present in Session_Identification, packets that
1110 will be included in the session MUST be of the same protocol as the
1111 starting packet.
1113 Type: Boolean
1114 Presence: single, optional
1115 Location: Session_Identification
1117 Same_Direction
1119 If this element is present in Session_Identification, packets that
1120 will be included in the session MUST have been sent in the same
1121 direction as the starting packet.
1123 Type: Boolean
1124 Presence: single, optional
1125 Location: Session_Identification
1126 Session_Instructions
1128 This element works like a switch statement for the state mechanism of
1129 an IDS. The information contained in this element defines the
1130 statefull behavior of an IDS for this session. The element contains
1131 several Session_Case elements that include conditions for the case to
1132 apply, as well as instructions to be carried out if the case applies.
1133 For efficiency reasons, it is assumed that all conditions for state
1134 instructions will be brought down into a conjunctive normal form (a
1135 logical expression that includes alternatives only at the highest
1136 level). That means that in every case element, all case conditions
1137 are treated as a logical conjunction (logical AND). This ought to
1138 simplify the processing of these instructions.
1140 Location: Session
1141 Presence: single, optional
1142 Contained elements: Session_Case [multiple]
1144 Session_Case
1146 This element contains the conditions and instructions of a case in
1147 the switch statement that is defined by the containing
1148 Session_Instructions element. For readability, the conditions are
1149 split up into three groups: additional conditions for sensor data
1150 that MUST be satisfied so that the packet will apply to this case,
1151 the direction of the packet, and the conditions that MUST be
1152 satisfied by the state variables of a session in order for the case
1153 to apply. The instructions of a case are contained in the mandatory
1154 Case_State_Instructions element.
1156 Location: Session_Instructions
1157 Presence: multiple
1158 Contained elements: Case_Filter [single, optional], Direction
1159 [single, optional], Case_State_Condition [single, optional],
1160 Case_State_Instructions [single, mandatory]
1162 Case_Filter
1164 Contains IDs of Source, Destination, Protocol or Pattern elements,
1165 combined using logical expressions in the format described in section
1166 2.4. The information contained in this element specifies the
1167 conditions that MUST be met by sensor data so that the packet will
1168 apply to this case.
1170 Location: Session_Case
1171 Presence: single, optional
1172 Allowed values: CIDSS logical expressions.
1174 Direction
1176 Defines a direction of network traffic, once a source and destination
1177 of traffic are specified (e.g. after the start of a session). Allowed
1178 values are: "sd" and "ds". If direction value is "sd" it means that
1179 the packet has been sent from source to destination. If the value of
1180 this element is "ds" it means that traffic goes from destination to
1181 source.
1183 Allowed values: sd|ds
1184 Default value: sd
1185 Location: Session_Case
1186 Presence: single, optional
1188 Case_State_Condition
1190 This element contains conditional state expressions that MUST all be
1191 satisfied (evaluate to a boolean value of "true") in order for the
1192 case to apply. These instructions MAY check the values of state
1193 variables stored by the IDS for this session.
1195 Location: Session_Case
1196 Presence: single, optional
1197 Contained elements: Isset_Var, Compare_Var
1199 Case_State_Instructions
1201 This element contains state instructions that MUST all be
1202 sequentially carried out by the IDS if the case applies. These
1203 instructions MAY set, unset or modify the values of state variables
1204 stored by the IDS for this session.
1206 Location: Session_Case
1207 Presence: single, optional
1208 Contained elements: Set_Var, Unset_Var, Isset_Var, Isnotset_Var,
1209 Compare_Var, Toggle_Var
1211 Isset_Var
1213 A conditional state expression that evaluates to a boolean value of
1214 "true" if the variable of a name that is specified in the "var"
1215 attribute is set in the state of this session.
1217 Location: Case_State_Condition
1218 Presence: multiple, optional
1219 Attributes: var [type: string; single, mandatory]
1220 Isnotset_Var
1222 A conditional state expression that evaluates to a boolean value of
1223 "true" if the variable of a name that is specified in the "var"
1224 attribute is not set in the state of this session.
1226 Location: Case_State_Condition
1227 Presence: multiple, optional
1228 Attributes: var [type: string; single, mandatory]
1230 Compare_Var
1232 Location: Case_State_Condition
1233 Presence: multiple, optional
1234 Attributes: var [type: string; single, mandatory], value [type:
1235 string; single, mandatory]
1237 Set_Var
1239 Sets value of "var" attribute in state of particular session.
1241 Location: Case_State_Instructions
1242 Presence: multiple, optional
1243 Attributes: var [type: string; single, mandatory], value [type:
1244 string; single, mandatory]
1246 Unset_Var
1248 Nullifies value of "var" used in this session.
1250 Location: Case_State_Instructions
1251 Presence: multiple, optional
1252 Attributes: var [type: string; single, mandatory]
1254 Toggle_Var
1256 Toggle value of "var" attribute in state of particular session. Set
1257 the specified state if the state is unset, otherwise unsets the state
1258 if the state is set.
1260 Location: Case_State_Instructions
1261 Presence: multiple, optional
1262 Attributes: var [type: string; single, mandatory], value [type:
1263 string; single, mandatory]
1265 3. Conventions used in this document
1267 In examples, "C:" and "S:" indicate lines sent by the client and
1268 server respectively.
1270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
1271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
1272 document are to be interpreted as described in RFC-2119 [1].
1274 4. Security Considerations
1276 This Internet Draft describes the CIDSS format for storing
1277 information about IDS signatures. The applications of this standard
1278 can raise security concerns, but there is no security concerns
1279 related strictly to the document format.
1281 It is RECOMMENDED that a system for storing CIDSS data SHOULD be
1282 protected against unauthorized access and unauthorized use. The means
1283 for achieving this protection are outside the scope of this document.
1285 5. IANA Considerations
1287 There are no IANA issues in this document.
1289 The RFC Editor may remove this section prior to publication.
1291 6. Acknowledgments
1293 This document was prepared using 2-Word-v2.0.template.dot.
1295 7. References
1297 7.1. Normative References
1299 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1300 Levels", BCP 14, RFC 2119, March 1997.
1302 [2] Markup Language (XML) 1.0, Third Edition,
1303 http://www.w3.org/TR/2004/REC-xml-20040204/
1305 [3] XML Schema - Specifications and Development,
1306 http://www.w3.org/XML/Schema#dev
1308 [4] Roesch Martin, Green Chris, "Snort Users Manual", 2.3.0,
1309 January 2005, http://www.snort.org
1311 [5] PCRE - Perl Compatible Regular Expressions,
1312 http://www.pcre.org/
1314 7.2. Informative References
1316 [6] Dragon. Intrusion Detection System. Topics on Writing
1317 Signatures" Enterasys Networks, 2002,
1318 http://dragon.enterasys.com
1320 [7] Shoki, "Shoki User's Guide", Release 0.3.0,
1321 http://shoki.sourceforge.net/
1323 [8] ISS - Internet Security Systems, Documentation,
1324 http://www.iss.net/support/documentation/
1326 [9] Cisco - NetRanger, Documentation,
1327 http://www.cisco.com/univercd/cc/td/doc/product/iaabu/netrangr/
1329 [10] Curry D., Lynch Merrill, Debar H., "The Intrusion Detection
1330 Message Exchange Format", Internet Draft draft-ietf-idwg-idmef-
1331 xml-11, January 2004, expires July 2004
1333 [11] McLaughlin Brett, Java & XML, 2nd Edition,
1334 ISBN: 0-596-00197-5
1336 [12] K. Miakisz, "Translator i wspolny jezyk sygnatur systemow
1337 wykrywania wlaman (Translator and Common Intrusion Detection
1338 Systems Language)", Bachelor thesis, Polish-Japanese Institute
1339 of Information Technology, 2003
1341 [13] arachNIDS - Whitehats Network Security Resource,
1342 http://whitehats.com/ids/
1344 APPENDIX A: XML CIDSS Document Example
1346 Here we present a sample signature in CIDSS format. Elements of this
1347 signature have been used as examples in the previous sections.
1349
1350
1352
1353 true
1354 snort
1355 alert
1356 NETBIOS SMB-DS DCERPC Remote Activation bind attempt;
1357 sid=2252
1358 NETBIOS SMB-DS DCERPC Remote Activation bind
1359 attempt
1360 reference: cve,CAN-2003-0528
1361 reference: cve,CAN-2003-0605
1362 reference: cve,CAN-2003-0715
1363 reference:
1364 url,www.microsoft.com/technet/security/bulletin/MS03-
1365 039.mspx
1366
1367
1371
1375
1379 1 AND 2 AND 3
1380
1381
1382
1383 any
1384 445
1385
1386
1387 192.168.1.0
1389 445
1390
1391
1392 10.0.0.0
1394 445
1395
1396 1 AND 2 AND 3
1397
1398
1399
1400 established
1401
1402 1
1403
1404
1405
1406 string
1407
1409 5
1410 4
1411
1412
1413 string
1414
1416 2
1417 56
1418
1419
1420 string
1421 |5C
1422 00|P|00|I|00|P|00|E|00 5C 00|
1423 12
1424 5
1425
1426
1427 hex
1428 05
1429 1
1430
1431
1432 hex
1433 0B
1434 1
1435 1
1436
1437
1438 string
1439 |B8|J|9F|M|1C|}|CF 11
1440 86 1E 00| |AF|n|7C|W
1441 16
1442 29
1443
1444 1 AND 2 AND 3 AND 4 AND 5 AND 6
1445
1446
1447 (SRC_1 AND SRC_2 AND SRC_3) AND (DST_1 AND
1448 DST_2 AND DST_3) AND PROTO_1 AND (PAT_1 AND PAT_2 AND PAT_3 AND PAT_4
1449 AND PAT_5 AND PAT_6)
1450
1451 5
1452
1453
1454
1455
1457 APPENDIX B: The schema of CIDSS - common.xsd
1459 Available at http://cidss.sourceforge.net/down/common_v2.3.xsd
1461 Author's Addresses
1463 dr Adam Wierzbicki
1464 Polish-Japanese Institute of Information Technology
1465 Koszykowa 86
1466 02-008 Warsaw, Poland
1467 Email: adamw@pjwstk.edu.pl
1469 Jacek Kalinski
1470 Rechniewskiego 6/24
1471 03-980 Warsaw, Poland
1472 Email: jacek@dyski.one.pl
1474 Tomasz Kruszona
1475 Garwolinska 9/83
1476 04-348 Warsaw, Poland
1477 Email: t.kruszona@b59.net
1479 Full Copyright Statement
1481 Copyright (C) The IETF Trust (2008).
1483 This document is subject to the rights, licenses and restrictions
1484 contained in BCP 78, and except as set forth therein, the authors
1485 retain all their rights.
1487 This document and the information contained herein are provided on an
1488 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1489 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1490 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1491 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1492 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1493 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1495 Disclaimer of Validity
1497 This document and the information contained herein are provided on an
1498 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1499 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1500 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1501 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1502 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1503 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1505 Intellectual Property Statement
1507 The IETF takes no position regarding the validity or scope of any
1508 Intellectual Property Rights or other rights that might be claimed to
1509 pertain to the implementation or use of the technology described in
1510 this document or the extent to which any license under such rights
1511 might or might not be available; nor does it represent that it has
1512 made any independent effort to identify any such rights. Information
1513 on the procedures with respect to rights in RFC documents can be
1514 found in BCP 78 and BCP 79.
1516 Copies of IPR disclosures made to the IETF Secretariat and any
1517 assurances of licenses to be made available, or the result of an
1518 attempt made to obtain a general license or permission for the use of
1519 such proprietary rights by implementers or users of this
1520 specification can be obtained from the IETF on-line IPR repository at
1521 http://www.ietf.org/ipr.
1523 The IETF invites any interested party to bring to its attention any
1524 copyrights, patents or patent applications, or other proprietary
1525 rights that may cover technology that may be required to implement
1526 this standard. Please address the information to the IETF at
1527 ietf-ipr@ietf.org.