Subject: [xml2rfc] vague oops error problems
From: [email-masked] (Marshall Rose)
Date: Thu, 20 Jun 2002 23:32:24 -0700

> I've been using xml2rfc for a couple of weeks now, but managed to do 
> something to my document which is now causing xml2rfc to produce:
> 
> can't read "elem()": no such element in array.
> 
> Context:
>   <rfc category="std" ipr="none">
> 
> 
> Unfortunately, this doesnt really help solve the problem....
> 
> Is there any way to get TCL to show more info about the context of the 
> error?

i take it that you're not running under an windowing system. if so, a
window should pop up with more information.

in general, this error means that a mandatory element is missing. if you
run your xml file through a validator against rfc2629.dtd it will tell
you what's wrong.

if you can't do that, then try this:
    
    % tclsh
    tclsh> source xml2rfc.tcl
    tclsh> xml2rfc example.xml
    pass 1...
    pass 2...
    can't read "elem()": no such element in array

    Context: 
        <rfc number="3288" category="std">
    tclsh> set errorInfo
    can't read "elem()": no such element in array
        while executing
    ...
    
the lines that first print out at ... will tell you where the error
is...
    
/mtr

From: [email-masked] (Mike Duigou)
Date: Thu, 20 Jun 2002 16:27:24 -0700
Subject: [xml2rfc] vague oops error problems
Message-ID: <[email-masked]>

I've been using xml2rfc for a couple of weeks now, but managed to do 
something to my document which is now causing xml2rfc to produce:

can't read "elem()": no such element in array.

Context:
  <rfc category="std" ipr="none">

Unfortunately, this doesnt really help solve the problem....

Is there any way to get TCL to show more info about the context of the 
error?

Mike Duigou

From: [email-masked] (Marshall Rose)
Date: Wed, 12 Jun 2002 21:47:11 -0700
Subject: [xml2rfc] Re: IDXP xml problems
In-Reply-To: <397E0659AA2DD411843500508B64F1CE04310241@USBOSMX01>
References: <397E0659AA2DD411843500508B64F1CE04310241@USBOSMX01>
Message-ID: <[email-masked]>

hi. the problem is that the

	%include.
    
syntax got replaced because it wasn't "XML-like enough". there are two
ways now to do include files. the one you want is
    
    <?rfc include='reference.RFC.xxxx' ?>
    
in general, i really don't like making incompatible changes in xml2rfc,
but there were enough people nagging me about this that i gave in...
    
sorry!

/mtr

From: [email-masked] ([email-masked])
Date: Wed, 12 Jun 2002 21:06:50 -0400
Subject: [xml2rfc] IDXP xml problems
Message-ID: <397E0659AA2DD411843500508B64F1CE04310241@USBOSMX01>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C21276.996E2A90
Content-Type: text/plain;
	charset="iso-8859-1"

Hey Marshall,

Has something changed with the references on xml.resource.org?
IDXP-04 will no longer go through the submit page. I have IDXP-05
nearly ready, but it suffers the same problem. Please help. Attached
is the XML source for IDXP-04 and IDXP-05. Many thanks!
The error page is:

Unable to convert:

can't read "xref(RFC3080)": no such element in array

Context: 
    <rfc ipr="full2026" docName="draft-ietf-idwg-beep-idxp-05">
    <middle>
    <section anchor="intro" title="Introduction">
    <t>

Ben Feinstein
  Software Development Engineer, R & D
  W: 678.585.7865 x6726 F: 770.645.8311 M: 678.772.4126
  8302 Dunwoody Pl., Suite 320, Atlanta, GA 30350 www.guardent.com
_____________________________________________________
G U A R D E N T
  Enterprise Security and Privacy Programs

------_=_NextPart_000_01C21276.996E2A90
Content-Type: application/octet-stream;
	name="draft-ietf-idwg-beep-idxp-04.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-idwg-beep-idxp-04.xml"

<?xml version=3D"1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc=3D"yes"?>

<!--

$Header: /cvsroot/idxp-java/idxp-doc/draft-ietf-idwg-beep-idxp.xml,v =
1.3 2002/01/08 19:51:22 bfeinste Exp $

-->

<!-- Remember to increment the document number for each release -->
<rfc ipr=3D"full2026" docName=3D"draft-ietf-idwg-beep-idxp-04">

<front>
<title abbrev=3D"The IDXP">The Intrusion Detection Exchange Protocol =
(IDXP)</title>

<author initials=3D"B.S." surname=3D"Feinstein" fullname=3D"Benjamin S. =
Feinstein">
<organization>Guardent, Inc.</organization>
<address>
<email>[email-masked]</email>
<uri>http://www.guardent.com/</uri>
</address>
</author>

<author initials=3D"G.A." surname=3D"Matthews" fullname=3D"Gregory A. =
Matthews">
<organization>CSC/NASA Ames Research Center</organization>
<address>
<email>[email-masked]</email>
<uri>http://www.nas.nasa.gov/</uri>
</address>
</author>

<author initials=3D"J.C.C." surname=3D"White" fullname=3D"John C. C. =
White">
<organization>MITRE Corporation</organization>
<address>
<email>[email-masked]</email>
<uri>http://www.mitre.org/</uri>
</address>
</author>

<!-- Remember to update the date for each release -->
<date day=3D"8" month=3D"January" year=3D"2002" />
<area>Security</area>
<workgroup>Intrusion Detection Exchange Format</workgroup>
<keyword>intrusion detection</keyword>
<keyword>security</keyword>
<keyword>secure</keyword>
<keyword>secure protocol</keyword>
<keyword>exchange</keyword>
<keyword>intrusion</keyword>
<keyword>IDS</keyword>
<keyword>BEEP</keyword>
<keyword>intrusion detection protocol</keyword>

<abstract>
<t>This memo describes the Intrusion Detection Exchange Protocol =
(IDXP), an application-level protocol for exchanging data between =
intrusion detection entities. IDXP supports mutual-authentication, =
integrity, and confidentiality over a connection-oriented protocol. The =
protocol provides for the exchange of IDMEF messages, unstructured =
text, and binary data. The IDMEF message elements are described in the =
<xref target=3D"refs.IDMEF">Intrusion Detection Message Exchange Format =
(IDMEF)</xref>, a companion document of the Intrusion Detection =
Exchange Format (IDWG) working group of the IETF.</t>
</abstract>
</front>
<middle>

<section anchor=3D"intro" title=3D"Introduction">
<t>IDXP is specified, in part, as a <xref target=3D"RFC3080">Blocks =
Extensible Exchange Protocol (BEEP)</xref> "profile". BEEP is a generic =
application protocol framework for connection-oriented, asynchronous =
interactions. Features such as authentication and confidentiality are =
provided through the use of other BEEP profiles. Accordingly, many =
aspects of IDXP (e.g., confidentiality) are provided within the BEEP =
framework.</t>

  <section anchor=3D"purpose" title=3D"Purpose">
<t>IDXP provides for the exchange of <xref =
target=3D"refs.IDMEF">IDMEF</xref> messages, unstructured text, and =
binary data between intrusion detection entities. Addressing the =
security-sensitive nature of exchanges between intrusion detection =
entities, underlying BEEP security profiles should be used to offer =
IDXP the required set of security properties. See <xref =
target=3D"proto-reqs" /> for a discussion of how IDXP fulfills the IDWG =
communication protocol requirements. See <xref target=3D"security" /> =
for a discussion of security considerations.</t>

<t>IDXP is primarily intended for the exchange of data created by =
intrusion detection entities. <xref target=3D"refs.IDMEF">IDMEF</xref> =
messages should be used for the structured representation of this =
intrusion detection data, although IDXP may be used to exchange =
unstructured text and binary data.</t>
  </section>

  <section title=3D"Profiles">

<t>There are several BEEP profiles discussed, the first of which we =
define in this memo:</t>
<t><list style=3D"empty">
  <t>The IDXP Profile</t>
  <t><xref target=3D"refs.tunnel">The TUNNEL Profile</xref></t>
  <t>The Simple Authentication and Security Layer (SASL) Family of =
Profiles (c.f., Section 4.1 of <xref target=3D"RFC3080" />)</t>
  <t>The TLS Profile (c.f., Section 3.1 of <xref target=3D"RFC3080" =
/>)</t>
</list></t>
  </section>

  <section anchor=3D"terminology" title=3D"Terminology">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this =
document are to be interpreted as described in <xref =
target=3D"RFC2119">RFC 2119</xref>.</t>

<t>Throughout this memo, the terms "analyzer" and "manager" are used in =
the context of the <xref target=3D"refs.IDWG-reqs">Intrusion Detection =
Message Exchange Requirements</xref>. In particular, Section 3.2 of =
<xref target=3D"refs.IDWG-reqs" /> defines the meaning of a collection =
of intrusion detection terms.</t>

<t>The terms "peer", "initiator", "listener", "client", and "server" =
are used in the context of <xref target=3D"RFC3080">BEEP</xref>. In =
particular, Section 2.1 of the BEEP framework memo discusses the roles =
that a BEEP peer may perform.</t>

<t>Note that the term "proxy" is specific to IDXP, and does not exist =
in the context of BEEP. The term "intrusion detection" is abbreviated =
as "ID".</t>
  </section>

</section>

<section anchor=3D"model" title=3D"The Model">

  <section anchor=3D"connect" title=3D"Connection Provisioning">

<t>Intrusion detection entities using IDXP to transfer data are termed =
IDXP peers. Peers can exist only in pairs, and these pairs communicate =
over a single BEEP session with one or more BEEP channels opened for =
transferring data. Peers are either managers or analyzers, as defined =
in Section 3.2 of <xref target=3D"refs.IDWG-reqs" />.</t>

<t> The relationship between analyzers and managers is potentially =
many-to-many. I.e., an analyzer MAY communicate with many managers; =
similarly, a manager MAY communicate with many analyzers. Likewise, the =
relationship between different managers is potentially many-to-many, so =
that a manager MAY receive the alerts sent by a large number of =
analyzers by receiving them through intermediate managers. Analyzers =
MUST NOT establish IDXP exchanges with other analyzers.</t>

<!--
<t>[Rationale: Analyzers may send alert data and receive configuration =
data, and managers may send or receive both alert and configuration =
data.]</t>
-->

<t>An ID entity wishing to establish IDXP communications with another =
ID entity does so by opening a BEEP channel, which may entail =
initiating a BEEP session. A BEEP security profile offering the =
required security properties SHOULD initially be negotiated (see <xref =
target=3D"security" /> for a discussion of security considerations). =
Following the successful negotiation of the BEEP security profile, IDXP =
greetings are exchanged and connection provisioning proceeds.</t>

<figure>
<preamble>In the following sequence an ID entity 'Alice' initiates an =
IDXP exchange with the entity 'Bob'.</preamble>
<artwork><![CDATA[
     Alice                                               Bob
       ---------------- xport connect[1] ------------------>
      <-------------------- greeting ---------------------->
      <-------------start security profile[2] ------------->
      <-------------------- greeting ---------------------->
      <------------------ start IDXP[3] ------------------->
]]></artwork>
</figure>
<t>Notes:</t>
<t><list style=3D"hanging">
<t hangText=3D"[1]">'Alice' initiates a transport connection to 'Bob', =
triggering the exchange of BEEP greeting messages.</t>
<t hangText=3D"[2]">both entities negotiate the use of a BEEP security =
profile.</t>
<t hangText=3D"[3]">both entities negotiate the use of the IDXP =
profile.</t>
</list></t>

<t>In between a pair of IDXP peers may be an arbitrary number of =
proxies. A proxy may be necessary for administrative reasons, such as =
running on a firewall to allow restricted access. Another use might be =
one proxy per company department, which forwards data from the analyzer =
peers in the department onto a company-wide manager peer.</t>

<!--

<t>To create an application-layer tunnel that transparently forwards =
data over a chain of proxies, the <xref target=3D"refs.tunnel">TUNNEL =
profile</xref> should be used. See <xref target=3D"refs.tunnel" /> for =
more detail concerning the options available to setup an =
application-layer tunnel, and see . Once a tunnel is established =
between two peers, a new BEEP greeting must be exchanged. At this =
point, a BEEP security profile offering the required security =
properties would be negotiated, followed by negotiation of the IDXP =
profile.</t>

-->

<t>A BEEP tuning profile MAY be used to create an application-layer =
tunnel that transparently forwards data over a chain of proxies. The =
<xref target=3D"refs.tunnel">TUNNEL profile</xref> SHOULD be used for =
this purpose; see <xref target=3D"refs.tunnel" /> for more detail =
concerning the options available to setup an application-layer tunnel =
using TUNNEL, and see <xref target=3D"security.tunnel" /> for a =
discussion of TUNNEL related security considerations. TUNNEL MUST be =
offered as a tuning profile for the creation of application-layer =
tunnels. The TUNNEL profile MUST offer the use of some form of SASL =
authentication (c.f., Section 4.1 of <xref target=3D"RFC3080" />). Once =
a tunnel has been created a BEEP security profile offering the required =
security properties SHOULD be negotiated, followed by negotiation of =
the IDXP profile.</t>

<figure>
<preamble>The following sequence shows how TUNNEL might be used to =
create an application-layer tunnel through which IDXP would operate. An =
ID entity 'Alice' initiates the creation of a BEEP session using the =
IDXP profile with the entity 'Bob' by first contacting 'proxy1'. In the =
greeting exchange between 'Alice' and 'proxy1', the TUNNEL profile is =
selected, and subsequently the use of the TUNNEL profile is extended to =
reach through 'proxy2' to 'Bob'.</preamble>
<artwork><![CDATA[
Alice              proxy1               proxy2               Bob
  -- xport connect -->
 <---- greeting ----->
  -- start TUNNEL --->
                      - xport connect[1] ->
                     <----- greeting ----->
                      --- start TUNNEL --->
                                           --- xport connect -->
                                          <----- greeting ----->
                                           --- start TUNNEL --->
                                          <----- <ok>[2] ------
                     <------- <ok> -------
 <------ <ok> -------
 <------------------------- greeting -------------------------->
 <------------------ start security profile ------------------->
 <------------------------- greeting -------------------------->
 <------------------------ start IDXP ------------------------->
]]></artwork>
</figure>
<t>Notes:</t>
<t><list style=3D"hanging">
<t hangText=3D"[1]">Instead of immediately acknowledging the request =
from 'Alice' to start TUNNEL, 'proxy1' attempts to establish use of =
TUNNEL with 'proxy2'. 'proxy2' also delays its acknowledgment to =
'proxy1'.</t>
<t hangText=3D"[2]">'Bob' acknowledges the request from 'proxy2' to =
start TUNNEL, and this acknowledgment propagates back to 'Alice' so =
that a TUNNEL application-layer tunnel is established from 'Alice' to =
'Bob'.</t>
</list></t>
  </section>

  <section anchor=3D"transfer" title=3D"Data Transfer">

