Subject: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters

From: Tom Taylor <[email-masked]>
Date: Thu, 02 May 2013 21:07:03 -0400

In organizing the encoding for the SYSLOG approach, I need to decide how 
to define the structured data elements. Each such element is identified 
by an SD-ID and contains a specified set of parameters.

I have eight events in all (including "invalid port detected"), and 
twenty different parameters. The accounting is a little different from 
IPFIX because some IPFIX parameters end up in the SYSLOG headers 
instead. One parameter is common to all of the events, a few are common 
to at least four of them, and the rest are more scattered. There may be 
some reconciliation required when I submit the SYSLOG update.

The question is how to define the structured data elements. Here are the 
possibilities:

(a) define only one structured data element, within which all parameters 
are optional from the point of view of SYSLOG, but individual parameters 
may be mandatory from the application point of view depending on the 
event type. Every event would use the same structured data element.

(b) define one structured data element per event, with mandatory and 
optional parameters as required. The same parameter would then be 
registered formally with IANA once for each event using it.

(c) variation on (a): partition the parameters amongst multiple 
structured data elements, more than one of which may be needed to make 
up a complete event report. One possible use is to group parameters 
relating to a given NAT type. The disadvantage is a bit longer log 
lengths because of the additional structured data headers.

Are there any opinions on all this? SYSLOG is defined in RFC 5424.

Tom Taylor

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 3 May 2013 01:42:15 +0000

Option b would be my preference, as it seems the most straight forward
approach, 
easy to understand and implement.

Senthil

On 5/2/13 9:07 PM, "Tom Taylor" <[email-masked]> wrote:

>_______________________________________________
>Behave mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/behave

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 3 May 2013 01:57:54 +0000

I agree Senthil's proposal.

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 3 May 2013 08:38:17 -0700 (PDT)

Hi,

The thought that went into structured data in RFC5424 was to keep it 
simple for the sender to put together, and easy for the receiver to parse. 
The latter is especially critical if the receiver is going to immediately 
parse the message upon receipt.  If anyone is interested, John Kelsey 
wrote some things about that in Section 7 of RFC 5848, "Signed Syslog 
Messages".

I'd also agree that B gives the most flexibility.

Thanks,
Chris