[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: auditing
I agree with Ted. I also agree with Mark.. The BCP idea is a good one.
I agree for all the various reasons listed. The security of the base protocol
doesn't depend on it. There are places were implementing auditing is
at best difficult and leaves implementations open to denial of service attacks.
Etc. etc.
Auditing is not a protocol issue. If we choose to make it a protocol issue,
we MUST spell out the details a lot more clearly than saying compliant
implementations have to audit this or that. If we aren't willing to do that,
and I for one, am not willing, we SHOULD leave it as a SHOULD. The
implementors of the target implementation and finally the market place
will determine what MUST be done for auditing.
-Rob
----------
From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU]
Sent: Wednesday, April 02, 1997 12:55 PM
To: Ran Atkinson
Cc: Derrell Piper; ipsec@tis.com
Subject: Re: auditing
I have to agree with those who think that audit support should be a
SHOULD, not a MUST, for the same reasons they cited; it's not protocol
issue, it should be a host issue, there may be some host environments
where logging isn't possible, etc.
I have two other thoughts. What happens if the administrators decides
not turn off auditing those types of events, or the other end of the
SNMP trap receiver which the Cisco router has been forwarding the events
is just ignoring all of the packets and sending the logs to /dev/null.
Does the way the administrator configure a product make that product
non-conformant with the RFC?
Also, why is it so critical that we log packets with non-existent
security associations? Is the security of IPSEC fundamentally
compromised if system administrators don't review the logs daily looking
for these events? I understand the desireability of influencing vendors
to provide auditing capability for these sorts of events, but we're in
pretty bad shape if the security of a protocol depends on someone poring
over the audit logs!
- Ted