Subject: Comments on Glenn's Comments on the Requirements ID

From: Mike Erlinger <[email-masked]>
Date: Mon, 5 Feb 2001 14:43:50 -0800

hi everyone

Glenn's Comments are followed by my comments.  I made some suggestions
for changes, but most i have left open to working group discussion.  I
have noted my comments by XXXX.  I think one of the key issues here is
just how much effort at making changes the WG is willing to provide.
I can only encourage others to add their own comments and suggestions
for changes and indicate my desire that this not be a conversation between
Glenn, Stuart and me.
At the time of the IESG comments on the original draft, very few members
of the WG provided response.  I realize that as a WG we are well past
the Requirements Doc, but it would be nice to get it published as an
Informational RFC.
Stuart has not had time to review all this comments and may disagree with
my comments, but I wanted to get this posted to the WG mailing list to
get YOUR comments.

mike

-------------------------------------------------------------------------
From Glenn
  Attached please find my comments on draft-ietf-idwg-requirements-04.txt.
  I have in general limited myself to concerns raised by IESG.
  The First part of the text refers to "High-level issues" raised by Vern 
  Paxon and the remainder of the text refers to 
  "draft-ietf-idwg-requirements-04.txt"
  My comments are preceded by a "==>". 

Cheers

Glenn

                                 Part-1.
                                 ======
1. High level issues:
   - The document presupposes that "activity", i.e., what gets reported
     via IDEF, directy reflects attacks or at least probable attacks.
     But it seems fundamentally more flexible for IDEF to encompass
     may not reflect an attack, but with additional context available
     more generic events, such as "user login", which by themselves
     to the Analyzer, may.
==> This comment has not been fully incorporated.

XXXX How so?  It seems to me that there are the following sets of things
XXXX defined in section 3.2 and the figure.   Activity is anything of
XXXX interest that a Sensor sees, based on what a sensor is looking for
XXXX it sends an Event to the Analyzer.  In Vern's case of "user login"
XXXX it is Activity, and it is an Event because some Sensor forwards to some
XXXX Analyzer.  The Alert is then "A message from an Analyzer that an
XXXX Event has taken place.
XXXX This all seems pretty logical to me and was worked on by the working
XXXX group and Mark for a very long time.

XXXX What specific changes would you make?

    - The examples ("Scenario:") are quite often unnecessary 
==> This is still a problem.
XXXX How so?   Neither the IESG nor Vern indicated that all Scenarios 
XXXX should be removed.  The changes made were an attempt to include
XXXX only Scenarios that clarified.

XXXX What specific changes would you make?  Namely what Scenarios do
XXXX you want removed and which ones that were removed do you want back?

    - The MUST/SHOULD/etc keywords are generally only used for ....
==> This still remains
XXXX See the introductory sentence of Section 2, the sentence that begins...
XXXX "This is not an IETF standards track document....
XXXX Discussions with the AD and others indicate that the phrase
XXXX "are NOT as in RFC 2119" is all that is needed.

    - There should be explicit discussion of trust models.
==> This is still missing. It needs to be added to the assumptions 
==> section
XXXX The Working Group was asked to specify this when the comments were
XXXX made and before the IESG comments at various meetings.  Neither the WG,
XXXX nor the IESG, had any specific comments to make.  I would argue that
XXXX the trust model is implied by the protocol chosen, e.g. TLS.  As a
XXXX working group we have never specified any more.  

XXXX We could add some words saying that the Trust Model
XXXX is whatever we get, but in my opinion,  since this is a Requirements
XXXX Document, leaving
XXXX the Trust Model unspecified is better.   We could say something like,
XXXX "The Trust Model is not specified as a requirement, but is rather left
XXXX  to the choice of protocol, i.e., a Design Decision"

XXXX What specific changes would you make? 

    - It often isn't clear when requirements are referring to
      specifications or formats; or to products (implementations).
