2.6.5 Intrusion Detection Exchange Format (idwg)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00


Michael Erlinger <mike@cs.hmc.edu>
Stuart Staniford-Chen <stanifor@cs.ucdavis.edu>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:idwg-public@zurich.ibm.com
To Subscribe: idwg-public-request@zurich.ibm.com
Archive: http://www.semper.org/idwg-public/

Description of Working Group:

Security incidents are becoming more common and more serious, and intrusion detection systems are becoming of increasing commercial importance. Numerous intrusion detection systems are important in the market and different sites will select different vendors. Since incidents are often distributed over multiple sites, it is likely that different aspects of a single incident will be visible to different systems. Thus it would be advantageous for diverse intrusion detection systems to be able to share data on attacks in progress.

The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them. The Intrusion Detection Working Group will coordinate its efforts with other IETF Working Groups.

The outputs of this working group will be:

1. A requirements document, which describes the high-level functional requirements for communication between intrusion detection systems and requirements for communication between intrusion detection systems and with management systems, including the rationale for those requirements. Scenarios will be used to illustrate the requirements.

2. A common intrusion language specification, which describes data formats that satisfy the requirements.

3. A framework document, which identifies existing protocols best used for communication between intrusion detection systems, and describes how the devised data formats relate to them.

Goals and Milestones:

Apr 99


Submit Requirements document as an Internet-Draft

Aug 99


Submit Framework and Language documents as Internet-Drafts

Aug 99


Submit Requirements document to IESG for consideration as an RFC.

Dec 99


Submit Framework and Language documents to IESG for consideration as RFCs.


No Request For Comments

Current Meeting Report

Working Group Meeting Minutes, 47th IETF

The IDWG working group met at 3:30 pm on Thursday and at 9:00 am on Friday at the 47th IETF meeting in Adelaide, Australia. Both co-chairs (Stuart Staniford-Chen and Mike Erlinger) were present, and Dave Donahoo took the minutes. Over the two sessions there were about 65 attendees.


Mike presented a brief introduction and history of the working group progress to date. He then initiated a discussion into the agenda. He noted that although some of the documents to be discussed did not make it into IETF before the cutoff we did get them out on the mailing list and would continue the discussions here.


- Agenda Bashing 5 Min
- Requirements Document Discussion 5 Min
- Data Model Discussion 30 Min
- XML/SNMP Discussion 30 Min
- Intrusion Alert Protocol Discussion 5 Min
- DTD Definition Discussion 30 Min
- Other Issues 10 Min

Requirements Document Discussion:

Requirements document has gone through editing by IETF and we have received a few comments on the document. Mark Wood has agreed to work on these comments in the next few weeks. After his rewrite we will send it back out into the mailing list for review and then back into the IETF for approval as an informational RFC

IDWG Data Model:

Stuart presented a short brief into the nature and make up of the data model including a description of classes and attributes. The discussion also included a discussion of relationships. "Kind of" and "part of" used in the UML model.

Stuart continued his discussion by describing the overall data structure and ended by giving an example of an alert using this model.

Issue: Data model does not specify how an analyzer reports an alert. It leaves that to the vendor to determine

Discussion: Thought is that we don't want to tell the analyzer how to report an alert.

One problem we get into is that whenever we allow vendors to represent something two ways we insert ambiguity into the produce. Lesson learned by work with CIDF is that this creates a programming nightmare.

Problem is under the current model if two sensors agree there is a port scan there are two ways to say it in an alert. One is as a single alert i.e. one attacker scanning many ports, and another is as multiple alerts where the analyzer reports an alert for each port scanned.

It is unclear how to specify this in a model.

Maybe this could be expressed and a "Should". When an analyzer sees an alert as a port scan is "should" cram all the information into a single alert.

Resolution: The concept of if a sensor/analyzer determines that an attack is a single attack (i.e. a port scan) it "SHOULD" produce one alert with all the data in a single alert.

Issue: We need to do more work on Confidence, Impact and others

Discussion: This is something we need to address
Resolution: None at this time.

Issue: The introduction is currently too long.

Discussion: Editorial in nature.

Resolution: None at this time.

Issue: Confidence. 0=100 scale is not well defined.

Discussion: Should be the analyzers best estimate of the probability of the attack. Scale should be 0 to 1. Lesson learned from RMON. Confidence is a complex item-how do we come to agreement. Given vendor differences, can we come up with a single measure to suite all applications. Vendors give different confidences on different alerts.

Resolution: Still an open issue. Needs further discussion on the mailing list.

Issue: Impact there is concern as to the enumeration-ordering of attacks under Impact.

Discussion: Impact seems to deal with both the type of event and severity of event. Might be able to set this up as a scale with "Unknown" on one end and "Admin Access" on the other. We cannot identify all events.

