Subject: Minutes of the IDWG meetings at the 49th IETF

From: "John C. C. White" <[email-masked]>
Date: Thu, 11 Jan 2001 15:15:56 -0500

INTRUSION DETECTION EXCHANGE FORMAT (IDEF) Working Group Meeting
Minutes, 49th IETF

The IDWG met at 0900 on both Thursday and Friday of the 49th IETF
meeting in San Diego CA.

First meeting - 14 December 2000

The first presentation was on the Intrusion Alert Protocol (IAP). It was
presented by Roy Pollock, using slides prepared by Dipankar Gupta. Some
changes have been made to the protocol, partly to align it more closely
with HTTP1.1. The changes include:

1. Added content-type: application/xml

2. The initiator of the TCP connection must now also initiate the TLS
handshake

3. A RESPONSE message may now contain a body

4. A Host: header has been added, to support a virtual hostname.

The following issues were identified:

1. The IDWG's relationship with the work being done by the SYSLOG WG
needs to be determined.

2. Interoperability between implementations has not been tested.

3. A port number has not been requested from IANA.

4. IANA OID's for the desired key extensions are needed.

A new draft of the IAP document was sent to the mailing list, and will
be properly submitted when possible.

Darren New made a presentation on BEEP, the Block Extensible Exchange
Protocol. BEEP (née BXXP) provides a framework for an application
protocol, and is being used by the SYSLOG WG, whose requirements are
very similar to those of the IDWG. The draft BEEP document is currently
in "last call" status. BEEP is asynchronous, bi-directional, and
multi-channel. It uses SASL and TLS to establish a session's security
properties. A profile defines the properties of a channel. Several
interoperable implementations of the previous version of BEEP exist, in
multiple languages including Python, PERL, Java, and Tcl; several of
these will be updated to the current BEEP specification within the next
couple of months. One issue mentioned was that TLS pass-through (a
firewall) is not precisely specified, but this is not thought to be a
problem.

The question of whether we should use BEEP, and if not why not, was
raised. The group's consensus was that we should explore BEEP further,
even though it will delay our moving ahead with IAP. Paul Osterwald,
John White, and the Aerospace group from Harvey Mudd took on the task of
examining BEEP prior to the next IWDG meeting.

Stuart Staniford presented some remaining Data Model and XML
Representation issues.

Issue: It has been proposed that the fields of an IP packet be broken
out, and also that some stream information be included for context. This
is clearly just one example of many technical issues that could be dealt
with by XML extension.

Action: David Curry will study the issue of XML extensibility in
general. The need for packet breakout should be explored on the mailing
list.

Issue: The revised <user> format is in the model, not yet in the XML.

Resolution: Use the revised format in both.

Issue: Addresses can be ambiguous in private address spaces. Propose to
add optional VLAN number and VLAN name attributes to <address>, and
"interface" to <source> and <target>.

Resolution: Make the change to both model and XML.

Issue: <Environment> and <Arguments> add unnecessary nesting and should
be eliminated.

Resolution: OK

Issue: The "unknown" type in <AdditionalData> is meaningless and should
be eliminated.

Resolution: OK

Issue: Time representation in the XML is verbose and somewhat
inconsistent. It is proposed that we use the IEEE-8601 standard, change
<ntpstamp> from an element to an attribute, eliminate <Time> and add
<CreateTime>. There is also a question of whether to represent time
periods (useful for aggregation), rather than just point times.

Resolution: Switch to the proposed format, using only point time for
now.

Issue: "Impact" is a poorly defined collection of sometimes orthogonal
attributes. It is proposed that it be decomposed into severity,
completion (optional), and type (optional).

Action: OK to decompose impact, leave the exact decomposition and number
of levels to be explored on the mailing list.

Issue: It is proposed that summary counts be added to <Source> and
<Target>, for use where the number of instances is excessive. There are
probably other cases where a summary count would be useful also.

Action: Identify those items where this would be useful, discuss it on
the mailing list. Also, look at the combination of network and network
mask to see if it makes sense for aggregated elements.

Yuri Demchenko spoke on the subject of incident reports. These are
human-oriented, long-lived, evidentiary reports of a much broader scope
than those envisioned in the IDWG charter. The question is whether it
makes sense to add this kind of reporting to our charter. They have a
requirements draft for the Incident Object Description and Exchange
Format, and intend to use an XML representation. The next step in their
process is a meeting in January, in Barcelona, between a few European
CSIRT's. It was agreed that there were many commonalities and many
differences between incident reports and IDMEF messages; there was no
consensus regarding any joint effort.