<t>Between a pair of ID entities communicating over a BEEP session, one =
or more BEEP channels MAY be opened using the IDXP profile. If desired, =
additional BEEP sessions MAY be established to offer additional =
channels using the IDXP profile. However, in most situations additional =
channels using the IDXP profile SHOULD be opened within an existing =
BEEP session, as opposed to provisioning a new BEEP session containing =
the additional channels using the IDXP profile.</t>

<t>Peers assume the role of client or server on a per-channel basis, =
with one acting as the client and the other as the server. A peer's =
role of client or server is determined independent of whether the peer =
assumed the role of initiator or listener during the BEEP session =
establishment. Clients and servers act as sources and sinks, =
respectively, for exchanging data.</t>

<figure>
<preamble>In a simple case, an analyzer peer sends data to a manager =
peer. E.g.,</preamble>
<artwork>
        +----------+                          +----------+
        |          |                          |          |
        |          |****** BEEP session ******|          |
        |          |                          |          |
        | Analyzer | ----- IDXP profile ----> | Manager  |
        | (Client) |                          | (Server) |
        |          |                          |          |
        |          |**************************|          |
        |          |                          |          |
        +----------+                          +----------+
</artwork>
<!--<postamble>Note that the arrowhead for the BEEP channel using the =
IDXP profile points from client to server.</postamble>-->
</figure>

<t>Use of multiple BEEP channels in a BEEP session facilitates =
categorization and prioritization of data sent between IDXP peers. For =
example, a manager 'M1', sending alert data to another manager, 'M2', =
may choose to open a separate channel to exchange different categories =
of alerts. 'M1' would act as the client on each of these channels, and =
manager 'M2' can then process and act on the incoming alerts based on =
their respective channel categorizations. See <xref =
target=3D"idxp_options" /> for more detail on how to incorporate =
categorization and/or prioritization into channel creation.</t>

<figure>
<artwork>
+----------+                                            +----------+
|          |                                            |          |
|          |*************** BEEP session ***************|          |
|          |                                            |          |
|          | -- IDXP profile, network-based alerts ---> |          |
| Manager  |                                            | Manager  |
|   M1     | ---- IDXP profile, host-based alerts ----> |   M2     |
| (Client) |                                            | (Server) |
|          | ------ IDXP profile, other alerts -------> |          |
|          |                                            |          |
|          |********************************************|          |
|          |                                            |          |
+----------+                                            +----------+
</artwork>
</figure>

  </section>

  <section title=3D"Connection Teardown">
  <t>An IDXP peer may choose to close an IDXP channel under many =
different circumstances (e.g., an error in processing has occurred). To =
close a channel, the peer sends a "close" element (c.f., Section =
2.3.1.3 of <xref target=3D"RFC3080" />) on channel zero indicating =
which channel is being closed. An IDXP peer may also choose to close an =
entire BEEP session by sending a "close" element indicating that =
channel zero is to be closed. Section 2.3.1.3 of <xref =
target=3D"RFC3080" /> offers a more complete discussion of the =
circumstances under which a BEEP peer is permitted to close a channel =
and the mechanisms for doing so.</t>
  <t>It is anticipated that due to the overhead of provisioning an =
application-layer tunnel and/or a BEEP security profile, BEEP sessions =
containing IDXP channels will be long-lived. Additionally, the repeated =
overhead of IDXP channel provisioning (i.e., the exchange of IDXP =
greetings) may be avoided by keeping IDXP channels open even while data =
is not actively being exchanged on them. These are recommendations and, =
as such, IDXP peers may choose to close and re-provision BEEP sessions =
and/or IDXP channels as they see fit.</t>
  </section>

  <section anchor=3D"trust" title=3D"Trust Model">
  <t>In our model, trust is placed exclusively in the IDXP peers. =
Proxies are always assumed to be untrustworthy. A BEEP security profile =
is used to establish end-to-end security between pairs of IDXP peers, =
doing away with the need to place trust in any intervening proxies. =
Only after successful negotiation of the underlying security profile =
are IDXP peers to be trusted. Only BEEP security profiles offering at =
least the protections required by Section 6 of <xref =
target=3D"refs.IDWG-reqs" /> should be used to secure a BEEP session =
containing channels using the IDXP profile. See Section 3 of <xref =
target=3D"RFC3080" /> for the registration of the TLS profile, an =
example of a BEEP security profile meeting the requirements of Section =
6 of <xref target=3D"refs.IDWG-reqs" />. See <xref =
target=3D"proto-reqs" /> for a discussion of how IDXP fulfills the IDWG =
communications protocol requirements.</t>
  </section>

</section>

<section anchor=3D"IDXP-profile" title=3D"The IDXP Profile">

  <section title=3D"IDXP Profile Overview">
  <t>The IDXP profile provides a mechanism for exchanging information =
between intrusion detection entities. A BEEP tuning profile MAY be used =
to create an application-layer tunnel that transparently forwards data =
over a chain of proxies. The <xref target=3D"refs.tunnel">TUNNEL =
profile</xref> SHOULD be used for this purpose; see <xref =
target=3D"refs.tunnel" /> for more detail concerning the options =
available to setup an application-layer tunnel using TUNNEL, and see =
<xref target=3D"security.tunnel" /> for a discussion of TUNNEL related =
security considerations. TUNNEL MUST be offered as a tuning profile for =
the creation of application-layer tunnels. The TUNNEL profile MUST =
offer the use of some form of SASL authentication (c.f., Section 4.1 of =
<xref target=3D"RFC3080" />). The TLS profile SHOULD be used to provide =
the required combination of mutual-authentication, integrity, and =
confidentiality for the IDXP profile. For further discussion of =
application-layer tunnel and security issues see <xref =
target=3D"connect" /> and <xref target=3D"security" />.</t>

  <t>The IDXP profile supports several elements of interest:</t>
  <t><list style=3D"symbols">
    <t>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.</t>
    <t>The "Option" element is used to convey optional channel =
parameters between peers during the exchange of "IDXP-Greeting" =
elements. This element is OPTIONAL.</t>
    <t>The "IDMEF-Message" element carries the structured information =
to be exchanged between the peers.</t>
  </list></t>
  </section>

  <section title=3D"IDXP Profile Identification and Initialization">
  <t>The IDXP profile is identified as</t>
  <t><list style=3D"empty">
    <t>http://iana.org/beep/transient/idwg/idxp</t>
  </list></t>
  <t>in the BEEP "profile" element during channel creation.</t>

  <t>During channel creation, "IDXP-Greeting" elements MUST be mutually =
exchanged between the peers. An "IDXP-Greeting" element MAY be =
contained within the corresponding "profile" element in the BEEP =
"start" element. 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. 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 dependent on local provisioning =
of the peer.</t>

  </section>

  <section anchor=3D"IDXP-syntax" title=3D"IDXP Profile Message =
Syntax">
  <t>BEEP messages in the profile MUST have a <xref =
target=3D"RFC2046">MIME Content-Type</xref> of "text/xml", =
"text/plain", or "application/octet-stream". The syntax of the =
individual elements is specified in <xref target=3D"idxp_dtd" /> and =
Section 5 of <xref target=3D"refs.IDMEF" />.</t>
  </section>

  <section anchor=3D"IDXP-semantics" title=3D"IDXP Profile Semantics">
  <t>Each BEEP peer issues the "IDXP-Greeting" element using "MSG" =
