idnits 2.17.1
draft-wierzbicki-cidss-03.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 34.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1509.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1520.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1527.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1533.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 4
longer pages, the longest (page 3) being 60 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The exact meaning of the all-uppercase expression 'MAY NOT' is not
defined in RFC 2119. If it is intended as a requirements expression, it
should be rewritten using one of the combinations defined in RFC 2119;
otherwise it should not be all-uppercase.
== The expression 'MAY NOT', while looking like RFC 2119 requirements text,
is not defined in RFC 2119, and should not be used. Consider using 'MUST
NOT' instead (if that is what you mean).
Found 'MAY NOT' in this paragraph:
Here we present a sample signature in CIDSS format. Elements of
this signature have been used as examples in the previous sections. (This
appendix MAY NOT be compatible with Internet Draft formatting).
-- 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 (May 2006) is 6556 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'FSRPAU120' is mentioned on line 479, but not defined
== Unused Reference: 'IDWG11' is defined on line 1451, but no explicit
reference was found in the text
== Unused Reference: 'JAVAXML' is defined on line 1456, but no explicit
reference was found in the text
== Unused Reference: 'CIDSL' is defined on line 1459, but no explicit
reference was found in the text
== Unused Reference: 'ARACH' is defined on line 1465, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'SNORTman'
-- Possible downref: Non-RFC (?) normative reference: ref. 'DRAGON'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SHOKIug'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML10'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XSD'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ISSdoc'
-- Possible downref: Non-RFC (?) normative reference: ref. 'CISCOdoc'
-- Possible downref: Non-RFC (?) normative reference: ref. 'PCRE'
== Outdated reference: A later version (-16) exists of
draft-ietf-idwg-idmef-xml-11
Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 16 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Draft A. Wierzbicki
3 J. Kalinski
4 T. Kruszona
5 Document: draft-wierzbicki-cidss-03.txt Polish-Japanese
6 Institute of
7 Information
8 Technology
9 Expires: November 2006 May 2006
11 Common Intrusion Detection Signatures Standard
13 Status of this Memo
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as
18 Internet-Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/1id-abstracts.html.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 By submitting this Internet-Draft, each author represents that any
32 applicable patent or other IPR claims of which he or she is aware
33 have been or will be disclosed, and any of which he or she becomes
34 aware will be disclosed, in accordance with Section 6 of BCP 79.
36 Distribution of this memo is unlimited.
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 Conventions used in this document
52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
54 document are to be interpreted as described in RFC 2119 [RFC2119].
56 Table of Contents
58 Status of this Memo...............................................1
59 Abstract..........................................................1
60 Conventions used in this document.................................2
61 Table of Contents.................................................2
62 1. Introduction...................................................3
63 1.1 About CIDSS................................................3
64 1.2 Potential Applications of CIDSS............................3
65 2. XML CIDSS Signatures...........................................5
66 2.1 Structure of a CIDSS document..............................5
67 2.2 Structure of a CIDSS signature.............................5
68 2.3 Data types used by the Pattern_Content element.............6
69 2.4 Logical expressions used in CIDSS signature definitions....6
70 2.5 XML elements and attributes used in CIDSS..................7
71 2.5.1 Signatures...........................................8
72 2.5.2 Signature............................................8
73 2.5.3 Protocols............................................9
74 2.5.4 Sources.............................................16
75 2.5.5 Destinations........................................16
76 2.5.6 Patterns............................................19
77 2.5.7 Session.............................................23
78 3. Security Considerations.......................................30
79 Appendix A.......................................................31
80 Appendix B.......................................................33
81 References.......................................................33
82 Normative references.............................................33
83 Informative references...........................................34
84 Author's Addresses...............................................34
85 Comments to:.....................................................34
86 Copyright Notice.................................................35
87 Disclaimer of Validity...........................................35
88 Intellectual Property Statement..................................35
89 IANA Considerations..............................................35
91 1.
92 Introduction
94 1.1
95 About CIDSS
97 Common Intrusion Detection Signatures Standard is intended to be a
98 standard format of signatures used widely in Network Intrusion
99 Detection Systems (NIDS). An IDS is controlled by a set of decision
100 rules. A decision rule of an IDS is composed of two components: a
101 description of specific characteristics of an intrusion attempt (a
102 signature) and an action that has to be carried out when the data
103 provided by IDS sensors matches the signature. This document focuses
104 on the remaining part of an IDS decision rule: the IDS signature.
106 Currently, every IDS uses a different format of signatures. CIDSS
107 defines a common format of signatures that attempts to express all
108 information contained in signatures of various IDS. The CIDSS
109 signature format is based on XML to facilitate the adaptation and
110 applications of the proposed standard. The CIDSS signature format is
111 designed to be extensible, and therefore it SHOULD be simple to
112 incorporate features of future and current IDS systems that have not
113 been taken into account in the first design.
115 The main goal of CIDSS is to enable administrators of IDS systems to
116 share, compare, evaluate and criticize signatures used to detect
117 intrusion events. The increasingly dynamic, global, and frequent
118 nature of intrusion attempts is a trend that forces administrators to
119 greater efforts to protect increasingly valuable information. The
120 possibility to disseminate knowledge and experience about IDS
121 systems' operation would be enhanced by the introduction of a common
122 signature format. Therefore the use of a common IDS signature format
123 SHOULD lead to a greater security of information. Other possible
124 applications of CIDSS will be discussed in the next section.
126 CIDSS Homepage: http://cidss.b59.net
128 1.2
129 Potential Applications of CIDSS
131 One of the main applications of CIDSS is the translation of
132 signatures between various IDS. The ability to translate a signature
133 of an IDS into the common data format and to carry out a reverse
134 translation implies that it SHOULD be possible to translate
135 signatures of different IDS using the common data format as an
136 intermediate form. The development of this standard has been carried
137 out in parallel with the development of an IDS signature translator.
138 Currently, the translator is able to translate signatures of Snort
139 [SNORTman] and Dragon [DRAGON] IDS into the common format, and among
140 the three systems. It's also partially tested with: Shoki [SHOKIug],
141 ISS RealSecure(TM) [ISSdoc], and Cisco NetRanger(TM) [CISCOdoc].
143 The IDS translator is developed under the GNU General Public License
144 and is available from http://translator.b59.net.
146 Another possible application of CIDSS would be the creation and
147 maintenance of signature databases by independent providers of IDS
148 signatures. The use of XML as a base for the common signature format
149 enables a simple integration of collections of signatures into a
150 database. This SHOULD improve the searching and management of a
151 signature collection. The business model of an independent signature
152 provider could be the delivery of up-to-date, comprehensive signature
153 collections to increase security of specific services, systems and
154 platforms.
156 -------------------------------------
157 | First part of a signature |
158 | ... |<-------|--|
159 | ... |<-------|--|
160 | ... |<-------|--|
161 | ... |<-------|--|
162 ------------------------------------- | |
163 ------------------------------------------- | |
164 | Second part of a signature | | |
165 | | | |
166 | ... | | |
167 | ... | | |
168 | | | |
169 | ... | | |
170 | | | |
171 | ...|----- |
172 | | |
173 | ... |---------
174 | |
175 | |
176 -------------------------------------------
178 Figure 1. The main components and logical structure of a CIDSS
179 signature
181 2.
182 XML CIDSS Signatures
184 This section describes the logical and structural rules for creating
185 signatures in CIDSS format. Each XML element and attribute used in
186 the CIDSS format are described and explained on examples. In appendix
187 A, a full CIDSS signature is provided that has been used to provide
188 the examples used in this section.
189 CIDSS meets XML ver. 1.0 requirements [XML10]. CIDSS is defined as a
190 dialect of XML using the XML Schema Definition (XSD). The schema of
191 CIDSS is an appendix to this document (see appendix B: CIDSS XSD
192 schema. cidss.xsd)
194 2.1
195 Structure of a CIDSS document
197 A CIDSS document is a collection of signatures. Each signature is
198 independent, and can be stored in a separate CIDSS document or
199 together with other signatures. The main XML element of a CIDS
200 document is the "Signatures" element.
202 2.2
203 Structure of a CIDSS signature
205 A CIDSS signature is composed of several XML elements, contained in a
206 common "Signature" element. A signature can be divided into two
207 basic, logical parts. The first part, that includes (among others)
208 the elements "Sources", "Destinations", "Protocols" and "Patterns",
209 is used to define building blocks of a signature definition. These
210 blocks are combined in the second part of a signature, and are kept
211 separate in order to shorten the signature definition and avoid
212 redundancy. For instance, the definition of relevant information
213 about the TCP protocol might be kept inside the "Protocols" element
214 and might be later combined with several patterns (defined inside the
215 "Patterns" element). Rather than repeat the definition of the TCP
216 protocol each time a new pattern is used, the signature definition
217 will refer to the information kept inside the "Protocols" element.
218 The second part of a signature contains information on how to use the
219 building blocks defined in the first part. The main XML element of
220 the second part of a signature is the "Session" element. A "Session"
221 element defines the main signature behavior. A signature MAY use
222 state managed by the IDS for a certain flow of packets (or session).
223 However, it is possible to create stateless signatures, by omitting
224 information REQUIRED for the state mechanisms to work. Then, the
225 information contained in a "Session" element defines the conditions
226 that MUST be fulfilled by sensor data in order to trigger the
227 signature.
229 In the second part of a signature, the information contained in the
230 first part is combined using logical expressions. Each element in the
231 first part of a signature that contains a "building block" for the
232 signature definition MUST have an identifier that is unique in the
233 signature (not necessarily in the CIDSS document that contains the
234 signature). This identifier can be used in the second part of a
235 signature to refer to the "building block" defined by this element.
236 The building blocks MAY be combined using logical expressions that
237 are constructed by the "AND" and "OR" operators. The logical
238 expressions are contained in special tags, and are treated as strings
239 by the XML parser. CIDSS logical expressions are described in section
240 2.4.
242 When the content of element contain "<" (less then), ">" (greater
243 then), "&" (ampersand), "'" (apostrophe) or """ (quotation mark)
244 signs, it MUST be put into CDATA section. A CDATA section starts with
245 "".
246 Only the characters "<" and "&" are strictly illegal in XML.
247 Apostrophes, quotation marks and greater than signs are legal, but it
248 is a good habit to replace them.
249 Note: A CDATA section cannot contain the string "]]>"
251 2.3
252 Data types used by the Pattern_Content element
254 The data types used in CIDSS signatures are compatible with the
255 XML[XML10] and XML Schema (XSD) [XSD] specification. The following
256 data types are supported:
258 - String values
259 You MUST use encoding defined by "encoding" attribute (e.g. ). UTF-8 RECOMMENDED. Refer to
261 Appendix A and Appendix B
262 - Hexadecimal values
263 - Decimal values
265 2.4
266 Logical expressions used in CIDSS signature definitions
268 Some elements in the CIDSS signature contain information that
269 describes how other elements MUST be combined in the signature
270 definitions. The content of these elements is a String value that
271 contains a logical expression. A translating software MUST be able to
272 process these expressions.
273 CIDSS logical expressions MUST use operators "AND", "OR", and "NOT"
274 (uppercase). The operators are interpreted as follows:
276 - AND - logical conjunction
277 - OR - logical alternative
278 - NOT - logical negation
280 The operator precedence in CIDSS logical expressions MUST be
281 interpreted as follows: NOT precedes AND precedes OR.
282 CIDSS logical expressions MAY contain ordinary braces "(" or ")" that
283 are interpreted as in logical expressions.
284 Apart from braces and operators, CIDSS logical expressions MUST
285 contain unique identifiers of other XML elements in the CIDSS
286 signature definition that MAY be used in logical expressions.
288 2.5
289 XML elements and attributes used in CIDSS
291 In this section, all XML elements defined by the CIDSS standard SHALL
292 be introduced. Each element will be defined using a common template
293 to simplify a presentation. This template is explained below:
295 Element name
297 Element description.
298 Presence: [mandatory | optional, single | multiple]
299 Location: element name
300 Attributes: attribute name [type [, unique]]
301 Contained elements: element names
303 mandatory - means that the element MUST exist in the signature
304 optional - the element MAY exist in the signature
305 single - if the element exists in the signature, then this element
306 MUST exist in exactly one instance
307 multiple - if the element exists in the signature, then this element
308 MAY exist many instances
309 unique - value of the element MUST NOT be repeated as value of the
310 same element in other place
312 2.5.1
313 Signatures
315 A root element of a CIDSS XML document.
317 Presence: mandatory, single
318 Location: root element
319 Contained elements: Signature [multiple, mandatory]
320 Example:
321
323 where "" SHOULD be replaced by the filename of the
324 XSD schema file (e.g. cidss.xsd)
326 2.5.2
327 Signature
329 This element contains all information about a signature. Describes
330 conditions required to identify traffic as suspicious and to take an
331 action.
333 Presence: mandatory
334 Location: element Signatures
335 Attributes: SID [type: integer, single, mandatory, unique]
336 Contained elements: Enabled [single, mandatory], Sig_Source [single,
337 optional], Description [single, optional], Action [single, optional],
338 Protocols [single, mandatory], Sources [single, mandatory],
339 Destinations [single, mandatory], Patterns [single, mandatory],
340 Logged_Packets [single, optional], Message [single, mandatory],
341 Comment [multiple, optional], Session [single, mandatory]
342 Example: See Appendix A
344 Enabled
346 Defines a current signature state. Setting this to true, the
347 signature will be analyzed by the IDS. Otherwise the signature SHOULD
348 be skipped.
350 Presence: mandatory
351 Type: Boolean
352 Default value: true
353 Location: element Signature
354 Example: true
356 Sig_Source
358 Optional element for use in translators. Specifies the IDS from which
359 the signature was translated or ported. This element SHOULD contain
360 string that identifies a signature source.
362 Presence: optional, single
363 Type: String
364 Location: element Signature
365 Example: Snort
367 Description
369 This element MAY contain a simple description of the signature.
371 Presence: optional
372 Type: String
373 Location: element Signature
374 Example: Try to get passwd file using ftp
376 Action
378 This MAY define actions performed by an IDS after intrusion detection
379 Suggested values: drop, allow, alert, and warning
381 Presence: optional, single
382 Type: String
383 Location: element Signature
384 Example: alert
386 2.5.3
387 Protocols
389 This element contains description of multiple protocols used in
390 potential attack.
392 Location: Signature
393 Presence: mandatory, multiple
394 Attributes: ID[integer,unique]
396 Protocol
398 The element used to describe the network protocol. Options of the
399 protocol used in this element depend on a protocol type.
400 The Proto_ID attribute is used for identification in the Proto_Logic
401 element - it is REQUIRED only when there is more than one Protocol in
402 the Protocols element.
404 Presence: mandatory, multiple.
405 Type: String
406 Attributes: Proto_ID [integer, unique], Type [enum: tcp, udp, ip,
407 icmp, application]
408 Location: element Signature
409 Contained elements: TCP_Ack [single, optional], TCP_State [single,
410 optional], TCP_Seq [single, optional], TCP_Dsize [single, optional],
411 TCP_Flags [single, optional], TCP_Window [single, optional],
412 UDP_Dsize [single, optional], ICMP_Dsize [single, optional],
413 ICMP_Icmp_Id [single, optional], ICMP_Icmp_Seq [single, optional],
414 ICMP_Icode [single, optional], ICMP_Itype [single, optional], IP_Ttl
415 [single, optional], IP_Tos [single, optional], IP_Ipopts [single,
416 optional], IP_Fragbits [single, optional], IP_Id [single, optional],
417 IP_Ip_Proto [single, optional], IP_Dsize [single, optional], Isdataat
418 [single, optional], Rpc [single, optional]
420 Isdataat
422 Checks that the data fields in the packet are in the specified
423 offset. When the content of this element contain "<" and ">" signs,
424 it MUST be put into section. In other way it MAY
425 contain CDATA section, but it is not REQUIRED.
427 Allowed values: Integer or integer (more than a given value)
429 Location: Protocol
430 Presence: single, optional
431 Example:
433 Rpc
435 This element specifies the RPC application, version, and procedure
436 numbers in SUNRCP call requests. It MUST contain a string in the
437 following format:
439 Allowed format: , [|*],
440 [|*]>
441 Location: Protocol, Type=="Application"
442 Presence: single, optional
443 Type: String
444 Example: 100000,*,3
446 TCP_Ack
448 Checks the specific TCP ack number
450 Location: Protocol, Type=="TCP"
451 Presence: single, optional
452 Type: integer
453 Example: 0
455 TCP_Seq
457 Checks the specific TCP seq number
459 Location: Protocol, Type=="TCP"
460 Presence: single, optional
461 Type: integer
462 Example: TCP_Seq>0
464 TCP_State
466 Describes current protocol state e.g. established, stateless
468 Location: Protocol, Type=="TCP"
469 Allowed values: [established|stateless]
470 Presence: single, optional
471 Type: string
472 Example: established
474 TCP_Flags
476 Check if the specific TCP Flags are present
478 Location: Protocol, Type=="TCP"
479 Allowed values: [!|*|+][FSRPAU120]
480 Values description: F-FIN, S-SYN, R-RST, P-PSH, A-ACK, U-URG, 1-
481 Reserved bit 1, 2-Reserved bit 2, 0-No Flags set.
482 Modifiers description: + - match on the specific bits, plus any
483 others, * - match if any of the specified bits are set, ! - match if
484 specified bits are not set
485 Presence: single, optional
486 Type: String
487 Example: +SA
489 TCP_Window
491 Checks value of the TCP window size
493 Location: Protocol, Type=="TCP"
494 Presence: single, optional
495 Type: integer
496 Example: 34000
498 TCP_Dsize
500 Checks the packet data field size in TCP protocol. When the content
501 of 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=="TCP"
507 Presence: single, optional
508 Type: String
509 Example:
511 UDP_Dsize
513 Checks packet data field size in UDP protocol. When the content of
514 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=="UDP"
520 Presence: single, optional
521 Type: String
522 Example:
524 ICMP_Dsize
526 Checks the packet data field size in ICMP protocol. When the content
527 of this element contain "<" and ">" signs, it MUST be put into
528 section. In other way it MAY contain CDATA section,
529 but it is not REQUIRED.
531 Allowed signs: <, >, <=, >=, number
532 Location: Protocol, Type=="ICMP"
533 Presence: single, optional
534 Type: String
535 Example: =64]]>
537 ICMP_Icmp_Id
539 Checks the value of specific ICMP ID
541 Location: Protocol, Type=="ICMP"
542 Presence: single, optional
543 Type: integer
544 Example: 0
546 ICMP_Icmp_Seq
548 Checks the value of ICMP sequence
550 Location: Protocol, Type=="ICMP"
551 Presence: single, optional
552 Type: integer
553 Example: 0
555 ICMP_Icode
557 Checks the value of specific ICMP code. When the content of this
558 element contain "<" and ">" signs, it MUST be put into
559 section. In other way it MAY contain CDATA section,
560 but it is not REQUIRED.
562 Allowed signs: <, >, number
563 Location: Protocol, Type=="ICMP"
564 Presence: single, optional
565 Type: String
566 Example: 25]]>
568 ICMP_Itype
570 Checks the value of specified ICMP type. When the content of this
571 element contain "<" and ">" signs, it MUST be put into
572 section. In other way it MAY contain CDATA section,
573 but it is not REQUIRED.
575 Allowed signs: <, >, number
576 Location: Protocol, Type=="ICMP"
577 Presence: single, optional
578 Type: String
579 Example: 25]]>
581 IP_Ttl
583 Specifies IP time-to-live value. When the content of this element
584 contain "<" and ">" signs, it MUST be put into
585 section. In other way it MAY contain CDATA section, but it is not
586 REQUIRED.
588 Allowed signs: <, >, <=, >=,-, number
589 Location: Protocol, Type=="IP"
590 Presence: single, optional
591 Type: string
592 Example: 6-8 - values between 6 and 8
594 IP_Tos
596 Check the IP ToS field for specified value
597 Location: Protocol, Type=="IP"
599 Presence: single, optional
600 Type: integer
601 Example: 2
603 IP_Fragbits
605 Checks fragmentations bits for the specified value
607 Location: Protocol, Type=="IP"
608 Presence: single, optional
609 Type: String
610 Example: DM+
612 IP_Id
614 Checks ID field in IP protocol for the specified value
616 Location: Protocol, Type=="IP"
617 Presence: single, optional
618 Type: integer
619 Example: 34222
621 IP_Ipopts
623 This element checks if the specified IP option is present.
625 Allowed values: rr - Record route, eol - end of list, nop - no op, ts
626 - Time Stamp, sec - IP security option, lsrr - Loose source routing,
627 ssrr - Strict source routing, satid - Stream identifier, any - any IP
628 options are set
629 Location: Protocol, Type=="IP"
630 Presence: single, optional
631 Type: String
632 Example: lsrr
634 IP_Dsize
636 Checks size of packet data field. When the content of this element
637 contain "<" and ">" signs, it MUST be put into
638 section. In other way it MAY contain CDATA section, but it is not
639 REQUIRED.
641 Allowed signs: <, >, <=, >=, number
642 Location: Protocol, Type=="IP"
643 Presence: single, optional
644 Type: String
645 Example: 34000
647 IP_Ip_Proto
649 Checks IP protocol header for the specified value. When the content
650 of this element contain "<" and ">" signs, it MUST be put into
651 section. In other way it MAY contain CDATA section,
652 but it is not REQUIRED.
654 Allowed signs: <, >, <=, >=, number, name
655 Location: Protocol, Type=="IP"
656 Presence: single, optional
657 Type: String
658 Example: igmp
660 Proto_Logic
662 This element describes logical rules to combine the information in
663 Protocol elements contained in one Protocols element. Logical
664 operators in Proto Logic element are described in section 2.4.
666 Presence: optional, single
667 Location: element Protocols
668 Example: 1 OR (2 AND 3)
670 2.5.4
671 Sources
673 This element contains information that describes properties of a
674 source of network communications. If Sources occurs more then once,
675 then every Sources MUST have an unique id (attribute) used in
676 Src_Logic that defines logical dependences between each of them.
678 Presence: mandatory, single
679 Location: element Signature
680 Attributes: ID
681 Contained elements: Source[multiple, mandatory], Src_Logic [single,
682 optional]
683 Example: See Appendix A
685 Source
687 This element contains descriptions of source hosts. Src_ID attribute
688 is local (in one Sources element) id for use with the Src_Logic
689 element.
691 Presence: mandatory, multiple
692 Location: element Sources
693 Attributes: Src_ID [presence: mandatory if more than one Source_ in
694 one Sources element, type: integer, unique]
695 Contained elements: Source_IP[single, mandatory], Source_Port[single,
696 optional]
697 Example: See Appendix A
699 2.5.5
700 Destinations
702 This element contains information that describes properties of a
703 destination of network communications. If Destinations occurs more
704 then once, then every Destination MUST have an unique id (attribute)
705 used in Dst_Logic to define logical dependences between each of them.
707 Presence: mandatory, single
708 Location: element Signature
709 Contained elements: Destination [multiple, mandatory]
710 Example: See Appendix A
712 Destination
714 This element contains descriptions of destination hosts. Dst_ID
715 attribute is local (in one Destinations element) id for use with the
716 Dst_Logic element.
718 Presence: mandatory, multiple
719 Location: element Destinations
720 Attributes: Dst_ID [presence: mandatory if more than one Destination_
721 in one Destinations element, type: integer, unique]
722 Contained elements: Destination_IP [single, mandatory],
723 Destination_Port [single, optional]
724 Example: See Appendix A
726 Source_IP
728 This element contains an IPv4 or IPv6 network address in any
729 notation. The value "any" means that all addresses will be considered
730 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the
731 value of Neg attribute is "true", then the values specified in the
732 Source_IP element are interpreted as addresses that MUST NOT match
733 the source address in order for the signature to apply. Mask
734 attribute defines IP mask for current IP.
736 Allowed values: Any string
737 Attributes: Neg [presence: mandatory, type: boolean, allowed values:
738 true|false, default: false], Mask [presence: mandatory, type: string,
739 allowed values: mask in octet or bit notation]
740 Presence: mandatory, single
741 Type: String
742 Location: element Source
743 Example: $EXTERNAL_NET
744 Variable $EXTERNAL_NET is defined in an IDS. (e.g.
745 $EXTERNAL_NET=1.2.3.4)
747 Destination_IP
749 This element contains an IPv4 or IPv6 network address in any
750 notation. The value "any" means that all addresses will be considered
751 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the
752 value of Neg attribute is "true", then the values specified in the
753 Destination_IP element are interpreted as addresses that MUST NOT
754 match the source address in order for the signature to apply. Mask
755 attribute defines IP mask for current IP.
757 Allowed values: Any string
758 Attributes: Neg [presence: mandatory, type: boolean, allowed values:
759 true|false, default: false], Mask [presence: mandatory, type: string,
760 allowed values: mask in octet or bit notation]
761 Presence: mandatory, single
762 Type: String
763 Location: element Destination
764 Example: Similar as in Source_IP element
766 Source_Port
768 The value of this element is a port number or range of ports
769 expressed by two port numbers divided with a ":" sign. The "135:139"
770 expression means that all ports between 135 and 139 will be
771 considered, accounting ports 135 and 139. The value "any" means that
772 all ports will be considered.
773 Presence: If Protocol Type is set to tcp, udp or ip then mandatory,
774 if Protocol Type value is icmp then MUST NOT be set.
776 Type: String
777 Location: element Source
778 Example: any
780 Destination_Port
782 The value of this element is a port number or range of ports
783 expressed by two port numbers divided with a ":" sign. The "135:139"
784 expression means that all ports between 135 and 139 will be
785 considered, accounting ports 135 and 139. The value "any" means that
786 all ports will be considered.
788 Presence: If Protocol Type value is set to tcp, udp or ip then
789 mandatory, if Protocol Type value is icmp then MUST NOT be set.
790 Type: String
791 Location: element Destination
792 Example: 445
794 Src_Logic
796 Defines logical dependences between each Source description. Logical
797 operators: (, ), AND, OR
799 Location: Sources
800 Example: 2 OR (1 AND 3)
802 Dst_Logic
804 Defines logical dependences between each Destination description.
805 Logical operators: (, ), AND, OR
807 Location: Destinations
808 Example: 1 AND 2
810 2.5.6
811 Patterns
813 This element contains multiple Pattern elements.
815 Presence: single, mandatory (if Protocol is to tcp, udp, ip or
816 application than element is present)
818 Location: element Signature
819 Contained elements: Pattern [multiple, optional]
820 Attributes: ID[integer, unique]
821 Example: See Appendix A
823 Pattern
825 This element contains information about the content of a packet that
826 is considered as potentially dangerous. Attribute Pat_ID is used in
827 Pat_Logic element to define logical expressions using multiple
828 Pattern elements
830 Presence: mandatory, multiple
831 Location: element Patterns
832 Contained elements: Pattern_Type [single, mandatory], Pattern_Content
833 [single, optional], Pattern_Depth [single, optional],
834 Pattern_Uricontent [single, optional], Pattern_Offset [single,
835 optional], Pattern_Within [single, optional], Pattern_Distance
836 [single, optional]
837 Attributes: Pat_ID [integer, unique]
838 Example: See Appendix A
840 Pattern_Type
842 Using CIDSS you can specify patterns in hexadecimal, decimal, or
843 string
845 Presence: mandatory
846 Type: String
847 Location: element Pattern
848 Permitted values: "hex", "dec", "string", "pcre"
849 Default value: "string"
850 Example: string
852 Pattern_Content
854 Defines packet content that is interpreted as an intrusion and
855 considered dangerous. To define the content, regular expressions can
856 be used in the Pattern_Content element. Regular expression MUST be in
857 the PCRE format (Perl Compatible Regular Expressions) [PCRE]. If
858 Rawbytes attribute value is "true" it means pattern is searched in
859 raw packets ignoring decoding that was done by preprocessors. If Neg
860 attribute is true, it means pattern MUST NOT contain specified value.
861 If the content of this element contain "<" and ">" signs, it MUST be
862 put into section. In other way it MAY contain CDATA
863 section, but it is not REQUIRED.
865 Presence: mandatory, single
866 Attributes: CaseSensitive [allowed values: true|false, default value:
867 true], Rawbytes [allowed values: true|false, default value: false],
868 Neg [allowed values: true|false, default: false]
869 Type: Same as value of Pattern_Type
870 Location: element Pattern
871 Example: RETR
872 passwd
874 Pattern_Pcre_Flags
876 Contains standard Perl Compatible_Regular_Expressions modifiers and
877 Perl compatible modifiers or Snort modifiers (used for Snort
878 compatibility)
880 Presence: optional, single
881 Location: element Pattern
882 Type: string
883 Example: iRm
885 Pattern_Depth
887 Defines how many bytes of the packet MUST be searched in order to
888 find the content defined in the Pattern_Content element that is
889 contained by the same Pattern element as this element.
891 Presence: optional, single
892 Location: element Pattern
893 Type: Integer
894 Example: 10
896 Pattern_Uricontent
898 This element describes content of packet in URI format. If this
899 element contains restricted characters (as described in section 2.2)
900 it MUST be put into section. In other way it MAY
901 contain CDATA section, but it is not REQUIRED.
903 Type: string
904 Location: Pattern
905 Presence: optional, single
906 Example:
907
910 Pattern_Offset
912 Specifies offset in bytes from beginning of packet to search for the
913 pattern.
915 Type: integer
916 Location: Pattern
917 Presence: optional, single
918 Example: 5
920 Pattern_Within
922 Used to describe how many packets MUST be at most between two
923 patterns.
925 Type: integer
926 Location: Pattern
927 Presence: optional, single
928 Example: 4
930 Pattern_Distance
932 Defines how far the IDS SHOULD look into a packet for the specified
933 pattern relative to last match.
935 Type: integer
936 Location: Pattern
937 Presence: optional, single
938 Example: 3
940 Pat_Logic
942 This element describes logical rules to combine the information in
943 Pattern elements contained in one Patterns element. Logical operators
944 in Pat_Logic expressions SHOULD be: OR, AND, NOT (as described in
945 section 2.4).
947 Presence: optional, single
948 Location: element Patterns
949 Example: (NOT 1 AND 2) OR 3
951 Logged_Packets
953 Number of packets logged when the system detects an intrusion
955 Presence: optional, single
956 Location: element Signature
957 Type: Integer
958 Example: 0
960 Message
962 Contains the message generated by the IDS when a packet described by
963 this signature was detected. If the content of this element contain
964 "<" and ">" signs, it MUST be put into section. In
965 other way it MAY contain CDATA section, but it is not REQUIRED.
967 Presence: mandatory, single
968 Location: element Signature
969 Type: String
970 Example: FTP password file GET request
972 Comment
974 This element MAY be used for additional comments and information
975 about the signature. The element MAY contain additional information
976 about signature vendor, vulnerability description, http links etc. If
977 the content of this element contains "<" and ">" signs, it MUST be
978 put into section. In other way it MAY contain CDATA
979 section, but it is not REQUIRED.
981 Presence: optional, multiple
982 Location: element Signature
983 Type: String
984 Example: Vendor: Arachnids
986 2.5.7
987 Session
989 Defines a session that could be identified by the signature if the
990 state mechanisms of an IDS could be used. Otherwise, the information
991 contained in this element describes the conditions that MUST be
992 satisfied by the sensor data in order to trigger the signature.
994 Location: Signature
995 Presence: single, mandatory
996 Contained elements: Session_Filter [single, optional], Session_Start
997 [single, optional], Session_End [single, optional],
998 Session_Identification [single, optional], Session_Instructions
999 [single, optional]
1001 Session_Filter
1003 Contains IDs of Source, Destination, Protocol and 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 be
1007 included in this session.
1009 Location: Session
1010 Presence: single, optional
1011 Allowed values: CIDSS logical expressions.
1013 Session_Start
1015 Contains IDs of Source, Destination, Protocol or Pattern elements,
1016 combined using logical expressions in the format described in section
1017 2.4. The information contained in this element specifies the
1018 conditions that MUST be met by sensor data so that the packet will
1019 define the beginning of a new session. All session state MUST be
1020 reset by the IDS when a new session begins.
1022 Location: Session
1023 Presence: single, optional
1024 Allowed values: CIDSS logical expressions.
1026 Session_End
1028 Contains IDs of Source, Destination, Protocol or Pattern elements,
1029 combined using logical expressions in the format described in section
1030 2.4. The information contained in this element specifies the
1031 conditions that MUST be met by sensor data so that the packet will
1032 define the beginning of a new session.
1033 Instead of or in addition to conditions for sensor data, this element
1034 MAY include the element Session_Timeout, that specifies a timeout for
1035 the session or MAY include Session_Pckt_Count, that defines maximum
1036 number of packets considered in current session. When both conditions
1037 are specified, then the one that is fulfilled first will terminate
1038 the session.
1040 Location: Session
1041 Presence: single, mandatory if the Session_Start element is present
1042 Contained elements: Session_Timeout [single, optional],
1043 Session_Pckt_Count [single, optional]
1045 Session_Pckt_Count
1047 Defines maximum number of packets that are considered during session.
1049 Presence: single, optional
1050 Location: Session_End
1051 Type: Integer
1052 Example: 5
1054 Session_Timeout
1056 Defines a timeout for the session. The time MUST be specified in the
1057 format: an integer and a single character (the character MUST be one
1058 of: ms,s,m,h - milliseconds, seconds, minutes, hours).
1060 Presence: optional, single
1061 Type: String
1062 Location: Session_End
1063 Example: 10s
1064 Example description: The timeout for the session is 10 seconds.
1066 Session_Identification
1068 Defines additional conditions that MUST be met by sensor data so that
1069 a packet will be included in this session. These conditions apply
1070 after a session has started. For instance, a TCP session will include
1071 only the packets that have the same source and destination as the
1072 source and destination of packets that started the session. The
1073 conditions are specified by including special elements in this
1074 element.
1076 Location: Session
1077 Presence: single, mandatory if the Session_Start attribute is present
1078 Contained elements: Same_Source_IP [single, optional],
1079 Same_Source_Port [single, optional], Same_Destination_IP [single,
1080 optional], Same_Destination_Port [single, optional], Same_Protocol
1081 [single, optional], Same_Direction [single, optional]
1083 Same_Source_IP
1085 If this element is present in Session_Identification, packets that
1086 will be included in the session MUST have the same source IP address
1087 as the starting packet.
1089 Type: boolean
1090 Presence: single, optional
1091 Location: Session_Identification
1093 Same_Source_Port
1095 If this element is present in Session_Identification, packets that
1096 will be included in the session MUST have the same source port as the
1097 starting packet.
1099 Type: boolean
1100 Presence: single, optional
1101 Location: Session_Identification
1103 Same_Destination_IP
1105 If this element is present in Session_Identification, packets that
1106 will be included in the session MUST have the same destination IP
1107 address as the starting packet.
1109 Type: boolean
1110 Presence: single, optional
1111 Location: Session_Identification
1113 Same_Destination_Port
1115 If this element is present in Session_Identification, packets that
1116 will be included in the session MUST have the same destination port
1117 as the starting packet.
1119 Type: boolean
1120 Presence: single, optional
1121 Location: Session_Identification
1123 Same_Protocol
1125 If this element is present in Session_Identification, packets that
1126 will be included in the session MUST be of the same protocol as the
1127 starting packet.
1129 Type: boolean
1130 Presence: single, optional
1131 Location: Session_Identification
1133 Same_Direction
1135 If this element is present in Session_Identification, packets that
1136 will be included in the session MUST have been sent in the same
1137 direction as the starting packet.
1139 Type: boolean
1140 Presence: single, optional
1141 Location: Session_Identification
1143 Session_Instructions
1145 This element works like a switch statement for the state mechanism of
1146 an IDS. The information contained in this element defines the
1147 statefull behavior of an IDS for this session. The element contains
1148 several Session_Case elements that include conditions for the case to
1149 apply, as well as instructions to be carried out if the case applies.
1150 For efficiency reasons, it is assumed that all conditions for state
1151 instructions will be brought down into a conjunctive normal form (a
1152 logical expression that includes alternatives only at the highest
1153 level). That means that in every case element, all case conditions
1154 are treated as a logical conjunction (logical AND). This ought to
1155 simplify the processing of these instructions.
1157 Location: Session
1158 Presence: single, optional
1159 Contained elements: Session_Case [multiple]
1161 Session_Case
1163 This element contains the conditions and instructions of a case in
1164 the switch statement that is defined by the containing
1165 Session_Instructions element. For readability, the conditions are
1166 split up into three groups: additional conditions for sensor data
1167 that MUST be satisfied so that the packet will apply to this case,
1168 the direction of the packet, and the conditions that MUST be
1169 satisfied by the state variables of a session in order for the case
1170 to apply. The instructions of a case are contained in the mandatory
1171 Case_State_Instructions element.
1173 Location: Session_Instructions
1174 Presence: multiple
1175 Contained elements: Case_Filter [single, optional], Direction
1176 [single, optional], Case_State_Condition [single, optional],
1177 Case_State_Instructions [single, mandatory]
1179 Case_Filter
1181 Contains IDs of Source, Destination, Protocol or Pattern elements,
1182 combined using logical expressions in the format described in section
1183 2.4. The information contained in this element specifies the
1184 conditions that MUST be met by sensor data so that the packet will
1185 apply to this case.
1187 Location: Session_Case
1188 Presence: single, optional
1189 Allowed values: CIDSS logical expressions.
1191 Direction
1193 Defines a direction of network traffic, once a source and destination
1194 of traffic are specified (e.g. after the start of a session). Allowed
1195 values are: "sd" and "ds". If direction value is "sd" it means that
1196 the packet has been sent from source to destination. If the value of
1197 this element is "ds" it means that traffic goes from destination to
1198 source.
1200 Allowed values: sd|ds
1201 Default value: sd
1202 Location: Session_Case
1203 Presence: single, optional
1205 Case_State_Condition
1207 This element contains conditional state expressions that MUST all be
1208 satisfied (evaluate to a boolean value of "true") in order for the
1209 case to apply. These instructions MAY check the values of state
1210 variables stored by the IDS for this session.
1212 Location: Session_Case
1213 Presence: single, optional
1214 Contained elements: Isset_Var, Compare_Var
1216 Case_State_Instructions
1218 This element contains state instructions that MUST all be
1219 sequentially carried out by the IDS if the case applies. These
1220 instructions MAY set, unset or modify the values of state variables
1221 stored by the IDS for this session.
1223 Location: Session_Case
1224 Presence: single, optional
1225 Contained elements: Set_Var, Unset_Var, Isset_Var, Isnotset_Var,
1226 Compare_Var, Toggle_Var
1228 Isset_Var
1230 A conditional state expression that evaluates to a boolean value of
1231 "true" if the variable of a name that is specified in the "var"
1232 attribute is set in the state of this session.
1234 Location: Case_State_Condition
1235 Presence: multiple, optional
1236 Attributes: var [type: string; single, mandatory]
1238 Isnotset_Var
1240 A conditional state expression that evaluates to a boolean value of
1241 "true" if the variable of a name that is specified in the "var"
1242 attribute is not set in the state of this session.
1244 Location: Case_State_Condition
1245 Presence: multiple, optional
1246 Attributes: var [type: string; single, mandatory]
1248 Compare_Var
1250 Location: Case_State_Condition
1251 Presence: multiple, optional
1252 Attributes: var [type: string; single, mandatory], value [type:
1253 string; single, mandatory]
1255 Set_Var
1257 Sets value of "var" attribute in state of particular session.
1259 Location: Case_State_Instructions
1260 Presence: multiple, optional
1261 Attributes: var [type: string; single, mandatory], value [type:
1262 string; single, mandatory]
1264 Unset_Var
1266 Nullifies value of "var" used in this session.
1268 Location: Case_State_Instructions
1269 Presence: multiple, optional
1270 Attributes: var [type: string; single, mandatory]
1272 Toggle_Var
1274 Toggle value of "var" attribute in state of particular session. Set
1275 the specified state if the state is unset, otherwise unsets the state
1276 if the state is set.
1278 Location: Case_State_Instructions
1279 Presence: multiple, optional
1280 Attributes: var [type: string; single, mandatory], value [type:
1281 string; single, mandatory]
1283 3.
1284 Security Considerations
1286 This Internet Draft describes the CIDSS format for storing
1287 information about IDS signatures. The applications of this standard
1288 can raise security concerns, but there is no security concerns
1289 related strictly to the document format.
1291 It is RECOMMENDED that a system for storing CIDSS data SHOULD be
1292 protected against unauthorized access and unauthorized use. The means
1293 for achieving this protection are outside the scope of this document.
1295 Appendix A
1296 XML CIDSS Document Example
1298 Here we present a sample signature in CIDSS format. Elements of this
1299 signature have been used as examples in the previous sections. (This
1300 appendix MAY NOT be compatible with Internet Draft formatting).
1302
1303
1305
1306 true
1307 snort
1308 alert
1309 NETBIOS SMB-DS DCERPC Remote Activation bind attempt;
1310 sid=2252
1311 NETBIOS SMB-DS DCERPC Remote Activation bind
1312 attempt
1313 reference: cve,CAN-2003-0528
1314 reference: cve,CAN-2003-0605
1315 reference: cve,CAN-2003-0715
1316 reference:
1317 url,www.microsoft.com/technet/security/bulletin/MS03-
1318 039.mspx
1319
1320
1324
1328
1332 1 AND 2 AND 3
1333
1334
1335
1336 any
1337 445
1338
1339
1340 192.168.1.0
1342 445
1343
1344
1345 10.0.0.0
1347 445
1348
1349 1 AND 2 AND 3
1350
1351
1352
1353 established
1354
1355 1
1356
1357
1358
1359 string
1360
1362 5
1363 4
1364
1365
1366 string
1367
1369 2
1370 56
1371
1372
1373 string
1374 |5C
1375 00|P|00|I|00|P|00|E|00 5C 00|
1376 12
1377 5
1378
1379
1380 hex
1381 05
1382 1
1383
1384
1385 hex
1386 0B
1387 1
1388 1
1389
1390
1391 string
1392 |B8|J|9F|M|1C|}|CF 11
1393 86 1E 00| |AF|n|7C|W
1394 16
1395 29
1397
1398 1 AND 2 AND 3 AND 4 AND 5 AND 6
1399
1400
1401 (SRC_1 AND SRC_2 AND SRC_3) AND (DST_1 AND
1402 DST_2 AND DST_3) AND PROTO_1 AND (PAT_1 AND PAT_2 AND PAT_3 AND PAT_4
1403 AND PAT_5 AND PAT_6)
1404
1405 5
1406
1407
1408
1409
1411 Appendix B
1412 The schema of CIDSS - cidss.xsd
1414 Available at http://translator.b59.net/docs/cidss.xsd
1416 References
1418 Normative references
1420 [SNORTman] Roesch Martin, Green Chris, "Snort Users Manual", 2.3.0
1421 January 2005, http://www.snort.org
1423 [DRAGON] "Dragon. Intrusion Detection System. Topics on Writing
1424 Signatures" Enterasys Networks, 2002,
1425 http://dragon.enterasys.com
1427 [SHOKIug] Shoki, "Shoki User's Guide", Release 0.3.0,
1428 http://shoki.sourceforge.net/
1430 [XML10] Extensible Markup Language (XML) 1.0, Third Edition,
1431 http://www.w3.org/TR/2004/REC-xml-20040204/
1433 [XSD] XML Schema - Specifications and Development,
1434 http://www.w3.org/XML/Schema#dev
1436 [ISSdoc] ISS - Internet Security Systems, Documentation,
1437 http://www.iss.net/support/documentation/
1439 [CISCOdoc] Cisco - NetRanger, Documentation,
1440 http://www.cisco.com/univercd/cc/td/doc/product/iaabu/\
1441 netrangr/
1443 [PCRE] PCRE - Perl Compatible Regular Expressions,
1444 http://www.pcre.org/
1446 Informative references
1448 [RFC2119] Bradner S., "Key words for use in RFCs to Indicate
1449 Requirement Levels", BCP 14, RFC 2119, March 1997.
1451 [IDWG11] Curry D., Lynch Merrill, Debar H., "The Intrusion
1452 Detection Message Exchange Format", Internet Draft
1453 draft-ietf-idwg-idmef-xml-11, January 2004,
1454 expires July 2004.
1456 [JAVAXML] McLaughlin Brett, Java & XML, 2nd Edition,
1457 ISBN: 0-596-00197-5
1459 [CIDSL] K. Miakisz, Translator i wspolny jezyk sygnatur
1460 systemow wykrywania wlaman (Translator and Common
1461 Intrusion Detection Systems Language), Bachelor thesis,
1462 Polish-Japanese Institute of Information Technology,
1463 2003
1465 [ARACH] arachNIDS - Whitehats Network Security Resource,
1466 http://whitehats.com/ids/
1468 Author's Addresses
1470 dr Adam Wierzbicki
1471 Polish-Japanese Institute of Information Technology
1472 Koszykowa 86
1473 02-008 Warsaw, Poland
1474 Email: adamw@pjwstk.edu.pl
1476 Jacek Kalinski
1477 Rechniewskiego 6/24
1478 03-980 Warsaw, Poland
1479 Email: jacek@dyski.one.pl
1481 Tomasz Kruszona
1482 Garwolinska 9/83
1483 04-348 Warsaw, Poland
1484 Email: t.kruszona@b59.net
1486 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 Copyright Notice
1495 Copyright (C) The Internet Society (2006).
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 Disclaimer of Validity
1503 This document and the information contained herein are provided on an
1504 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1505 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1506 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1507 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1508 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1509 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1511 Intellectual Property Statement
1513 The IETF takes no position regarding the validity or scope of any
1514 Intellectual Property Rights or other rights that might be claimed to
1515 pertain to the implementation or use of the technology described in
1516 this document or the extent to which any license under such rights
1517 might or might not be available; nor does it represent that it has
1518 made any independent effort to identify any such rights. Information
1519 on the procedures with respect to rights in RFC documents can be
1520 found in BCP 78 and BCP 79.
1522 Copies of IPR disclosures made to the IETF Secretariat and any
1523 assurances of licenses to be made available, or the result of an
1524 attempt made to obtain a general license or permission for the use of
1525 such proprietary rights by implementers or users of this
1526 specification can be obtained from the IETF on-line IPR repository at
1527 http://www.ietf.org/ipr.
1529 The IETF invites any interested party to bring to its attention any
1530 copyrights, patents or patent applications, or other proprietary
1531 rights that may cover technology that may be required to implement
1532 this standard. Please address the information to the IETF at
1533 ietf-ipr@ietf.org.
1535 IANA Considerations
1537 This document does not introduce any IANA considerations.