Subject: RE: Resolution of Comments on Last Call of IDMEF

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 12 Dec 2001 19:58:06 -0500

Hello Glenn et. al.;

My comments interspersed below...

On Monday, December 10, 2001 8:49 PM, Glenn Mansfield Keeni 
[SMTP:[email-masked]] wrote:
> My coments are inline:
> [The parts about which I do not have further comments are deleted.]
>
> >  Glenn> 2. sec 4.4.7 NTP timestamps. the definitions is not very clear.
> >
> >  Glenn> textual representation of two 32-bit numbers separated by a '.'.
> >  Glenn> That is what we want - right ?
> >
> >  --------------
> >  Dave
> >
> >  No, two hexadecimal representations (not "textual," that's too vague). I
> >  think the sentence that's there is pretty clear on this.
> >
> >
> >  But if you have alternate wording to propose...?
> >
> >  -------------
> >
> Question: are we sure about "hexadecimal representation". I could not verify
> whether this is decimal or hexadecimal. I thought it was decimal.
> >

This is a hex representation of an unsigned fixed-point decimal.  Only the 
representation is hex for the positive integral part separated by a dot from a 
positive mantissa.

> >  PROPOSED RESOLUTION
> >  No further comments on the mail list. Therefore this issue is closed.
> >
> >
> >
> >  *************************************************************************
> >
> >
> >
> >  Glenn> 3. I am alarmed to see that Alert-ID is optional. I feel this
> encourages
> >
> >  Glenn> sensors to break mamagers.
> >  -------------
> >
> >  Dave
> >
> >
> >  Alert-ID is not optional.  It will always appear in an alert; it may have
> the
> >  value of zero (the default).  We have always permitted the value of zero
> for
> >
> >  analyzers that cannot generate unique ids.
> >
> >
> >  The rules on whether or not Alert-ID must be provided have not changed.
> The
> >  only rules that have changed are the uniqueness rules; the current rules
> as
> >
> >  reflected in the document were decided upon at the March, 2000 IDWG
> meeting.
> >  -------------
> >
> >5.2.
> >  PROPOSED RESOLUTION
> >
> >  Daves comments indicate that Glenn misread the document.
> >  No further comments on the mail list for a different wording.
> >
> >  Therefore this issue is closed.
> >
> The document I have (draft-ietf-idwg-idmef-xml-05.txt) does not say anywhere
> that AlertID is mandatory. Correct me if I am wrong.
>   In Sec 4.4.9 item (2)
>    2. The Alert, Heartbeat, Source, Target, Node, User, Process,
>       Service, File, Address, and UserId classes' (Sections 5.2.2,
>       5.2.3, 5.2.4.3, 5.2.4.4, 5.2.7.1, 5.2.7.2, 5.2.7.3, 5.2.7.4,
>       5.2.7.5, 5.2.7.1.1, and 5.2.7.2.1) "ident" attribute, if
>       specified, MUST have a value that is unique across all messages
>       sent by the individual analyzer.
> And in Sec 5.2.2. it says
>   Alert is represented in the XML DTD as follows:
>
>       <!ELEMENT Alert                           (
>           Analyzer, CreateTime, DetectTime?, AnalyzerTime?, Source*,
>           Target*, Classification+, Assessment?, (ToolAlert |
>           OverflowAlert | CorrelationAlert)?, AdditionalData*
>         )>
>       <!ATTLIST Alert
>           ident                 ID                      #IMPLIED
>         >
>
>    The Alert class has one attribute:
>    ident
>       Optional.  A unique identifier for the alert, see Section 4.4.9.
>
> I do not see the mandatory AlertID ? What am I missing ?

I think you are missing "alertident", that's what I thought we were talking 
about ( -05 draft)

Section 5.2.2.1 The ToolAlert Class

alertident
      One or more.  STRING.  The list of alert identifiers that are
      related to this alert.  Because alert identifiers are only unique
      across the alerts sent by a single analyzer, the optional
      "analyzerid" attribute of "alertident" should be used to identify
      the analyzer that a particular alert came from.  If the
      "analyzerid" is not provided, the alert is assumed to have come
      from the same analyzer that is sending the ToolAlert.

Not optional because it is substituted per se by its context, e.g. from the 
analyzer sending the alert.