messages. The "IDXP-Greeting" element MAY contain one or more "Option" =
sub-elements, conveying optional channel parameters. Each BEEP peer =
then issues "ok" in "RPY" messages or "error" in "ERR" messages. (See =
Section 2.3.1 of <xref target=3D"RFC3080" /> 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.</t>

    <section title=3D"The IDXP-GREETING Element">
    <t>The "IDXP-Greeting" element serves to identify the 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 MUST include =
the role of the peer on the channel (client or server) and the <xref =
target=3D"RFC2396">Uniform Resource Identifier (URI)</xref> of the =
peer. Additionally, the "IDXP-Greeting" element MAY include a =
combination of the fully qualified domain name (c.f., <xref =
target=3D"RFC1034" />) and IP address of the peer. The IP address =
chosen SHOULD correspond to the IP address associated with the =
underlying transport protocol carrying the channel. One or more =
"Option" sub-elements MAY be present.</t>

    <t>An "IDXP-Greeting" element MAY be sent by either peer at any =
time. The peer receiving the "IDXP-Greeting" MUST respond with an "ok" =
(indicating acceptance), or an "error" (indicating rejection). A peer's =
identity and role on a channel and any optional channel parameters are, =
in effect, specified by the most recent "IDXP-Greeting" it sent that =
was answered with an "ok".</t>

    <t>An "IDXP-Greeting" may be rejected (with an "error" element) =
under many circumstances. These include, but are not limited to, =
authentication failure, lack of authorization to connect under the =
specified role, the negotiation of an inadequate ciphersuite, or the =
presence of a channel option that must be understood but was =
unrecognized.</t>

    <figure>
      <preamble>For example, a successful creation with an embedded =
"IDXP-Greeting" might look like this:</preamble>
<artwork>
I: MSG 0 10 . 1592 187
I: Content-Type: text/xml
I:
I: &lt;start number=3D'1'&gt;
I:   &lt;profile uri=3D'http://iana.org/beep/transient/idwg/idxp'&gt;
I:     &lt;![CDATA[ &lt;IDXP-Greeting uri=3D'http://example.com/alice'
I:       role=3D'client' /&gt; ]]&gt;
I:   &lt;/profile&gt;
I: &lt;/start&gt;
I: END
L: RPY 0 10 . 1865 91
L: Content-Type: text/xml
L:
L: &lt;profile uri=3D'http://iana.org/beep/transient/idwg/idxp'&gt;
L:   &lt;![CDATA[ &lt;ok /&gt; ]]&gt;
L: &lt;/profile&gt;
L: END
L: MSG 0 11 . 1956 61
L: Content-Type: text/xml
L:
L: &lt;IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server' =
/&gt;
L: END
I: RPY 0 11 . 1779 7
I: Content-Type: text/xml
I:
I: &lt;ok /&gt;
I: END
</artwork>
    </figure>

    <figure>
      <preamble>A creation with an embedded "IDXP-Greeting" that fails =
might look like this:</preamble>
<artwork>
I: MSG 0 10 . 1776 185
I: Content-Type: text/xml
I:
I: &lt;start number=3D'1'&gt;
I:   &lt;profile uri=3D'http://iana.org/beep/transient/idwg/idxp'&gt;
I:     &lt;![CDATA[ &lt;IDXP-Greeting uri=3D'http://example.com/eve'
I:       role=3D'client' /&gt; ]]&gt;
I:   &lt;/profile&gt;
I: &lt;/start&gt;
I: END
L: RPY 0 10 . 1592 182
L: Content-Type: text/xml
L:
L: &lt;profile uri=3D'http://iana.org/beep/transient/idwg/idxp'&gt;
L:   &lt;![CDATA[
L:     &lt;error code=3D'530'&gt;'http://example.com/eve' must first
L:       negotiate the TLS profile&lt;/error&gt; ]]&gt;
L: &lt;/profile&gt;
L: END
</artwork>
    </figure>

    </section>

    <section title=3D"The OPTION Element">
    <t>If present, the "Option" element MUST be contained within an =
"IDXP-Greeting" element. An individual "IDXP-Greeting" element MAY =
contain one or more "Option" sub-elements. Each "Option" element within =
an "IDXP-Greeting" element represents a request to enable an IDXP =
option on the channel being negotiated. See <xref =
target=3D"idxp_options" /> for a complete description of IDXP options =
and the "Option" element.</t>
    </section>

    <section title=3D"The IDMEF-MESSAGE Element">
    <t>The "IDMEF-Message" element carries the information to be =
exchanged between the peers. See Section 5 of <xref =
target=3D"refs.IDMEF" /> for the definition of this element.</t>
    </section>

  </section>

</section>

<section anchor=3D"idxp_options" title=3D"IDXP Options">

<t>IDXP provides a service for the reliable exchange of data between =
intrusion detection entities. Options are used to alter the semantics =
of the service.</t>

<t>The specification of an IDXP option MUST define:</t>

<t><list style=3D"symbols">
  <t>the identity of the option;</t>
  <t>what content, if any, is contained within the option; and,</t>
  <t>the processing rules for the option.</t>
</list></t>

<t>An option registration template (c.f. <xref target=3D"option_reg" =
/>) organizes this information.</t>

<t>An "Option" element is contained within an "IDXP-Greeting" element. =
The "IDXP-Greeting" element itself MAY contain one or more "Option" =
elements. The "Option" element has several attributes and contains =
arbitrary content:</t>

<t><list style=3D"symbols">
  <t>the "internal" and the "external" attributes, exactly one of which =
MUST be present, uniquely identify the option;</t>
  <t>the "mustUnderstand" attribute, whose presence is OPTIONAL and =
whose default value is "false", specifies whether the option, if =
unrecognized, MUST cause an error in processing to occur; and,</t>
  <t>the "localize" attribute, whose presence is OPTIONAL, specifies =
one or more language tokens, each identifying a desirable language tag =
to be used if textual diagnostics are returned to the originator.</t>
</list></t>

<t>The value of the "internal" attribute is the IANA-registered name =
for the option. If the "internal" attribute is not present, then the =
value of the "external" attribute is a URI or URI with a =
fragment-identifier. Note that a relative-URI value is not allowed.</t>

<t>The "mustUnderstand" attribute specifies whether the peer may ignore =
the option if it is unrecognized. If the value of the "mustUnderstand" =
attribute is "true", and if the peer does not recognize the option, =
then an error in processing has occurred. When absent, the value of the =
"mustUnderstand" attribute is defined to be "false".</t>

  <section anchor=3D"priority_option" title=3D"The channelPriority =
Option">
    <t><xref target=3D"priority_opt_reg" /> contains the IDXP option =
registration for the "channelPriority" option. This option contains a =
"channelPriority" element (c.f., <xref target=3D"priority_dtd" />).</t>
    <t>By default, IDXP does not place any requirements on how peers =
should manage multiple IDXP channels. The "channelPriority" option =
provides a way for peers using multiple IDXP channels to request =
relative priorities for each channel. When sending an "IDXP-Greeting" =
element during the provisioning of an IDXP channel, the originating =
peer MAY request that the remote peer assign a priority to the channel =
by including an "Option" element containing a "channelPriority" =
element.</t>
    <t>The "channelPriority" element has one attribute named =
"priority", of range 0..2147483647. This attribute is REQUIRED. Not =
coincidentally, this is the maximum range of possible BEEP channel =
numbers. 0 is defined to represent the highest priority, with relative =
priority decreasing as the "priority" value ascends.</t>

    <figure>
      <preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, an analyzer successfully requests =
that a manager assign a priority to the channel:</preamble>
<artwork>
<![CDATA[
    analyzer                                           manager
       --------------- greeting w/ option ----------------->
      <---------------------- <ok> ------------------------

C: MSG 1 17 . 1984 165
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri=3D'http://example.com/alice' role=3D'client'>
C:   <Option internal=3D'channelPriority'>
C:     <channelPriority priority=3D'0' />
C:   </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 17 . 2001 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
]]></artwork>
    </figure>

    <figure>
      <preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, a manager unsuccessfully requests =
that an analyzer assign a priority to the channel:</preamble>
<artwork>
<![CDATA[
    analyzer                                           manager
      <---------------- greeting w/ option ----------------
       --------------------- <error> ---------------------->

S: MSG 1 17 . 1312 194
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server'>
S:   <Option internal=3D'channelPriority' mustUnderstand=3D'true'>
S:     <channelPriority priority=3D'2147483647' />
S:   </Option>
S: </IDXP-Greeting>
S: END
C: RPY 1 17 . 451 68
C: Content-Type: text/xml
C:
C: <error code=3D'504'>'channelPriority' option was =
unrecognized</error>
C: END
]]></artwork>
    </figure>

  </section>

  <section anchor=3D"type_option" title=3D"The streamType Option">
    <t><xref target=3D"type_opt_reg" /> contains the IDXP option =
registration for the "streamType" option. This option contains a =
"streamType" element (c.f., <xref target=3D"st_dtd" />).</t>
    <t>By default, IDXP provides no explicit method for categorizing =
channels. The "streamType" option provides a way for peers to request =
that a channel be categorized as a particular stream type. When sending =
an "IDXP-Greeting" element during the provisioning of an IDXP channel, =
the originating peer MAY request that the remote peer assign a stream =
type to the channel by including an "Option" element containing a =
"streamType" element.</t>
    <t>The "streamType" element has one attribute named "type", with =
the possible values of "alert", "heartbeat", or "config". This =
attribute is REQUIRED. A value of "alert" indicates that the channel =
should be categorized as being used for the exchange of ID alerts. A =
value of "heartbeat" indicates that the channel should be categorized =
as being used for the exchange of heartbeat messages such as the =
"Heartbeat" element (c.f., Section 5 of <xref target=3D"refs.IDMEF" =
/>). A value of "config" indicates that the channel should be =
categorized as being used for the exchange of configuration =
messages.</t>

    <figure>
      <preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, an analyzer successfully requests =
that a manager assign a stream type to the channel:</preamble>
<artwork>
<![CDATA[
    analyzer                                           manager
       --------------- greeting w/ option ----------------->
      <---------------------- <ok> ------------------------

C: MSG 1 21 . 1963 155
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri=3D'http://example.com/alice' role=3D'client'>
C:   <Option internal=3D'streamType'>
C:     <streamType type=3D'alert' />
C:   </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 21 . 1117 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
]]></artwork>
    </figure>

    <figure>
      <preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, a manager unsuccessfully requests =
that an analyzer assign a stream type to the channel:</preamble>
<artwork>
<![CDATA[

    analyzer                                           manager
      <---------------- greeting w/ option ----------------
       --------------------- <error> ---------------------->

S: MSG 1 21 . 1969 176
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server'>
S:   <Option internal=3D'streamType' mustUnderstand=3D'true'>
S:     <streamType type=3D'config' />
S:   </Option>
S: </IDXP-Greeting>
S: END
C: RPY 1 21 . 1292 63
C: Content-Type: text/xml
C:
C: <error code=3D'504'>'streamType' option was unrecognized</error>
C: END
]]></artwork>
    </figure>

  </section>

</section>

<section anchor=3D"proto-reqs" title=3D"Fulfillment of IDWG =
Communications Protocol Requirements">

<t>The following lists the communications protocol requirements =
established in Section 6 of <xref target=3D"refs.IDWG-reqs" /> and, for =
each requirement, describes the manner in which it is fulfilled by =
IDXP.</t>

  <t>The [protocol] MUST support reliable transmission of messages.</t>
  <t><list style=3D"empty">
    <t>IDXP operates over BEEP, which operates only over reliable =
connection-oriented transport protocols (e.g., TCP). In addition, BEEP =
peers communicate using a simple request-response protocol, which =
provides end-to-end reliability between peers.</t>
  </list></t>

  <t>The [protocol] MUST support transmission of messages between ID =
components across firewall boundaries without compromising =
security.</t>

  <t><list style=3D"empty">
    <t>The TUNNEL profile <xref target=3D"refs.tunnel" /> MUST be =
offered as an option for creation of application-layer tunnels to allow =
operation across firewalls. The TUNNEL profile SHOULD be used to =
provide an application-layer tunnel. The ability to authenticate hosts =
during the creation of an application-layer tunnel MUST be provided by =
the mechanism chosen to create such tunnels. A firewall may therefore =
be configured to authenticate all hosts attempting to tunnel into the =
protected network. If the TUNNEL profile is used, SASL (c.f., Section =
4.1 of <xref target=3D"RFC3080" />) MUST be offered as a mechanism by =
which hosts can be authenticated.</t>
  </list></t>

  <t>The [protocol] MUST support mutual authentication of the analyzer =
and the manager to each other.</t>

  <t><list style=3D"empty">
    <t>IDXP supports mutual authentication of the peers through the use =
of an appropriate underlying BEEP security profile. The TLS profile and =
members of the SASL family of profiles (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) are examples of security profiles that may be =
used to authenticate the identity of communicating ID components. TLS =
MUST be offered as a mechanism to provide mutual authentication, and =
TLS SHOULD be used to provide mutual authentication.</t>
  </list></t>

  <t>The [protocol] 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.</t>

  <t><list style=3D"empty">
    <t>IDXP supports confidentiality through the use of an appropriate =
underlying BEEP security profile. The TLS profile is an example a =
security profile that offers confidentiality. The TLS profile with the =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a =
mechanism to provide confidentiality, and TLS with this cipher suite =
SHOULD be used to provide confidentiality. The =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses ephemeral =
Diffie-Hellman (DHE) with DSS signatures for key exchange and triple =
DES (3DES) and cipher-block chaining (CBC) for encryption. Stronger =
cipher suites are optional.</t>
  </list></t>

  <t>The [protocol] 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.</t>

  <t><list style=3D"empty">
    <t>IDXP supports message integrity through the use of an =
appropriate underlying BEEP security profile. The TLS profile and =
members of the SASL family of profiles (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) are examples of security profiles that offer =
message integrity. The TLS profile with the =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a =
mechanism to provide integrity, and TLS with this cipher suite SHOULD =
be used to provide integrity. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA =
cipher suite uses the Secure Hash Algorithm (SHA) for integrity =
protection using a keyed message authentication code. Stronger cipher =
suites are optional.</t>
  </list></t>

  <t>The [protocol] SHOULD be able to ensure non-repudiation of the =
origin of IDMEF messages.</t>

  <t><list style=3D"empty">
    <t>IDXP supports non-repudiation of message origin through the use =
of an appropriate underlying BEEP security profile. The TLS profile is =
an example of a security profile that offers non-repudiation of message =
origin through the authentication of public-key certificates. TLS MUST =
be offered as a mechanism to provide non-repudiation of message origin, =
and TLS SHOULD be used to provide non-repudiation of message =
origin.</t>
  </list></t>

  <t>The [protocol] SHOULD resist protocol denial of service =
attacks.</t>

  <t><list style=3D"empty">
    <t>IDXP supports resistance to denial of service (DoS) attacks =
through the use of an appropriate underlying BEEP security profile. =
BEEP peers offering the IDXP profile MUST offer the use of TLS with the =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite, and SHOULD use TLS with =
that cipher suite. To resist DoS attacks it is helpful to discard =
traffic arising from a non-authenticated source. BEEP peers MUST =
support the use of authentication in conjunction with any mechanism =
used to create application-layer tunnels. In particular, the use of =
some form of SASL authentication (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) MUST be offered to provide authentication in the =
use of the TUNNEL profile. See Section 7 of <xref =
target=3D"refs.tunnel" /> for a discussion of security considerations =
in the use of the TUNNEL profile.</t>
  </list></t>

  <t>The [protocol] SHOULD resist malicious duplication of =
messages.</t>

  <t><list style=3D"empty">
    <t>IDXP supports resistance to malicious duplication of messages =
(i.e., replay attacks) through the use of an appropriate underlying =
BEEP security profile. The TLS profile is an example of a security =
profile offering resistance to replay attacks. The TLS profile with the =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a =
mechanism to provide resistance against replay attacks, and TLS with =
this cipher suite SHOULD be used to provide resistance against replay =
attacks. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses =
cipher-block chaining (CBC) to ensure that even if a message is =
duplicated the cipher-text duplicate will produce a very different =
plain-text result. Stronger cipher suites are optional.</t>
  </list></t>

</section>

<section title=3D"IDXP Option Registration Template" =
anchor=3D"option_reg">

<t>When an IDXP option is registered, the following information is =
supplied:</t>
<t>Option Identification: specify the NMTOKEN or the URI that =
authoritatively identifies this option.</t>
<t>Contains: specify the XML content that is contained within the =
"Option" element.</t>
<t>Processing Rules: specify the processing rules associated with the =
option.</t>
<t>Contact Information: specify the postal and electronic contact =
information for the author(s) of the option.</t>

</section>

<section title=3D"Initial Registrations">

  <section anchor=3D"idxp-registration" title=3D"Registration: The IDXP =
Profile">

<t>Profile identification: http://iana.org/beep/transient/idwg/idxp</t>
<t>Messages exchanged during channel creation: "IDXP-Greeting"</t>
<t>Messages starting one-to-one exchanges: "IDXP-Greeting", =
"IDMEF-Message"</t>
<t>Messages in positive replies: "ok"</t>
<t>Messages in negative replies: "error"</t>
<t>Messages in one-to-many exchanges: none</t>
<t>Message syntax: c.f., <xref target=3D"IDXP-syntax" /></t>
<t>Message semantics: c.f., <xref target=3D"IDXP-semantics" /></t>
<t>Contact information: c.f., the "Authors' Addresses" section of this =
memo</t>

  </section>

  <section anchor=3D"port-registration" title=3D"Registration: The =
System (Well-Known) TCP port number for IDXP">
    <t>Protocol Number: TCP</t>
    <t>Message Formats, Types, Opcodes, and Sequences: c.f., <xref =
target=3D"IDXP-syntax" /></t>
    <t>Functions: c.f., <xref target=3D"IDXP-semantics" /></t>
    <t>Use of Broadcast/Multicast: none</t>
    <t>Proposed Name: Intrusion Detection Exchange Protocol</t>
    <t>Short name: idxp</t>
    <t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>

  </section>

  <section anchor=3D"priority_opt_reg" title=3D"Registration: The =
channelPriority Option">
    <t>Option Identification: channelPriority</t>
    <t>Contains: channelPriority (c.f., <xref target=3D"priority_dtd" =
/>)</t>
    <t>Processing Rules: c.f., <xref target=3D"priority_option" /></t>
    <t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
  </section>

  <section anchor=3D"type_opt_reg" title=3D"Registration: The =
streamType Option">
    <t>Option Identification: streamType</t>
    <t>Contains: streamType (c.f., <xref target=3D"st_dtd" />)</t>
    <t>Processing Rules: c.f., <xref target=3D"type_option" /></t>
    <t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
  </section>

</section>

<section title=3D"The DTDs">

  <section anchor=3D"idxp_dtd" title=3D"The IDXP DTD">

<t>The following is the DTD defining the valid elements for the IDXP =
profile</t>
<figure>
<artwork><![CDATA[
  <!--
  DTD for the IDXP Profile, as of 2002-01-08

  Refer to this DTD as:

    <!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC XXXX IDXP v1.0//EN">

    %IDXP;
  -->

  <!-- Includes -->

    <!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN">

    %BEEP;

    <!ENTITY % IDMEF-Message PUBLIC "-//IETF//DTD RFC XXXX IDMEF =
v1.0//EN">

    %IDMEF;

  <!--
    Profile Summary

      BEEP profile http://iana.org/beep/transient/idwg/idxp

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

  <!--
    Entity Definitions

          entity        syntax/reference     example
          =3D=3D=3D=3D=3D=3D        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D     =
=3D=3D=3D=3D=3D=3D=3D
      an authoritative identification
          URI           c.f., [RFC-2396]       http://example.com

      a fully qualified domain name
          FQDN          c.f., [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
    IDXP-Greeting element may contain one or more Option
    sub-elements.
  -->

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

  <!--
    The Option element conveys an IDXP channel option.
    Note that the %LOCS entity is imported from the BEEP Channel
    Management DTD.
  -->

<!ELEMENT Option (ANY)>
<!ATTLIST Option
          internal       NMTOKEN              ""
          external       %URI;                ""
          mustUnderstand (true|false)         "false"
          localize       %LOCS;               "i-default"> =20

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

<!-- End of DTD -->
]]></artwork>
</figure>

  </section>

  <section anchor=3D"priority_dtd" title=3D"The channelPriority Option =
DTD">
<t>The following is the DTD defining the valid elements for the =
channelPriority option</t>
    <figure>
<artwork><![CDATA[
  <!--
  DTD for the channelPriority IDXP option, as of 2002-01-08

  Refer to this DTD as:

    <!ENTITY % IDXP-channelPriority PUBLIC
      "-//IETF//DTD RFC XXXX IDXP-channelPriority v1.0//EN">

    %IDXP-channelPriority;
  -->

  <!--
    Entity Definitions

          entity        syntax/reference     example
          =3D=3D=3D=3D=3D=3D        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D     =
=3D=3D=3D=3D=3D=3D=3D
    a priority number
          PRIORITY      0..2147483647        1
  -->

<!ENTITY % PRIORITY          "CDATA">

<!ELEMENT channelPriority    EMPTY>
<!ATTLIST channelPriority
          priority           %PRIORITY    #REQUIRED>

<!-- End of DTD -->=20
]]></artwork>
    </figure>
  </section>

  <section anchor=3D"st_dtd" title=3D"The streamType DTD">
<t>The following is the DTD defining the valid elements for the =
streamType option</t>
    <figure>
<artwork><![CDATA[
  <!--
  DTD for the streamType IDXP option, as of 2002-01-08

  Refer to this DTD as:

    <!ENTITY % IDXP-streamType PUBLIC
      "-//IETF//DTD RFC XXXX IDXP-streamType v1.0//EN">

    %IDXP-streamType;
  -->

  <!--
    Entity Definitions

          entity        syntax/reference                example
          =3D=3D=3D=3D=3D=3D        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D                =
=3D=3D=3D=3D=3D=3D=3D
     a stream type
          STYPE         (alert | heartbeat | config)    "alert"
  -->

<!ENTITY % STYPE        (alert|heartbeat|config)>

<!ELEMENT streamType    EMPTY>
<!ATTLIST streamType
          type          %STYPE    #REQUIRED>

<!-- End of DTD -->
]]></artwork>
    </figure>

  </section>

</section>

<section title=3D"Reply Codes">
<figure>
<preamble>This section lists the three-digit error codes the IDXP =
profile may generate.</preamble>
<artwork>
code    meaning
=3D=3D=3D=3D    =3D=3D=3D=3D=3D=3D=3D
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)
</artwork>
</figure>

</section>

<section anchor=3D"security" title=3D"Security Considerations">

<t>The IDXP profile is a profile of BEEP. In BEEP, transport security,
user authentication, and data exchange are orthogonal. Refer to Section =
8
of <xref target=3D"RFC3080" /> for a discussion of this. It is strongly =
recommended that those wanting to use the IDXP profile initially =
negotiate a BEEP security profile between the peers that offers the =
required security properties. The TLS profile SHOULD be used to provide =
for transport security. See <xref target=3D"proto-reqs" /> for a =
discussion of how IDXP fulfills the IDWG communications protocol =
requirements.</t>

<t>See <xref target=3D"trust" /> for a discussion of the trust =
model.</t>

  <section anchor=3D"security.tunnel" title=3D"Use of the TUNNEL =
Profile">
  <t>See <xref target=3D"proto-reqs" /> for IDXP's requirements on =
application-layer tunneling and the TUNNEL profile specifically. See =
Section 7 of <xref target=3D"refs.tunnel" /> for a discussion of the =
security considerations inherent in the use of the TUNNEL profile.</t>
  </section>

  <section title=3D"Use of Underlying Security Profiles">
  <t>At present, the TLS profile is the only BEEP security profile =
known to meet all of the requirements set forth in Section 6 of <xref =
target=3D"refs.IDWG-reqs" />. When securing a BEEP session with the TLS =
profile, the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite offers an =
acceptable level of security. See <xref target=3D"proto-reqs" /> for a =
discussion of how IDXP fulfills the IDWG communications requirements =
through the use of an underlying security profile.</t>

  </section>

</section>

</middle>
<back>

<references>

%include.reference.RFC.2396;

%include.reference.RFC.2119;

<reference anchor=3D"refs.IDMEF">
<front>
<title>Intrusion Detection Message Exchange Format Data Model and =
Extensible Markup Language (XML) Document Type Definition</title>
<author initials=3D"D." surname=3D"Curry" fullname=3D"David Curry">
<organization>Merrill Lynch & Co.</organization>
</author>
<author initials=3D"H." surname=3D"Debar" fullname=3D"Herve Debar">
<organization>France Telecom R & D</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>

<!--
<reference anchor=3D"refs.IDMEF" target=3D"draft-ietf-idwg-idmef-xml-03 =
(work in progress)">
<front>
<title>Intrusion Detection Message Exchange Format Data Model and =
Extensible Markup Language (XML) Document Type Definition</title>
<author initials=3D"D." surname=3D"Curry" fullname=3D"David Curry">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"H." surname=3D"Debar" fullname=3D"Herve Debar">
<organization>France Telecom</organization>
</author>
<date day=3D"14" month=3D"February" year=3D"2001" />
</front>
</reference>
-->

<!--
%include.reference.RFC.2246;
-->

%include.reference.RFC.2046;

<!--
<reference anchor=3D"refs.IAP" target=3D"draft-ietf-idwg-iap-03 (work =
in progress)">
<front>
<title>IAP: Intrusion Alert Protocol</title>
<author initials=3D"D." surname=3D"Gupta" fullname=3D"Dipankar Gupta">
<organization abbrev=3D"HP">Hewlett-Packard</organization>
</author>
<date month=3D"December" year=3D"2000" />
</front>
</reference>
-->

