[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 4767

Network Working Group                                     B.S. Feinstein
Internet-Draft                                             G.A. Matthews
Expires: August 21, 2001                             Harvey Mudd College
                                                       February 20, 2001


            The Intrusion Detection Exchange Protocol (IDXP)
                      draft-ietf-idwg-beep-idxp-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 21, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   This memo describes the Intrusion Detection Exchange Protocol
   (IDXP), an application-level protocol for exchanging data between
   intrusion detection entities. Although it is intended that Intrusion
   Detection Message Exchange Format (IDMEF)[2] messages be exchanged,
   the exchange of structured, unstructured, and binary data is
   supported. The protocol supports mutual-authentication, integrity,
   and privacy over a connection-oriented protocol.







Feinstein & Matthews    Expires August 21, 2001                 [Page 1]

Internet-Draft                  The IDXP                   February 2001


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Purpose  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2   Profiles . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.3   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    The Model  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1   Connection Setup . . . . . . . . . . . . . . . . . . . . . .  4
   2.2   Data Transfer  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.3   Trust Model  . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.    The IDXP Profile . . . . . . . . . . . . . . . . . . . . . .  8
   3.1   IDXP Profile Overview  . . . . . . . . . . . . . . . . . . .  8
   3.2   IDXP Profile Identification and Initialization . . . . . . .  8
   3.3   IDXP Profile Message Syntax  . . . . . . . . . . . . . . . .  8
   3.4   IDXP Profile Semantics . . . . . . . . . . . . . . . . . . .  8
   3.4.1 The IDXP-GREETING Element  . . . . . . . . . . . . . . . . .  9
   3.4.2 The IDMEF-MESSAGE Element  . . . . . . . . . . . . . . . . . 11
   4.    Registration: The IDXP Profile . . . . . . . . . . . . . . . 12
   5.    The IDXP DTD . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.    Reply Codes  . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
   7.1   Use of the TUNNEL Profile  . . . . . . . . . . . . . . . . . 16
   7.2   Use of Underlying Security Profiles  . . . . . . . . . . . . 16
         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
























Feinstein & Matthews    Expires August 21, 2001                 [Page 2]

Internet-Draft                  The IDXP                   February 2001


1. Introduction

   IDXP is specified, in part, as a Blocks Extensible Exchange Protocol
   (BEEP)[7] "profile". BEEP is a generic application protocol
   framework for connection-oriented, asynchronous interactions.
   Features such as authentication and privacy are provided through the
   use of other BEEP profiles. Accordingly, many aspects of IDXP (e.g.,
   privacy) are provided within the BEEP framework.

1.1 Purpose

   IDXP provides for the exchange of structured (e.g., IDMEF[2]
   messages), unstructured data, and binary data between intrusion
   detection (ID) elements. Due to the security-sensitive nature of
   data sent between ID elements it is unacceptable to perform an
   exchange without guaranteeing that certain security measures are in
   place.

   IDXP is primarily intended for the exchange of data created by ID
   sensors and analyzers. It has also been designed to exchange
   configuration information among ID elements, whether reporting about
   a configuration or effecting a change in the configuration of some
   element.

1.2 Profiles

   There are three BEEP profiles discussed, the first of which we
   define in this memo:

      The IDXP Profile

      The TUNNEL Profile[6]

      The TLS Profile (see Section 3.1 of [7])

1.3 Terminology

   Throughout this memo, the terms "analyzer" and "manager" are used in
   the context of the Intrusion Detection Message Exchange
   Requirements[8]. In particular, Section 3.2 of [8] defines the
   meaning of a collection of intrusion detection terms.

   The terms "peer", "initiator", "listener", "client", and "server"
   are used in the context of BEEP[7]. In particular, Section 2.1 of
   the BEEP framework memo discusses the roles that a BEEP peer may
   perform.

   Note that the terms "endpoint" and "proxy" are specific to IDXP, and
   do not exist in the context of BEEP.


Feinstein & Matthews    Expires August 21, 2001                 [Page 3]

Internet-Draft                  The IDXP                   February 2001


2. The Model

2.1 Connection Setup

   Intrusion detection entities using IDXP to transfer data are termed
   IDXP endpoints. Endpoints can exist only in pairs, and these pairs
   communicate over a single BEEP session with one or more BEEP
   channels opened for transferring data. Endpoints are either managers
   or analyzers, as defined in Section 3.2 of [8].

   The relationship between analyzers and managers is potentially
   many-to-many. I.e., an analyzer might communicate with many
   managers; similarly, a manager might communicate with many
   analyzers. Likewise, the relationship between different managers is
   potentially many-to-many, so that a manager can receive the alerts
   sent by a large number of analyzers by receiving them through
   intermediate managers. Analyzers are not allowed to establish IDXP
   exchanges with other analyzers.

   [Rationale: Analyzers may send alert data and receive config data,
   and managers may send or receive both alert and config data.]

   An intrusion detection entity wishing to establish an IDXP session
   with another intrusion detection entity does so by initiating a BEEP
   session. The TLS profile should be setup first (see Section 7 for a
   discussion on security considerations), and after a new BEEP
   greeting message has been exchanged the IDXP profile can be chosen.

   In the following sequence an intrusion detection entity 'initial'
   initiates an IDXP exchange with the entity 'final'.

     initial                                             final
        ---------------- xport connect[1] ------------------>
       <-------------------- greeting ---------------------->
       <------------------ start TLS[2] -------------------->
       <-------------------- greeting ---------------------->
       <------------------ start IDXP[3] ------------------->

   Notes:

      [1] 'initial' initiates a transport connection to 'final',
         triggering the exchange of BEEP greeting messages.

      [2] both entities negotiate the use of the TLS profile.

      [3] both entities negotiate the use of the IDXP profile.

   In between a pair of IDXP endpoints may be an arbitrary number of
   proxies. A proxy may be necessary for administrative reasons, such


Feinstein & Matthews    Expires August 21, 2001                 [Page 4]

Internet-Draft                  The IDXP                   February 2001


   as running on a firewall to allow restricted access. Another use
   might be one proxy per company department, which forwards data from
   the analyzer endpoints in the department onto a company-wide manager
   endpoint.

   To create an application-layer tunnel that transparently forwards
   data over a chain of proxies, the TUNNEL profile[6] should be used.
   See [6] for more detail concerning the options available to setup an
   application-layer tunnel. Once a tunnel is established between two
   endpoints, a new BEEP greeting must be exchanged. If both endpoints
   advertise the IDXP profile in this greeting message then the
   endpoints may choose to proceed with the creation of an IDXP session.

   In the following sequence an intrusion detection entity 'initial'
   initiates the creation of an IDXP session with the entity 'final' by
   first contacting 'proxy1'. In the greeting exchange between
   'initial' and 'proxy1', the TUNNEL profile is selected, and
   subsequently the use of the TUNNEL profile is extended to reach
   through 'proxy2' to 'final'.

     initial            proxy1               proxy2                final
       -- xport connect -->
      <---- greeting ----->
       -- start TUNNEL --->
                           - xport connect[1] ->
                          <----- greeting ----->
                           --- start TUNNEL --->
                                                -- xport  connect -->
                                               <------ greeting ---->
                                                --- start TUNNEL --->
                                               <------ ok[2] -------
                          <------- ok ---------
      <------- ok --------
      <------------------------- greeting -------------------------->
      <------------------------ start TLS -------------------------->
      <------------------------- greeting -------------------------->
      <------------------------ start IDXP ------------------------->

   Notes:

      [1] Instead of immediately acknowledging the request from
         'initial' to start TUNNEL, 'proxy1' attempts to establish use
         of TUNNEL with 'proxy2'. 'proxy2' also delays its
         acknowledgment to 'proxy1'.

      [2] 'final' acknowledges the request from 'proxy2' to start
         TUNNEL, and this acknowledgment propagates back to 'initial'
         so that a TUNNEL application-layer tunnel is established from
         'initial' to 'final'.


Feinstein & Matthews    Expires August 21, 2001                 [Page 5]

Internet-Draft                  The IDXP                   February 2001


2.2 Data Transfer

   Between a pair of intrusion detection entities that wish to exchange
   data using IDXP there should exist only one BEEP session that is
   using the IDXP profile, and this BEEP session may have one or more
   BEEP channels open for transferring data.

   Endpoints assume the role of client or server on a per-channel
   basis, with one acting as the client and the other as the server. An
   endpoint's role of client or server is determined independent of
   whether the endpoint assumed the role of initiator or listener
   during the BEEP session establishment. Clients and servers act as
   sources and sinks, respectively, for exchanging data.

   In a simple case, an analyzer endpoint sends data to a manager
   endpoint. E.g.,

        +----------+                        +---------+
        |          |##### BEEP session #####|         |
        |          |                        |         |
        |          |                        |         |
        | Analyzer | ---- BEEP channel ---> | Manager |
        |          |                        |         |
        |          |                        |         |
        |          |########################|         |
        +----------+                        +---------+

   Note that the arrowhead for the BEEP channel points from client to
   server.

   Use of multiple BEEP channels in a BEEP session facilitates
   categorization/prioritization of data sent between IDXP endpoints.
   For example, a manager M1, sending alert data to another manager,
   M2, may choose to open a separate channel for every type of analyzer
   M1 receives alerts from. Different analyzer types include
   host-based, signature-based, and network-based. M1 would act as the
   client on each of these channels, and manager M2 can then choose in
   which order it receives and processes alerts from the different
   channels, perhaps giving priority to one channel over another for
   reasons stated in a security policy.











Feinstein & Matthews    Expires August 21, 2001                 [Page 6]

Internet-Draft                  The IDXP                   February 2001


          +---------+                        +---------+
          |         |##### BEEP session #####|         |
          |         |                        |         |
          |         | ---- alert type 1 ---> |         |
          | Manager |                        | Manager |
          |         | ---- alert type 2 ---> |         |
          |   M1    |                        |   M2    |
          |         | ---- alert type 3 ---> |         |
          |         |                        |         |
          |         |########################|         |
          +---------+                        +---------+

2.3 Trust Model

   In our model, trust is placed exclusively in the endpoints. Proxies
   are always assumed to be untrustworthy. A BEEP security profile is
   used to establish end-to-end security between pairs of IDXP
   endpoints, doing away with the need to place trust in any
   intervening proxies. Only after successful negotiation of the
   underlying security profile are IDXP endpoints to be trusted. Only
   BEEP security profiles offering at least the protections required by
   Section 6 of [8] should be used to secure an IDXP session. See
   Section 3 of [7] for the registration of the TLS profile, an example
   of a BEEP security profile meeting the requirements of [8].



























Feinstein & Matthews    Expires August 21, 2001                 [Page 7]

Internet-Draft                  The IDXP                   February 2001


3. The IDXP Profile

3.1 IDXP Profile Overview

   The IDXP profile provides a mechanism for exchanging information
   between intrusion detection elements. The TUNNEL profile can be used
   to provision a BEEP session running the IDXP profile over an
   application-layer tunnel. An underlying BEEP security profile can be
   used to provide some combination of integrity, mutual
   authentication, and confidentiality for the IDXP profile.

   The IDXP profile supports two elements of interest:

   o  The "IDXP-Greeting" element identifies an analyzer or manager at
      one end of a BEEP channel to the analyzer or manager at the other
      end of the channel.

   o  The "IDMEF-Message" element carries the structured information to
      be exchanged between the peers.

3.2 IDXP Profile Identification and Initialization

   The IDXP profile is identified as

      http://www.cs.hmc.edu/clinic/projects/2000/aerospace/IDXP

   in the BEEP "profile" element during channel creation.

   During channel creation, the corresponding "profile" element in the
   BEEP "start" element may contain an "IDXP-Greeting" element. If
   channel creation is successful, then before sending the
   corresponding reply, the BEEP peer processes the "IDXP-Greeting"
   element and includes the resulting response in the reply. This
   response will be an "ok" element or an "error" element. The choice
   of which element is returned is dependant on local provisioning of
   the server. Including an "IDXP-Greeting" element in the initial
   "start" element has exactly the same semantics as passing it as the
   first MSG message on the channel.

3.3 IDXP Profile Message Syntax

   BEEP messages in the profile may have a MIME Content-Type[4] of
   text/xml, text/plain, or application/octet-stream. The syntax of the
   individual elements is specified in Section 5.

3.4 IDXP Profile Semantics

   Each BEEP peer issues the "IDXP-Greeting" element using "MSG"
   messages. Each BEEP peer then issues "ok" in "RPY" messages or


Feinstein & Matthews    Expires August 21, 2001                 [Page 8]

Internet-Draft                  The IDXP                   February 2001


   "error" in "ERR" messages. (See Section 2.3.1 of [7] for the
   definitions of the "error" and "ok" elements.) Based on the
   respective client/server roles negotiated during the exchange of
   "IDXP-Greeting" elements, the client sends data using "MSG"
   messages. Depending on the MIME Content-Type, this data may be an
   "IDMEF-Message" element, plain text, or binary. The server then
   issues "ok" in "RPY" messages or "error" in "ERR" messages.

3.4.1 The IDXP-GREETING Element

   The "IDXP-Greeting" element serves to identify an analyzer or
   manager at one end of the BEEP channel to the analyzer or manager at
   the other end of the channel. The "IDXP-Greeting" element includes
   the role of the peer on the channel (client or server) and the URI
   identifying the peer. Additionally, the "IDXP-Greeting" element may
   include a combination of the fully qualified domain name and IP
   address of the peer. The IP address chosen should be the IP address
   associated with the underlying transport protocol carrying the
   channel. The character data of the element is free-form
   human-readable text. It may be used to further identify the peer,
   such as describing the physical location of the machine.

   An "IDXP-Greeting" element may be sent by either peer at any time.
   The peer receiving the "IDXP-Greeting" responds with an "ok"
   (indicating acceptance), or an "error" (indicating rejection). A
   peer's identity and role on a channel in effect is specified by the
   most recent "IDXP-Greeting" it sent that was answered with an "ok".

   An "IDXP-Greeting" could be rejected (with an "error" element) if
   the security that has been negotiated is inadequate or if the
   authenticated peer does not have authorization to connect as the
   specified type or to serve in the specified role.



















Feinstein & Matthews    Expires August 21, 2001                 [Page 9]

Internet-Draft                  The IDXP                   February 2001


   For example, a successful creation with an embedded "IDXP-Greeting"
   might look like this:

   I: MSG 0 10 . 1592 243
   I: Content-Type: text/xml
   I:
   I: <start number='1'>
   I:   <profile
   I:       uri='http://www.cs.hmc.edu/clinic/projects/2000/aerospace/IDXP'>
   I:     <![CDATA[ <IDXP-Greeting uri='http://example.com/alice'
   I:       role='client' /> ]]>
   I:   </profile>
   I: </start>
   I: END
   L: RPY 0 10 . 1256 142
   L: Content-Type: text/xml
   L:
   L: <profile
   L:     uri='http://www.cs.hmc.edu/clinic/projects/2000/aerospace/IDXP'>
   L:   <![CDATA[ <ok /> ]]>
   L: </profile>
   L: END
   L: MSG 0 11 . 1398 88
   L: Content-Type: text/xml
   L:
   L: <IDXP-Greeting uri='http://example.com/bob' role='server' />
   L: END
   I: RPY 0 11 . 1835 34
   I: Content-Type: text/xml
   I:
   I: <ok />
   I: END



















Feinstein & Matthews    Expires August 21, 2001                [Page 10]

Internet-Draft                  The IDXP                   February 2001


   A creation with an embedded "IDXP-Greeting" that fails might look
   like this:

   I: MSG 0 10 . 1776 ?
   I: Content-Type: text/xml
   I:
   I: <start number='1'>
   I:   <profile
   I:       uri='http://www.cs.hmc.edu/clinic/projects/2000/aerospace/IDXP'>
   I:     <![CDATA[ <IDXP-Greeting uri='http://example.com/eve'
   I:       role='client' /> ]]>
   I:   </profile>
   I: </start>
   I: END
   L: RPY 0 10 . 1592 ?
   L: Content-Type: text/xml
   L:
   L: <profile uri='http://www.cs.hmc.edu/clinic/projects/2000/aerospace/IDXP'>
   L:   <![CDATA[
   L:     <error code='530'>'http://example.com/eve' must first
   L:       negotiate the TLS profile</error> ]]>
   L: </profile>
   L: END

3.4.2 The IDMEF-MESSAGE Element

   The "IDMEF-Message" element carries the information to be exchanged
   between the peers. See [2] for the definition of this element.























Feinstein & Matthews    Expires August 21, 2001                [Page 11]

Internet-Draft                  The IDXP                   February 2001


4. Registration: The IDXP Profile

   Profile Identification:
   http://www.cs.hmc.edu/clinic/projects/2000/aerospace/IDXP

   Messages exchanged during Channel Creation: IDXP-Greeting

   Messages starting one-to-one exchanges: IDXP-Greeting, IDMEF-Message

   Messages in positive replies: ok

   Messages in negative replies: error

   Messages in one-to-many exchanges: None

   Message Syntax: See Section 3.3

   Message Semantics: See Section 3.4

   Contact Information: See the "Authors' Addresses" section of this
   memo






























Feinstein & Matthews    Expires August 21, 2001                [Page 12]

Internet-Draft                  The IDXP                   February 2001


5. The IDXP DTD

   The following is the DTD defining the valid elements for the IDXP
   profile

     <!--
     DTD for the IDXP Profile, as of 2001-02-09

     Refer to this DTD as:

       <!ENTITY % IDXP PUBLIC "-//Blocks//DTD IDXP//EN"
                  "http://www.cs.hmc.edu/clinic/projects/2000/aerospace/IDXP/idxp.dtd">

       %IDXP;
     -->

     <!-- Includes -->

       <!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
                  "http://xml.resource.org/profiles/BEEP/beep.dtd">

       %BEEP;



       <!ENTITY % IDMEF PUBLIC "-//IETF//DTD RFCxxxx IDMEF v0.3//EN"
                  "/some/path/to/the/idmef-message.dtd">

       %IDMEF;

     <!--
       Profile Summary

         BEEP profile http://www.cs.hmc.edu/clinic/projects/2000/aerospace/IDXP

         role       MSG               RPY      ERR
         ====       ===               ===      ===
         I or L     IDXP-Greeting     ok       error
         C          IDMEF-Message     ok       error
     -->

     <!--
       Entity Definitions

             entity        syntax/reference     example
             ======        ================     =======
         an authoritative identification
             URI           See [RFC-2396]       http://example.com



Feinstein & Matthews    Expires August 21, 2001                [Page 13]

Internet-Draft                  The IDXP                   February 2001


         a fully qualified domain name
             FQDN          See [RFC-1034]       www.example.com

         a dotted-quad IP address
             IP            1*3DIGIT "." 1*3DIGIT "."
                            1*3DIGIT "." 1*3DIGIT
                                                10.0.0.27
     -->

     <!ENTITY % URI      "CDATA">
     <!ENTITY % FQDN     "CDATA">
     <!ENTITY % IP       "CDATA">

     <!--
       The IDXP-Greeting element declares the role and identity of
       the peer issuing it, on a per channel basis. The contents of
       the element may include human-readable informative text,
       such as the physical location of the computer issuing the
       "IDXP-Greeting".
     -->

   <!ELEMENT IDXP-Greeting  (#PCDATA)>
   <!ATTLIST IDXP-Greeting
             uri            %URI;                #REQUIRED
             role           (client|server)      #REQUIRED
             fqdn           %FQDN;               #IMPLIED
             ip             %IP;                 #IMPLIED>

     <!--
       The IDMEF-Message element conveys the intrusion detection information
       that is exchanged.  This element is defined in the idmef-message.dtd
     -->

   <!-- End of DTD -->

















Feinstein & Matthews    Expires August 21, 2001                [Page 14]

Internet-Draft                  The IDXP                   February 2001


6. Reply Codes

   This section lists the three-digit error codes the IDXP profile may
   generate.

   code    meaning
   ====    =======
   421     Service not available
           (E.g., the peer does not have sufficient resources.)

   450     Requested action not taken
           (E.g, DNS lookup failed or connection could not
            be established. See also 550.)

   454     Temporary authentication failure

   500     General syntax error
           (E.g., poorly-formed XML)

   501     Syntax error in parameters
           (E.g., non-valid XML)

   504     Parameter not implemented

   530     Authentication required

   534     Authentication mechanism insufficient
           (E.g., cipher suite too weak, sequence exhausted, etc.)

   535     Authentication failure

   537     Action not authorized for user

   550     Requested action not taken
           (E.g., peer could be contacted, but
            malformed greeting or no IDXP profile advertised.)

   553     Parameter invalid

   554     Transaction failed
           (E.g., policy violation)










Feinstein & Matthews    Expires August 21, 2001                [Page 15]

Internet-Draft                  The IDXP                   February 2001


7. Security Considerations

   The IDXP profile is a profile of BEEP. In BEEP, transport security,
   user authentication, and data exchange are orthogonal. Refer to
   Section 8 of [7] for a discussion of this. It is strongly
   recommended that those wanting to use the IDXP profile initially
   negotiate the TLS profile between the peers.

   See Section 2.3 for a discussion of the trust model.

7.1 Use of the TUNNEL Profile

   See Section 7 of [6] for a discussion of the security considerations
   inherent in the use of the TUNNEL profile.

7.2 Use of Underlying Security Profiles

   At present the only BEEP security profile known to provide the
   security measures set forth in Section 6 of [8]. When securing a
   BEEP session with the TLS profile, the
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite offers a recommended
   acceptable level of security.





























Feinstein & Matthews    Expires August 21, 2001                [Page 16]

Internet-Draft                  The IDXP                   February 2001


References

   [1]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
        1998.

   [2]  Curry, D. and H. Debar, "Intrusion Detection Message Exchange
        Format Data Model and Extensible Markup Language (XML) Document
        Type Definition", February 2001,
        <draft-ietf-idwg-idmef-xml-03 (work in progress)>.

   [3]  Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A.
        O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
        January 1999.

   [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.

   [5]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
        1034, November 1987.

   [6]  New, D., "The TUNNEL Profile Registration", February 2001,
        <draft-ietf-idwg-beep-tunnel-00 (work in progress)>.

   [7]  Rose, M.T., "The Blocks Extensible Exchange Protocol Core",
        January 2001,
        <draft-ietf-beep-framework-11 (work in progress)>.

   [8]  Wood, M., "Intrusion Detection Message Exchange Requirements",
        December 2000,
        <draft-ietf-idwg-requirements-04 (work in progress)>.


Authors' Addresses

   Benjamin S. Feinstein
   Harvey Mudd College

   EMail: bfeinste@cs.hmc.edu
   URI:   http://www.cs.hmc.edu/


   Gregory A. Matthews
   Harvey Mudd College

   EMail: gmatthew@cs.hmc.edu
   URI:   http://www.cs.hmc.edu/



Feinstein & Matthews    Expires August 21, 2001                [Page 17]

Internet-Draft                  The IDXP                   February 2001


Appendix A. Acknowledgements

   The authors gratefully acknowledge the contributions of Darren New,
   Marshall Rose, and John White.















































Feinstein & Matthews    Expires August 21, 2001                [Page 18]

Internet-Draft                  The IDXP                   February 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.



















Feinstein & Matthews    Expires August 21, 2001                [Page 19]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/