[RFC]: extend iptables' AUDIT target functionality

[Mr Dash Four]

As it stands currently, when a NETFILTER_PKT type message is logged by 
the audit daemon for ICMP type 3 messages (destination unreachable), I 
get absolutely no information in that log as to who/what caused that to 
be triggered by the kernel, apart from, may be, the SELinux context. I 
get something like:

type=NETFILTER_PKT msg=audit(16/02/2013 07:10:28.004:7802) : action=0 
hook=3 len=80 inif=? outif=eth4 saddr=10.2.7.2 daddr=10.3.0.6 ipid=21794 
proto=icmp icmptype=destination-unreachable icmpcode=1 
obj=system_u:object_r:web_client_pkt_t:s0

I have managed to successfully change the AUDIT iptables target to 
include additional information from the original connection which caused 
this ICMP type message to be emitted, though before committing and 
issuing the relevant patches, I thought to seek more broad consensus as 
to what I should include as additional information in that audit log.

When ICMP type 3 message is triggered (that is also valid for type 4 - 
"source quench", and type 11 - "time exceeded" ICMP messages), and also 
depending on the type of the original connection, the following 
information is available to the modified AUDIT iptables target and could 
be transferred in the audit log for that (original) connection:

IP-related properties:
~~~~~~~
1. Source IP address;
2. Destination IP address;
3. Protocol used;
4. Type of service (TOS) value of the original packet;
5. Time-to-live (TTL) value of the original packet;
6. Checksum;
7. Total length of the original packet;

TCP-related (valid only when the original connection was TCP):
~~~~~~~~~
1. Source port;
2. Destination port;
3. TCP flags of the original packet;
4. TCP sequence value of the original packet;
5. Acknowledgement sequence number of the original packet;
6. Checksum;
7. Window size value;

UDP-related (valid only when the original connection was UDP):
~~~~~~~~~
1. Source port;
2. Destination port;
3. Packet length (header + payload) of the original packet;
4. Checksum;

SCTP-related (valid only when the original connection was SCTP):
~~~~~~~~~~
1. Source port;
2. Destination port;
3. Checksum;

Please note that this is *all* the data available to the AUDIT target, 
not what is (or should be) included in the audit logs!

As it stands, I have currently included the following in the AUDIT 
target to be logged, though this is not final, as I am still seeking 
more broad consensus, hence this email:

IP-related properties: Source & destination IP addresses, protocol and 
total length of the original packet;
TCP-related: Source & destination ports, TCP flags;
UDP-related: Source & destination ports;
SCTP-related: Source & destination ports;

As already mentioned, there are at least two things I am still 
considering: 1) should I add/exclude some of what I just listed above?; 
and 2) what should be the structure of the audit message?

For the latter, I have currently placed everything in a single audit 
message: the properties of the ICMP audit message (as shown in the 
example above), plus the field name/value pairs of the original 
connection added after that. They are currently named as "oX=V", where 
"X" is the brief description of the property in question and "V" is its 
value (in other words, TCP source port with a value of 443 of the 
original connection is constructed as "osport=443" in the final audit 
message).

I would like to know whether there are any objections, new ideas or 
suggestions to the above before committing this and issuing the relevant 
patches. Thanks!