Network Working Group M. Wood Request for Comments: 4766 Internet Security Systems, Inc. Category: Informational M. Erlinger Harvey Mudd College March 2007
Intrusion Detection Message Exchange Requirements
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements.
Table of Contents
1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................3 2. Overview ........................................................4 2.1. Rationale for IDMEF ........................................4 2.2. Intrusion Detection Terms ..................................4 2.3. Architectural Assumptions ..................................8 2.4. Organization of This Document ..............................9 2.5. Document Impact on IDMEF Designs ..........................10 3. General Requirements ...........................................10 3.1. Use of Existing RFCs ......................................10 3.2. IPv4 and IPv6 .............................................10 4. Message Format Requirements ....................................11 4.1. Internationalization and Localization .....................11 4.2. Message Filtering and Aggregation .........................11
Wood & Erlinger Informational [Page 1]
RFC 4766 IDME Requirements March 2007
5. IDMEF Communication Protocol (IDP) Requirements ................12 5.1. Reliable Message Transmission .............................12 5.2. Interaction with Firewalls ................................12 5.3. Mutual Authentication .....................................13 5.4. Message Confidentiality ...................................13 5.5. Message Integrity .........................................13 5.6. Per-source Authentication .................................14 5.7. Denial of Service .........................................14 5.8. Message Duplication .......................................14 6. Message Content Requirements ...................................15 6.1. Detected Data .............................................15 6.2. Event Identity ............................................15 6.3. Event Background Information ..............................16 6.4. Additional Data ...........................................16 6.5. Event Source and Target Identity ..........................17 6.6. Device Address Types ......................................17 6.7. Event Impact ..............................................17 6.8. Automatic Response ........................................18 6.9. Analyzer Location .........................................18 6.10. Analyzer Identity ........................................19 6.11. Degree of Confidence .....................................19 6.12. Alert Identification .....................................19 6.13. Alert Creation Date and Time .............................20 6.14. Time Synchronization .....................................21 6.15. Time Format ..............................................21 6.16. Time Granularity and Accuracy ............................21 6.17. Message Extensions .......................................22 6.18. Message Semantics ........................................22 6.19. Message Extensibility ....................................22 7. Security Considerations ........................................23 8. References .....................................................23 8.1. Normative References ......................................23 8.2. Informative References ....................................23 9. Acknowledgements ...............................................23
This document defines requirements for the Intrusion Detection Message Exchange Format (IDMEF) [5], a product of the Intrusion Detection Exchange Format Working Group (IDWG). IDMEF was planned to be a standard format that automated Intrusion Detection Systems (IDSs) [4] could use for reporting what they have deemed to be suspicious or of interest. This document also specifies requirements for a communication protocol for communicating IDMEF. As chartered, IDWG has the responsibility to first evaluate existing communication protocols before choosing to specify a new one. Thus the requirements in this document can be used to evaluate existing communication protocols. If IDWG determines that a new communication protocol is necessary, the requirements in this document can be used to evaluate proposed solutions.
This is not an IETF standards-track document [2], and thus the key words MUST, MUST NOT, SHOULD, and MAY are NOT as in BCP 14, RFC 2119 [1], but rather:
o MUST: This word, or the terms REQUIRED or SHALL, means that the described behavior or characteristic is an absolute requirement for a proposed IDWG specification.
o MUST NOT: This phrase, or the phrase SHALL NOT, means that the described behavior or characteristic is an absolute prohibition of a proposed IDWG specification.
o SHOULD: This word, or the adjective RECOMMENDED, means that there may exist valid reasons in particular circumstances for a proposed IDWG specification to ignore described behavior or characteristics.
o MAY: This word, or the adjective OPTIONAL, means that the described behavior or characteristic is truly optional for a proposed IDWG specification. One proposed specification may choose to include the described behavior or characteristic, whereas another proposed specification may omit the same behavior or characteristic.
The reasons such a format should be useful are as follows:
1. A number of commercial and free Intrusion Detection Systems are available and more are becoming available all the time. Some products are aimed at detecting intrusions on the network, others are aimed at host operating systems, while still others are aimed at applications. Even within a given category, the products have very different strengths and weaknesses. Hence it is likely that users will deploy more than a single product, and users will want to observe the output of these products from one or more manager(s). A standard format for reporting will simplify this task greatly.
2. Intrusions frequently involve multiple organizations as victims, or multiple sites within the same organization. Typically, those sites will use different IDSs. It would be very helpful to correlate such distributed intrusions across multiple sites and administrative domains. Having reports from all sites in a common format would facilitate this task.
3. The existence of a common format should allow components from different IDSs to be integrated more readily. Thus, Intrusion Detection (ID) research should migrate into commercial products more easily.
4. In addition to enabling communication from an ID analyzer to an ID manager, the IDMEF notification system may also enable communication between a variety of IDS components. However, for the remainder of this document, we refer to the communication as going from an analyzer to a manager.
All of these reasons suggest that a common format for reporting anything deemed suspicious should help the IDS market to grow and innovate more successfully, and should result in IDS users obtaining better results from deployment of ID systems.
In order to make the rest of the requirements clearer, we define some terms about typical IDSs. These terms are presented in alphabetical order. The diagram at the end of this section illustrates the relationships of some of the terms defined herein.
Elements of the data source or occurrences within the data source that are identified by the sensor or analyzer as being of interest to the operator. Examples of this include (but are not limited to) network session showing unexpected telnet activity, operating system log file entries showing a user attempting to access files to which he is not authorized to have access, application log files showing persistent login failures, etc.
Activity can range from extremely serious occurrences (such as an unequivocally malicious attack) to less serious occurrences (such as unusual user activity that's worth a further look) to neutral activity (such as user login).
The human with overall responsibility for setting the security policy of the organization, and, thus, for decisions about deploying and configuring the IDS. This may or may not be the same person as the operator of the IDS. In some organizations, the administrator is associated with the network or systems administration groups. In other organizations, it's an independent position.
A message from an analyzer to a manager that an event of interest has been detected. An alert typically contains information about the unusual activity that was detected, as well as the specifics of the occurrence.
The ID component or process that analyzes the data collected by the sensor for signs of unauthorized or undesired activity or for events that might be of interest to the security administrator. In many existing IDSs, the sensor and the analyzer are part of the same component. In this document, the term analyzer is used generically to refer to the sender of the IDMEF message.
The raw information that an intrusion detection system uses to detect unauthorized or undesired activity. Common data sources include (but are not limited to) raw network packets, operating system audit logs, application audit logs, and system-generated checksum data.
The ID component or process from which the operator manages the various components of the ID system. Management functions typically include (but are not limited to) sensor configuration, analyzer configuration, event notification management, data consolidation, and reporting.
The method by which the IDS manager makes the operator aware of the alert occurrence and thus the event. In many IDSs, this is done via the display of a colored icon on the IDS manager screen, the transmission of an e-mail or pager message, or the transmission of a Simple Network Management Protocol (SNMP) trap, although other notification techniques are also used.
The human that is the primary user of the IDS manager. The operator often monitors the output of the ID system and initiates or recommends further action.
The actions taken in response to an event. Responses may be undertaken automatically by some entity in the IDS architecture or may be initiated by a human. Sending a notification to the operator is a very common response. Other responses include (but are not limited to) logging the activity; recording the raw data (from the data source) that characterized the event; terminating a network, user, or application session; or altering network or system access controls.
The ID component that collects data from the data source. The frequency of data collection will vary across IDS offerings. The sensor is set up to forward events to the analyzer.
A rule used by the analyzer to identify interesting activity to the security administrator. Signatures represent one of the mechanisms (though not necessarily the only mechanism) by which IDSs detect intrusions.
The predefined, formally documented statement that defines what activities are allowed to take place on an organization's network or on particular hosts to support the organization's requirements. This includes, but is not limited to, which hosts are to be denied external network access.
The diagram above illustrates the terms above and their relationships. Not every IDS will have all of these separate components exactly as shown. Some IDSs will combine these components into a single module; some will have multiple instances of these modules.
In this document, as defined in the terms above, we assume that an analyzer determines somehow that a suspicious event has been seen by a sensor, and sends an alert to a manager. The format of that alert and the method of communicating it are what IDMEF proposes to standardize.
For the purposes of this document, we assume that the analyzer and manager are separate components and that they are communicating pairwise across a TCP/IP network. No other form of communication between these entities is contemplated in this document, and no other use of IDMEF alerts is considered. We refer to the communication
Wood & Erlinger Informational [Page 8]
RFC 4766 IDME Requirements March 2007
protocol that communicates IDMEF as the IDMEF Communication Protocol (IDP).
The Trust Model is not specified as a requirement, but is rather left to the choice of the IDMEF Communication Protocol, i.e., a design decision. What is specified are individual security-related requirements; see Section 5.
We try to make no further architectural assumptions than those just stated. For example, the following points should not matter:
o Whether the sensor and the analyzer are integrated or separate.
o Whether the analyzer and manager are isolated or are embedded in some large hierarchy or distributed mesh of components.
o Whether the manager actually notifies a human, takes action automatically, or just analyzes incoming alerts and correlates them.
o Whether a component might act as an analyzer with respect to one component, while also acting as a manager with respect to another.
Besides this requirements document, the IDWG should produce two other documents. The first should describe a data format or language for exchanging information about suspicious events. In this, the requirements document, we refer to that document as the "data-format specification". The second document to be produced should identify existing IETF protocols that are best used for conveying the data so formatted, and explain how to package this data in those existing formats or the document should specify a new protocol. We refer to this as the IDP (IDMEF Communication Protocol).
Accordingly, the requirements here are partitioned into four sections:
o The first of these contains general requirements that apply to all aspects of the IDMEF specification (Section 3).
o The second section describes requirements on the formatting of IDMEF messages (Section 4).
o The third section outlines requirements on the communications mechanism, IDP, used to move IDMEF messages from the analyzer to the manager (Section 5).
Wood & Erlinger Informational [Page 9]
RFC 4766 IDME Requirements March 2007
o The final section contains requirements on the content and semantics of the IDMEF messages (Section 6).
For each requirement, we attempt to state the requirement as clearly as possible without imposing an idea of what a design solution should be. Then we give the rationale for why this requirement is important, and state whether this should be an essential feature of the specification or is beneficial but could be lacking if it is difficult to fulfill. Finally, where it seems necessary, we give an illustrative scenario. In some cases, we include possible design solutions in the scenario. These are purely illustrative.
It is expected that proposed IDMEF designs will, at a minimum, satisfy the requirements expressed in this document. However, this document will be used only as one of many criteria in the evaluation of various IDMEF designs and proposed communication protocols. It is recognized that the working group may use additional metrics to evaluate competing IDMEF designs and/or communication protocols.
The IETF has already completed a great deal of research and work into the areas of networks and security. In the interest of time, it is smart to use already defined and accepted standards.
Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6 environments are expected to exist within the time frame of IDMEF implementations, the IDMEF specification MUST support IPv6 and IPv4 environments.
The IDMEF message format is intended to be independent of the IDMEF Communication Protocol (IDP). It should be possible to use a completely different transport mechanism without changing the IDMEF format. The goal behind this requirement is to ensure a clean separation between semantics and communication mechanisms. Obviously, the IDMEF Communication Protocol is recommended.
Since network security and intrusion detection are areas that cross geographic, political, and cultural boundaries, the IDMEF messages MUST be formatted such that they can be presented to an operator in a local language and adhering to local presentation customs.
An IDMEF specification might include numeric event identifiers. An IDMEF implementation might translate these numeric event identifiers into local language descriptions. In cases where the messages contain strings, the information might be represented using the ISO/IEC IS 10646-1 character set and encoded using the UTF-8 transformation format to facilitate internationalization [3].
Since it is anticipated that some managers might want to perform filtering and/or data aggregation functions on IDMEF messages, the IDMEF messages MUST be structured to facilitate these operations.
An IDMEF specification proposal might recommend fixed-format messages with strong numerical semantics. This would lend itself to high- performance filtering and aggregation by the receiving station.
Wood & Erlinger Informational [Page 11]
RFC 4766 IDME Requirements March 2007
5. IDMEF Communication Protocol (IDP) Requirements
IDS managers often rely on receipt of data from IDS analyzers to do their jobs effectively. Since IDS managers will rely on IDMEF messages for this purpose, it is important that IDP deliver IDMEF messages reliably.
Since it is expected that firewalls will often be deployed between IDMEF capable analyzers and their corresponding managers, the ability to relay messages via proxy or other suitable mechanism across firewalls is necessary. Setting up this communication MUST NOT require changes to the intervening firewall(s) that weaken the security of the protected network(s). Nor SHOULD this be achieved by mixing IDMEF messages with other kinds of traffic (e.g., by overloading the HTTP POST method) since that would make it difficult for an organization to apply separate policies to IDMEF traffic and other kinds of traffic.
One possible design is the use of TCP to convey IDMEF messages. The general goal in this case is to avoid opening dangerous inbound "holes" in the firewall. When the manager is inside the firewall and the analyzers are outside the firewall, this is often achieved by having the manager initiate an outbound connection to each analyzer. However, it is also possible to place the manager outside the firewall and the analyzers on the inside; this can occur when a third-party vendor (such as an ISP) is providing monitoring services to a user. In this case, the outbound connections would be initiated by each analyzer to the manager. A mechanism that permits either the manager or the analyzer to initiate connections would provide maximum flexibility in manager and analyzer deployment.
The IDP MUST support mutual authentication of the analyzer and the manager to each other. Application-layer authentication is required irrespective of the underlying transport layer.
Since the alert messages are used by a manager to direct responses or further investigation related to the security of an enterprise network, it is important that the receiver have confidence in the identity of the sender and that the sender have confidence in the identity of the receiver. This is peer-to-peer authentication of each party to the other. It MUST NOT be limited to authentication of the underlying communications mechanism, for example, because of the risk that this authentication process might be subverted or misconfigured.
The IDP MUST support confidentiality of the message content during message exchange. The selected design MUST be capable of supporting a variety of encryption algorithms and MUST be adaptable to a wide variety of environments.
IDMEF messages potentially contain extremely sensitive information (such as passwords) and would be of great interest to an intruder. Since it is likely some of these messages will be transmitted across uncontrolled network segments, it is important that the content be shielded. Furthermore, since the legal environment for encryption technologies is extremely varied and changes often, it is important that the design selected be capable of supporting a number of different encryption options and be adaptable by the user to a variety of environments.
The IDP MUST ensure the integrity of the message content. The selected design MUST be capable of supporting a variety of integrity mechanisms and MUST be adaptable to a wide variety of environments.
IDMEF messages are used by the manager to direct action related to the security of the protected enterprise network. It is vital for the manager to be certain that the content of the message has not been changed after transmission.
The IDP MUST support separate authentication keys for each sender. If symmetric algorithms are used, these keys would need to be known to the manager it is communicating with.
Given that sensitive security information is being exchanged via the IDMEF, it is important that the manager can authenticate each analyzer sending alerts.
A common way to defeat secure communications systems is through resource exhaustion. While this does not corrupt valid messages, it can prevent any communication at all. It is desirable that IDP resist such denial-of-service attacks.
An attacker penetrates a network being defended by an IDS. Although the attacker is not certain that an IDS is present, he is certain that application-level encrypted traffic (i.e., IDMEF traffic) is being exchanged between components on the network being attacked. He decides to mask his presence and disrupt the encrypted communications by initiating one or more flood events. If the IDP can resist such an attack, the probability that the attacker will be stopped increases.
A common way to impair the performance of secure communications mechanisms is to duplicate the messages being sent, even though the attacker might not understand them, in an attempt to confuse the receiver. It is desirable that the IDP resist such message duplication.
An attacker penetrates a network being defended by an IDS. The attacker suspects that an IDS is present and quickly identifies the encrypted traffic flowing between system components as being a possible threat. Even though she cannot read this traffic, she copies the messages and directs multiple copies at the receiver in an attempt to confuse it. If the IDP resists such message duplication, the probability that the attacker will be stopped increases.
There are many different types of IDSs, such as those based on signatures, anomalies, correlation, network monitoring, host monitoring, or application monitoring. The IDMEF design MUST strive to accommodate these diverse approaches by concentrating on conveying *what* an IDS has detected, rather than *how* it detected it.
There are many types of IDSs that analyze a variety of data sources. Some are profile based and operate on log files, attack signatures, etc. Others are anomaly based and define normal behavior and detect deviations from the established baseline. Each of these IDSs reports different data that, in part, depends on their intrusion detection methodology. All MUST be supported by this standard.
The content of IDMEF messages MUST contain the identified name of the event (event identity) if it is known. This name MUST be drawn from a standardized list of events (if available) or will be an implementation-specific name if the event identity has not yet been standardized. It is not known how this standardized list will be defined or updated. Requirements on the creation of this list are beyond our efforts. Other groups within the security arena are investigating the creation of such lists.
Given that this document presents requirements on standardizing ID message formats so that an ID manager is able to receive alerts from analyzers from multiple implementations, it is important that the manager understand the semantics of the reported events. There is, therefore, a need to identify known events and store information concerning their methods and possible fixes to these events. Some events are well known and this recognition can help the operator.
Intruder launches an attack that is detected by two different analyzers from two distinct implementations. Both report the same event identity to the ID manager, even though the algorithms used to detect the attack by each analyzer might have been different.
The IDMEF message design MUST include information, which the sender should provide, that allows a receiver to locate background information on the kind of event that is being reported in the alert.
Attacker performs a well-known attack. A reference to a URL to background information on the attack is included in the IDMEF message. The operator uses this information to initiate repairs on the vulnerable system.
The IDMEF message MUST be able to reference additional detailed data related to this specific underlying event. It is OPTIONAL for implementations to use this field. No requirements are placed on the format or content of this field. It is expected that this will be defined and described by the implementor.
Operators might want more information on specifics of an event. This field, if filled in by the analyzer, MAY point to additional or more detailed information about the event.
The IDMEF message MUST contain the identity of the source of the event and target component identifier if it is known. In the case of a network-based event, this will be the source and destination IP address of the session used to launch the event. Note that the identity of source and target will vary for other types of events, such as those launched/detected at the operating system or application level.
A device is a uniquely addressable element on the network (i.e., not limited to computers or networks or a specific level of the network protocol hierarchy). In addition, devices involved in an intrusion event might use addresses that are not IP-centric.
The IDS recognizes an intrusion on a particular device and includes both the IP address and the MAC address of the device in the IDMEF message. In another situation, the IDS recognizes an intrusion on a device that has only a MAC address and includes only that address in the IDMEF message. Another situation involves analyzers in an Asynchronous Transfer Mode (ATM) switch fabric that use E.164 address formats.
The IDMEF message MUST contain an indication of the possible impact of this event on the target. The IDMEF design document MUST define the scope of this value.
Information concerning the possible impact of the event on the target system provides an indication of what the intruder is attempting to do and is critical data for the operator to perform damage assessment. Not all systems will be able to determine this, but it is important data to transmit for those systems that can. This requirement places no requirements on the list itself (e.g., properties of the list, maintenance, etc.), rather the requirement only specifies that the IDMEF must contain a field for specifying the impact and that the IDMEF must define the scope of such values.
It is very important for the operator to know if there was an automated response and what that response was. This will help determine what further action to take, if any.
One interesting scenario involves the progress of an intrusion event throughout a network. If the same event is detected and reported by multiple analyzers, the identity of the analyzer (in the case of a network-based analyzer) might provide some indication of the network location of the target systems and might warrant a specific type of response. This might be implemented as an IP address.
Users might run multiple IDSs to protect their enterprise. This data will help the systems administrator determine which implementor and analyzer detected the event.
Analyzer X from implementor Y detects a potential intrusion. A message is sent reporting that it found a potential break-in with X and Y specified. The operator is therefore able to include the known capabilities or weaknesses of analyzer X in his decision regarding further action.
The IDMEF message MUST be able to state the degree of confidence of the report. The completion of this field by an analyzer is OPTIONAL, as this data might not be available at all analyzers.
Many IDSs contain thresholds to determine whether or not to generate an alert. This might influence the degree of confidence one has in the report or perhaps would indicate the likelihood of the report being a false alarm.
The alarm threshold monitor is set at a low level to indicate that an organization wants reports on any suspicious activity, regardless of the probability of a real attack. The degree-of-confidence measure is used to indicate whether this is a low-probability or high- probability event.
An IDMEF message might be sent by multiple geographically-distributed analyzers at different times. A unique identifier will allow an IDMEF message to be identified efficiently for data reduction and correlation purposes.
The unique identifier might consist of a unique originator identifier (e.g., IPv4 or IPv6 address) concatenated with a unique sequence number generated by the originator. In a typical IDS deployment, a low-level event analyzer will log the raw sensor information into, e.g., a database while analyzing and reporting results to higher levels. In this case, the unique raw message identifier can be included in the result message as supporting evidence. Higher-level analyzers can later use this identifier to retrieve the raw message from the database if necessary.
The IDMEF MUST support reporting alert creation date and time in each event, where the creation date and time refer to the date and time that the analyzer decided to create an alert. The IDMEF MAY support additional dates and times, such as the date and time the event reference by the alert began.
Time is important from both a reporting and correlation point of view. Event onset time might differ from the alert creation time because it might take some time for the sensor to accumulate information about a monitored activity before generating the event, and additional time for the analyzer to receive the event and create an alert. The event onset time is therefore more representative of the actual time that the reported activity began than is the alert creation time.
If an event is reported in the quiet hours of the night, the operator might assign a higher priority to it than she would to the same event reported in the busy hours of the day. Furthermore, an event (such as a lengthy port scan) may take place over a long period of time and it would be useful for the analyzer to report the time of the alert as well as the time the event began.
Time SHALL be reported such that events from multiple analyzers in different time zones can be received by the same manager and that the local time at the analyzer can be inferred.
A distributed ID system has analyzers located in multiple time zones, all reporting to a single manager. An intrusion occurs that spans multiple time zones as well as multiple analyzers. The central manager requires sufficient information to normalize these alerts and determine that all were reported near the same "time" and that they are part of the same attack.
The format for reporting the date MUST be compliant with all current standards for Year 2000 rollover, and it MUST have sufficient capability to continue reporting date values past the year 2038.
It is desirable that the IDMEF have a long lifetime and that implementations be suitable for use in a variety of environments. Therefore, characteristics that limit the lifespan of the IDMEF (such as 2038 date representation limitation) MUST be avoided.
The IDMEF cannot assume a certain clock granularity on sensing elements, and so cannot impose any requirements on the granularity of the event timestamps. Nor can the IDMEF assume that the clocks being used to timestamp the events have a specified accuracy.
The IDMEF message MUST support an extension mechanism used by implementors to define implementation-specific data. The use of this mechanism by the implementor is OPTIONAL. This data contains implementation-specific information determined by each implementor. The implementor MUST indicate how to interpret these extensions, although there are no specific requirements placed on how implementors describe their implementation-specific extensions. The lack or presence of such message extensions for implementation- specific data MUST NOT break interoperation.
Implementors might wish to supply extra data such as the version number of their product or other data that they believe provides value added due to the specific nature of their product. Implementors may publish a document or web site describing their extensions; they might also use an in-band extension mechanism that is self-describing. Such extensions are not a license to break the interoperation of IDMEF messages.
Good semantics are key to understanding what the message is trying to convey so there are no errors. Operators will decide what action to take based on these messages, so it is important that they can interpret them correctly.
Without this requirement, the operator receives an IDMEF message and interprets it one way. The implementor who constructed the message intended it to have a different meaning from the operator's interpretation. The resulting corrective action is therefore incorrect.
The IDMEF itself MUST be extensible. As new ID technologies emerge and as new information about events becomes available, the IDMEF message format MUST be able to include this new information. Such message extensibility must occur in such a manner that interoperability is NOT impacted.
As intrusion detection technology continues to evolve, it is likely that additional information relating to detected events will become available. The IDMEF message format MUST be able to be extended by a specific implementation to encompass this new information. Such extensions are not a license to break the interoperation of IDMEF messages.
The following individuals contributed substantially to this document and should be recognized for their efforts. This document would not exist without their help:
Mark Crosbie, Hewlett-Packard
David Curry, IBM Emergency Response Services
David Donahoo, Air Force Information Warfare Center
Mike Erlinger, Harvey Mudd College
Wood & Erlinger Informational [Page 23]
RFC 4766 IDME Requirements March 2007
Fengmin Gong, Microcomputing Center of North Carolina
Dipankar Gupta, Hewlett-Packard
Glenn Mansfield, Cyber Solutions, Inc.
Jed Pickel, CERT Coordination Center
Stuart Staniford-Chen, Silicon Defense
Maureen Stillman, Nokia IP Telephony
Authors' Addresses
Mark Wood Internet Security Systems, Inc. 6303 Barfield Road Atlanta, GA 30328 US
EMail: mark1@iss.net
Michael A. Erlinger Harvey Mudd College Computer Science Dept 301 East 12th Street Claremont, CA 91711 US
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.