The meeting was then adjourned for the day.

Second meeting - 15 December 2000

Kevin Green spoke regarding the Vulnerability Detection Message. It has
goals similar to those of the IDMEF, so the addition of the VDMEF is
proposed as an alternative to establishing an independent WG. The VDMEF
would require a new class of messages, but its elements would be very
like the IDMEF's. Their goals are to prepare a requirements document, a
model, and a DTD. It was noted that joining forces would appear to
require some modification of the IDWG charter. The group consensus was
that this should be pursued. It was observed that some restructure of
the DTD would be appropriate; what about the data model? Also it was
noted that the absence of a vulnerability is interesting, while the
absence of an intrusion is generally not.

Action: Stuart and Mike talk to Jeff Schiller (IESG Security Area
Director) about this.

Action: Dave Curry look at the IDMEF DTD to see how this might be
handled.

Action: Kevin will start work independently of the IDWG for now.

The general comment was made that we need the ability to add
extensibility, but getting version 1.0 out the door is important. We
will not, for instance, wait for the specification of XML Schemas to be
finished.

Action: Mike Slifcak will work on the Data Model draft, which needs
editorial work.

The remaining presentations were all related to IDWG standard
implementation experience.

Glenn Mansfield presented his work on the SMI representation of IDMEF
messages. He has drafted a document which provides exact mappings
between the XML and SMI representation; it contains 19 MIB tables and 70
Managed Objects. The mapping may be taken up as a possible RFC
(experimental or best current practice, not as a standard). Glenn has
also developed a lightweight MIB for a lightweight IDS, with just one
table and 19 MO's. He also described (and demonstrated) an experimental
implementation of the IDMEF.

Paul Sangree spoke on the issue of analyzer/manager time
synchronization, in an environment of multiple devices and hops. Some
devices may be synchronized, others not, and some simple proposals can
make the problem worse. At least there need to be some caveats in our
documents.

Jeff Flaxer spoke on Data Management of (large volumes of) Alerts. He is
considering environments with thousands of alerts per second, sufficient
to stress a DBMS. In this situation, hierarchy and aggregation of alerts
become essential. Future work by the IDWG in this area is anticipated.

Stuart Staniford described the IDMEF plug-in for Snort. It uses the
freely-available libidmef library, built with libxml. Snort is a
content-based rules engine, which allows plug-ins for more advanced
features (e.g., portscan detection, anomaly detection).

The Harvey Mudd Aerospace group (Tim Buchheim, Ben Feinstein, Greg
Matthews, and Roy Pollock) described their IAP implementation. It is
fairly complete, although it does not yet support TLS session
resumption. Some issues they have identified included the need for a
source header if going through a proxy, the uncertainty as to how the
proxy next hop is defined, and the use of "port" in the CONNECT message.
They are using the openssl library, and noted that it is at best
ill-documented; they are willing to share their hard-earned knowledge of
it.

The meeting was adjourned at about 1130.

Respectfully submitted,
John White
[email-masked]
(781)271-3284

---

From: Stuart Staniford <[email-masked]>
Date: Mon, 15 Jan 2001 16:46:26 -0800

John:

Many thanks for doing the minutes again; another fine, concise job.

> examining BEEP prior to the next IWDG meeting.

All please note: given the late stage of our development of IAP, I really
want to see an actual internet draft that describes IDMEF over BEEP in
detail by the next meeting or I'm going to move to kill it and proceed to
last call on IAP.  If there's really energy to do BEEP, and it's the right
decision, then no doubt a document will be forthcoming.  Otherwise this
issue will just further delay our already frustratingly late delivery of
documents (and I want to get on with my life).

> Action: Stuart and Mike talk to Jeff Schiller (IESG Security Area

I can't remember the details of the discussion on this.  Was the intent
that we talk to Jeff *prior* to the WG submitting our design docs?  Can
someone refresh my memory?

> Action: Kevin will start work independently of the IDWG for now.

I really want to encourage Kevin to do this.

Stuart.

-- 
Stuart Staniford  ---  President  ---  Silicon Defense
[email-masked]  http://www.silicondefense.com/
(707) 445-4355                     (707) 445-4222 (FAX)