Subject: Working Group Last Call on Req ID

From: Mike Erlinger <[email-masked]>
Date: Thu, 1 Feb 2001 07:25:36 -0800

Hi

This is a WG Last Call for the Requirements Internet Draft.  Hopefully
this time, the message will work :-).

The Last Call goes like this:

    1.  There is a current ID posted:
        draft-ietf-idwg-requirements-04.txt
        That ID was changed to reflect WG consensus on changes made to
        respond 'specifically' to the IESG comments of March 2000.

    2.  A mail message listing the IESG comments and the proposed changes
        was emailed to the WG mail list, 1/30.  If you did not get this
        message, please let us know.

    3.  Any 'specific' comments related to the IESG comments are encouraged.
        Be sure to include the specific changes that you would like to see.

    4.  Glenn Mansfield posted a set of comments last week.  Feel free to
        comment on those comments.  Since Mark Wood is no longer actively
        updating the document, mike erlinger will assume that role and
        thus will respond to Glenn's comments sometime this weekend, but
        of course anyone else should feel free to provide their own
        response.

    5.  The WG Last Call will end on 17 February.  Any comments made 
        during the Last Call period will be handled by 24 February at
        which time an ID will be posted and forwarded to the IESG  with
        a request to make the document an Informational RFC.

    6.  NORMALLY, a WG Last Call responding to IESG concerns is limited to
        SPECIFICALLY those concerns.  This is particularly relevant to this
        document in that the WG has long ago progressed past requirements
        to design and implementation.  Overall, the WG has a much better
        understanding about what it wants to do and thus there are 
        probably numerous requirements that could be added or modified.

        We discussed the following approach with the Security Area Directors
        and they have confirmed it is appropriate and reasonable.  Thus, we, 
        the WG co-chairs have decided (in concert with the ADs):

          1.  to review any and all comments, even those deemed to be outside
              the scope of the IESG comments.

          2.  But actual changes to the document will be restricted to those
              that address specific IESG concerns and those that are deemed
              by the WG co-chairs to clarify the document without
              significantly changing the document as a whole or any
              particular requirement.

          3.  the decision of the WG co-chairs in determining 'clarity'
              versus 'change' will be final.  we feel this is the best 
              way to apply the acquired WG knowledge to the document without
              reopening the whole process - something we are really NOT
              allowed to do after a document has gone to the IESG.
              Obviously, WG comments about any proposed change will greatly
              influence what is changed, so be sure to post your comments.

      If you disagree with this approach, please speak up before 10 February.
      If we cannot agree on a reasonable approach to 'clarification', we will
      have to restrict all comments to responses to specific IESG concerns -
      mail message from Vern Paxson, 17 March 2000.

mike & stuart

-- 
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: "Glenn Mansfield" <[email-masked]>
Date: Fri, 2 Feb 2001 14:17:10 +0900

Mike,
> this time, the message will work :-).
Yes it is working, thanks. Lets hope to get a robust Requirements Doc to the
IESG.
>         updating the document, mike erlinger will assume that role and
I am glad that you are taking up the role.I appreciate this very much. The
general feeling I got was that the document was an orphan.
I personally volunteer to help in any possible way, so feel free to share
the
load - particularly the editing related to
      1. definitions and terminology,
      2. architectural assumptions (e.g.  trust model, privacy, integrity, )
      3. general pruning
>         probably numerous requirements that could be added or modified.
I really like hearing that. We do have a much better understanding of  the
requirements. The document should (MUST ? ) be a more mature document
than what it was a year ago.
>               the scope of the IESG comments.
Since you are calling for "any and all" comments I will resend my comments
on
the documents dated 28/3/2000, for the records.
>               influence what is changed, so be sure to post your comments.
I agree with the approach. At this stage, we can probably target only the
clarity of
content not the content itself.
>       mail message from Vern Paxson, 17 March 2000.

Cheers

Glenn

---

From: "Michael J. Slifcak" <[email-masked]>
Date: Fri, 16 Feb 2001 12:55:50 -0500

The original author's name and company remain the same,
 although the address and telephone number have changed.

A spelling check revealed minor problems.

All these and the changes recommended below are attached in patch format
for easy inspection, modification to suit, and application.
CAUTION: Backup your copy of the draft before applying the patch.
         Some versions of "patch" remove the original file.

Opinions: This document delivers an adequate requirements message.
          It isn't perfect, and that's OK.

          Efforts spent completing the other documents
             should be the focus of this working group.

          What concerns me most is the apparent lack of developing
             consistent names for Events and Alerts.          

Best Regards,
-Mike Slifcak, Internet Security Systems, Inc.

A. #####

Section 3.1, Item 4  Starts the sentence with a vague phrase.

Please change : "We feel that, in addition ..."
           to : "In addition ..."

B. ##### Are there only TCP/IP networks  ?

Under "Architectural Assumptions", I believe specifying a TCP/IP
network for communication is wrong, for reasons identified in
Section 7.6.

Please change : "across a TCP/IP network."
           to : "across a communications mechanism."

C. ##### IDMEF is not a transport

Four of the statements that begin "The IDMEF MUST" in section 6,
"Communication Mechanism Requirements", do not clarify this.

One can add the missing text, which would force minor reformatting.
The new statements would begin :
6.1   The IDMEF communications mechanism MUST ...
6.2   The IDMEF communications mechanism MUST ...
6.3   The IDMEF communications mechanism MUST ...
6.4   The IDMEF communications mechanism MUST ...

D. ##### Tool == Analyzer