> >
> >
> >  Glenn> 5. Sec 5.2.4.1 The Analyzer Class
> >
> >  Glenn> The text says: The Analyzer class identifies the analyzer from 
which
> >  Glenn> the alert or heartbeat message originates.  Only one analyzer may 
be
> >
> >  Glenn> encoded for each alert or heartbeat, and that MUST be the analyzer 
at
> >  Glenn> which the alert or heartbeat originated. ....
> >
> >
> >  Glenn> I do not think that we are very clear about the "origination" of 
the
> >
> >  Glenn> alert. A clarification about this would probably avoid confusion.
> >  ------------
> >
> >  Dave
> >
> >
> >  I think the sentence that follows the two you quoted above clarifies what 
we
> >  mean pretty well (i.e., we don't let you record "relay" analyzers along 
the
> >  way).
> >
> >
> >  But if you have a clarification you like better than you want to 
propose...?
> >  ------------
> >
> >  Andy
> >  I agree. I think the text as written is clear.
> Well, what happens when Alert 1 was received from sensor Aconfirmed by
> Sensor B and forwarded  - in that case is the alert originated by B or
> relayed
> by B?
> >

See above.

> >
> >
> >  Glenn> 6. Sec 5.2.4.1 The Analyzer Class
> >
> >  Glenn> This class seems to be mandatory. But all the constituent elements 
are
> >  Glenn> optional !

See above.

> >  ------------
> >  Dave
> >
> >  No, the analyzerid attribute is not optional.
> >  ------------
> >

analyzerid is optional BUT, it is instantiated by context in alertident e.g. 
implied.

> Once again I seem to be reading the wrong document
> Section 4.4.9 says
> 4.4.9 Unique Identifiers
>
>    There are two types of unique identifiers used in this specification.
>    Both types are represented by STRING data types.
>
>    These identifiers are implemented as attributes on the relevant XML
>    elements, and must have unique values as follows:
>
>    1. The Analyzer class' (Section 5.2.4.1) "analyzerid" attribute, if
>       specified, MUST have a value that is unique across all analyzers
>       in the intrusion detection environment.
>
>       The "analyzerid" attribute is not required to be globally unique,
>       only unique within the intrusion detection environment of which
>       the analyzer is a member.  It is permissible for two analyzers, in
>       different intrusion detection environments, to have the same value
>       for "analyzerid".
>
>       The default value is "0", which indicates that the analyzer cannot
>       generate unique identifiers.
>
> and in 5.2.4.1 it says
>   analyzerid
>       Optional (but see below).  A unique identifier for the analyzer,
>       see Section 4.4.9.
>
>       This attribute is only "partially" optional.  If the analyzer
>       makes use of the "ident" attributes on other classes to provide
>       unique identifiers for those objects, then it MUST also provide a
>       valid "analyzerid" attribute.  This requirement is dictated by the
>       uniqueness requirements of the "ident" attribute (they are unique
>       only within the context of a particular "analyzerid").  If the
>       analyzer does not make use of the "ident" attributes however, it
>       may also omit the "analyzerid" attribute.
>

See above.

>
> >
> >  Glenn> 9. Sec 5.2.4.4 The Target Class
> >
> >  Glenn> The text says: Node  Zero or one.  Information about the host or 
device
> >  Glenn> that is receiving the events (network address, network name, etc.).
> >
> >  Glenn> Sensors (network sensors) will probably never know if the target IS
> >  Glenn> "receiving".
> >
> >
> >  ---------
> >
> >  Dave
> >  Changed to "...at which the event(s) is being directed."
> >
> >  ---------
> >  RESOLUTION
> >
> >     Fixed
> >
> >
> >
> >  Glenn> Same probably applies to "Source". class.
> >
> >
> >  ---------
> >
> >  Dave
> >  I don't believe it does.  Source says "...is causing the event(s)."
> >
> Yes. But a network IDS may not know whether the source it sees is
> indeed causing an event. There is a "Spoofed" flag - which may have
> values yes/no/unknown.

Glenn, that is the correct interpretation, IMHO.

> >  ---------
> >  PROPOSED RESOLUTION
> >
> >     No Further comments on the mail list, leave as is.
> >
> >
> >
> >  *************************************************************************
> >
> >
> >
> >  Glenn> 10. Sec 5.2.4.6 The AdditionalData Class
> >  Glenn> The Type attribute seems to be irrelevant. Or, have I missed
> >  Glenn> something?
> >  -----------------
> >
> >  Dave
> >  Why do you believe it to be irrelevant?  It specifies the type of data 
that
> >  the element contains; without knowing that, a manager (especially one that
> >  may not know what the data is, but wants to show it to the user or some
> >  such behavior) cannot do anything meaningful with the data.
> OK. Say that I have
>
>       Type: ntpstamp
>       Meaning: the ntp format timestamp when the action was taken against
>                      the attack
> Now say we do not have the type - what will be lost ?
> And then Meaning is "optional" ?
> Without meaning what will one make out the additionalData value ?

It could be a configuration issue in the manager on how to handle specific 
AdditionalData types.  Yes, the meaning to the manager is optional/configurable 
but the type attribute may allow for better interoperation by disparate 
implementations.  Given the option to configure actions, etc. at that 
[AdditionalData->Type] level.

