Hi Sam,
I also have a concern that we may try to craft an answer that provides
good security but that won't actually be deployed. As an analogy, snmp
has similar characteristics to syslog. usm has good security properties
but has not been widely deployed. isms is trying to redress that and
Banzsi:
I agree truncation does not solve the issue - that's why I don't want to
over-design it.
Splitting is an option I'd leave to application-layer running above syslog. It
is not precluded. Just a matter of another RFC with extra sd-elements.
If we do fragmentation in syslog
I think that you are leaping too soon into implementation space. That is
why the threat model is requested first. Off the top of my head here are
some components of the threat model. I organize these in terms of Asset,
Threat, Mitigation. There are certainly more threats because I know I
have
Rainer and all:
I'd like to propose a slight terminology change for syslog protocol for
structured data. I think there is confusion even in this group about current
terminology. For example, we (me included) keep referring to structured data
element, when we mean structured data parameter.