The word "tool" appears only in Section 7.10.  As it is not defined,
it introduces confusion in this document. If you substitute "tool"
with "analyzer", the intent is clear.

--- ../draft-ietf-idwg-requirements-04.txt	Tue Jan 30 18:04:18 2001
+++ draft-ietf-idwg-requirements-04.txt	Fri Feb 16 12:42:15 2001
@@ -128,10 +128,10 @@
    different ID systems to be integrated more readily. ID research
    should migrate into commercial products more easily.
 
-4) We feel that, in addition to enabling communication from an ID
-   analyzer to an ID manager, the IDMEF notification system may also
-   enable communication between a variety of IDS components. However,
-   for the remainder of this document, we refer to the communication as
+4) In addition to enabling communication from an ID analyzer to an
+   ID manager, the IDMEF notification system may also enable
+   communication between a variety of IDS components. However, for the
+   remainder of this document, we refer to the communication as
    going from an analyzer to a manager.
 
 All of these reasons suggest that a common format for reporting
@@ -306,7 +306,7 @@
 
 The diagram above illustrates the terms above and their relationships.
 Not every intrusion detection system will have all of these separate
-components exactly as shown. Some ID sytems will combine these
+components exactly as shown. Some ID systems will combine these
 components into a single module; some will have multiple instances
 of these modules.
 
@@ -339,7 +339,7 @@
 
 For the purposes of this document, we assume that the analyzer and
 manager are separate components, and that they are communicating 
-pairwise across a TCP/IP network.  No other form of communication 
+pairwise across a communications mechanism.  No other form of communication 
 between these entities is contemplated in this document, and no other 
 use of IDMEF alerts is considered.
 
@@ -426,7 +426,7 @@
       implementations.
 
 4.2.1 Rationale: Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6 
-      environments are expected to exist within the timeframe of IDMEF 
+      environments are expected to exist within the time frame of IDMEF 
       implementations, the IDMEF specification MUST support IPv6
       and IPv4 environments.
 
@@ -481,7 +481,8 @@
 
 6.  Communications Mechanism Requirements
 
-6.1   The IDMEF MUST support reliable transmission of messages.
+6.1   The IDMEF communications mechanism MUST support reliable transmission
+      of messages.
 
 6.1.1 Rationale: IDS managers often rely on receipt of data from IDS
       analyzers to do their jobs effectively. Since IDS managers will
@@ -489,9 +490,9 @@
       messages be delivered reliably.

-6.2   The IDMEF MUST support transmission of messages between ID 
-      components across firewall boundaries without compromising 
-      security.
+6.2   The IDMEF communications mechanism MUST support transmission of
+      messages between ID components across firewall boundaries without
+      compromising security.
 
 6.2.1 Rationale: Since it is expected that firewalls will often be
       deployed between IDMEF analyzers and their corresponding managers,
@@ -527,8 +528,8 @@
       in manager and analyzer deployment.

-6.3   The IDMEF MUST support mutual authentication of the analyzer and
-      the manager to each other.
+6.3   The IDMEF communications mechanism MUST support mutual authentication
+      of the analyzer and the manager to each other.
 
 6.3.1 Rationale: Since the alert messages are used by a manager to
       direct responses or further investigation related to the security 
@@ -541,9 +542,9 @@
       authentication process might be subverted or misconfigured.

-6.4   The IDMEF 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 
+6.4   The IDMEF communications mechanism 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.
 
 6.4.1 Rationale: IDMEF messages potentially contain extremely sensitive
@@ -612,7 +613,7 @@
       attempt to confuse the receiver. It is desirable that the IDMEF
       communications mechanism resist such message duplication.
 
-6.8.2 Scenario: At attacker penetrates a network being defended by an
+6.8.2 Scenario: An attacker penetrates a network being defended by an
       IDS. The attacker suspects that an IDS is present and quickly
       identifies the encrypted traffic flowing between system components
       as being a possible threat. Even though she cannot read this
@@ -779,17 +780,17 @@

 7.10   The IDMEF message MUST be able to contain the identity of the 
-       implementer and the tool that detected the event.
+       implementer and the analyzer that detected the event.
 
 7.10.1 Rationale: Users might run multiple intrusion detection systems
        to protect their enterprise. This data will help the systems
-       administrator determine which implementer and tool detected the 
+       administrator determine which implementer and analyzer detected the 
        event.
 
-7.10.2 Scenario: Tool X from implementer Y detects a potential
+7.10.2 Scenario: Analyzer X from implementer Y detects a potential
        intrusion. A message is sent reporting that it found a potential 
        break-in with X and Y specified. The operator is therefore able 
-       to include the known capabilities or weaknesses of tool X in his 
+       to include the known capabilities or weaknesses of analyzer X in his 
        decision regarding further action.

@@ -901,7 +902,7 @@
 
 7.16.1 Rationale: The IDMEF cannot assume a certain clock granularity on 
        sensing elements, and so cannot impose any requirements on the 
-       granularity of the event timestamps. Nor can the IDEF assume that
+       granularity of the event timestamps. Nor can the IDMEF assume that
        the clocks being used to timestamp the events have a specified 
        accuracy.
 
@@ -1015,10 +1016,9 @@
 
      Mark Wood
      Internet Security Systems, Inc.
-     6600 Peachtree-Dunwoody Road
-     300 Embassy Row
+     6303 Barfield Road
      Atlanta, GA 30328
-     Phone: +1 (678) 443-6147
+     Phone: +1 (404) 236-2600
      E-mail: [email-masked]