%include.reference.RFC.1034;

<!--
%include.reference.RFC.2222;
-->

<!--
<reference anchor=3D"refs.syslog" =
target=3D"draft-ietf-syslog-reliable-03 (work in progress)">
<front>
<title>Reliable Delivery for syslog</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<author initials=3D"M.T." surname=3D"Rose" fullname=3D"Marshall T. =
Rose">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date month=3D"January" year=3D"2001" />
</front>
</reference>
-->

<reference anchor=3D"refs.tunnel">
<front>
<title>The TUNNEL Profile Registration</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>

<!--
<reference anchor=3D"refs.tunnel" =
target=3D"draft-ietf-idwg-beep-tunnel-02 (work in progress)">
<front>
<title>The TUNNEL Profile Registration</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date day=3D"23" month=3D"August" year=3D"2001" />
</front>
</reference>
-->

<!--
<reference anchor=3D"refs.APEX" target=3D"draft-mrose-apex-core-00 =
(work in progress)">
<front>
<title>The Application Exchange Framework</title>
<author initials=3D"M.T." surname=3D"Rose" fullname=3D"Marshall T. =
Rose">
<organization>Invisible Worlds, Inc.</organization>
</author>
<author initials=3D"G." surname=3D"Klyne" fullname=3D"Graham Klyne">
<organization>Content Technologies Limited</organization>
</author>
<author initials=3D"D.H." surname=3D"Crocker" fullname=3D"David H. =
Crocker">
<organization>Brandenburg Consulting</organization>
</author>
<date month=3D"December" year=3D"2000" />
</front>
</reference>
-->

%include.reference.RFC.3080;

<!--
%include.reference.RFC.2629;
-->

<reference anchor=3D"refs.IDWG-reqs">
<front>
<title>Intrusion Detection Message Exchange Requirements</title>
<author initials=3D"M." surname=3D"Wood" fullname=3D"Mark Wood">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"M." surname=3D"Erlinger" fullname=3D"Mike =
Erlinger">
<organization>The Aerospace Corporation</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>

<!--
<reference anchor=3D"refs.IDWG-reqs" =
target=3D"draft-ietf-idwg-requirements-05 (work in progress)">
<front>
<title>Intrusion Detection Message Exchange Requirements</title>
<author initials=3D"M." surname=3D"Wood" fullname=3D"Mark Wood">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"M." surname=3D"Erlinger" fullname=3D"Mike =
Erlinger">
<organization>The Aerospace Corporation</organization>
</author>
<date day=3D"20" month=3D"February" year=3D"2001" />
</front>
</reference>
-->

</references>

<section anchor=3D"IANA" title=3D"IANA Considerations">

  <t>The IANA registers "IDXP" as a standards-track BEEP profile, as =
specified in <xref target=3D"idxp-registration" />. The IANA changes =
the IDXP profile identification to "http://iana.org/beep/IDXP".</t>

  <t>The IANA registers "idxp" as a TCP port number, as specified in =
<xref target=3D"port-registration" /></t>

  <t>The IANA maintains a list of:</t>

  <t><list style=3D"empty">
    <t>IDXP options, c.f., <xref target=3D"option_reg"/>.</t>
  </list></t>

  <t>For this list, the IESG is responsible for assigning a designated =
expert to review the specification prior to the IANA making the =
assignment. As a courtesy to developers of non-standards track IDXP =
options, the mailing list [email-masked] may be =
used to solicit commentary.</t>

  <t>The IANA makes the registrations specified in <xref =
target=3D"priority_opt_reg" /> and <xref target=3D"type_opt_reg" =
/>.</t>

</section>

<section title=3D"History of Significant Changes" anchor=3D"changes">

  <t>The RFC Editor should remove this section and its corresponding =
TOC references prior to publication.</t>

  <section title=3D"Significant Changes Since beep-idxp-03">
    <t>Modified references to Internet-Drafts to contain placeholders =
for their forthcoming RFC numbers.</t>
    <t>Modified IDMEF formal public identifier (FPI) in the IDXP DTD to =
reflect the changes in draft-ietf-idwg-idmef-xml-06.</t>
    <t>Modified IDXP FPI for the IDXP DTD to be more in line with the =
IDMEF FPI.</t>
  </section>

  <section title=3D"Significant Changes Since beep-idxp-02">
    <t>Added IDXP option registration template and registered two =
initial options.</t>
    <t>Indicated that the IANA should change the profile identification =
to "http://iana.org/beep/IDXP" upon adoption of IDXP as a =
standards-track BEEP profile.</t>
    <t>Renamed the "Options" element to "Option" and allowed multiple =
"Option" sub-elements within an "IDXP-Greeting" element. Also added =
attributes to "Option" element.</t>
    <t>Modified IANA profile registration and added TCP port number =
IANA registration.</t>
    <t>Reordered some sections to improve the flow of the document.</t>
    <t>Changed IDXP DTD identifier to be more IETF-like and removed =
URLs from ENTITY declarations.</t>
    <t>Changed IDXP profile URI to fall under the =
"http://iana.org/beep/transient" namespace.</t>
    <t>Modified <xref target=3D"terminology" /> to reference the =
requirements language specified by <xref target=3D"RFC2119" />.</t>
    <t>Eliminated the use of the "endpoint" terminology, in favor of =
"peer".</t>
    <t>Modified figures to make them more understandable.</t>
    <t>Modified Sections 2, 3, and 4 to use the requirements language =
specified by <xref target=3D"RFC2119"/>.</t>
    <t>Indicated that the RFC Editor should remove <xref =
target=3D"changes" /> and its corresponding TOC reference prior to =
publication.</t>
    <t>Fixed several typos.</t>
  </section>

  <section title=3D"Significant Changes Since beep-idxp-01">
    <t>Added new MUST and SHOULD language for use of TLS and TUNNEL =
profiles.</t>
    <t>Modified the "IDXP-Greeting" element to include an "Options" =
sub-element.</t>
    <t>Changed IDXP profile URI.</t>
  </section>

  <section title=3D"Significant Changes Since beep-idxp-00">
    <t>Added <xref target=3D"proto-reqs" />, describing how IDXP =
fulfills the communication protocol requirements of the IDWG.</t>
    <t>Moved IDXP profile registration to <xref target=3D"IANA" />.</t>
    <t>Clarified the role that underlying BEEP security profiles must =
play.</t>
    <t>Clarified how IDMEF messages fit into IDXP.</t>
    <t>Clarified how the IDXP profile channels and BEEP sessions =
interact.</t>
    <t>Made terminology clarifications and changes for overall =
consistency.</t>
  </section>

</section>

<section title=3D"Acknowledgements">
<t>The authors gratefully acknowledge the contributions of Darren New, =
Marshall T. Rose, Roy Pollock, Tim Buchheim, Mike Erlinger, and Paul =
Osterwald.</t>
</section>

</back>
</rfc>

------_=_NextPart_000_01C21276.996E2A90
Content-Type: application/octet-stream;
	name="draft-ietf-idwg-beep-idxp-05.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-idwg-beep-idxp-05.xml"

<?xml version=3D"1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc=3D"yes"?>

<!--

$Header: /cvsroot/idxp-java/idxp-doc/draft-ietf-idwg-beep-idxp.xml,v =
1.3 2002/01/08 19:51:22 bfeinste Exp $

-->

<!-- Remember to increment the document number for each release -->
<rfc ipr=3D"full2026" docName=3D"draft-ietf-idwg-beep-idxp-05">

<front>
<title abbrev=3D"The IDXP">The Intrusion Detection Exchange Protocol =
(IDXP)</title>

<author initials=3D"B.S." surname=3D"Feinstein" fullname=3D"Benjamin S. =
Feinstein">
<organization>Guardent, Inc.</organization>
<address>
<email>[email-masked]</email>
<uri>http://www.guardent.com/</uri>
</address>
</author>

<author initials=3D"G.A." surname=3D"Matthews" fullname=3D"Gregory A. =
Matthews">
<organization>CSC/NASA Ames Research Center</organization>
<address>
<email>[email-masked]</email>
<uri>http://www.nas.nasa.gov/</uri>
</address>
</author>

<author initials=3D"J.C.C." surname=3D"White" fullname=3D"John C. C. =
White">
<organization>MITRE Corporation</organization>
<address>
<email>[email-masked]</email>
<uri>http://www.mitre.org/</uri>
</address>
</author>

<!-- Remember to update the date for each release -->
<date day=3D"12" month=3D"June" year=3D"2002" />
<area>Security</area>
<workgroup>Intrusion Detection Exchange Format</workgroup>
<keyword>intrusion detection</keyword>
<keyword>security</keyword>
<keyword>secure</keyword>
<keyword>secure protocol</keyword>
<keyword>exchange</keyword>
<keyword>intrusion</keyword>
<keyword>IDS</keyword>
<keyword>BEEP</keyword>
<keyword>intrusion detection protocol</keyword>

<abstract>
<t>This memo describes the Intrusion Detection Exchange Protocol =
(IDXP), an application-level protocol for exchanging data between =
intrusion detection entities. IDXP supports mutual-authentication, =
integrity, and confidentiality over a connection-oriented protocol. The =
protocol provides for the exchange of IDMEF messages, unstructured =
text, and binary data. The IDMEF message elements are described in the =
<xref target=3D"refs.IDMEF">Intrusion Detection Message Exchange Format =
(IDMEF)</xref>, a companion document of the Intrusion Detection =
Exchange Format (IDWG) working group of the IETF.</t>
</abstract>
</front>
<middle>

<section anchor=3D"intro" title=3D"Introduction">
<t>IDXP is specified, in part, as a <xref target=3D"RFC3080">Blocks =
Extensible Exchange Protocol (BEEP)</xref> "profile". BEEP is a generic =
application protocol framework for connection-oriented, asynchronous =
interactions. Features such as authentication and confidentiality are =
provided through the use of other BEEP profiles. Accordingly, many =
aspects of IDXP (e.g., confidentiality) are provided within the BEEP =
framework.</t>

  <section anchor=3D"purpose" title=3D"Purpose">
<t>IDXP provides for the exchange of <xref =
target=3D"refs.IDMEF">IDMEF</xref> messages, unstructured text, and =
binary data between intrusion detection entities. Addressing the =
security-sensitive nature of exchanges between intrusion detection =
entities, underlying BEEP security profiles should be used to offer =
IDXP the required set of security properties. See <xref =
target=3D"proto-reqs" /> for a discussion of how IDXP fulfills the IDWG =
communication protocol requirements. See <xref target=3D"security" /> =
for a discussion of security considerations.</t>

