Subject: [IDMEF][Issue 5] duplicate information related to protocol information.

From: Herve Debar <[email-masked]>
Date: Thu, 08 Jan 2004 17:46:43 +0100

The current draft allow specification of tcp or udp as protocol only. 
This is a problem for other protocols. Moreover, the information can 
be inserted in two places, in source and destination, and there is no 
constraint ensuring that they should be the same.

I somehow think that the protocol should be something like:

<Protocol ip_version=[number] iana_number=[number] iana_name=[free 
text] >some text</Protocol>

That way we would have any IP protocol represented.

I haven't yet made my mind where to attach this protocol information.

 From Krzysztof Zaraska ->
The problem is that we are usually dealing with a protocol stack.
Therefore, what about the layer 2 information for example? Ethernet
addresses can go into into Source/Target, but what about, say, VPI/VCI
fields in ATM, or any other connection identifier? [This is not an
academic problem, as some people are trying to combine Prelude with
logging all traffic at the session level for later inspection and 
would appreciate some form of connection identifier within the alert.]

I see this as actually 2 problems, although I blend them in one for 
the moment because they may have the same solution:

1) duplicate, possibly incoherent, information in messages.
2) inability to represent anything else than TCP and UDP. I think that
    at least for ICMP it's a shame.

Hervé
-- 
Hervé Debar             <mailto:[email-masked]>
Tel: +33 (0)2 31 75 92 61            GSM: +33 (0)6 74 09 09 66
France Télécom R&D                   Fax: +33 (0)2 31 75 93 13
42 rue des Coutures  (--)  BP 6243  (--)  F-14066 Caen Cedex 4

---

From: "David A. Curry" <[email-masked]>
Date: Sun, 11 Jan 2004 20:48:40 -0500

>>>>> On Thu, 8 Jan 2004, Herve Debar, identified as "Herve" below, wrote:

  Herve> I somehow think that the protocol should be something like:

  Herve> <Protocol ip_version=[number] iana_number=[number] iana_name=[free
  Herve> text] >some text</Protocol>

  Herve> That way we would have any IP protocol represented.

This seems reasonable to me... it's at least quite a bit better than "tcp"
and "udp", and we'll at least need the flexibility of IPv4 -vs- IPv6
anyway...

  Herve> From Krzysztof Zaraska -> The problem is that we are usually dealing
  Herve> with a protocol stack.  Therefore, what about the layer 2 information
  Herve> for example? Ethernet addresses can go into into Source/Target, but
  Herve> what about, say, VPI/VCI fields in ATM, or any other connection
  Herve> identifier? [This is not an academic problem, as some people are
  Herve> trying to combine Prelude with logging all traffic at the session
  Herve> level for later inspection and would appreciate some form of
  Herve> connection identifier within the alert.]

I think Layer 2 is outside the scope of what IDMEF was originally thinking
about.  That doesn't mean it couldn't be added (although I'm loathe to do
so at this late date), or that Prelude (I don't know what that is, but I
assume it's an IDS project of some sort) couldn't define some type of an
extension for it.

--Dave

---

From: Krzysztof Zaraska <[email-masked]>
Date: Mon, 12 Jan 2004 16:44:27 +0100 (CET)

On Sun, 11 Jan 2004, David A. Curry wrote:

> about.  

If so, then the draft should state it clearly. 

> That doesn't mean it couldn't be added (although I'm loathe to do so
> at this late date),

I understand. :-)

> or that Prelude (I don't know what that is, but I assume it's an IDS
> project of some sort)

Correct. http://www.prelude-ids.org/

> couldn't define some type of an extension for it.

We already do, by putting the layer 2 information into Additional Data
objects. This way has turned out to be impractical, paticularly because of
problems related to constructing relevant database queries. So we're
looking at the other possible solutions. 

// Krzysztof Zaraska * kzaraska (at) student.uci.agh.edu.pl
// http://mops.uci.agh.edu.pl/~kzaraska/ * http://www.prelude-ids.org/
// A dream will always triumph over reality, once it is given the chance.
//		-- Stanislaw Lem