If a threat model
for Syslog is required, I would be very interested in helping out. Let me
know.
-Eric
Eric A. Hibbard, CISSP, ISSAP, ISSMP,
ISSEPSenior Director,
Data Networking TechnologyChair, SNIA Security Technical Work
Group
Office of the CTOHITACHI DATA
SYSTEMS750 Central
Hi Sam,
On Thu, 5 Jan 2006, Sam Hartman wrote:
Hi. The IESg reviewed the proposed syslog charter at today's telechat
and decided that it requires revision. The main concern seems to be
the lack of a mandatory to implement security mechanism. I indicated
this might be the case in the
Hi Folks,
This is it. We need people to review this and get back to the WG.
When you reivew it, either send in notes about issues, or respond by
saying that you have reviewed it. (We DO need me too's.)
Thanks,
Chris
-- Forwarded message --
Date: Tue, 03 Jan 2006 15:50:02
Chris == Chris Lonvick [EMAIL PROTECTED] writes:
Chris Is Section 8 in draft-ietf-syslog-protocol-16.txt
Chris sufficient? Alternatively, Section 6 in RFC 3164 is fairly
Chris comprehensive.
Both of these look good. My main question with them is whether you
believe it is a
Rainer and all:
I started reading draft #16. Since we are revisiting everything... I am not
very comfortable with the current truncation rules.
Receivers SHOULD follow this order of preference when it comes to truncation:
1) No truncation
2) Truncation by dropping SD-ELEMENTs
3) If 2) not
Sam
I struggle to think what a security system would look like when the protocol is
purely simplex, apart from a MAC to give integrity with some shared secret
transmitted totally out of band.
Are there any examples of simplex security elsewhere in the IETF?
Tom Petch
- Original Message
Tom == Tom Petch [EMAIL PROTECTED] writes:
Tom Sam I struggle to think what a security system would look
Tom like when the protocol is purely simplex, apart from a MAC to
Tom give integrity with some shared secret transmitted totally
Tom out of band.
By this do you mean without