<t>IDXP is primarily intended for the exchange of data created by =
intrusion detection entities. <xref target=3D"refs.IDMEF">IDMEF</xref> =
messages should be used for the structured representation of this =
intrusion detection data, although IDXP may be used to exchange =
unstructured text and binary data.</t>
  </section>

  <section title=3D"Profiles">

<t>There are several BEEP profiles discussed, the first of which we =
define in this memo:</t>
<t><list style=3D"empty">
  <t>The IDXP Profile</t>
  <t><xref target=3D"refs.tunnel">The TUNNEL Profile</xref></t>
  <t>The Simple Authentication and Security Layer (SASL) Family of =
Profiles (c.f., Section 4.1 of <xref target=3D"RFC3080" />)</t>
  <t>The TLS Profile (c.f., Section 3.1 of <xref target=3D"RFC3080" =
/>)</t>
</list></t>
  </section>

  <section anchor=3D"terminology" title=3D"Terminology">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this =
document are to be interpreted as described in <xref =
target=3D"RFC2119">RFC 2119</xref>.</t>

<t>Throughout this memo, the terms "analyzer" and "manager" are used in =
the context of the <xref target=3D"refs.IDWG-reqs">Intrusion Detection =
Message Exchange Requirements</xref>. In particular, Section 3.2 of =
<xref target=3D"refs.IDWG-reqs" /> defines the meaning of a collection =
of intrusion detection terms.</t>

<t>The terms "peer", "initiator", "listener", "client", and "server", =
and the
characters "I", "L", "C", and "S" are used in the context of <xref =
target=3D"RFC3080">BEEP</xref>.
 In particular, Section 2.1 of BEEP discusses the roles that a BEEP =
peer may perform.</t>

<t>The term "Document Type Declaration" is abbreviated as "DTD" and is =
defined in Section 2.8 of the
<xref target=3D"W3C.REC-xml">Extensible Markup Language =
(XML)</xref>.</t>

<t>Note that the term "proxy" is specific to IDXP, and does not exist =
in the
context of BEEP. The term "intrusion detection" is abbreviated as =
"ID".</t>
  </section>

</section>

<section anchor=3D"model" title=3D"The Model">

  <section anchor=3D"connect" title=3D"Connection Provisioning">

<t>Intrusion detection entities using IDXP to transfer data are termed =
IDXP peers. Peers can exist only in pairs, and these pairs communicate =
over a single BEEP session with one or more BEEP channels opened for =
transferring data. Peers are either managers or analyzers, as defined =
in Section 3.2 of <xref target=3D"refs.IDWG-reqs" />.</t>

<t> The relationship between analyzers and managers is potentially =
many-to-many. I.e., an analyzer MAY communicate with many managers; =
similarly, a manager MAY communicate with many analyzers. Likewise, the =
relationship between different managers is potentially many-to-many, so =
that a manager MAY receive the alerts sent by a large number of =
analyzers by receiving them through intermediate managers. Analyzers =
MUST NOT establish IDXP exchanges with other analyzers.</t>

<!--
<t>[Rationale: Analyzers may send alert data and receive configuration =
data, and managers may send or receive both alert and configuration =
data.]</t>
-->

<t>An IDXP peer wishing to establish IDXP communications with another =
IDXP peer does so by opening a BEEP channel, which may entail =
initiating a BEEP session. A BEEP security profile offering the =
required security properties SHOULD initially be negotiated (see <xref =
target=3D"security" /> for a discussion of security considerations). =
Following the successful negotiation of the BEEP security profile, IDXP =
greetings are exchanged and connection provisioning proceeds.</t>

<figure>
<preamble>In the following sequence a peer 'Alice' initiates an IDXP =
exchange with the peer 'Bob'.</preamble>
<artwork><![CDATA[
     Alice                                               Bob
       ---------------- xport connect[1] ------------------>
      <-------------------- greeting ---------------------->
      <-------------start security profile[2] ------------->
      <-------------------- greeting ---------------------->
      <------------------ start IDXP[3] ------------------->
]]></artwork>
</figure>
<t>Notes:</t>
<t><list style=3D"hanging">
<t hangText=3D"[1]">'Alice' initiates a transport connection to 'Bob', =
triggering the exchange of BEEP greeting messages.</t>
<t hangText=3D"[2]">both entities negotiate the use of a BEEP security =
profile.</t>
<t hangText=3D"[3]">both entities negotiate the use of the IDXP =
profile.</t>
</list></t>

<t>In between a pair of IDXP peers may be an arbitrary number of =
proxies. A proxy may be necessary for administrative reasons, such as =
running on a firewall to allow restricted access. Another use might be =
one proxy per company department, which forwards data from the analyzer =
peers in the department onto a company-wide manager peer.</t>

<!--

<t>To create an application-layer tunnel that transparently forwards =
data over a chain of proxies, the <xref target=3D"refs.tunnel">TUNNEL =
profile</xref> should be used. See <xref target=3D"refs.tunnel" /> for =
more detail concerning the options available to setup an =
application-layer tunnel, and see . Once a tunnel is established =
between two peers, a new BEEP greeting must be exchanged. At this =
point, a BEEP security profile offering the required security =
properties would be negotiated, followed by negotiation of the IDXP =
profile.</t>

-->

<t>A BEEP tuning profile MAY be used to create an application-layer =
tunnel that transparently forwards data over a chain of proxies. The =
<xref target=3D"refs.tunnel">TUNNEL profile</xref> SHOULD be used for =
this purpose; see <xref target=3D"refs.tunnel" /> for more detail =
concerning the options available to setup an application-layer tunnel =
using TUNNEL, and see <xref target=3D"security.tunnel" /> for a =
discussion of TUNNEL related security considerations. TUNNEL MUST be =
offered as a tuning profile for the creation of application-layer =
tunnels. The TUNNEL profile MUST offer the use of some form of SASL =
authentication (c.f., Section 4.1 of <xref target=3D"RFC3080" />). Once =
a tunnel has been created a BEEP security profile offering the required =
security properties SHOULD be negotiated, followed by negotiation of =
the IDXP profile.</t>

<figure>
<preamble>The following sequence shows how TUNNEL might be used to =
create an application-layer tunnel through which IDXP would operate. A =
peer 'Alice' initiates the creation of a BEEP session using the IDXP =
profile with the entity 'Bob' by first contacting 'proxy1'. In the =
greeting exchange between 'Alice' and 'proxy1', the TUNNEL profile is =
selected, and subsequently the use of the TUNNEL profile is extended to =
reach through 'proxy2' to 'Bob'.</preamble>
<artwork><![CDATA[
Alice              proxy1               proxy2               Bob
  -- xport connect -->
 <---- greeting ----->
  -- start TUNNEL --->
                      - xport connect[1] ->
                     <----- greeting ----->
                      --- start TUNNEL --->
                                           --- xport connect -->
                                          <----- greeting ----->
                                           --- start TUNNEL --->
                                          <----- <ok>[2] ------
                     <------- <ok> -------
 <------ <ok> -------
 <------------------------- greeting -------------------------->
 <------------------ start security profile ------------------->
 <------------------------- greeting -------------------------->
 <------------------------ start IDXP ------------------------->
]]></artwork>
</figure>
<t>Notes:</t>
<t><list style=3D"hanging">
<t hangText=3D"[1]">Instead of immediately acknowledging the request =
from 'Alice' to start TUNNEL, 'proxy1' attempts to establish use of =
TUNNEL with 'proxy2'. 'proxy2' also delays its acknowledgment to =
'proxy1'.</t>
<t hangText=3D"[2]">'Bob' acknowledges the request from 'proxy2' to =
start TUNNEL, and this acknowledgment propagates back to 'Alice' so =
that a TUNNEL application-layer tunnel is established from 'Alice' to =
'Bob'.</t>
</list></t>
  </section>

  <section anchor=3D"transfer" title=3D"Data Transfer">

<t>Between a pair of ID entities communicating over a BEEP session, one =
or more BEEP channels MAY be opened using the IDXP profile. If desired, =
additional BEEP sessions MAY be established to offer additional =
channels using the IDXP profile. However, in most situations additional =
channels using the IDXP profile SHOULD be opened within an existing =
BEEP session, as opposed to provisioning a new BEEP session containing =
the additional channels using the IDXP profile.</t>

<t>Peers assume the role of client or server on a per-channel basis, =
with one acting as the client and the other as the server. A peer's =
role of client or server is determined independent of whether the peer =
assumed the role of initiator or listener during the BEEP session =
establishment. Clients and servers act as sources and sinks, =
respectively, for exchanging data.</t>

<figure>
<preamble>In a simple case, an analyzer peer sends data to a manager =
peer. E.g.,</preamble>
<artwork>
        +----------+                          +----------+
        |          |                          |          |
        |          |****** BEEP session ******|          |
        |          |                          |          |
        | Analyzer | ----- IDXP profile ----> | Manager  |
        | (Client) |                          | (Server) |
        |          |                          |          |
        |          |**************************|          |
        |          |                          |          |
        +----------+                          +----------+
</artwork>
<!--<postamble>Note that the arrowhead for the BEEP channel using the =
IDXP profile points from client to server.</postamble>-->
</figure>

<t>Use of multiple BEEP channels in a BEEP session facilitates =
categorization and prioritization of data sent between IDXP peers. For =
example, a manager 'M1', sending alert data to another manager, 'M2', =
may choose to open a separate channel to exchange different categories =
of alerts. 'M1' would act as the client on each of these channels, and =
manager 'M2' can then process and act on the incoming alerts based on =
their respective channel categorizations. See <xref =
target=3D"idxp_options" /> for more detail on how to incorporate =
categorization and/or prioritization into channel creation.</t>

<figure>
<artwork>
+----------+                                            +----------+
|          |                                            |          |
|          |*************** BEEP session ***************|          |
|          |                                            |          |
|          | -- IDXP profile, network-based alerts ---> |          |
| Manager  |                                            | Manager  |
|   M1     | ---- IDXP profile, host-based alerts ----> |   M2     |
| (Client) |                                            | (Server) |
|          | ------ IDXP profile, other alerts -------> |          |
|          |                                            |          |
|          |********************************************|          |
|          |                                            |          |
+----------+                                            +----------+
</artwork>
</figure>

  </section>

  <section title=3D"Connection Teardown">
  <t>An IDXP peer may choose to close an IDXP channel under many =
different circumstances (e.g., an error in processing has occurred). To =
close a channel, the peer sends a "close" element (c.f., Section =
2.3.1.3 of <xref target=3D"RFC3080" />) on channel zero indicating =
which channel is being closed. An IDXP peer may also choose to close an =
entire BEEP session by sending a "close" element indicating that =
channel zero is to be closed. Section 2.3.1.3 of <xref =
target=3D"RFC3080" /> offers a more complete discussion of the =
circumstances under which a BEEP peer is permitted to close a channel =
and the mechanisms for doing so.</t>
  <t>It is anticipated that due to the overhead of provisioning an =
application-layer tunnel and/or a BEEP security profile, BEEP sessions =
containing IDXP channels will be long-lived. Additionally, the repeated =
overhead of IDXP channel provisioning (i.e., the exchange of IDXP =
greetings) may be avoided by keeping IDXP channels open even while data =
is not actively being exchanged on them. These are recommendations and, =
as such, IDXP peers may choose to close and re-provision BEEP sessions =
and/or IDXP channels as they see fit.</t>
  </section>

  <section anchor=3D"trust" title=3D"Trust Model">
  <t>In our model, trust is placed exclusively in the IDXP peers. =
Proxies are always assumed to be untrustworthy. A BEEP security profile =
is used to establish end-to-end security between pairs of IDXP peers, =
doing away with the need to place trust in any intervening proxies. =
Only after successful negotiation of the underlying security profile =
are IDXP peers to be trusted. Only BEEP security profiles offering at =
least the protections required by Section 5 of <xref =
target=3D"refs.IDWG-reqs" /> should be used to secure a BEEP session =
containing channels using the IDXP profile. See Section 3 of <xref =
target=3D"RFC3080" /> for the registration of the TLS profile, an =
example of a BEEP security profile meeting the requirements of Section =
5 of <xref target=3D"refs.IDWG-reqs" />. See <xref =
target=3D"proto-reqs" /> for a discussion of how IDXP fulfills the IDWG =
communications protocol requirements.</t>
  </section>

</section>

<section anchor=3D"IDXP-profile" title=3D"The IDXP Profile">

  <section title=3D"IDXP Profile Overview">
  <t>The IDXP profile provides a mechanism for exchanging information =
between intrusion detection entities. A BEEP tuning profile MAY be used =
to create an application-layer tunnel that transparently forwards data =
over a chain of proxies. The <xref target=3D"refs.tunnel">TUNNEL =
profile</xref> SHOULD be used for this purpose; see <xref =
target=3D"refs.tunnel" /> for more detail concerning the options =
available to setup an application-layer tunnel using TUNNEL, and see =
<xref target=3D"security.tunnel" /> for a discussion of TUNNEL related =
security considerations. TUNNEL MUST be offered as a tuning profile for =
the creation of application-layer tunnels. The TUNNEL profile MUST =
offer the use of some form of SASL authentication (c.f., Section 4.1 of =
<xref target=3D"RFC3080" />). The TLS profile SHOULD be used to provide =
the required combination of mutual-authentication, integrity, and =
confidentiality for the IDXP profile. For further discussion of =
application-layer tunnel and security issues see <xref =
target=3D"connect" /> and <xref target=3D"security" />.</t>

  <t>The IDXP profile supports several elements of interest:</t>
  <t><list style=3D"symbols">
    <t>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.</t>
    <t>The "Option" element is used to convey optional channel =
parameters between peers during the exchange of "IDXP-Greeting" =
elements. This element is OPTIONAL.</t>
    <t>The "IDMEF-Message" element carries the structured information =
to be exchanged between the peers.</t>
  </list></t>
  </section>

  <section title=3D"IDXP Profile Identification and Initialization">
  <t>The IDXP profile is identified as</t>
  <t><list style=3D"empty">
    <t>http://iana.org/beep/transient/idwg/idxp</t>
  </list></t>
  <t>in the BEEP "profile" element during channel creation.</t>

  <t>During channel creation, "IDXP-Greeting" elements MUST be mutually =
exchanged between the peers. An "IDXP-Greeting" element MAY be =
contained within the corresponding "profile" element in the BEEP =
"start" element. 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. 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 dependent on local provisioning =
of the peer.</t>

  </section>

  <section anchor=3D"IDXP-syntax" title=3D"IDXP Profile Message =
Syntax">
  <t>BEEP messages in the profile MUST have a <xref =