Resolution: Editorial issue between XML and Data Model. Scales need to be consistent between the DTD and Data model. This item needs to be discussed further on the mailing list.

XML/SNMP Discussion:

Glen gave a briefing of the XML/DTD document. He included a quick overview of the data model and the concepts behind generating and delivering an alert.

Glen presented the same briefing he presented at the Interim meeting. See the mailing list notes on that meeting for details.

At the Interim meeting it was decided to use XML over IAP. It was then sent to the mailing list for comments.

Things missing from documents:

- Look at COPS from the policy group.
- Separation of SMI from SNMP
- Selection criteria for XML
- Clarify Tell-only --vs-- tell and ask
- Section 1 not needed
- Clarity on MIB structures
- Section 2 Data Report
- Citing Printf
- Code sizes too vague
- MIB Browsers interfacing with SMI
- SMI-MIBs and bulk data
- Extensible
- SNMP-PDUs over IAP??
- Sensors -vs-Analzers-terminology

Implementation effort Impact of changes to the format

Concern is more that if we can't write a document to support and document our group decisions it endangers the group work.

Stuart put it to the group: Is there anyone in the room who strongly support SMI over XML--No one spoke up.

Given this, we need to focus on writing a document that states that XML is the group choice. Not that it is any better but it solves and accomplishes all our goals and objectives.

There are 2 things we need to do. Juegens comments need to be integrated into the document.

Another is to relook the requirements document to see if naming is a requirement. When we discussed it before we decided it was not important.

At 1745 we called it quits for the night and will pick-up tomorrow morning with discussion of the XML DTD.

Intrusion Alert Protocol Discussion:

Issue: Rational need to be added.

Discussion: This was to be done following the Interim meeting but it fell through the crack.

Resolution: Mike will take the lead on tracking this and follow up on getting it done.

Issue: Relationship to SYSLOG needs to be examined.

Discussion: SYSLOG BOF was held this week. We need to look at what we are doing and see if it can support what SYSLOG is doing.

Resolution: Open


IDEF Working Group (day 2 discussions)
31 March 2000
(Attendance 35)

DTD Definition Discussion:

Stuart presented a briefing on the DTD Draft written by Dave Curry. Only a handful of people have actually read the DTD document. The best way to start the discussions would be to put up a few examples and comment on them.

Stuart went over the teardrop attack example and explained the fields line by line.

Issue: Question Category="DNS" seems to be an attribute of node. Shouldn't it be an attribute of Name.


Resolution: Open

Issue: Dave added Query/Response messages.

Discussion: This gets in timing problems-i.e. how long do you keep messages within a sensor analyzer. We'd have to specify timing issues in the spec. Do we want to go down this road or not?

Resolution: We need to do away with these messages.

Issue: Managing distributed ID?????

Discussion: Target IDs etc. may prove a big hurdle. While attractive I'm not sure we have done the pre-work to support,this. A good thing about XML is that we may later add this ability if needed.

Resolution: We will not attempt to manage distributed Ids.

Issue: XML Digital Signatures????

Discussion: Is this something we want to support? Won't requiring signatures open the system up for a performance issue. If the issue is ensuring the message is authentic-that can be accomplished in the transport layer.

Resolution: We will put it in that we MAY support XML Digital signatures. It is out of scope of this document.

Issue: This idea of IDMEF-Message tag which is currently the top level of the XML model. Do we need it?

Discussion: There are currently 4 types of messages under this: Alert, Query, Response, Heartbeat. We have already done away with Query and response, Heartbeat has been debated on the mailing list as a function of the protocol.

Resolution: Mild feeling to keep this as a means to provide flexibility.

Next example is from a Host based IDS. Load module forking shell.

Issue: If we ant to keep this concept of heartbeat we need to clarify the issue

Discussion: It seems to be a good thing. It is also felt that this should be a feature of the IAP. IAP can do this if it is a persistent connection. If not it may need to be within the XML. All we define is if the sensor chooses to send a heartbeat-this is the format. There are advantages of have this in the application-knowing the machine is alive.

Resolution: Seems people are in agreement with this as long as we are not dedicating the specifics of the heartbeat. We need to simply state if the sensor chooses to send a heartbeat this is the format of the message. IT will be optional.

Issue: Why use time offset? Why not say time zone?

Discussion: This may be a standard representation of time.

Resolution: Dave needs to ensure this is a standard representation of time and if not-he needs to rewrite it to comply with standards.

Other Issues:

No other issues here. Your support is needed through the mailing list. No interim meetings are currently scheduled. Our next meeting will be in Pittsburgh at the 48th IETF (end of July 00)


None received.