RFC 5070
The Incident Object Description Exchange Format
Network Working Group R. Danyliw Request for Comments: 5070 CERT Category: Standards Track J. Meijer UNINETT Y. Demchenko University of Amsterdam December 2007 The Incident Object Description Exchange Format Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract
The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. About the IODEF Data Model . . . . . . . . . . . . . . . . 5 1.4. About the IODEF Implementation . . . . . . . . . . . . . . 6 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Characters and Strings . . . . . . . . . . . . . . . . . . 7 2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . . 7 2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . . 7 2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . . . 8 2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . . 8
2.9. Timezone String . . . . . . . . . . . . . . . . . . . . . 8
2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . . 8
2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . . 9
2.12. Person or Organization . . . . . . . . . . . . . . . . . . 9
2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . . 9
2.14. Email String . . . . . . . . . . . . . . . . . . . . . . . 9
2.15. Uniform Resource Locator strings . . . . . . . . . . . . . 9
3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . . 9
3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . . 10
3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . . 10
3.3. IncidentID Class . . . . . . . . . . . . . . . . . . . . . 14
3.4. AlternativeID Class . . . . . . . . . . . . . . . . . . . 14
3.5. RelatedActivity Class . . . . . . . . . . . . . . . . . . 15
3.6. AdditionalData Class . . . . . . . . . . . . . . . . . . . 16
3.7. Contact Class . . . . . . . . . . . . . . . . . . . . . . 18
3.7.1. RegistryHandle Class . . . . . . . . . . . . . . . . . 21
3.7.2. PostalAddress Class . . . . . . . . . . . . . . . . . 22
3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 22
3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23
3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . . 23
3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24
3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . . 24
3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . . 24
3.9.1. Reference Class . . . . . . . . . . . . . . . . . . . 25
3.10. Assessment Class . . . . . . . . . . . . . . . . . . . . . 25
3.10.1. Impact Class . . . . . . . . . . . . . . . . . . . . . 27
3.10.2. TimeImpact Class . . . . . . . . . . . . . . . . . . . 29
3.10.3. MonetaryImpact Class . . . . . . . . . . . . . . . . . 30
3.10.4. Confidence Class . . . . . . . . . . . . . . . . . . . 31
3.11. History Class . . . . . . . . . . . . . . . . . . . . . . 32
3.11.1. HistoryItem Class . . . . . . . . . . . . . . . . . . 33
3.12. EventData Class . . . . . . . . . . . . . . . . . . . . . 34
3.12.1. Relating the Incident and EventData Classes . . . . . 36
3.12.2. Cardinality of EventData . . . . . . . . . . . . . . . 37
3.13. Expectation Class . . . . . . . . . . . . . . . . . . . . 37
3.14. Flow Class . . . . . . . . . . . . . . . . . . . . . . . . 40
3.15. System Class . . . . . . . . . . . . . . . . . . . . . . . 40
3.16. Node Class . . . . . . . . . . . . . . . . . . . . . . . . 42
3.16.1. Counter Class . . . . . . . . . . . . . . . . . . . . 43
3.16.2. Address Class . . . . . . . . . . . . . . . . . . . . 45
3.16.3. NodeRole Class . . . . . . . . . . . . . . . . . . . . 46
3.17. Service Class . . . . . . . . . . . . . . . . . . . . . . 48
3.17.1. Application Class . . . . . . . . . . . . . . . . . . 50
3.18. OperatingSystem Class . . . . . . . . . . . . . . . . . . 51
3.19. Record Class . . . . . . . . . . . . . . . . . . . . . . . 51
3.19.1. RecordData Class . . . . . . . . . . . . . . . . . . . 51
3.19.2. RecordPattern Class . . . . . . . . . . . . . . . . . 53
3.19.3. RecordItem Class . . . . . . . . . . . . . . . . . . . 54
4. Processing Considerations . . . . . . . . . . . . . . . . . . 54
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 55
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 55
5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 56
5.1. Extending the Enumerated Values of Attributes . . . . . . 56
5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 57
6. Internationalization Issues . . . . . . . . . . . . . . . . . 59
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 61
7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . . 63
7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . . . 65
8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . . 66
9. Security Considerations . . . . . . . . . . . . . . . . . . . 87
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 88
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12.1. Normative References . . . . . . . . . . . . . . . . . . . 89
12.2. Informative References . . . . . . . . . . . . . . . . . . 90
1. Introduction
Organizations require help from other parties to mitigate malicious activity targeting their network and to gain insight into potential threats. This coordination might entail working with an ISP to filter attack traffic, contacting a remote site to take down a bot- network, or sharing watch-lists of known malicious IP addresses in a consortium. The Incident Object Description Exchange Format (IODEF) is a format for representing computer security information commonly exchanged between Computer Security Incident Response Teams (CSIRTs). It provides an XML representation for conveying incident information across administrative domains between parties that have an operational responsibility of remediation or a watch-and-warning over a defined constituency. The data model encodes information about hosts, networks, and the services running on these systems; attack methodology and associated forensic evidence; impact of the activity; and limited approaches for documenting workflow. The overriding purpose of the IODEF is to enhance the operational capabilities of CSIRTs. Community adoption of the IODEF provides an improved ability to resolve incidents and convey situational awareness by simplifying collaboration and data sharing. This structured format provided by the IODEF allows for: o increased automation in processing of incident data, since the resources of security analysts to parse free-form textual documents will be reduced; o decreased effort in normalizing similar data (even when highly structured) from different sources; and o a common format on which to build interoperable tools for incident handling and subsequent analysis, specifically when data comes from multiple constituencies. Coordinating with other CSIRTs is not strictly a technical problem. There are numerous procedural, trust, and legal considerations that might prevent an organization from sharing information. The IODEF does not attempt to address them. However, operational implementations of the IODEF will need to consider this broader context. Sections 3 and 8 specify the IODEF data model with text and an XML schema. The types used by the data model are covered in Section 2. Processing considerations, the handling of extensions, and internationalization issues related to the data model are covered in
Sections 4, 5, and 6, respectively. Examples are listed in Section 7. Section 1 provides the background for the IODEF, and Section 9 documents the security considerations.1.1. Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [6]. Definitions for some of the common computer security-related terminology used in this document can be found in Section 2 of [16].1.2. Notations
The normative IODEF data model is specified with the text in Section 3 and the XML schema in Section 8. To help in the understanding of the data elements, Section 3 also depicts the underlying information model using Unified Modeling Language (UML). This abstract presentation of the IODEF is not normative. For clarity in this document, the term "XML document" will be used when referring generically to any instance of an XML document. The term "IODEF document" will be used to refer to specific elements and attributes of the IODEF schema. The terms "class" and "element" will be used interchangeably to reference either the corresponding data element in the information or data models, respectively.1.3. About the IODEF Data Model
The IODEF data model is a data representation that provides a framework for sharing information commonly exchanged by CSIRTs about computer security incidents. A number of considerations were made in the design of the data model. o The data model serves as a transport format. Therefore, its specific representation is not the optimal representation for on- disk storage, long-term archiving, or in-memory processing. o As there is no precise widely agreed upon definition for an incident, the data model does not attempt to dictate one through its implementation. Rather, a broad understanding is assumed in the IODEF that is flexible enough to encompass most operators. o Describing an incident for all definitions would require an extremely complex data model. Therefore, the IODEF only intends to be a framework to convey commonly exchanged incident information. It ensures that there are ample mechanisms for
extensibility to support organization-specific information, and
techniques to reference information kept outside of the explicit
data model.
o The domain of security analysis is not fully standardized and must
rely on free-form textual descriptions. The IODEF attempts to
strike a balance between supporting this free-form content, while
still allowing automated processing of incident information.
o The IODEF is only one of several security relevant data
representations being standardized. Attempts were made to ensure
they were complimentary. The data model of the Intrusion
Detection Message Exchange Format [17] influenced the design of
the IODEF.
Further discussion of the desirable properties for the IODEF can be
found in the Requirements for the Format for Incident Information
Exchange (FINE) [16].
1.4. About the IODEF Implementation
The IODEF implementation is specified as an Extensible Markup
Language (XML) [1] Schema [2] in Section 8.
Implementing the IODEF in XML provides numerous advantages. Its
extensibility makes it ideal for specifying a data encoding framework
that supports various character encodings. Likewise, the abundance
of related technologies (e.g., XSL, XPath, XML-Signature) makes for
simplified manipulation. However, XML is fundamentally a text
representation, which makes it inherently inefficient when binary
data must be embedded or large volumes of data must be exchanged.
2. IODEF Data Types
The various data elements of the IODEF data model are typed. This
section discusses these data types. When possible, native Schema
data types were adopted, but for more complicated formats, regular
expressions (see Appendix F of [3]) or external standards were used.
2.1. Integers
An integer is represented by the INTEGER data type. Integer data
MUST be encoded in Base 10.
The INTEGER data type is implemented as an "xs:integer" [3] in the
schema.
2.2. Real Numbers
Real (floating-point) attributes are represented by the REAL data type. Real data MUST be encoded in Base 10. The REAL data type is implemented as an "xs:float" [3] in the schema.2.3. Characters and Strings
A single character is represented by the CHARACTER data type. A character string is represented by the STRING data type. Special characters must be encoded using entity references. See Section 4.1. The CHARACTER and STRING data types are implement as an "xs:string" [3] in the schema.2.4. Multilingual Strings
STRING data that represents multi-character attributes in a language different than the default encoding of the document is of the ML_STRING data type. The ML_STRING data type is implemented as an "iodef:MLStringType" in the schema.2.5. Bytes
A binary octet is represented by the BYTE data type. A sequence of binary octets is represented by the BYTE[] data type. These octets are encoded using base64. The BYTE data type is implemented as an "xs:base64Binary" [3] in the schema.2.6. Hexadecimal Bytes
A binary octet is represented by the HEXBIN (and HEXBIN[]) data type. This octet is encoded as a character tuple consisting of two hexadecimal digits. The HEXBIN data type is implemented as an "xs:hexBinary" [3] in the schema.
2.7. Enumerated Types
Enumerated types are represented by the ENUM data type, and consist of an ordered list of acceptable values. Each value has a representative keyword. Within the IODEF schema, the enumerated type keywords are used as attribute values. The ENUM data type is implemented as a series of "xs:NMTOKEN" in the schema.2.8. Date-Time Strings
Date-time strings are represented by the DATETIME data type. Each date-time string identifies a particular instant in time; ranges are not supported. Date-time strings are formatted according to a subset of ISO 8601: 2000 [13] documented in RFC 3339 [12]. The DATETIME data type is implemented as an "xs:dateTime" [3] in the schema.2.9. Timezone String
A timezone offset from UTC is represented by the TIMEZONE data type. It is formatted according to the following regular expression: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". The TIMEZONE data type is implemented as an "xs:string" with a regular expression constraint in the schema. This regular expression is identical to the timezone representation implemented in an "xs: dateTime".2.10. Port Lists
A list of network ports are represented by the PORTLIST data type. A PORTLIST consists of a comma-separated list of numbers and ranges (N-M means ports N through M, inclusive). It is formatted according to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*". For example, "2,5-15,30,32,40-50,55-60". The PORTLIST data type is implemented as an "xs:string" with a regular expression constraint in the schema.
2.11. Postal Address
A postal address is represented by the POSTAL data type. This data type is an ML_STRING whose format is documented in Section 2.23 of RFC 4519 [10]. It defines a postal address as a free-form multi-line string separated by the "$" character. The POSTAL data type is implemented as an "xs:string" in the schema.2.12. Person or Organization
The name of an individual or organization is represented by the NAME data type. This data type is an ML_STRING whose format is documented in Section 2.3 of RFC 4519 [10]. The NAME data type is implemented as an "xs:string" in the schema.2.13. Telephone and Fax Numbers
A telephone or fax number is represented by the PHONE data type. The format of the PHONE data type is documented in Section 2.35 of RFC 4519 [10]. The PHONE data type is implemented as an "xs:string" in the schema.2.14. Email String
An email address is represented by the EMAIL data type. The format of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [11] The EMAIL data type is implemented as an "xs:string" in the schema.2.15. Uniform Resource Locator strings
A uniform resource locator (URL) is represented by the URL data type. The format of the URL data type is documented in RFC 2396 [8]. The URL data type is implemented as an "xs:anyURI" in the schema.3. The IODEF Data Model
In this section, the individual components of the IODEF data model will be discussed in detail. For each class, the semantics will be described and the relationship with other classes will be depicted with UML. When necessary, specific comments will be made about corresponding definition in the schema in Section 8
3.1. IODEF-Document Class
The IODEF-Document class is the top level class in the IODEF data model. All IODEF documents are an instance of this class. +-----------------+ | IODEF-Document | +-----------------+ | STRING version |<>--{1..*}--[ Incident ] | ENUM lang | | STRING formatid | +-----------------+ Figure 1: IODEF-Document Class The aggregate class that constitute IODEF-Document is: Incident One or more. The information related to a single incident. The IODEF-Document class has three attributes: version Required. STRING. The IODEF specification version number to which this IODEF document conforms. The value of this attribute MUST be "1.00" lang Required. ENUM. A valid language code per RFC 4646 [7] constrained by the definition of "xs:language". The interpretation of this code is described in Section 6. formatid Optional. STRING. A free-form string to convey processing instructions to the recipient of the document. Its semantics must be negotiated out-of-band.3.2. Incident Class
Every incident is represented by an instance of the Incident class. This class provides a standardized representation for commonly exchanged incident data.
+--------------------+ | Incident | +--------------------+ | ENUM purpose |<>----------[ IncidentID ] | STRING ext-purpose |<>--{0..1}--[ AlternativeID ] | ENUM lang |<>--{0..1}--[ RelatedActivity ] | ENUM restriction |<>--{0..1}--[ DetectTime ] | |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ EndTime ] | |<>----------[ ReportTime ] | |<>--{0..*}--[ Description ] | |<>--{1..*}--[ Assessment ] | |<>--{0..*}--[ Method ] | |<>--{1..*}--[ Contact ] | |<>--{0..*}--[ EventData ] | |<>--{0..1}--[ History ] | |<>--{0..*}--[ AdditionalData ] +--------------------+ Figure 2: The Incident Class The aggregate classes that constitute Incident are: IncidentID One. An incident tracking number assigned to this incident by the CSIRT that generated the IODEF document. AlternativeID Zero or one. The incident tracking numbers used by other CSIRTs to refer to the incident described in the document. RelatedActivity Zero or one. The incident tracking numbers of related incidents. DetectTime Zero or one. The time the incident was first detected. StartTime Zero or one. The time the incident started. EndTime Zero or one. The time the incident ended. ReportTime One. The time the incident was reported.
Description
Zero or more. ML_STRING. A free-form textual description of the
incident.
Assessment
One or more. A characterization of the impact of the incident.
Method
Zero or more. The techniques used by the intruder in the
incident.
Contact
One or more. Contact information for the parties involved in the
incident.
EventData
Zero or more. Description of the events comprising the incident.
History
Zero or one. A log of significant events or actions that occurred
during the course of handling the incident.
AdditionalData
Zero or more. Mechanism by which to extend the data model.
The Incident class has four attributes:
purpose
Required. ENUM. The purpose attribute represents the reason why
the IODEF document was created. It is closely related to the
Expectation class (Section 3.13). This attribute is defined as an
enumerated list:
1. traceback. The document was sent for trace-back purposes.
2. mitigation. The document was sent to request aid in
mitigating the described activity.
3. reporting. The document was sent to comply with reporting
requirements.
4. other. The document was sent for purposes specified in the
Expectation class.
5. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-purpose
Optional. STRING. A means by which to extend the purpose
attribute. See Section 5.1.
lang
Optional. ENUM. A valid language code per RFC 4646 [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6.
restriction
Optional. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere for
the information represented in this class and its children. This
guideline provides no security since there are no specified
technical means to ensure that the recipient of the document
handles the information as the sender requested.
The value of this attribute is logically inherited by the children
of this class. That is to say, the disclosure rules applied to
this class, also apply to its children.
It is possible to set a granular disclosure policy, since all of
the high-level classes (i.e., children of the Incident class) have
a restriction attribute. Therefore, a child can override the
guidelines of a parent class, be it to restrict or relax the
disclosure rules (e.g., a child has a weaker policy than an
ancestor; or an ancestor has a weak policy, and the children
selectively apply more rigid controls). The implicit value of the
restriction attribute for a class that did not specify one can be
found in the closest ancestor that did specify a value.
This attribute is defined as an enumerated value with a default
value of "private". Note that the default value of the
restriction attribute is only defined in the context of the
Incident class. In other classes where this attribute is used, no
default is specified.
1. public. There are no restrictions placed in the information.
2. need-to-know. The information may be shared with other
parties that are involved in the incident as determined by the
recipient of this document (e.g., multiple victim sites can be
informed of each other).
3. private. The information may not be shared.
4. default. The information can be shared according to an
information disclosure policy pre-arranged by the
communicating parties.
3.3. IncidentID Class
The IncidentID class represents an incident tracking number that is
unique in the context of the CSIRT and identifies the activity
characterized in an IODEF Document. This identifier would serve as
an index into the CSIRT incident handling system. The combination of
the name attribute and the string in the element content MUST be a
globally unique identifier describing the activity. Documents
generated by a given CSIRT MUST NOT reuse the same value unless they
are referencing the same incident.
+------------------+
| IncidentID |
+------------------+
| STRING |
| |
| STRING name |
| STRING instance |
| ENUM restriction |
+------------------+
Figure 3: The IncidentID Class
The IncidentID class has three attributes:
name
Required. STRING. An identifier describing the CSIRT that
created the document. In order to have a globally unique CSIRT
name, the fully qualified domain name associated with the CSIRT
MUST be used.
instance
Optional. STRING. An identifier referencing a subset of the
named incident.
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.4. AlternativeID Class
The AlternativeID class lists the incident tracking numbers used by
CSIRTs, other than the one generating the document, to refer to the
identical activity described the IODEF document. A tracking number
listed as an AlternativeID references the same incident detected by
another CSIRT. The incident tracking numbers of the CSIRT that generated the IODEF document should never be considered an AlternativeID. +------------------+ | AlternativeID | +------------------+ | ENUM restriction |<>--{1..*}--[ IncidentID ] | | +------------------+ Figure 4: The AlternativeID Class The aggregate class that constitutes AlternativeID is: IncidentID One or more. The incident tracking number of another CSIRT. The AlternativeID class has one attribute: restriction Optional. ENUM. This attribute has been defined in Section 3.2.3.5. RelatedActivity Class
The RelatedActivity class lists either incident tracking numbers of incidents or URLs (not both) that refer to activity related to the one described in the IODEF document. These references may be to local incident tracking numbers or to those of other CSIRTs. The specifics of how a CSIRT comes to believe that two incidents are related are considered out of scope. +------------------+ | RelatedActivity | +------------------+ | ENUM restriction |<>--{0..*}--[ IncidentID ] | |<>--{0..*}--[ URL ] +------------------+ Figure 5: RelatedActivity Class
The aggregate classes that constitutes RelatedActivity are:
IncidentID
One or more. The incident tracking number of a related incident.
URL
One or more. URL. A URL to activity related to this incident.
The RelatedActivity class has one attribute:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.6. AdditionalData Class
The AdditionalData class serves as an extension mechanism for
information not otherwise represented in the data model. For
relatively simple information, atomic data types (e.g., integers,
strings) are provided with a mechanism to annotate their meaning.
The class can also be used to extend the data model (and the
associated Schema) to support proprietary extensions by encapsulating
entire XML documents conforming to another Schema (e.g., IDMEF). A
detailed discussion for extending the data model and the schema can
be found in Section 5.
Unlike XML, which is self-describing, atomic data must be documented
to convey its meaning. This information is described in the
'meaning' attribute. Since these description are outside the scope
of the specification, some additional coordination may be required to
ensure that a recipient of a document using the AdditionalData
classes can make sense of the custom extensions.
+------------------+
| AdditionalData |
+------------------+
| ANY |
| |
| ENUM dtype |
| STRING ext-dtype |
| STRING meaning |
| STRING formatid |
| ENUM restriction |
+------------------+
Figure 6: The AdditionalData Class
The AdditionalData class has five attributes:
dtype
Required. ENUM. The data type of the element content. The
permitted values for this attribute are shown below. The default
value is "string".
1. boolean. The element content is of type BOOLEAN.
2. byte. The element content is of type BYTE.
3. character. The element content is of type CHARACTER.
4. date-time. The element content is of type DATETIME.
5. integer. The element content is of type INTEGER.
6. portlist. The element content is of type PORTLIST.
7. real. The element content is of type REAL.
8. string. The element content is of type STRING.
9. file. The element content is a base64 encoded binary file
encoded as a BYTE[] type.
10. frame. The element content is a layer-2 frame encoded as a
HEXBIN type.
11. packet. The element content is a layer-3 packet encoded as a
HEXBIN type.
12. ipv4-packet. The element content is an IPv4 packet encoded
as a HEXBIN type.
13. ipv6-packet. The element content is an IPv6 packet encoded
as a HEXBIN type.
14. path. The element content is a file-system path encoded as a
STRING type.
15. url. The element content is of type URL.
16. csv. The element content is a common separated value (CSV)
list per Section 2 of [20] encoded as a STRING type.
17. winreg. The element content is a Windows registry key
encoded as a STRING type.
18. xml. The element content is XML (see Section 5).
19. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-dtype
Optional. STRING. A means by which to extend the dtype
attribute. See Section 5.1.
meaning
Optional. STRING. A free-form description of the element
content.
formatid
Optional. STRING. An identifier referencing the format and
semantics of the element content.
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
(page 18 continued on part 2)