> >  -----------------
> >
> >  PROPOSED RESOLUTION
> >     No Further comments on the mail list, leave as is.
> >
> >
> >
> >
> >
> >  *************************************************************************
> >
> >  Glenn> 11. Sec 5.2.6 The Assessment Classes
> >  Glenn> Is it OK to have "textual descriptions of  impact" ? This raises 
the
> >  Glenn> basic issue -
> >
> >  -----------------
> >  Dave
> >
> >  Unless you have an all-encompassing pleases-everybody set of attributes 
that
> >  we can use instead...
> >
> >
> >  This has been a topic at more than one IDWG meeting; I don't believe it 
was
> >  ever resolved. The current approach is to have some broad categories, but
> >  to leave the details to free-form text.  This way, at least the 
information
> >  gets up to the manager, even if we can't solve the standard format problem
> >  now.
> >
> >  -----------------
> >  Eric Williams
> >
> >  While I feel there may become a tendency early on to overuse the
> >  "free-form" nature of the "textual descriptions of impact" that
> >  tendency will most likely be short lived.  Based on some of the other
> >  discussion on this issue re: "verbosity" it seems likely more compact
> >  forms will prevail and thus deprecate the textual description as
> >  things move forward.  Textual is OK, a good short term compensatory
> >  measure.
> >  -----------------
> >
> >  PROPOSED RESOLUTION
> >     No Further comments on the mail list, leave as is.
> >
> I understand the point. But I am afraid that keeping both enumerated and
> free form in the same definition is revolutionary. General practice is to
> keep enumerated with "other" as one of the candidates. How will the
> parsers work and what meaning can be made out of the field. When
> one sees a value how does one know whether it is one of the enumerated
> values or some other free form encoding by some sensor. So now we will
> have to define free form ...

It should be left to implementers to define the semantics or style for free 
form impact data.  Good representations will win out in the short term and 
eventually be over taken by more compact methods in the future (that's my read 
anywho).  Again, it may be empty so that is not revolutionary, I think.  What 
is revolutionary is providing a compensation measure in the element itself so 
that implementers can 'figure' the best way to codify impact for greater 
interoperability.  We are giving a tool to them that can be used to leverage 
the information provided by other implementations. A manager could in effect 
only interpret the 'other' type and ignore textual descriptions or be 
configurable to interpret textual descriptions of a specific format.   I think 
its cool.
> >
> >
>
> >
> >  Glenn> 13. Sec 5.2.7.1.1. The Address Class
> >  Glenn> I do not understand all the ranks in the category. Are all these
> >  Glenn> required. e.g. rank 7, 8 , 9 , 10?
> >  ----------
> >
> >  Dave
> >  Addresses are used to represent hosts and users, that's why there's the 
kind
> >  of odd mix.  And it was decided some time ago (two or three IDWG meetings 
ago)
> >  that networks needed to be represented too.
> >
> >
> >  Why would you remove all four of the IPv4 notations?  IPv6 has not taken 
over
> >  the world yet.
> >
> >  ----------
> I did not want to take off all of those!
> Among the categories 7 and 10 say pretty much all that is there say about
> IPv4 addresses (hosts and networks). I do not see the purpose of 8 and 9.
> >
> >
> >  Glenn> Do we require the domain name representation of an address ? That 
is
> >  Glenn> not present ?
> >  -----------------
> >  Dave
> >
> >  Do you mean PTR records?  Or something else?
> >  -----------------
> No. Just plain DNS addresses e.g. www.ietf.org. some analyzers (e.g. a log
> analyzer ) may get a FQDNS only. It will have to use it as the address
> unless the address is optional (It is not.)

Since you don't mean PTRs and you are really talking about FQDNs then that 
presents a whole different set of issues.  I understand your point, but should 
an analyzer 'trust' a domain name ever?  Even in a log file, if I have control 
over the PTRs for a set of ipaddrs then it would be trivial to make my address 
appear to be www.ietf.org in a log file (reverse address mapping is what causes 
the log entry as a FQDN).  I am not sure here, without a correlation engine for 
log analysis with a trusted/time-synchronized ipaddr, you can't trust it. 
That's my $.02.
> >
> >  Eric Williams
> >  I think Glenn means PTR's here Dave.  My opinion is that since PTR
> >  may be unreliable unless all caches along the resolution path, and
> >  the authoritative records, are trusted (not likely) you don't need
> >  that in or mapped to the Address class.
> >  ---------------
> >
> > PROPOSED RESOLUTION
> >    No Further comments on the mail list, leave as is.
>
>
>
> Glenn

Eric
PGP Public Key
http://new.infobro.com/KeyServ/EricDWilliams.asc
Finger Print: 1055 8AED 9783 2378 73EF  7B19 0544 A590 FF65 B789