IDXP comments

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey ya'll,

What follows is my response to Glenn's comments on
draft-ietf-idwg-beep-idxp-04.  This response also includes some
material input from Darren New.

Sections from the IDXP draft are prefixed with an 'ID'.  Glenn's
comments are prefixed with an 'GMK'. My commends are prefixed with an
'BSF'.  Sections from RFC 3080 are prefixed with a 'BEEP'.

Another revision of IDXP, draft-ietf-idwg-beep-idxp-05 will be sent
out to this distribution list as soon as I can get xml2rfc to play
nicely.

Cheers,
Ben

- -------------------------

GMK  1.  Section 5 Page 20

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

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

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

BSF  Agreed.  Change made.

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

BSF  Agreed.  Change made.

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

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

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

BSF  I think you have a point here.  One option would be to allow
both IPv4 and
BSF  IPv6 style IP addresses within the optional %IP attribute. 
However, we
BSF  really shouldn't assume that the BEEP session underlying an IDXP
channel is
BSF  running over an IP-based transport (e.g., the RFC 3081 mapping
of BEEP onto
BSF  TCP).  To my knowledge, RFC 3080 does not contain any transport
requirement
BSF  for IP.  Therefore, I've removed any references to IP, and
hence, the %IP
BSF  attribute.

GMK  4. Sec 5 Page 21
ID    The [protocol] SHOULD be able to ensure non-repudiation of the
ID    origin of IDMEF messages.
ID  
ID        IDXP supports non-repudiation of message origin through the
use
ID        of an appropriate underlying BEEP security profile.  The
TLS
ID        profile is an example of a security profile that offers
non-
ID        repudiation of message origin through the authentication of

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

BSF  Point taken.  I've rewritten this section, hopefully more to
Glenn's liking.

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

BSF  A bibliographical reference to the W3C XML Recommendation has
been added
BSF  in Section 1.3 "Terminology".

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

BSF  NMTOKENS is defined in the W3C XML Recommendation.  We assume
BSF  familiarity with XML and the data types defined therein

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

BSF  The semantics of the IDXP Profile are described in Section 3.4
and formally
BSF  specified in the DTD in Section 8.1.  The semantics of the two
IDXP Options
BSF  are described in Section 4.1 and 4.2 and formally specified in
the DTDs in
BSF  Section 8.2 and Section 8.3.  I think this is enough
explanation.

GMK  8. The examples/enumerations are not clear too. E.g.
ID          role       MSG               RPY      ERR
ID          ====       ===               ===      ===
ID          I or L     IDXP-Greeting     ok       error
ID          C          IDMEF-Message     ok       error
GMK  What is "I", "L", "C" above ?
GMK  It is probably necessary to copy the following text from RFC3080
- -
GMK  RFC3080 Page 61
BEEP     o  When a BEEP session is established, the peer that awaits
new
BEEP        connections is acting in the listening role, and the
other peer,
BEEP        which establishes a connection to the listener, is acting
in the
BEEP       initiating role.  In the examples which follow, these are
referred
BEEP        to as "L:" and "I:", respectively.
BEEP  
BEEP     o  A BEEP peer starting an exchange is termed the client;
similarly,
BEEP        the other BEEP peer is termed the server.  In the
examples which
BEEP        follow, these are referred to as "C:" and "S:",
respectively.

BSF  I think a reference to RFC 3080 in Section 1.3 "Terminology"
should
BSF  suffice.  I've added an explicit mention of the "I", "L", "C",
"S"
BSF  shorthand used in RFC 3080 and IDXP.  We assume familiarity with
RFC
BSF  3080.

GMK  9. Regarding tunnelling and communication across firewalls - I
may
GMK  have missed the details - but how does the whole thing work? How
GMK  does one configure an analyzer to send a message to the manager
GMK  via the "proxy" ?
GMK  In  Page 6 Section 2.1
ID   The following sequence shows how TUNNEL might be used to create
an
ID   application-layer tunnel through which IDXP would operate.  An
ID
ID   entity 'Alice' initiates the creation of a BEEP session using
the
ID   IDXP profile with the entity 'Bob' by first contacting 'proxy1'.
 In
ID   the greeting exchange between 'Alice' and 'proxy1', the TUNNEL
ID   profile is selected, and subsequently the use of the TUNNEL
profile
ID   is extended to reach through 'proxy2' to 'Bob'.
GMK  How is the TUNNEL profile "extended" to reach proxy2 and then
onto Bob,
GMK  I apologize for my ignorance ( I am sure that this has been
discussed
GMK  in the WG-meetings I have missed ) but how does Alice know about
proxy1
GMK  and how does proxy1 know about proxy2. Will it need to know all
the
GMK  proxies if, there are any and, if IDXP is used ?

BSF  The IDXP and TUNNEL peers must be configured to understand how
to proxy.
BSF  There have been no methods for automated TUNNEL proxy discovery
proposed as of yet.

GMK  10. Page 12 Section 12.3.1
ID   The "IDXP-Greeting" element serves to identify the analyzer or
ID   manager at one end of the BEEP channel to the analyzer or
manager at
ID   the other end of the channel.  The "IDXP-Greeting" element MUST
ID   include the role of the peer on the channel (client or server)
and
ID   the Uniform Resource Identifier (URI) [1] of the peer. 
Additionally,
GMK  There are 2 peers - it is not very clear which one is being
referred to
GMK  in the above. Maybe we should qualify with "originating-"peer
and
GMK  "receiving-"peer.
GMK  And then in the same paragraph
ID   qualified domain name (c.f., [5]) and IP address of the peer. 
The IP
ID   address chosen SHOULD correspond to the IP address associated
with
ID   the underlying transport protocol carrying the channel.
GMK  It is not clear what exactly is meant by the "IP address
associated
GMK  with the underlying transport ... ".

BSF  I've removed any reference to IP or the %IP attribute, for the
reasons
BSF  stated above.

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

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

GMK  What do those "I:"s signify ?

BSF  See the new Section 1.3.  See comments above.

GMK  Other minor editorial matters:

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

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

BSF  I've changed this to say just "BEEP".

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

BSF  All "entities" have been replaced with "peers".

GMK  Comment that may not be specific to document:

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

GMK  Any comments from the RFC/I-D editor ?

GMK  Glenn

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPQfvfvt7bOk+HH2bEQKA5gCg+apRDSceWSB78JDllQ7xOiv77w8AoKmy
X1BSWP4IwpuBCuz8OtoN1Vsj
=kCcg
-----END PGP SIGNATURE-----