==> I feel that this is still a problem. 
XXXX Where specifically?  Stuart's and other's comments on the IESG comments
XXXX provided  various wording changes that were incorporated in the ID.
XXXX At the time of those proposed wording changes, neither Vern nor the WG
XXXX made any additional comments.

XXXX What specific changes would you make? 

==>
==> I think that we need to get the terminology straightened out.
==> In the text the definitions are unclear and terms [alert/event/
==> attack] are used interchangeably. 
==> My take is :
==>    
==>    Sensors look for Events that may have been caused by Attacks.
==>          [There are well known attacks and enumerations of attacks]
XXXX   I would argue Sensors look for Events.  Events are whatever a
XXXX   Sensor looks for.  It does NOT have to be an attack

==>    Events are detected by a Sensor and reported to an Analyzer 
==>          [ According to the requirements doc. this is not 
==>             within the scope of IDMEF]
XXXX   Events are currently not within the scope.  My view is that
XXXX   Sensors are low level and probably very implementation dependent.

==>    Analyzers send Alerts to Managers.
==>
==>    IDMEF defines the format of the Alert
==>
==>    Corollaries:
==>      o An Alert is not an Event or an Event report 
==>      o An Alert it is not an Attack.     
==>      o IDMEF is not a communication mechanism. It is designed to be
==>        independent of the communication mechanism.
==>    
==>    Addendum:
==>      The IDWG also intends to define a communication mechanism
==>      for exchanging Alerts [IDMEF messages] 
==>
XXXX   I think this last statement is a Big area of concern.  It was not
XXXX   an IESG concern, but was one of mine which I felt reluctant to
XXXX   make major changes.  My view is that when the Req Doc was written
XXXX   IDMEF was both the protocol and the Alert format in many people's
XXXX   mines.  As a WG we were defined to specify the message format, and
XXXX   to look for a protocol solution.  There are separate sections in
XXXX   the Req Doc, but there is
XXXX   some ambiguity in many areas.  I have no problem with this being
XXXX   one of those areas that we try to clarify.
XXXX   I believe this all flows from our name IDEF, see the WG web page
XXXX   for further clarification.