target=3D"RFC2046">MIME Content-Type</xref> of "text/xml", =
"text/plain", or "application/octet-stream". The syntax of the =
individual elements is specified in <xref target=3D"idxp_dtd" /> and =
Section 5 of <xref target=3D"refs.IDMEF" />.</t>
  </section>

  <section anchor=3D"IDXP-semantics" title=3D"IDXP Profile Semantics">
  <t>Each BEEP peer issues the "IDXP-Greeting" element using "MSG" =
messages. The "IDXP-Greeting" element MAY contain one or more "Option" s=
ub-elements, conveying optional channel parameters. Each BEEP peer then =
issues "ok" in "RPY" messages or "error" in "ERR" messages. (See =
Section 2.3.1 of <xref target=3D"RFC3080" /> 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.</t>

    <section title=3D"The IDXP-GREETING Element">
    <t>The "IDXP-Greeting" element serves to identify the 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 MUST include =
the role of the peer on the channel (client or server) and the <xref =
target=3D"RFC2396">Uniform Resource Identifier (URI)</xref> of the =
peer. Additionally, the "IDXP-Greeting" element MAY include the fully =
qualified domain name (c.f., <xref target=3D"RFC1034" />) of the peer. =
One or more "Option" sub-elements MAY be present.</t>

    <t>An "IDXP-Greeting" element MAY be sent by either peer at any =
time. The peer receiving the "IDXP-Greeting" MUST respond with an "ok" =
(indicating acceptance), or an "error" (indicating rejection). A peer's =
identity and role on a channel and any optional channel parameters are, =
in effect, specified by the most recent "IDXP-Greeting" it sent that =
was answered with an "ok".</t>

    <t>An "IDXP-Greeting" may be rejected (with an "error" element) =
under many circumstances. These include, but are not limited to, =
authentication failure, lack of authorization to connect under the =
specified role, the negotiation of an inadequate ciphersuite, or the =
presence of a channel option that must be understood but was =
unrecognized.</t>

    <figure>
      <preamble>For example, a successful creation with an embedded =
"IDXP-Greeting" might look like this:</preamble>
<artwork>
I: MSG 0 10 . 1592 187
I: Content-Type: text/xml
I:
I: &lt;start number=3D'1'&gt;
I:   &lt;profile uri=3D'http://iana.org/beep/transient/idwg/idxp'&gt;
I:     &lt;![CDATA[ &lt;IDXP-Greeting uri=3D'http://example.com/alice'
I:       role=3D'client' /&gt; ]]&gt;
I:   &lt;/profile&gt;
I: &lt;/start&gt;
I: END
L: RPY 0 10 . 1865 91
L: Content-Type: text/xml
L:
L: &lt;profile uri=3D'http://iana.org/beep/transient/idwg/idxp'&gt;
L:   &lt;![CDATA[ &lt;ok /&gt; ]]&gt;
L: &lt;/profile&gt;
L: END
L: MSG 0 11 . 1956 61
L: Content-Type: text/xml
L:
L: &lt;IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server' =
/&gt;
L: END
I: RPY 0 11 . 1779 7
I: Content-Type: text/xml
I:
I: &lt;ok /&gt;
I: END
</artwork>
    </figure>

    <figure>
      <preamble>A creation with an embedded "IDXP-Greeting" that fails =
might look like this:</preamble>
<artwork>
I: MSG 0 10 . 1776 185
I: Content-Type: text/xml
I:
I: &lt;start number=3D'1'&gt;
I:   &lt;profile uri=3D'http://iana.org/beep/transient/idwg/idxp'&gt;
I:     &lt;![CDATA[ &lt;IDXP-Greeting uri=3D'http://example.com/eve'
I:       role=3D'client' /&gt; ]]&gt;
I:   &lt;/profile&gt;
I: &lt;/start&gt;
I: END
L: RPY 0 10 . 1592 182
L: Content-Type: text/xml
L:
L: &lt;profile uri=3D'http://iana.org/beep/transient/idwg/idxp'&gt;
L:   &lt;![CDATA[
L:     &lt;error code=3D'530'&gt;'http://example.com/eve' must first
L:       negotiate the TLS profile&lt;/error&gt; ]]&gt;
L: &lt;/profile&gt;
L: END
</artwork>
    </figure>

    </section>

    <section title=3D"The OPTION Element">
    <t>If present, the "Option" element MUST be contained within an =
"IDXP-Greeting" element. An individual "IDXP-Greeting" element MAY =
contain one or more "Option" sub-elements. Each "Option" element within =
an "IDXP-Greeting" element represents a request to enable an IDXP =
option on the channel being negotiated. See <xref =
target=3D"idxp_options" /> for a complete description of IDXP options =
and the "Option" element.</t>
    </section>

    <section title=3D"The IDMEF-MESSAGE Element">
    <t>The "IDMEF-Message" element carries the information to be =
exchanged between the peers. See Section 5 of <xref =
target=3D"refs.IDMEF" /> for the definition of this element.</t>
    </section>

  </section>

</section>

<section anchor=3D"idxp_options" title=3D"IDXP Options">

<t>IDXP provides a service for the reliable exchange of data between =
intrusion detection entities. Options are used to alter the semantics =
of the service.</t>

<t>The specification of an IDXP option MUST define:</t>

<t><list style=3D"symbols">
  <t>the identity of the option;</t>
  <t>what content, if any, is contained within the option; and,</t>
  <t>the processing rules for the option.</t>
</list></t>

<t>An option registration template (c.f. <xref target=3D"option_reg" =
/>) organizes this information.</t>

<t>An "Option" element is contained within an "IDXP-Greeting" element. =
The "IDXP-Greeting" element itself MAY contain one or more "Option" =
elements. The "Option" element has several attributes and contains =
arbitrary content:</t>

<t><list style=3D"symbols">
  <t>the "internal" and the "external" attributes, exactly one of which =
MUST be present, uniquely identify the option;</t>
  <t>the "mustUnderstand" attribute, whose presence is OPTIONAL and =
whose default value is "false", specifies whether the option, if =
unrecognized, MUST cause an error in processing to occur; and,</t>
  <t>the "localize" attribute, whose presence is OPTIONAL, specifies =
one or more language tokens, each identifying a desirable language tag =
to be used if textual diagnostics are returned to the originator.</t>
</list></t>

<t>The value of the "internal" attribute is the IANA-registered name =
for the option. If the "internal" attribute is not present, then the =
value of the "external" attribute is a URI or URI with a =
fragment-identifier. Note that a relative-URI value is not allowed.</t>

<t>The "mustUnderstand" attribute specifies whether the peer may ignore =
the option if it is unrecognized. If the value of the "mustUnderstand" =
attribute is "true", and if the peer does not recognize the option, =
then an error in processing has occurred. When absent, the value of the =
"mustUnderstand" attribute is defined to be "false".</t>

  <section anchor=3D"priority_option" title=3D"The channelPriority =
Option">
    <t><xref target=3D"priority_opt_reg" /> contains the IDXP option =
registration for the "channelPriority" option. This option contains a =
"channelPriority" element (c.f., <xref target=3D"priority_dtd" />).</t>
    <t>By default, IDXP does not place any requirements on how peers =
should manage multiple IDXP channels. The "channelPriority" option =
provides a way for peers using multiple IDXP channels to request =
relative priorities for each channel. When sending an "IDXP-Greeting" =
element during the provisioning of an IDXP channel, the originating =
peer MAY request that the remote peer assign a priority to the channel =
by including an "Option" element containing a "channelPriority" =
element.</t>
    <t>The "channelPriority" element has one attribute named =
"priority", of range 0..2147483647. This attribute is REQUIRED. Not =
coincidentally, this is the maximum range of possible BEEP channel =
numbers. 0 is defined to represent the highest priority, with relative =
priority decreasing as the "priority" value ascends.</t>

    <figure>
      <preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, an analyzer successfully requests =
that a manager assign a priority to the channel:</preamble>
<artwork>
<![CDATA[
    analyzer                                           manager
       --------------- greeting w/ option ----------------->
      <---------------------- <ok> ------------------------

C: MSG 1 17 . 1984 165
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri=3D'http://example.com/alice' role=3D'client'>
C:   <Option internal=3D'channelPriority'>
C:     <channelPriority priority=3D'0' />
C:   </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 17 . 2001 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
]]></artwork>
    </figure>

    <figure>
      <preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, a manager unsuccessfully requests =
that an analyzer assign a priority to the channel:</preamble>
<artwork>
<![CDATA[
    analyzer                                           manager
      <---------------- greeting w/ option ----------------
       --------------------- <error> ---------------------->

S: MSG 1 17 . 1312 194
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server'>
S:   <Option internal=3D'channelPriority' mustUnderstand=3D'true'>
S:     <channelPriority priority=3D'2147483647' />
S:   </Option>
S: </IDXP-Greeting>
S: END
C: RPY 1 17 . 451 68
C: Content-Type: text/xml
C:
C: <error code=3D'504'>'channelPriority' option was =
unrecognized</error>
C: END
]]></artwork>
    </figure>

  </section>

  <section anchor=3D"type_option" title=3D"The streamType Option">
    <t><xref target=3D"type_opt_reg" /> contains the IDXP option =
registration for the "streamType" option. This option contains a =
"streamType" element (c.f., <xref target=3D"st_dtd" />).</t>
    <t>By default, IDXP provides no explicit method for categorizing =
channels. The "streamType" option provides a way for peers to request =
that a channel be categorized as a particular stream type. When sending =
an "IDXP-Greeting" element during the provisioning of an IDXP channel, =
the originating peer MAY request that the remote peer assign a stream =
type to the channel by including an "Option" element containing a =
"streamType" element.</t>
    <t>The "streamType" element has one attribute named "type", with =
the possible values of "alert", "heartbeat", or "config". This =
attribute is REQUIRED. A value of "alert" indicates that the channel =
should be categorized as being used for the exchange of ID alerts. A =
value of "heartbeat" indicates that the channel should be categorized =
as being used for the exchange of heartbeat messages such as the =
"Heartbeat" element (c.f., Section 5 of <xref target=3D"refs.IDMEF" =
/>). A value of "config" indicates that the channel should be =
categorized as being used for the exchange of configuration =
messages.</t>

    <figure>
      <preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, an analyzer successfully requests =
that a manager assign a stream type to the channel:</preamble>
<artwork>
<![CDATA[
    analyzer                                           manager
       --------------- greeting w/ option ----------------->
      <---------------------- <ok> ------------------------

C: MSG 1 21 . 1963 155
C: Content-Type: text/xml
C:
C: <IDXP-Greeting uri=3D'http://example.com/alice' role=3D'client'>
C:   <Option internal=3D'streamType'>
C:     <streamType type=3D'alert' />
C:   </Option>
C: </IDXP-Greeting>
C: END
S: RPY 1 21 . 1117 7
S: Content-Type: text/xml
S:
S: <ok />
S: END
]]></artwork>
    </figure>

    <figure>
      <preamble>For example, during the exchange of "IDXP-Greeting" =
elements during channel provisioning, a manager unsuccessfully requests =
that an analyzer assign a stream type to the channel:</preamble>
<artwork>
<![CDATA[

    analyzer                                           manager
      <---------------- greeting w/ option ----------------
       --------------------- <error> ---------------------->

S: MSG 1 21 . 1969 176
S: Content-Type: text/xml
S:
S: <IDXP-Greeting uri=3D'http://example.com/bob' role=3D'server'>
S:   <Option internal=3D'streamType' mustUnderstand=3D'true'>
S:     <streamType type=3D'config' />
S:   </Option>
S: </IDXP-Greeting>
S: END
C: RPY 1 21 . 1292 63
C: Content-Type: text/xml
C:
C: <error code=3D'504'>'streamType' option was unrecognized</error>
C: END
]]></artwork>
    </figure>

  </section>

</section>

<section anchor=3D"proto-reqs" title=3D"Fulfillment of IDWG =
Communications Protocol Requirements">

<t>The following lists the communications protocol requirements =
established in Section 5 of <xref target=3D"refs.IDWG-reqs" /> and, for =
each requirement, describes the manner in which it is fulfilled by =
IDXP.</t>

  <t>The [protocol] MUST support reliable transmission of messages.</t>
  <t><list style=3D"empty">
    <t>IDXP operates over BEEP, which operates only over reliable =
connection-oriented transport protocols (e.g., TCP). In addition, BEEP =
peers communicate using a simple request-response protocol, which =
provides end-to-end reliability between peers.</t>
  </list></t>

  <t>The [protocol] MUST support transmission of messages between ID =
components across firewall boundaries without compromising =
security.</t>

  <t><list style=3D"empty">
    <t>The TUNNEL profile <xref target=3D"refs.tunnel" /> MUST be =
offered as an option for creation of application-layer tunnels to allow =
operation across firewalls. The TUNNEL profile SHOULD be used to =
provide an application-layer tunnel. The ability to authenticate hosts =
during the creation of an application-layer tunnel MUST be provided by =
the mechanism chosen to create such tunnels. A firewall may therefore =
be configured to authenticate all hosts attempting to tunnel into the =
protected network. If the TUNNEL profile is used, SASL (c.f., Section =
4.1 of <xref target=3D"RFC3080" />) MUST be offered as a mechanism by =
which hosts can be authenticated.</t>
  </list></t>

  <t>The [protocol] MUST support mutual authentication of the analyzer =
and the manager to each other.</t>

  <t><list style=3D"empty">
    <t>IDXP supports mutual authentication of the peers through the use =
of an appropriate underlying BEEP security profile. The TLS profile and =
members of the SASL family of profiles (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) are examples of security profiles that may be =
used to authenticate the identity of communicating ID components. TLS =
MUST be offered as a mechanism to provide mutual authentication, and =
TLS SHOULD be used to provide mutual authentication.</t>
  </list></t>

  <t>The [protocol] 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.</t>

  <t><list style=3D"empty">
    <t>IDXP supports confidentiality through the use of an appropriate =
underlying BEEP security profile. The TLS profile is an example a =
security profile that offers confidentiality. The TLS profile with the =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a =
mechanism to provide confidentiality, and TLS with this cipher suite =
SHOULD be used to provide confidentiality. The =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses ephemeral =
Diffie-Hellman (DHE) with DSS signatures for key exchange and triple =
DES (3DES) and cipher-block chaining (CBC) for encryption. Stronger =
cipher suites are optional.</t>
  </list></t>

  <t>The [protocol] 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.</t>

  <t><list style=3D"empty">
    <t>IDXP supports message integrity through the use of an =
appropriate underlying BEEP security profile. The TLS profile and =
members of the SASL family of profiles (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) are examples of security profiles that offer =
message integrity. The TLS profile with the =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a =
mechanism to provide integrity, and TLS with this cipher suite SHOULD =
be used to provide integrity. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA =
cipher suite uses the Secure Hash Algorithm (SHA) for integrity =
protection using a keyed message authentication code. Stronger cipher =
suites are optional.</t>
  </list></t>

  <t>The [protocol] SHOULD be able to ensure non-repudiation of the =
origin of IDMEF messages.</t>

  <t><list style=3D"empty">
    <t>IDXP supports non-repudiation of session origin through the use =
of an
appropriate underlying BEEP security profile. An IDXP peer application =
MAY use
IDMEF content and/or BEEP session credentials to provide for =
non-repudiation of
message origin. The TLS profile is an example of a security profile =
that offers
non-repudiation of session origin through the
authentication of public-key certificates. TLS MUST be offered as a =
mechanism to
provide non-repudiation of session origin, and TLS SHOULD be used to =
provide
non-repudiation of session origin.</t>
  </list></t>

  <t>The [protocol] SHOULD resist protocol denial of service =
attacks.</t>

  <t><list style=3D"empty">
    <t>IDXP supports resistance to denial of service (DoS) attacks =
through the use of an appropriate underlying BEEP security profile. =
BEEP peers offering the IDXP profile MUST offer the use of TLS with the =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite, and SHOULD use TLS with =
that cipher suite. To resist DoS attacks it is helpful to discard =
traffic arising from a non-authenticated source. BEEP peers MUST =
support the use of authentication in conjunction with any mechanism =
used to create application-layer tunnels. In particular, the use of =
some form of SASL authentication (c.f., Section 4.1 of <xref =
target=3D"RFC3080" />) MUST be offered to provide authentication in the =
use of the TUNNEL profile. See Section 7 of <xref =
target=3D"refs.tunnel" /> for a discussion of security considerations =
in the use of the TUNNEL profile.</t>
  </list></t>

  <t>The [protocol] SHOULD resist malicious duplication of =
messages.</t>

  <t><list style=3D"empty">
    <t>IDXP supports resistance to malicious duplication of messages =
(i.e., replay attacks) through the use of an appropriate underlying =
BEEP security profile. The TLS profile is an example of a security =
profile offering resistance to replay attacks. The TLS profile with the =
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a =
mechanism to provide resistance against replay attacks, and TLS with =
this cipher suite SHOULD be used to provide resistance against replay =
attacks. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses =
cipher-block chaining (CBC) to ensure that even if a message is =
duplicated the cipher-text duplicate will produce a very different =
plain-text result. Stronger cipher suites are optional.</t>
  </list></t>

</section>

<section title=3D"IDXP Option Registration Template" =
anchor=3D"option_reg">

<t>When an IDXP option is registered, the following information is =
supplied:</t>
<t>Option Identification: specify the NMTOKEN or the URI that =
authoritatively identifies this option.</t>
<t>Contains: specify the XML content that is contained within the =
"Option" element.</t>
<t>Processing Rules: specify the processing rules associated with the =
option.</t>
<t>Contact Information: specify the postal and electronic contact =
information for the author(s) of the option.</t>

</section>

<section title=3D"Initial Registrations">

  <section anchor=3D"idxp-registration" title=3D"Registration: The IDXP =
Profile">

<t>Profile identification: http://iana.org/beep/transient/idwg/idxp</t>
<t>Messages exchanged during channel creation: "IDXP-Greeting"</t>
<t>Messages starting one-to-one exchanges: "IDXP-Greeting", =
"IDMEF-Message"</t>
<t>Messages in positive replies: "ok"</t>
<t>Messages in negative replies: "error"</t>
<t>Messages in one-to-many exchanges: none</t>
<t>Message syntax: c.f., <xref target=3D"IDXP-syntax" /></t>
<t>Message semantics: c.f., <xref target=3D"IDXP-semantics" /></t>
<t>Contact information: c.f., the "Authors' Addresses" section of this =
memo</t>

  </section>

  <section anchor=3D"port-registration" title=3D"Registration: The =
System (Well-Known) TCP port number for IDXP">
    <t>Protocol Number: TCP</t>
    <t>Message Formats, Types, Opcodes, and Sequences: c.f., <xref =
target=3D"IDXP-syntax" /></t>
    <t>Functions: c.f., <xref target=3D"IDXP-semantics" /></t>
    <t>Use of Broadcast/Multicast: none</t>
    <t>Proposed Name: Intrusion Detection Exchange Protocol</t>
    <t>Short name: idxp</t>
    <t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>

  </section>

  <section anchor=3D"priority_opt_reg" title=3D"Registration: The =
channelPriority Option">
    <t>Option Identification: channelPriority</t>
    <t>Contains: channelPriority (c.f., <xref target=3D"priority_dtd" =
/>)</t>
    <t>Processing Rules: c.f., <xref target=3D"priority_option" /></t>
    <t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
  </section>

  <section anchor=3D"type_opt_reg" title=3D"Registration: The =
streamType Option">
    <t>Option Identification: streamType</t>
    <t>Contains: streamType (c.f., <xref target=3D"st_dtd" />)</t>
    <t>Processing Rules: c.f., <xref target=3D"type_option" /></t>
    <t>Contact Information: c.f., the "Authors' Addresses" section of =
this memo</t>
  </section>

</section>

<section title=3D"The DTDs">

  <section anchor=3D"idxp_dtd" title=3D"The IDXP DTD">

<t>The following is the DTD defining the valid elements for the IDXP =
profile</t>
<figure>
<artwork><![CDATA[
  <!--
  DTD for the IDXP Profile, as of 2002-01-08

  Refer to this DTD as:

    <!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC XXXX IDXP v1.0//EN">

    %IDXP;
  -->

  <!-- Includes -->

    <!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN">

    %BEEP;

    <!ENTITY % IDMEF-Message PUBLIC "-//IETF//DTD RFC XXXX IDMEF =
v1.0//EN">

    %IDMEF;

  <!--
    Profile Summary

      BEEP profile http://iana.org/beep/transient/idwg/idxp

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

  <!--
    Entity Definitions

          entity        syntax/reference     example
          =3D=3D=3D=3D=3D=3D        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D     =
=3D=3D=3D=3D=3D=3D=3D
      an authoritative identification
          URI           c.f., [RFC-2396]       http://example.com

      a fully qualified domain name
          FQDN          c.f., [RFC-1034]       www.example.com
  -->

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

  <!--
    The IDXP-Greeting element declares the role and identity of
    the peer issuing it, on a per channel basis. The
    IDXP-Greeting element may contain one or more Option
    sub-elements.
  -->

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

  <!--
    The Option element conveys an IDXP channel option.
    Note that the %LOCS entity is imported from the BEEP Channel
    Management DTD.
  -->

<!ELEMENT Option (ANY)>
<!ATTLIST Option
          internal       NMTOKEN              ""
          external       %URI;                ""
          mustUnderstand (true|false)         "false"
          localize       %LOCS;               "i-default"> =20

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

<!-- End of DTD -->
]]></artwork>
</figure>

  </section>

  <section anchor=3D"priority_dtd" title=3D"The channelPriority Option =
DTD">
<t>The following is the DTD defining the valid elements for the =
channelPriority option</t>
    <figure>
<artwork><![CDATA[
  <!--
  DTD for the channelPriority IDXP option, as of 2002-01-08

  Refer to this DTD as:

    <!ENTITY % IDXP-channelPriority PUBLIC
      "-//IETF//DTD RFC XXXX IDXP-channelPriority v1.0//EN">

    %IDXP-channelPriority;
  -->

  <!--
    Entity Definitions

          entity        syntax/reference     example
          =3D=3D=3D=3D=3D=3D        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D     =
=3D=3D=3D=3D=3D=3D=3D
    a priority number
          PRIORITY      0..2147483647        1
  -->

<!ENTITY % PRIORITY          "CDATA">

<!ELEMENT channelPriority    EMPTY>
<!ATTLIST channelPriority
          priority           %PRIORITY    #REQUIRED>

<!-- End of DTD -->=20
]]></artwork>
    </figure>
  </section>

  <section anchor=3D"st_dtd" title=3D"The streamType DTD">
<t>The following is the DTD defining the valid elements for the =
streamType option</t>
    <figure>
<artwork><![CDATA[
  <!--
  DTD for the streamType IDXP option, as of 2002-01-08

  Refer to this DTD as:

    <!ENTITY % IDXP-streamType PUBLIC
      "-//IETF//DTD RFC XXXX IDXP-streamType v1.0//EN">

    %IDXP-streamType;
  -->

  <!--
    Entity Definitions

          entity        syntax/reference                example
          =3D=3D=3D=3D=3D=3D        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D                =
=3D=3D=3D=3D=3D=3D=3D
     a stream type
          STYPE         (alert | heartbeat | config)    "alert"
  -->

<!ENTITY % STYPE        (alert|heartbeat|config)>

<!ELEMENT streamType    EMPTY>
<!ATTLIST streamType
          type          %STYPE    #REQUIRED>

<!-- End of DTD -->
]]></artwork>
    </figure>

  </section>

</section>

<section title=3D"Reply Codes">
<figure>
<preamble>This section lists the three-digit error codes the IDXP =
profile may generate.</preamble>
<artwork>
code    meaning
=3D=3D=3D=3D    =3D=3D=3D=3D=3D=3D=3D
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)
</artwork>
</figure>

