Subject: [IDWG] 'ident' ambiguities & inconsistencies

From: Paul Sangree <[email-masked]>
Date: Mon, 29 Jan 2001 16:24:39 -0600

There are some ambiguities in the definition of the various unique
identifiers  (ident, targetid, sourceid, etc.) in the IDMEF DTD spec.

1.  The scope of uniqueness of the identifiers is not clear.  Must a
specific 'ident' or 'alertid' attribute value be unique within the
IDMEF-Message, within the scope of a specific communications link, within
the entire installed network of analyzers and managers, etc?  I suggest
that we specify that it MUST be unique within the scope of the sending (not
necessarily the originating) Analyzer.  Thus it is unique 'at least' on a
hop-by-hop basis.  This leaves it to the system implementation to provide
mechanisms for uniqueness within a larger scope as needed, and for
correlating alerts originated by the same Analyzer, but sent via different
routes.

2.  The text sometimes disagrees with the DTD regarding whether an
identifier is optional or required:
  (a) Section 6.2.1 says the alertId attribute of <Alert> is required, but
has a default value of 0.  It makes no sense to define a default value for
a required attribute.
  (b) The 'ident' attribute of <Service> is specified as 'required' in Sect
6.5.5, but as optional in the DTD.  It should be optional.

3. Two different naming systems ('ident' v.s. 'targetid', 'sourceid',
'alertid' and 'heartbeatid') are used for the identifiers, but the naming
system doesn't imply anything about the characteristics of the identifier.
I suggest we adopt a single consistent scheme.   To avoid confusion between
'pid' and 'processid', and similarly between 'uid' and 'userid', I suggest
we use a 'ref' suffix instead of 'id'.  Therefore we should replace all the
'ident 'attributes as well as 'targetid', 'sourceid', etc with 'sourceref',
'targetref', 'alertref', 'heartbeatref', 'addressref', 'noderef',
'processref', 'serviceref' and 'userref'.

4.  Section 5.7 specifies that two sets of rules are used for defining
identifiers.  However, it appears to me that the only difference is that
'alertid', 'heartbeatid', and the 'ident' attribute of <Analyzer> are
required attributes, while all others are optional.  If so, then the
distinction can either be omitted from 5.7 (since it's already covered in
the individual definitions) or could be stated more clearly.

5.  I question the need for the ident attribute of SNMPService and
WebService, since they merely elaborate on the parent <Service> element,
which has it's own 'ident' attribute.  I don't think there is ever a need
to reference a <SNMPService> or a <WebService> without referencing the
<Service> that it describes.  Maybe I misunderstand this relationship?

6. (Note: If you agree with the previous point then this point is moot)
Section 5.7 states "The identification numbers used with the sourceid
attribute of the <Source> element, the targetid attribute of the <Target>
element, and the ident attribute of the <Address>, <Node>, <Process>,
<Service> and <User> elements MUST be unique for each particular
combination...".   If SNMPService and WebService are to retain their
'ident' attributes (see item #5, above), they should be added to this list.

Paul Sangree

---

From: Paul Sangree <[email-masked]>
Date: Mon, 29 Jan 2001 16:47:53 -0600

I forgot to mention that the range of values of the identifiers should also be
specified.  I suggest a 32-bit unsigned integer (0 to 2^32-1).

Paul

>'ident' attributes (see item #5, above), they should be added to this list.

---------------------------------------------------------------
Paul Sangree <mailto:[email-masked]>
Active Audit Engineering
Cisco Systems, Inc.
12515 Research Blvd, AST03/B2-6
Austin, TX, USA 78759
voice: 512-378-1518
fax:    512-378-1250

---

From: Paul Sangree <[email-masked]>
Date: Tue, 30 Jan 2001 11:55:30 -0600

>Y'know... after I responded with the above, I started thinking about this some
>more.  Do we really need globally unique?
>
>Do we even need unique across the whole IDS environment?  For everything
except
>the analyzer identifier, isn't just "unique from this analyzer" sufficient,
>since combining that value with the analyzer name/address/ident/whatever would
>make it unique?
>
>Analyzer identifiers need to be unique within the IDS environment, and might
>arguably need to be globally unique, but I can't see that anything else needs
>to be.
>

I was having the same thoughts.  Since <Analyzer> refers to the analyzer that
originated the <Alert> or <Heartbeat> (BTW, thanks for clarification on this) I
think your scheme should work. 

>BTW, if we decide globally unique, we probably need something a little more
>flexible than a 32-bit integer...

You're right about that.  Maybe 64 bits, 128?  I dunno.   However, I don't
think globally unique is really necessary even for <Analyzer> ident.  I don't
see any reason to go beyond the scope of an installed 'system' (meaning all
analyzers and managers that speak IDMEF with each other), unless we envision a
world-wide Internet IDS (wwids? Interids?).  However, this almost amounts to
the same thing if we want garaunteed interoperability between systems from
different vendors, since if they choose overlapping numbering systems, chaos
would result when we plug them together.  It would be best if we could nail
down the identification scheme so everybody plays by the same rules, but I
don't know how.  Maybe a 64-bit number composed of the concatenation of the ip
address and a random number?