XXXX   IDMEF occurs about a 100 times in the document.  I would propose
XXXX   that we change the Intro to specify that the working group is
XXXX   IDWG, that the message format is IDMEF, and that the protocol is
XXXX   an unspecified name (when the Reg doc was created it was still unclear
XXXX   whether we would use an existing protocol or create a new one.
 
                                   Part-II
                                   =======      
            Intrusion Detection Message Exchange Requirements
                 <draft-ietf-idwg-requirements-04.txt>

1. Abstract

     The purpose of the Intrusion Detection Exchange Format is to
     define data formats and exchange procedures for sharing
==>  The "format" will define exchange procedures too ?
XXXX In this case, the term "Working Group" is missing.  There is a
XXXX fundamental issue here in that the working group was defined with
XXXX the term "Format" in its name and its task can be simplied to defining
XXXX a message format and a protocol.  We are not going to change our
XXXX name, so we need to live with the ambiguity.  See above about
XXXX modifying the use of IDMEF throughout the document.

     information of interest to intrusion detection and response
     systems, and to the management systems which may need to interact
     with them.  This Internet-Draft describes the high-level
     requirements for such communication, including the rationale for
     those requirements where clarification is needed. Scenarios are
     used to illustrate the requirements.
   
[Deleted]
2. Conventions used in this document
     
==> Perhaps we can do away with this section [ s/MUST/must/ etc]
==> I think that was the intent of Vern's mail.

XXXX If you think that was the intent of his email, you should have said
XXXX so when the email was sent, 17 March 2000.  Talking to the AD, this
XXXX was NOT the IESG intent, but rather that we make it clear what our
XXXX MUST, etc., meant.  Requirements documents are generally written with
XXXX must, should, etc.  We just needed to make clear that we were not
XXXX using them in the 'standard' IETF way, which we did.

3.  Introduction

This document defines requirements for the Intrusion Detection Message
Exchange Format (IDMEF), which is the intended work product of the Intrusion
Detection Exchange Format Working Group (IDWG). IDMEF is planned to be
a standard format which automated Intrusion Detection Systems can use
for reporting events which they have deemed to be suspicious or of interest.

==> Note. IDMEF will be used for "reporting events". Compare with
==> diagram below.

XXXX Same issue as above, except change "event" to alert.
XXXX I would proposed doing a grep on 'event' and making sure that it is
XXXX not confused with 'alert'

 ________                   
|        |                   --------
| Data   |_________ ________|        |  __________
| Source |     Activity     |Sensor  | |          |
|________|         |        |________| | Operator |_______
                   |            |      |__________|       |
                  \|/         Event         A             |
              _____V___         |          /|\            |
             |         |        |            \            |
             | Sensor  |__      |         Notification    |
             |_________| Event  |              \         \|/
                   A      |     V_________       \         V
                  /|\     |    |         |       \     Response
                   |       --->| Analyzer|__      |       A
                   |           |         | Alert  |      /|\
                   |           |_________|  |     |       |
                   |                A       |     |       |
                   |               /|\     \|/    |       |
                   |________________|   ____V___  |       |
                       |               |        |_|       |
                       |               | Manager|_________|
                       |               |________|
                       |                  A
                     Security            /|\
     _______________   |  Policy__________|
    |               |  |
    | Administrator |__|
    |_______________|

==> Note: In the figure an Alert is passed from Analyzer to Manager. 
==> Is "Alert" = "event report" ? Uniform terminology will be helpful.
==> "Event" is reported from Sensor to Analyzer in the figure. 

I do not see the problem in the figure above, once the word "event"
is changed to "alert" in the 3. Intro.

==> Perhaps we have strayed here. We are probably concerned only in 
==> the Alert that goes from the Analyzer to the Manager. Do we really 
==> need Administrator, Operator, Security Policy, Notification, 
==> Response ?  We probably do not need those definitions either. 

XXXX To me, these definitions were worked on by the WG over a long period.
XXXX While the IDMEF WG is only concerned with "alerts", in my opinion
XXXX (and to those
XXXX who worked on this) the definitions provide much clarity about the 
XXXX operational model the WG felt reflected reality and the areas where
XXXX the working group would focus at this time.  the figure lays out for
XXXX future working groups what we viewed as our charter. the verbage 
XXXX indicates where the WG will be spending its time.

[Deleted]
3.3  Architectural Assumptions
==> Trust Model needs to be discussed here.
XXXX  See the Intro comments above about Trust Models.  If you have some
XXXX  particular wording, please make it known.  I really believe that the
XXXX  WG left this unspecified on purpose.  The Trust Model will come
XXXX  through the protocol which is unspecified.

==> The format AND the method of communicating it will be standardized ?
XXXX Yes, change IDMEF to IDEF, which is our correct title or to IDWG
XXXX which is our acronym.
XXXX See above about IDMEF usage.  If there is any doubt, the Req Doc is
XXXX meant to lay out requirements for the message format and the protocol.

[Deleted]
3.4  Organization of this document.

Besides this requirements document, the IDWG working group should
produce two other documents. The first should describe a data format or
language for exchanging information about suspicious events.  In this
document, we refer to that as the "data-format specification".  The
second document should identify existing IETF protocols that are best

==> identify "existing" IETF protocols ?  
XXXX like all working groups we agreed to look at existing protocols
XXXX rather than to blindly invent new ones.  We did look at SNMP, HTTP,
XXXX and now BEEP.  So whatever protocol we choose, we will have evaluated
XXXX the protocol in terms of existing IETF protocols.  The fact that we
XXXX create a new protocol, IAP, is a design decision that we made based
XXXX on evaluation of existing protocols - why we need the protocol info
XXXX in the Req Doc.   I think your comment is more relevant
XXXX towards the IAP document, which has none of the justification for
XXXX creating a new document.  That was always on Dipankar's list, but
XXXX is not reflected in the current version of IAP.

used for conveying the data so formatted, and explain how to package
this data in those existing formats. We refer to this as the
"communication specification".

[DELETED]
3.5 Document Impact on IDMEF Designs

It is expected that proposed IDMEF designs will, at a minimum, satisfy
the requirements expressed in this document. However, this document will
be used only as one of many criteria in the evaluation of various IDMEF
designs. It is recognized that the working group may use additional
metrics to evaluate competing IDMEF designs.

==> Is 3.5 required?
XXXX Yes, it is.  I think it is very clear wording that the Requirements
XXXX Doc is not the only thing that will drive WG decisions.  For example,
XXXX the WG might compare the problems of implementation or the desires
XXXX of the WG in determining a choice.  The Req Doc is just one factor
XXXX in the decision process of the WG.

4.  General Requirements

4.1   The IDMEF SHALL reference and use previously published RFCs where
      possible.

4.1.1 Rationale: The IETF has already completed a great deal of research
      and work into the areas of networks and security. In the interest
      of time, it is smart to use already defined and accepted
      standards.  
==> Do we need 4.1.1 ?
XXXX Not an IESG issue, I don't think it matters one way or the other that
XXXX it is there.  I would argue that it was an additional plug for
XXXX existing protocols, something I personally supported.

4.2   The IDMEF specification MUST take into account that IDMEF should be
      able to operate in environments that contain IPv4 and IPv6
      implementations.

4.2.1 Rationale: Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6 
      environments are expected to exist within the timeframe of IDMEF 
      implementations, the IDMEF specification MUST support IPv6
      and IPv4 environments.
==> Do we need this? 4.2.1 can very well merged with 4.2.
XXXX  I do not see the merging issue.  IPv6 is a protocol whose time has
XXXX  arrived, but may or may not be coming.  This requirement was put in
XXXX  at the request of people outside the WG.  I cannot remember if it
XXXX  was the AD or someone else.  But we were requested to explicitly
XXXX  indicate support for IPv6 and the transition to IPv6.
XXXX  I believe that the current wording was proposed to the WG and Vern
XXXX  in an email from Mark and based on some things Stuart had to say.
XXXX  The rationale is there for people outside the IETF who do not 
XXXX  understand what is going on in terms of new IP , e.g., DARPA
XXXX  researchers and commercial vendors.

5. Message Format

The IDMEF message format is intended to be independent of the IDMEF
communications mechanism. It should be possible to use a completely
different transport mechanism without changing the IDMEF format. The
goal behind this requirement is to ensure a clean separation between
semantics and communication mechanisms. Obviously the IDMEF communication
mechanism is recommended.
==> Do we need to state the obvious ?
XXXX Yes, i believe that the last sentence was taken from one of IESG
XXXX or a response to them comments.

6.  Communications Mechanism Requirements
==> Do we need this section? 
==> The Format is unrelated to the communication mechanism. If our 
==> concern is the Format only then we do not need this section.
XXXX Again I think you are using "Format" to literally.  It is generally
XXXX true that Format and IDMEF are being used to indicate both the message
XXXX structure and the communication protocol.  In some ways, it is our
XXXX subsequent use of the terms in WG communications that changes their
XXXX meaning.  At the time of the Req Doc we were chartered to create
XXXX a format and choose a protocol.  Section 6 gives us an set of
XXXX requirements to consider in making a protocol decision.

XXXX I believe the changes above to the usage of IDMEF would help clarify
XXXX this.

6.1   The IDMEF MUST support reliable transmission of messages.
==>   IDMEF communications mechanism MUST support ....
XXXX  Would be cleaned up in the IDMEF clean up.

6.1.1 Rationale: IDS managers often rely on receipt of data from IDS
      analyzers to do their jobs effectively. Since IDS managers will
      rely on IDMEF messages for this purpose, it is important that IDMEF
      messages be delivered reliably.

6.2   The IDMEF MUST support transmission of messages between ID 
==>   IDMEF communications mechanism MUST support ....
      components across firewall boundaries without compromising 
      security.
XXXX  Would be cleaned up in the IDMEF clean up.

6.2.1 Rationale: Since it is expected that firewalls will often be
      deployed between IDMEF analyzers and their corresponding managers,
      the ability to send IDMEF messages through firewalls is necessary.
==> Do we need the following ? [I am not sure that is correct.] 
XXXX  I do not see the concern, nor what wording you would like to have
XXXX  nor what you think is incorrect (e.g., the desire to not make
XXXX  changes in the firewall or the POST method or ?).

      Setting up this communication MUST NOT require changes to the
      intervening firewall(s) that weaken the security of the protected
      network(s). Nor SHOULD this be achieved by conflating IDMEF
      messages with other kinds of traffic (e.g., by overloading the
      HTTP POST method) since that would make it difficult for an
      organization to apply separate policies to IDMEF traffic and other
      kinds of traffic.

6.3   The IDMEF MUST support mutual authentication of the analyzer and
==>   IDMEF communications mechanism MUST support ....
      the manager to each other.
XXXX  Would be cleaned up in the IDMEF clean up.

6.3.1 Rationale: Since the alert messages are used by a manager to
      direct responses or further investigation related to the security 
      of an enterprise network, it is important that the receiver have
      confidence in the identity of the sender and that the sender have
      confidence in the identity of the receiver. This is peer-to-peer 
      authentication of each party to the other. It MUST NOT be 
      based on authentication of the underlying communications 
      mechanism, for example, because of the risk that this 
      authentication process might be subverted or misconfigured.
==> IESG comments not addressed.
     [This appears to rule out use of IPSEC, which is "authentication 
     of the underlying communications mechanism".  That seems ill-advised, 
     so this should be clarified. ]

XXXX I thought that this wording had changed.  It appears not to have,
XXXX nor do I see the alternate wording that was proposed
XXXX What would you propose?
XXXX In my opinion a single word would suffice:  'solely'
XXXX "It MUST NOT be based 'solely' on authentication....

6.4   The IDMEF MUST support confidentiality of the message content 
==>   IDMEF communications mechanism MUST support ....
XXXX  Would be cleaned up in the IDMEF clean up.

6.4.1 Rationale: IDMEF messages potentially contain extremely sensitive
      information (such as passwords) and would be of great interest to 
      an intruder. Since it is likely some of these messages will be 
      transmitted across uncontrolled network segments, it is important 
      that the content be shielded. Furthermore, since the legal 
      environment for encryption technologies is extremely varied and 
      changes often, it is important that the design selected be capable 
      of supporting a number of different encryption options and be 
      adaptable by the user to a variety of environments.

6.5   The IDMEF MUST ensure the integrity of the message content. The
==>   IDMEF communications mechanism MUST support ....
XXXX  Would be cleaned up in the IDMEF clean up.
==> IESG concern "Won't the confidentiality requirement already take 
    care of this?" Is this addressed ?
XXXX  In security circles confidentiality and integrity are different.
XXXX  we are maintaining that view.

6.6   The IDMEF communications mechanism SHOULD be able to ensure non-
      repudiation of the origin of IDMEF messages.
==>   "nonrepudiation of IDMEF messages" should do.
XXXX  Either way is fine with me.  

6.6.1 Rationale: Given that sensitive security information is being
      exchanged with the IDMEF, it is important that the humans operating
      the system are able to associate messages with the originating
      IDMEF entity.
==> The explanation here is not clear enough. Something like "It is important 
    to prevent someone who sent a message from later claiming that he/she
    didn't" would be better ?
XXXX Since we are dealing with Analyzers and not humans, I like the current
XXXX wording.  There was no human in our figure and I hate to bring one in
XXXX now

6.8   The IDMEF communications mechanism SHOULD resist malicious 
      duplication of messages.

==> Is this is a "SHOULD" ? Should it be a "MUST"?
XXXX  I would argue that this is a change of a Requirement and out of the
XXXX  scope of the WG Last Call.  If we change one Requirement, we should
XXXX  review them all, which I would argue against.

7.1    There are many different types of intrusion detection systems,
       such as those based on: signatures, anomalies, correlation,
       network monitoring, host monitoring, or application monitoring.
       The IDMEF design MUST strive to accommodate these diverse
       approaches by concentrating on conveying *what* an IDS has
       detected, rather than *how* it detected it.

7.1.1  Rationale: There are many types of intrusion detection systems 
       that analyze a variety of data sources. Some are profile based
       and operate on log files, attack signatures etc. Others are 
       anomaly based and define normal behavior and detect deviations 
       from the established baseline. Each of these systems report 
       different data that, in part, depends on their intrusion 
       detection methodology. All MUST be supported by this standard.
==> 7.1.1 just repeats 7.1. They are better merged. 
XXXX  Disagree, one is a requirement, the other a rationale for that
XXXX  requirement.  I think that as in almost all the Requirement/Rationale
XXXX  pairs there is some repetition, I can live with this.
XXXX  What wording would you propose?

7.2    The content of IDMEF messages MUST contain the identified name of
       the event if it is known. This name MUST be drawn from a 
==>  Do we want to know the name of the event ? 
XXXX  Yes 
==>  Perhaps we want to know the name of the attack ? 
XXXX  Events are not attacks, they are what Sensor look for.

       standardized list of events or will be an implementation-specific 
       name if the event identity has not yet been standardized. It is 
       not known how this list will be defined or updated, although 
       requirements on the creation of this list are presented in the 
       next section of this document.

7.2.1  Rationale: Given that this document presents requirements on 
       standardizing ID message formats so that an ID manager is able to
       receive alerts from analyzers from multiple implementations, it 
       is important that the manager understand the semantics of the 
       reported events. There is, therefore, a need to identify known 
       events and store information concerning their methods and 
       possible fixes to these events. Some events are well known and 
       this recognition can help the operator.
==> The above is not very clear. The "semantics" of reported
==> events and the attack name are directly related? 
XXXX Yes, some events and attack  names are well known.  this is not
XXXX always true.  

7.2.2  Scenario: Intruder launches an attack that is detected by two 
       different analyzers from two distinct implementations. Both 
       report the same event identity to the ID manager, even though the 
       algorithms used to detect the attack by each analyzer might have 
       been different.
==> The term "event identity" is confusing. 
XXXX  the term "event identity" is used in a couple of places to refer
XXXX  to events that are well known and have a name/identity.  i do
XXXX  not see the confusion.  what term would you replace it with?

7.3    The IDMEF message design MUST include information, which the
       sender should provide, that allows a receiver to locate background
       information on the kind of event that is being reported in the
       alert. 
==> This is unclear. 
==> Are we saying that there will be [1] an (event) attack name 
==> and [2] a pointer to background information about the event ?
==> That does not sound real.
XXXX This was debated forever by the WG, this is the idea of having a
XXXX url in the Alert that allows the manager to lookup more information.
XXXX Whether that url is to the Sensor, Analyzer, or somewhere else is
XXXX NOT a working group issue, only that the message format support such
XXXX information.

XXXX So as a requirement this is not going away, what wording would you
XXXX recommend to make it more clear.  I think the clarity info is in
XXXX the Rationale, exactly what Rationales are for. 

7.3.1  Rationale: This information is used by administrators to report 
       and fix problems.
7.3.2  Scenario: Attacker performs a well-known attack. A reference to a
       URL to background information on the attack is included in the
       IDMEF message. The operator uses this information to initiate
       repairs on the vulnerable system.

7.4    The IDMEF message MUST be able to reference additional detailed 
       data related to this specific underlying event. It is OPTIONAL
       for implementations to use this field. No requirements are placed
       on the format or content of this field. It is expected that this
       will be defined and described by the implementer.
==> If it will be decided by the implementer then interoperability will
==> be broken. Unless sender and receiver are from the same implementer.
==> I think what we want to say is that the additional data field will 
==> have an associated additional data-type field and a few well known
==> data-types [e.g. URLs] will be optionally supported. 
XXXX  Do not see the problem.  We needed such a field, but its use
XXXX  is optional.  Again, a hotly discussed item at WG meetings.  I
XXXX  view it as a requirement that Supports interoperability, i.e.,
XXXX  the message format will support the field, but if a vendor does
XXXX  not have the info, they can still interoperate.
XXXX  Again, since this is a requirement I would be reluctant to make
XXXX  any change other than clarification.

7.4.1  Rationale: Operators might want more information on specifics of 
       an event. This field, if filled in by the analyzer, MAY point
       to additional or more detailed information about the event.
==> It is the Sender who has the information which it thinks will be of 
==> use to the receiver. 
XXXX  Yes, agree.  The analyzer is the sender.

[DELETED]
7.6    The IDMEF message MUST support the representation of different
       types of device addresses.

==> That is a new term that has appeared - "devices". What is a device?
==> a sensor, an analyzer , a manager ? If we need a new term it should 
==> be defined in the terminology section.
XXXX  I think it is overkill.  I would rather say something in the Rationale
XXXX  about a device being anything.  I remember a discussion that devices
XXXX  are not limited to network devices, so the Rationale might include
XXXX  new wording like, "For this Requirement, a device is anything that is
XXXX  involved in intrusion detection." and continue with the rest of
XXXX  the Rationale

7.7    The IDMEF message MUST contain an indication of the possible
       impact of this event on the target. The value of this field MUST 
       be drawn from a standardized list of values.

7.7.1  Rationale: Information concerning the possible impact of the
       event on the target system provides an indication of what the
       intruder is attempting to do and is critical data for the
       operator to perform damage assessment. Not all systems will be 
       able to determine this, but it is important data to transmit for 
       those systems that can.
==> IESG concern on properties of the standardized list of values
==> not addressed.
XXXX  Yes, that was missed in one sense.  But as Stuart said, this is
XXXX  a Requirements Document.  Vern's response indicated concern for
XXXX  properties of the list, maintenance, etc.  Our response is that
XXXX  it is NOT a concern for this document, we are just requiring a
XXXX  field in the message format.  
XXXX  Maybe the Rationale should include some wording to the effect that
XXXX  we are making NO requirements on the list itself, only a requirement
XXXX  that the message format contain such a field.

7.8    The IDMEF message MUST provide information about the automatic
       actions taken by the analyzer in response to the event (if any).
==> Presupposes that there is no (non-automatic) manual action and, if 
==> there is any, those are not of interest!
XXXX  I do not see that logic.  in my opinion it says that if there was
XXXX  an automatic response, put it in the field in the message.
XXXX  I would make NO change.

[DELETED]

7.10   The IDMEF message MUST be able to contain the identity of the 
       implementer and the tool that detected the event.

==> IESG concern regarding properties of the implementer identity are
==> not addressed.
XXXX  Nor do I think they should be in this document.  This is a ReqDoc,
XXXX  a design doc.  We just want the field.  Designs will specify the
XXXX  contents of the field.

[DELETED]
7.12   The IDMEF message MUST be uniquely identifiable in that it can be
       distinguished from other IDMEF messages.
==> IESG concern regarding properties of the degree of uniqueness is 
==> not addressed. [ Should be fairly straight]
XXXX  I would argue that this also is a design decision.  We could put
XXXX  some limitations on the range, but I would be reluctant to do so.
XXXX  There may be '8 bit' sensor/analyzers out there and I would not
XXXX  want to require in this Document an '64' bit identifier.

[DELETED]
7.13   The IDMEF MUST support reporting alert creation date and time in 
       each event. The IDMEF MAY support reporting the date and time the
       event began in addition to the date and time the alert was
       created.
==> The IESG concern was about having an "event onset" time. Which has 
==> got included. But "event detection" time has got dropped. Is this
==> intentional? All three [onset, detection, reporting] are significant 
==> IMHO.

XXXX  See below.

7.13.1 Rationale: Time is important from both a reporting and
       correlation point of view. Event detection time might differ from 
       the alert creation time as it might take some time to actually 
       generate the alert message given that an event has been detected. 
       If the sensing element can determine the time the event occurred 
       it is strongly encouraged to place that information in the alert 
       message as well.
==> The reference to "detection time" is not appropriate as that has been
==> dropped in 7.13.
XXXX  Agree.  This is the whole time issue revisited. I am not sure how
XXXX  to change the requirement.  Any changes need to NOT significantly
XXXX  change the requirement even if we have a better understanding of
XXXX  of what we would want to say.

XXXX  So how would you reword it?

[DELETED]

7.17   The IDMEF message MUST support an extension mechanism used by
       implementers to define implementation-specific data. The use of
       this mechanism by the implementer is OPTIONAL. This data contains 
       implementation-specific information determined by each
       implementer. The implementer MUST indicate how to interpret these 
       extensions, although there are no specific requirements place on
       how implementers describe their implementation-specific
       extensions.
==> This is pretty fuzzy. There is no indication of HOW the implementer 
==> will indicate how the data will be interpreted. 
==> Are we talking of (1) an indication of how the data will be 
==> interpreted and   (2) the data

XXXX I believe this issue goes beyond this document.  the WG is not trying
XXXX to indicate how additional data may be interpreted but rather only the
XXXX requirement that an extension method is available.  it is a design issue
XXXX on how that might happen.  I believe this is the same response that
XXXX was given on the mail list by either Stuart of Mark.

8. Alert Identifiers and the Alert Identifier Definition Process
==> Troublesome Terminology! This "Alert Identifier" term is VERY 
==> confusing. Are we talking about "Attack Identifier" ? 
XXXX Don't see the issue.  Alerts are NOT exclusively Attacks.  For example
XXXX courts have decided that Port Scans are NOT attacks, but I sure want
XXXX to know about them. 
     
==> Question: do we need this section for IDMEF ? 
XXXX Yes.

-- 
mike erlinger, professor computer science
www:      http://www.cs.hmc.edu/~mike
email:    [email-masked]
smail:    computer science dept harvey mudd college,
          301 E. 12th Street, Claremont, CA, 91711 
909-621-8912,   FAX: 909-621-8465

---

From: Paul Sangree <[email-masked]>
Date: Tue, 06 Feb 2001 09:18:23 -0600

My two cents are below.
Paul

>XXXX  So how would you reword it?
The requirement seems clear enough, but the rationale is confusing.  Using the
definitions for 'event' and 'alert' that are used elsewhere in the requirements
document and in the data model, 'events' are sent by the sensor to the
Analyzer, and 'alerts' are sent by the Analyzer to the Manager.  Therefore the
requirement's phrase "alert creation date and time" means the time that the
alert was created by the Analyzer, whereas "the date and time the event began"
means the time the sensor first detected the activity that it is reporting in
the event.  So I don't see any problem with the current wording of the
requirement part (7.13).  However, the rationale (7.13.1) uses different
terminology which obfuscates  the requirement.  How about rewording the second
sentence in the rationale as "Event onset time might differ from the alert
creation time because it might take some time for the sensor to accumulate
information about a monitored activity before generating the event, and
additional time for the Analyzer to receive the event and create the Alert."  
I would drop the last sentence "If the sensing element can ..." from the
rationale, since it is really just restating the requirement rather stating a
rationale for the requirement.  I would replace it with something like "The
event onset time is therefore more representative of the actual time that the
reported activity began than is the alert creation time."  Would this satisfy
everyone?

Paul Sangree

---

From: Mike Erlinger <[email-masked]>
Date: Tue, 6 Feb 2001 08:53:28 -0800

> reported activity began than is the alert creation time."  Would this satisfy

It would me.  Two things are playing on my need for help on this one.
First, it deals with time which is a never ending discussion....
Second, it was towards the end of the issues and i was losing it....
I think your changes clarify what the requirement says and what we are
really trying to say.

thanks
mike