</section>

<section anchor=3D"security" title=3D"Security Considerations">

<t>The IDXP profile is a profile of BEEP. In BEEP, transport security,
user authentication, and data exchange are orthogonal. Refer to Section =
8
of <xref target=3D"RFC3080" /> for a discussion of this. It is strongly =
recommended that those wanting to use the IDXP profile initially =
negotiate a BEEP security profile between the peers that offers the =
required security properties. The TLS profile SHOULD be used to provide =
for transport security. See <xref target=3D"proto-reqs" /> for a =
discussion of how IDXP fulfills the IDWG communications protocol =
requirements.</t>

<t>See <xref target=3D"trust" /> for a discussion of the trust =
model.</t>

  <section anchor=3D"security.tunnel" title=3D"Use of the TUNNEL =
Profile">
  <t>See <xref target=3D"proto-reqs" /> for IDXP's requirements on =
application-layer tunneling and the TUNNEL profile specifically. See =
Section 7 of <xref target=3D"refs.tunnel" /> for a discussion of the =
security considerations inherent in the use of the TUNNEL profile.</t>
  </section>

  <section title=3D"Use of Underlying Security Profiles">
  <t>At present, the TLS profile is the only BEEP security profile =
known to meet all of the requirements set forth in Section 5 of <xref =
target=3D"refs.IDWG-reqs" />. When securing a BEEP session with the TLS =
profile, the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite offers an =
acceptable level of security. See <xref target=3D"proto-reqs" /> for a =
discussion of how IDXP fulfills the IDWG communications requirements =
through the use of an underlying security profile.</t>

  </section>

</section>

</middle>
<back>

<references>

%include.reference.RFC.2396;

%include.reference.RFC.2119;

%include.reference.W3C.REC-xml;

<!-- %include.reference.I-D.ietf-idwg-idmef-xml; -->
<reference anchor=3D"refs.IDMEF">
<front>
<title>Intrusion Detection Message Exchange Format Data Model and =
Extensible Markup Language (XML) Document Type Definition</title>
<author initials=3D"D." surname=3D"Curry" fullname=3D"David Curry">
<organization>Merrill Lynch & Co.</organization>
</author>
<author initials=3D"H." surname=3D"Debar" fullname=3D"Herve Debar">
<organization>France Telecom R & D</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>

<!--
%include.reference.RFC.2246;
-->

%include.reference.RFC.2046;

<!--
<reference anchor=3D"refs.IAP" target=3D"draft-ietf-idwg-iap-03 (work =
in progress)">
<front>
<title>IAP: Intrusion Alert Protocol</title>
<author initials=3D"D." surname=3D"Gupta" fullname=3D"Dipankar Gupta">
<organization abbrev=3D"HP">Hewlett-Packard</organization>
</author>
<date month=3D"December" year=3D"2000" />
</front>
</reference>
-->

%include.reference.RFC.1034;

<!--
%include.reference.RFC.2222;
-->

<!--
<reference anchor=3D"refs.syslog" =
target=3D"draft-ietf-syslog-reliable-03 (work in progress)">
<front>
<title>Reliable Delivery for syslog</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<author initials=3D"M.T." surname=3D"Rose" fullname=3D"Marshall T. =
Rose">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date month=3D"January" year=3D"2001" />
</front>
</reference>
-->

<reference anchor=3D"refs.tunnel">
<front>
<title>The TUNNEL Profile Registration</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>

<!--
<reference anchor=3D"refs.tunnel" =
target=3D"draft-ietf-idwg-beep-tunnel-02 (work in progress)">
<front>
<title>The TUNNEL Profile Registration</title>
<author initials=3D"D." surname=3D"New" fullname=3D"Darren New">
<organization>Invisible Worlds, Inc.</organization>
</author>
<date day=3D"23" month=3D"August" year=3D"2001" />
</front>
</reference>
-->

%include.reference.RFC.3080;

<!--
%include.reference.RFC.2629;
-->

<!-- %include.reference.I-D.ietf-idwg-requirements; -->
<reference anchor=3D"refs.IDWG-reqs">
<front>
<title>Intrusion Detection Message Exchange Requirements</title>
<author initials=3D"M." surname=3D"Wood" fullname=3D"Mark Wood">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"M." surname=3D"Erlinger" fullname=3D"Mike =
Erlinger">
<organization>The Aerospace Corporation</organization>
</author>
<date day=3D"DD" month=3D"Month" year=3D"YYYY" />
</front>
<seriesInfo name=3D"RFC" value=3D"XXXX" />
</reference>

<!--
<reference anchor=3D"refs.IDWG-reqs" =
target=3D"draft-ietf-idwg-requirements-05 (work in progress)">
<front>
<title>Intrusion Detection Message Exchange Requirements</title>
<author initials=3D"M." surname=3D"Wood" fullname=3D"Mark Wood">
<organization abbrev=3D"ISS">Internet Security Systems, =
Inc.</organization>
</author>
<author initials=3D"M." surname=3D"Erlinger" fullname=3D"Mike =
Erlinger">
<organization>The Aerospace Corporation</organization>
</author>
<date day=3D"20" month=3D"February" year=3D"2001" />
</front>
</reference>
-->

</references>

<section anchor=3D"IANA" title=3D"IANA Considerations">

  <t>The IANA registers "IDXP" as a standards-track BEEP profile, as =
