2.6.3 Intrusion Detection Exchange Format (idwg)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


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, 46th IETF
Recorded By David Donahoo

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

This was an aggressive agenda with presentations as follows:

The group came to consensus on the Transport implementation and asked Dipankar to prepare an official Internet Draft under the IDEF banner.

The group further decided to have an interim meeting in early February (location to be determine). The purpose of this meeting is to focus on finalizing the data model and continue the SNMP vs XML implementations discussions.

Herve Debar and Dave Donahoo were tasked to lead a team (Felix Wu, Glenn Mansfield, Mark Wood, and Fengmin Gong) to further develop the data model. A main thrust will be to develop an Entity Relationship model to further explain/clarify the existing data model.

Glenn Mansfield and David Curry were tasked to develop a SNMP/XML document which will compare and contrast the two implementations. The IDWG is looking for a document to prompt the discussions on the pros and cons of each system. The intent is to enable the group to come to consensus on which implementation to support.

Session 1, 11 Nov 99, 3:30 PM (Attendance: 60)

Mike Erlinger opened this session by introducing the Agenda and running through an agenda bashing session.


Status: Mike briefed on the status of IDWG . Mark Wood has completed his work on the requirements document. We held the last call on the mailing list and have forwarded it to the IETF as an Informational RFC from this working group.

Since our Interim Meeting in Sept we have numerous documents on the table for discussion. Since we now have more than one implementation proposal we will have to come to some consensus on which way the group decides to go. We will get into this discussion on Friday during the "What's Next" discussion.

Herve Debar presented his data model and class hierarchy. For the full version of the draft look at <http://www.ietf.org/internet-drafts/draft-ietf-idwg-data-model-00.txt>. There was a good deal of valid discussions on his model. While we gained consensus on various portions of the model (i.e. eliminating the distinctions between "multi-host and single-host and making it a list or range of hosts), the greatest point of departure was the tree type representation of the class hierarchy. While the tree structure does a good job of identifying the parent child relationships among data elements it does little into identifying the relationships between data elements.

The group decided to form a sub-group to determine the best way to represent this data. An Entity Relationship Diagram was discussed as a possible solution. The group met informally following the Friday meeting to discuss the next steps and will work together over the next three weeks and publish the results to the list for discussion on or about the 15th of Dec. Group members include: Dave Donahoo, Herve Debar, Glenn Mansfield, Felix Wu, Fengmin Gong and Mark Wood.

Felix Wu then briefed his draft for a Correlation MIB which focuses on requirements 5.2, 7.1, 7.4, and 7.17. The objective of his MIB is to provide a data model to support event abstraction, anomaly detection and extensibility. While this MIB provided some very interesting applications of a possible IDS standard the group looked at it as being a little outside the scope of this working group. It appears to address implementation of IDS and not just the Data Exchange (which is the group focus). There was no consensus or significant comments to this draft. The following are highlights from his briefing points (Full Briefing slides available upon request):

Intrusion Detection System Event Correlation MIB

Objectives: A Data Model to support...

Focus on Information standard, not Analysis or Operation standards. Instead we want to make sure that the information model itself is sufficient and general enough to facilitate different analysis models.

Information versus Analysis. IDWG focuses on Data/Information Model standardization. In the Orlando/IETF meeting, we have decided NOT to worry about the standardization" of the analysis model at least at the first stage.

Proposed to IDWG: to develop the information correlation and aggregation data model document (either as part of the data model document or a separated one.) The first draft will probably be in UML.

Glenn Mansfield then began his presentation of his IDS SNMP MIB. He got about half way through before time expired and then he agreed to finish his presentation on the following morning session. For a full text version of this draft is posted on the mailing list. The following are highlights from his briefing points (Full Briefing slides available upon request):

Intrusion Detection Message MIB

ID Model Requirements


SNMP (v3)

SNMP (v3) Constraints

Session 2, 12 Nov 99, 9:00 AM (Attendance: 50)

Glenn Mansfield concluded his presentation on the IDS SNMP MIB.

Dave Curry Presented his XML Implementation IDEF Message Format. For a full version of this draft look at the mailing list. The following are highlights from his briefing points (Full Briefing slides available upon request):

The stated purpose of the message format is...

But there are so many other possibilities...

XML is the Extensible Markup Language

XML is a meta- language

XML allows a custom language just for intrusion detection

Lots and lots of processing tools already available

Full internationalization and localization support

Easy filtering, aggregation, rearranging, conversion

No license, no license fees, no royalties

A few thoughts on XML -vs- SNMP

XML is just text - it can be sent over "any" TCP protocol

The SNMP protocol (not the data format) has a "bad rep" "You want to send what through my firewall? Get out of my office!"

Following Dave Curry's presentation Stuart lead a discussion over SNMP vs XML. Stuart stated that what we need to do as a group is to discuss and try to resolve if we want to: choose either an XML solution or an SNMP solution, choose to work both, delay the decision, or turn it over to the Security Area Chairs to decide which we should choose.

Comments from the floor:

One thought is to keep both alive and align the efforts.

Speed may become a factor. SNMP is a faster mechanism than XML.

There are analyzers in place already using SNMP MIBs. This would make for an easier transition.

It doesn't make sense to pick both. That would give us two standards-this just doesn't make sense.

At this time IDS products do not have any XML implementations. All do use SNMP traps to capture data.

¬ From a vendor of consoles we are already supporting both and this is not a problem. It makes a lot of sense to support both.
¬ From a developer's view supporting both is easy, but developing a dual standard is not as easy. I support XML over SNMP.

SNMP is more portable. SNMP traps are not the issue-transport is. We could support the SNMP traps and design the transport later.

Speaking as a vendor of IDS, there are many things I need to think about. Network system management tools make very poor IDS's (but customer's use them). If I go to a customer and ask them to open up the SNMP port they'd throw me out. If, on the other hand, they are ready used it they tend to love it.

Speaking from the DoD side, our Security Policy forbids opening SNMP ports.

Efficiency is another issue. XML looks good but what is the cost in overhead bits?

I don't think the data model is strong enough for us to make a decision.

At this point Stuart stopped the discussion to bring the issue to a vote. He asked:

How many people think we need to select one of these to develop into the standard. Show of hand showed consensus the group feels strongly that we need a single standard.

A second vote showed that as a group we do not have enough information to make that decision. Glenn Mansfield and Dave Curry were tasked by the group to develop a document comparing and contrasting XML and SNMP.

End Of Floor Comments.

Dipankar Grupta then presented his transport protocol. For full text draft read document at <http://www.ietf.org/internet-drafts/draft-gupta-idwg-iap-00.txt>. The following are highlights from his briefing points (Full Briefing slides available upon request):

Problem Overview

Transport proposal: intrusion alert protocol (iap)

Intrusion Alert Protocol Highlights

Deployment Considerations

Four phases of IAP


None received.