Comments on IDXP

Hi all 

A set of comments on idxp never made it to the mailing list, but did make it
to the IESG.  The IESG has been waiting for our response before proceeding,
we have been waiting for the IESG to act - oh well.  

If you have any comments, please send them to the list.  We would like to
resolve this asap.

thanks
mike



Here are the comments from Glenn:

Date: Sun, 21 Apr 2002 22:19:56 +0900
From: Glenn Mansfield Keeni <[email protected]>
Subject: Re:Last Call: The Intrusion Detection Exchange Protocol (IDXP) to
        Proposed Standard
To: [email protected]
CC: [email protected]


Hi,

Comments on  draft-ietf-idwg-beep-idxp-02 [These should have come
up during the WG-last call. I missed it - apologies for that.]


1.  Section 5 Page 20

=5. Fulfillment of IDWG Communications Protocol Requirements
=
=   The following lists the communications protocol requirements
=   established in Section 6 of [8] and, for each requirement, describes
=   the manner in which it is fulfilled by IDXP.

If reference [8]
=   [8]  Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange
=        Requirements", RFC XXXX, Month YYYY.

points to draft-ietf-idwg-requirements-06.txt in the ietf repository
then  "Section 6 of [8]" should be "Section 5 of [8]". (Section 6 in
draft-ietf-idwg-requirements-06.txt is about "Message Content
Requirements ").

2.  Section 10.2 Page 31
    Same comment as in 1 above

3. In  draft-ietf-idwg-requirements-06.txt there are 4 sets of
requirements
     - General requirements (Section 3)
     - Message Format requirements (Section 4)
     - Communication Protocol requirements (Section 5)
     - Message Content requirements (Section 6)

In the present IDXP draft there is no mention about compliance to
the general requirements.
Are those requirements not applicable to the communications protocol?
The particular requirement that I have in mind is
=3.2
=
=   The IDMEF specification MUST take into account that IDMEF should be
=   able to operate in environments that contain IPv4 and IPv6
=   implementations.

In  section 8.1 (IDXP DTD) the attribute %IP may not be a dotted-quad
for IPv6 addresses.

4. Sec 5 Page 21
=  The [protocol] SHOULD be able to ensure non-repudiation of the
=  origin of IDMEF messages.
=
=      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

The above may be misleading. It is not clear how this will be done.
To my knowledge TLS does not guarantee non-repudiation of message
origin. (It can ensure non repudiation of TLS session origination
- but that does not ensure non-repudiation of message origin.). This
is probably a message content matter and thus beyond the communication
protocol.


5. It would be helpful to have some reference to the term "DTD"
(and, may be XML too) that appears in section 8 onwards.

6. Page 23 Section 6
The context of the terms "Option Identification:", "Contains:", etc.,
are not clear.
What are "NMTOKENS" ?
It would probably be better to have the registration template DTD in
this section/document.

7. Section 8 Page 28
Would be helpful if the semantics of the Data types used in the DTD's
were explained. Presently, for explanations one has to make do with
the comments/examples in the DTD itself.

8. The examples/enumerations are not clear too. E.g.
=         role       MSG               RPY      ERR
=         ====       ===               ===      ===
=         I or L     IDXP-Greeting     ok       error
=         C          IDMEF-Message     ok       error

What is "I", "L", "C" above ?

It is probably necessary to copy the following text from RFC3080 -
RFC3080 Page 61
:   o  When a BEEP session is established, the peer that awaits new
:      connections is acting in the listening role, and the other peer,
:      which establishes a connection to the listener, is acting in the
:     initiating role.  In the examples which follow, these are referred
:      to as "L:" and "I:", respectively.
:
:   o  A BEEP peer starting an exchange is termed the client; similarly,
:      the other BEEP peer is termed the server.  In the examples which
:      follow, these are referred to as "C:" and "S:", respectively.

9. Regarding tunnelling and communication across firewalls - I may
have missed the details - but how does the whole thing work? How
does one configure an analyzer to send a message to the manager
via the "proxy" ?
In  Page 6 Section 2.1
=  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'.
How is the TUNNEL profile "extended" to reach proxy2 and then onto Bob,
I apologize for my ignorance ( I am sure that this has been discussed
in the WG-meetings I have missed ) but how does Alice know about proxy1
and how does proxy1 know about proxy2. Will it need to know all the
proxies if, there are any and, if IDXP is used ?


10. Page 12 Section 12.3.1
=  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 Uniform Resource Identifier (URI) [1] of the peer.  Additionally,
There are 2 peers - it is not very clear which one is being referred to
in the above. Maybe we should qualify with "originating-"peer and
"receiving-"peer.
And then in the same paragraph
=  qualified domain name (c.f., [5]) 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.
It is not clear what exactly is meant by the "IP address associated
with the underlying transport ... ".

11. Page 12 Section 3.4.1
=  For example, a successful creation with an embedded "IDXP-Greeting"
=  might look like this:

=  I: MSG 0 10 . 1592 187
=  I: Content-Type: text/xml

What do those "I:"s signify ?
 

Other minor editorial matters:

12. Page 5 Section 1.3
=  used in the context of BEEP [7].  In particular, Section 2.1 of the
=  BEEP framework memo discusses the roles that a BEEP peer may perform.

A pointer/reference for the "BEEP framework memo" will be helpful.


13. Page 6 Section 2.1
There is a definition of IDXP Peers in
=  Intrusion detection entities using IDXP to transfer data are termed
=  IDXP peers.
But then a paragraph later
=  An ID entity wishing to establish IDXP communications with another ID
=  entity does so by opening a BEEP channel, which may entail initiating
we have the description in terms of "ID entity".
In section 2.2 the text reverts to "peers". For the sake of uniformity
and clarity it would be better to stick to same terminology.

Comment that may not be specific to document:

I understand that some of the referenced documents are expected to
become RFCs in the the (near) future. But, having references to some
future form of the document which does not exist now is problematic
as one doesn't know which is the document that is being referred to.

Any comments from the RFC/I-D editor ?


Glenn







-- 
Mike Erlinger, Professor and Chair Computer Science
www:      http://www.cs.hmc.edu/~mike
email:    [email protected]
smail:    Computer Science Dept., Harvey Mudd College,
          301 E. 12th Street, Claremont, CA, 91711 
          909-621-8912,   FAX: 909-607-8364