specified in <xref target=3D"idxp-registration" />. The IANA changes =
the IDXP profile identification to "http://iana.org/beep/IDXP".</t>

  <t>The IANA registers "idxp" as a TCP port number, as specified in =
<xref target=3D"port-registration" /></t>

  <t>The IANA maintains a list of:</t>

  <t><list style=3D"empty">
    <t>IDXP options, c.f., <xref target=3D"option_reg"/>.</t>
  </list></t>

  <t>For this list, the IESG is responsible for assigning a designated =
expert to review the specification prior to the IANA making the =
assignment. As a courtesy to developers of non-standards track IDXP =
options, the mailing list [email-masked] may be =
used to solicit commentary.</t>

  <t>The IANA makes the registrations specified in <xref =
target=3D"priority_opt_reg" /> and <xref target=3D"type_opt_reg" =
/>.</t>

</section>

<section title=3D"History of Significant Changes" anchor=3D"changes">

  <t>The RFC Editor should remove this section and its corresponding =
TOC references prior to publication.</t>

  <section title=3D"Significant Changes Since beep-idxp-04">
    <t>Fixed two locations where we were referencing the wrong section =
of the requirements document.</t>
    <t>Removed references to IP and the %IP attribute.</t>
    <t>Modified part of Section 5 dealing with non-repudiation of =
message origin.</t>
    <t>Modified Section 1.3 to further refine terminology.</t>
    <t>Replaced all remaining references to "entities" with references =
to "peers".</t>
  </section>

  <section title=3D"Significant Changes Since beep-idxp-03">
    <t>Modified references to Internet-Drafts to contain placeholders =
for their forthcoming RFC numbers.</t>
    <t>Modified IDMEF formal public identifier (FPI) in the IDXP DTD to =
reflect the changes in draft-ietf-idwg-idmef-xml-06.</t>
    <t>Modified IDXP FPI for the IDXP DTD to be more in line with the =
IDMEF FPI.</t>
  </section>

  <section title=3D"Significant Changes Since beep-idxp-02">
    <t>Added IDXP option registration template and registered two =
initial options.</t>
    <t>Indicated that the IANA should change the profile identification =
to "http://iana.org/beep/IDXP" upon adoption of IDXP as a =
standards-track BEEP profile.</t>
    <t>Renamed the "Options" element to "Option" and allowed multiple =
"Option" sub-elements within an "IDXP-Greeting" element. Also added =
attributes to "Option" element.</t>
    <t>Modified IANA profile registration and added TCP port number =
IANA registration.</t>
    <t>Reordered some sections to improve the flow of the document.</t>
    <t>Changed IDXP DTD identifier to be more IETF-like and removed =
URLs from ENTITY declarations.</t>
    <t>Changed IDXP profile URI to fall under the =
"http://iana.org/beep/transient" namespace.</t>
    <t>Modified <xref target=3D"terminology" /> to reference the =
requirements language specified by <xref target=3D"RFC2119" />.</t>
    <t>Eliminated the use of the "endpoint" terminology, in favor of =
"peer".</t>
    <t>Modified figures to make them more understandable.</t>
    <t>Modified Sections 2, 3, and 4 to use the requirements language =
specified by <xref target=3D"RFC2119"/>.</t>
    <t>Indicated that the RFC Editor should remove <xref =
target=3D"changes" /> and its corresponding TOC reference prior to =
publication.</t>
    <t>Fixed several typos.</t>
  </section>

  <section title=3D"Significant Changes Since beep-idxp-01">
    <t>Added new MUST and SHOULD language for use of TLS and TUNNEL =
profiles.</t>
    <t>Modified the "IDXP-Greeting" element to include an "Options" =
sub-element.</t>
    <t>Changed IDXP profile URI.</t>
  </section>

  <section title=3D"Significant Changes Since beep-idxp-00">
    <t>Added <xref target=3D"proto-reqs" />, describing how IDXP =
fulfills the communication protocol requirements of the IDWG.</t>
    <t>Moved IDXP profile registration to <xref target=3D"IANA" />.</t>
    <t>Clarified the role that underlying BEEP security profiles must =
play.</t>
    <t>Clarified how IDMEF messages fit into IDXP.</t>
    <t>Clarified how the IDXP profile channels and BEEP sessions =
interact.</t>
    <t>Made terminology clarifications and changes for overall =
consistency.</t>
  </section>

</section>

<section title=3D"Acknowledgements">
<t>The authors gratefully acknowledge the contributions of Darren New, =
Marshall T. Rose, Roy Pollock, Tim Buchheim, Mike Erlinger, and Paul =
Osterwald.</t>
</section>

</back>
</rfc>

------_=_NextPart_000_01C21276.996E2A90
Content-Type: application/octet-stream;
	name="PGPexch.rtf.asc"
Content-Disposition: attachment;
	filename="PGPexch.rtf.asc"

------_=_NextPart_000_01C21276.996E2A90--

From: [email-masked] (Erik =?iso-8859-1?Q?=C5man?=)
Date: Wed, 12 Jun 2002 21:11:53 +0200
Subject: [xml2rfc] TOC bug with long anchors for sections
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 2002-06-12 11:39 -0700, you wrote:
>yes, that's a fairly serious bug. it turns out the fix is fairly simple, 
>once you spend about 30 minutes looking at the code!
>
>anyway, here's a patch that goes against v1.13 along with the whole thing. 
>let me know if it works out for you...

Yes, it seems to be working now. Thanks a lot.

/Erik

From: [email-masked] (Marshall Rose)
Date: Wed, 12 Jun 2002 11:39:15 -0700
Subject: [xml2rfc] TOC bug with long anchors for sections
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

--Multipart_Wed__12_Jun_2002_11:39:15_-0700_08417c00
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

yes, that's a fairly serious bug. it turns out the fix is fairly simple, once you spend about 30 minutes looking at the code!

anyway, here's a patch that goes against v1.13 along with the whole thing. let me know if it works out for you...

thanks,

/mtr

--Multipart_Wed__12_Jun_2002_11:39:15_-0700_08417c00
Content-Type: application/x-tcl;
 name="xml2rfc.tcl"
Content-Disposition: attachment;
 filename="xml2rfc.tcl"
Content-Transfer-Encoding: base64

--Multipart_Wed__12_Jun_2002_11:39:15_-0700_08417c00
Content-Type: application/octet-stream;
 name="xml2rfc.patch"
Content-Disposition: attachment;
 filename="xml2rfc.patch"
Content-Transfer-Encoding: base64

--Multipart_Wed__12_Jun_2002_11:39:15_-0700_08417c00--

From: [email-masked] (Erik =?iso-8859-1?Q?=C5man?=)
Date: Wed, 12 Jun 2002 17:19:15 +0200
Subject: [xml2rfc] TOC bug with long anchors for sections
Message-ID: <[email-masked]>

Hi,

I'm creating an Internet-Draft in XML and I think that I have encountered a 
small but annoying bug in xml2rfc.tcl causing the table of contents to show 
the wrong page numbers. It seems that when the when the length of the title 
of a section plus the length of the anchor name for the same section is 
more than one line or so, the program overestimates the size of the TOC 
itself. Especially if an RFC or draft contains many such sections, this 
causes all page numbers indicated in the TOC to be incorrect.

I looked a bit at the source code but didn't understand how to correct this 
myself. But then I don't know any Tcl...

The page numbering is off by two pages in the current version of my draft. 
To simplify things, I constructed the test file included below which causes 
1 to be added to all page numbers. When converted to text, this file 
results five pages. Section 1 starts on page 3, but the TOC says 4. The 
"Full Copyright Statement" is on page 6 according to the TOC, but that page 
doesn't even exist.

Sample file triggering the bug:

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc tocompact="no" ?>
<rfc ipr='full2026' docName='draft-test-00'>
   <front>
     <title>Bug in xml2rfc.tcl</title>

     <author initials='F.J.' surname='Flintstone'
       fullname='Frederick Flintstone'>
       <organization>Slate Construction, Inc.</organization>

       <address>
	<postal>
	  <street>660 York Street</street>
	  <street>M/S 40</street>
	  <city>San Francisco</city> <region>CA</region>
	  <code>94110</code>
	  <country>US</country>
	</postal>
	
	<phone>+1 916 555 1234</phone>
	<email>[email-masked]</email>
	<uri>http://example.com/</uri>
       </address>
     </author>

     <date month='June' year='2002' />

     <area>General</area>
     <abstract>
       <t>This memo is written only to test a bug in the conversion program 
xml2rfc.tcl which converts RFCs and Internet-drafts in XML format in 
accordance with <xref target="RFC2629"></xref> to text. The table of 
contents shows incorrect page numbers when section elements use long 
strings as anchors and have long titles. </t>
     </abstract>
   </front>

   <middle>

     <section title="Section name A1">
       <section title="Section name A2">
	<section anchor="this_is_a_section_with_a_very_long_anchor_8" title="This 
section has a long title and a long anchor">
	</section>
       </section>
     </section>

     <section title="Section name B1">
       <section title="Section name B2">
	<section anchor="this_is_a_section_with_a_very_long_anchor_7" title="This 
section has a long title and a long anchor">
	</section>
       </section>
     </section>

     <section title="Section name C1">
       <section title="Section name C2">
	<section anchor="this_is_a_section_with_a_very_long_anchor_6" title="This 
section has a long title and a long anchor">
	</section>
       </section>
     </section>

     <section title="Section name D1">
       <section title="Section name D2">
	<section anchor="this_is_a_section_with_a_very_long_anchor_5" title="This 
section has a long title and a long anchor">
	</section>
       </section>
     </section>

     <section title="Section name E1">
       <section title="Section name E2">
	<section anchor="this_is_a_section_with_a_very_long_anchor_4" title="This 
section has a long title and a long anchor">
	</section>
       </section>
     </section>

     <section title="Section name F1">
       <section title="Section name F2">
	<section anchor="this_is_a_section_with_a_very_long_anchor_3" title="This 
section has a long title and a long anchor">
	</section>
       </section>
     </section>

     <section title="Section name G1">
       <section title="Section name G2">
	<section anchor="this_is_a_section_with_a_very_long_anchor_2" title="This 
section has a long title and a long anchor">
	</section>
       </section>
     </section>

     <section title="Section name H1">
       <section title="Section name H2">
	<section anchor="this_is_a_section_with_a_very_long_anchor_1" title="This 
section has a long title and a long anchor">
	</section>
       </section>
     </section>

   </middle>
   <back>
     <references>
       <reference anchor='RFC2629'>
	<front>
	  <title>Writing I-Ds and RFCs using XML</title>
	  <author initials='M.T.' surname='Rose' fullname='Marshall T. Rose'>
	    <organization>Invisible Worlds, Inc.</organization>
	  </author>
	  <date month='June' year='1999'></date>
	<seriesInfo name='RFC' value='2629' />
	</front>
       </reference>
     </references>
   </back>
</rfc>

From: [email-masked] (Michael Richardson)
Date: Sun, 02 Jun 2002 13:44:50 -0400
Subject: [xml2rfc] working on a remote server
In-Reply-To: Your message of "Fri, 31 May 2002 15:11:35 CDT." <[email-masked]>
Message-ID: <[email-masked]>

>>>>> "Peter" == Peter Saint-Andre <[email-masked]> writes:
    Peter> First off, thanks for xml2rfc, it makes my life much easier!

  I use:

rfc_pg: utils/rfc_pg.c

draft-richardson-ipsec-opportunistic.txt: draft-richardson-ipsec-opportunistic.nr rfc_pg
	perl utils/killtoodeepcontents.pl draft-richardson-ipsec-opportunistic.nr \
	| nroff -ms \
	| sed -e 's/FORMFEED\[Page/        \[Page/' | ./rfc_pg -n5 >draft-richardson-ipsec-opportunistic.txt

draft-richardson-ipsec-opportunistic.nr: src/draft-richardson-ipsec-opportunistic.xml
	XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2nroff $? $@

src/draft-richardson-ipsec-opportunistic.html: src/draft-richardson-ipsec-opportunistic.xml
	XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2html $? $@

in a Makefile.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

From: [email-masked] (Marshall Rose)
Date: Fri, 31 May 2002 16:48:00 -0700
Subject: [xml2rfc] working on a remote server
References: <[email-masked]> <[email-masked]>
Message-ID: <00dd01c208fd$9c893120$a100000a@easyinc>

> --- xml2rfc-1.12/xml2rfc.tcl.orig 2002-03-11 10:27:05.000001000 -0800
> +++ xml2rfc-1.12/xml2rfc.tcl 2002-05-02 14:52:53.000006000 -0700
> @@ -1,7 +1,7 @@
>  #!/bin/sh
>  # the next line restarts using the correct interpreter \
>  if   test ! -z "$DISPLAY"; then exec wish "$0" "$0" "$@"; \
> -elif test ! -z "$1";       then exec tclsh "$0" "$0" "$@"; fi; \
> +elif test ! -z "$1";       then exec tclsh "$0" "$0" "$@"; \
>  else                            echo "usage: $0 filename" >&2; exit 1; fi
>
>
> I was going to check that a bit further, since I thought it must just be
> me, but apparently not.  *wry grin*

right you are!

so, it's my bad...

/mtr

ps: 1.13 comes out tomorrow, mostly bugfixes, including this one.

From: [email-masked] (Russ Allbery)
Date: Fri, 31 May 2002 16:39:54 -0700
Subject: [xml2rfc] working on a remote server
In-Reply-To: <[email-masked]> (Peter Saint-Andre's message of "Fri, 31 May 2002 17:25:30 -0500 (CDT)")
References: <[email-masked]>
Message-ID: <[email-masked]>

Peter Saint-Andre <[email-masked]> writes:

> No, *my* bad. I had those lines commented out. :0

> But Marshall and I figured out that there's an extraneous 'fi;' at the
> end of line 4 in xml2rfc.tcl in version 1.12, so anyone using the script
> may need to edit line 4 to get things working correctly.

Or, to be precise:

--- xml2rfc-1.12/xml2rfc.tcl.orig	2002-03-11 10:27:05.000001000 -0800
+++ xml2rfc-1.12/xml2rfc.tcl	2002-05-02 14:52:53.000006000 -0700
@@ -1,7 +1,7 @@
 #!/bin/sh
 # the next line restarts using the correct interpreter \
 if   test ! -z "$DISPLAY"; then exec wish "$0" "$0" "$@"; \
-elif test ! -z "$1";       then exec tclsh "$0" "$0" "$@"; fi; \
+elif test ! -z "$1";       then exec tclsh "$0" "$0" "$@"; \
 else                            echo "usage: $0 filename" >&2; exit 1; fi

I was going to check that a bit further, since I thought it must just be
me, but apparently not.  *wry grin*

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>