Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Apr 2009 18:31:11 +0200

On Thu, Mar 26, 2009 at 06:34:04PM +0100, Scott O. Bradner wrote:
> 
> this starts a WGLC on 
>     draft-ietf-opsawg-syslog-snmp-02.txt
> and
>     draft-ietf-opsawg-syslog-msg-mib-02.txt
> 
> please send any comments to the list by April 13th

Please note the active WGLC. Also statements that you reviewed the
documents and are fine with them are helpful input for the chairs.
There is still one week left but Easter holidays are coming up
quickly...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Apr 2009 23:21:31 +0200 (CEST)

Hi,

>     draft-ietf-opsawg-syslog-snmp-02.txt

I have read this document, and my previous issues are now addressed.

There is some new text in section 4 (Relationship to the
SYSLOG-MSG-MIB).  The first paragraph gives the impression that the
section will describe how the two syslog/snmp documents can be used to
create tunnels.  But the rest of the section does not mention the
other document at all.

Minor nits:  3.2:  s/as as/as an/
             5:  s/show below/shown below/

>     draft-ietf-opsawg-syslog-msg-mib-02.txt

I have read this document, and my previous issues are now addressed.

Section 6 describes how the two documents are related.  It says:

   As a consequence,
   an SNMP management application should use trap-directed polling to
   determine whether a received SNMP notification did include all SD-IDs
   of a SYSLOG message.

But is trap-directed polling really necessary, since the notification
contains syslogMsgFlags which may set the bit 'truncated'?

Hmm.. from the description of 'truncated' it seems it applies to
trucation of syslogMsgMsg only, so maybe it can be set, but still all
SD-params are included?  But then the last sentence seems to
contradict this: "For syslog messages without structured data element
parameters that were not truncated by the converter, none of the bits
is set."

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2009 13:31:54 +0200

> create tunnels.  But the rest of the section does not mention the

I suggest to add "and [I-D.ietf-opsawg-syslog-msg-mib]" to the 1st
sentence in the second paragraph so things become clearer:

   A SYSLOG receiver supporting an SNMP notification originator
   implementing this specification and [I-D.ietf-opsawg-syslog-msg-mib]
   SHOULD translate received SYSLOG messages containing SNMP
   notifications back into the SNMP notifications.
 
>              5:  s/show below/shown below/

Fixed in my sources.
 
> contains syslogMsgFlags which may set the bit 'truncated'?

There are two issues here: The truncated bit it set when the SYSLOG
implementation truncates an incoming SYSLOG message due to resource
constraints and this usually affects the free form message part since
it comes last. The other issue is the number of SD-IDs that can be
included in a notification, which is in principle SNMP transport
dependent and thus can't be captured in a single flag. If we do not
want to resort to trap-directed polling, we could include an
additional object indicating the number of SD-IDs in the mandatory to
send notification objects and then the receiver can easily check
whether the SD-IDs received are complete:

	syslogMsgSDIDs OBJECT-TYPE
	    SYNTAX	Unsigned32
	    MAX-ACCESS	read-only
	    STATUS	current
	    DESCRIPTION
	       "The number of SD-IDs contained in the syslog 
                message. This object allows a notification
		receiver to check whether all SD-IDs have been
		carried in a notification."
            REFERENCE
               "RFC5424: The Syslog Protocol (section 6.3.3)"

Such an object renders the sdparams bit useless and since the
truncated bit only reports truncation of incoming messages but no
truncation that has happened on the path already, we might do away
with the syslogMsgFlags in favour of the syslogMsgSDIDs object 
defined above. 

I am open for this change. What do others think about this issue?

> parameters that were not truncated by the converter, none of the bits

I think the statement is actually correct but this text will change
anyway depending on the adoption of the suggestion outlined above.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2009 13:35:25 +0200

On Tue, Apr 07, 2009 at 05:48:48AM +0200, WashamFan wrote:
 
> I also suggest clarify when to use polling. If I understand
> correctly, if sdparams is not set, then polling is not
> needed. otherwise, polling is needed no matter SNMP notification
> includes SD-IDs or not. Cause we can not dertermine if the
> notification includes SD-IDs fully or partially.

Yes. But see my response to Martin for a possible way to avoid polling
to check whether all SD-IDs have been received.
 
> One more thing:
> The title of section 6 should be "Relationship to SNMP Notification to SYSLOG Mappings".

Fixed.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2009 14:10:17 +0200

On Tue, Apr 07, 2009 at 09:52:42AM +0200, WashamFan wrote:

> But some new issues I'd like to raise at this point:
> 
> (1)wrt/ the figure in page 6, there can be many SNMP notification
> originators, but why not allow for many SYSLOG collectors?

The figure shows a "common scenario" - it does not limit installations
to exactly three notification originators and a single collector. But
I can easily change the figure to show two syslog collectors if that
helps (but I still do not include proxies and the many other
combinations that are possible). It might also make sense to change
the figure so that the flow is from left to right:

   +------------+              +-------------------+
   |snmp        |     snmp     |                   | syslog  +---------+
   |notification| notification |  +-------------+  | message |syslog   |
   |originator  |------------->|  |syslog sender|  |-------->|collector|
   +------------+              |  +-------------+  |         +---------+
   +------------+              |  +------------+   |
   |snmp        |     snmp     |  |snmp        |   | syslog  +---------+
   |notification| notification |  |notification|   | message |syslog   |
   |originator  |------------->|  |receiver    |   |-------->|collector|
   +------------+              |  +------------+   |         +---------+
   +------------+              |  snmp-to-syslog   |
   |snmp        |     snmp     |    translator     |
   |notification| notification |                   |
   |originator  |------------->|                   |
   +------------+              +-------------------+
  
> (2) information extracted from SNMP notification should be reflected
> in snmp SDE only or some other places. for example, "origin" SD-ID can refect
> SNMP notif, which mentioned in sec3.2. What about SYSLOG HEADER,
> MSGID, for example, represents the type of SNMP notif or the SYSLOG
> messages, in the latter case, all SYSLOG messages containing snmp SDE
> should have the same MSGID.

I do not understand your question. Please elaborate or suggest what
should be changed and where.

> (3) How about one SYSLOG message contains multiplex snmp SDEs, is it
> allowed?

What are "multiplex snmp SDEs"?
 
> nit:
> 3rd sentence, 1st para, sec2.2:
> RFCxxxx should be RFC5424.

Fixed.

> I reviewed again, and found it has addressed my previous concerns.
> But, there are some concerns wrt/ consistency with syslog-snmp-02:
> 
> (1)snmp-to-syslog translator is defined in syslog-snmp-02, 
> but no syslog-to-snmp translator definition.

I wrote this document following the usual MIB template and I did not
feel a special term would be needed from an SNMP perspective. Do you
think it is needed? Or are you missing a figure like the one above
showing how SYSLOG messages can be accessed via the SYSLOG-MSG-MIB?

> (2)There should be a counterpart to para2, sec7 in syslog-snmp-02
> in this doc.

I do not think there is an access control mechanism for SYSLOG so I am
not sure what you are looking for. Can you elaborate?

> some nits:
> (3)sec4, para5:
> 
>    The syslogMsgTable contains one entry for each recorded SYSLOG
>    message.  The basic fields of SYSLOG messages are represented in
>    different columns of the conceptual table.
> 
> Actually, a flag syslogMsgFlags is also in the table, how about:
>    The basic fields of SYSLOG messages are represented in
>    different columns of the conceptual table as well as a flag called syslogMsgFlags.

Fixed.

> (4)
> --syslogMsgObjects(1)
>      |
>      +--syslogMsgSDTable(3)
>         |
>         +--syslogMsgSDEntry(1) [syslogMsgIndex,
>            |                    syslogMsgSDParamIndex            <--- comma lacked
>            |                    syslogMsgSDID,
>            |                    syslogMsgSDParamName]
>            |
>            +-- Unsigned32      syslogMsgSDParamIndex(1)
>            +-- DisplayString   syslogMsgSDID(2)
>            +-- DisplayString   syslogMsgSDParamName(3)
>            +-- SnmpAdminString syslogMsgSDParamValue(4)

Fixed.
 
> (5)I-D.ietf-syslog-protocol and I-D.ietf-syslog-tc-mib should 
> be substituted with corresponding RFCs.

Done already when the RFCs appeared.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Apr 2009 21:54:22 +0200 (CEST)

>    notifications back into the SNMP notifications.

The other document describes this tunneling in somewhat more details.
Can this document simply refer to the relevant section in the other
document instead?

> it comes last. 

Ok.

> The other issue is the number of SD-IDs that can be
> dependent and thus can't be captured in a single flag.
>
> If we do not
> want to resort to trap-directed polling,

This would still be trap-directed polling, right?  You get the trap,
check you got all SD-params, and if not, you poll the device.

> we could include an

On its own, this object does not cover the case that the
implementation truncated the syslogMsgMsg, but kept all SD params
(maybe there were none).  So I think this object should be added, but
also that the syslogMsgFlags is needed (with just the 'truncated' bit).

/martin

---

From: WashamFan <[email-masked]>
Date: Tue, 07 Apr 2009 11:48:48 +0800

>  create tunnels.  But the rest of the section does not mention the

+1
This section should be consistent with section 6 in syslog-msg-mib-02.
 
>  parameters that were not truncated by the converter, none of the bits

I also suggest clarify when to use polling. If I understand correctly, if sdparams
is not set, then polling is not needed. otherwise, polling is needed no matter
SNMP notification includes SD-IDs or not. Cause we can not dertermine if
the notification includes SD-IDs fully or partially.

One more thing:

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2009 23:02:41 +0200

> Can this document simply refer to the relevant section in the other

I think the two sections say something slightly different. I tried to
keep a loose binding between the two documents, but that probably
makes it also somewhat more difficult. I am not sure what to do. Do
you think there is something essential missing or are we talking about
how to present things best?
 
> check you got all SD-params, and if not, you poll the device.

The difference is that you only have to poll in case you missed some
SD-IDs. This can make a difference, in particular if you use SNMP
transports that support the meanwhile even for UDP recommended 1472
octet SNMP message sizes.
 
> also that the syslogMsgFlags is needed (with just the 'truncated' bit).

There is a significant price for this bit and note other SYSLOG
components such as relays can happily truncate without this being
communicated to anyone. I am not sure the price of ~10 bytes to carry
this truncated bit is really justified to indicate truncation in the
MIB instrumentation while we happily ignore truncation that happens
before on the SYSLOG forwarding path.

Perhaps we should drop the truncation text and instead recommend that
SNMP transports should support large message sizes, that is 1472
octets instead of just 484 octets for UDP, with a pointer to RFC 3417
section 3.2.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Apr 2009 23:17:25 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> I think the two sections say something slightly different.

My understanding, which might be wrong, was that the section in
msg-mib describes how two create two types of tunnels, and the section
in syslog-snmp describes one of these tunnels.

> I tried to

I just noted that it seems that the msg-mib section is a superset of
the syslog-snmp section, and wonder if this was the intention.

One difference is that the syslog-snmp section says that an
implementation SHOULD translate back; msg-mib says that an
implementation "may be configured to" translate back.

> octets instead of just 484 octets for UDP, with a pointer to RFC 3417

I don't mind making things simpler, if it is consistent with the rest
of the syslog architecture.  It would be good to get some feedback on
this proposal from some syslog people.

/martin

---

From: WashamFan <[email-masked]>
Date: Wed, 08 Apr 2009 11:37:37 +0800

>  should be changed and where.

Please bear with me, I made a mistake. Just ignoring that above.
Still I suggest more text for SYSLOG specific HEADER like this:
  "This specification does
   not mandate particular values for these fields; however, for
   consistency, SYSLOG originators MUST use the same values for APP-NAME,
   PROCID, and MSGID fields for every message that is
   sent, whichever values are chosen.  To allow for the possibility of
   multiple originators per host, the combination of APP-NAME, PROCID,
   and MSGID MUST be unique for each such originator.  If an originator
   daemon is restarted, it MAY use a new PROCID for what is otherwise
   the same originator but MUST continue to use the same APP-NAME and
   MSGID."  

>  What are "multiplex snmp SDEs"?

Can one SYSLOG message contain many snmp SDEs to convey many SNMP
notifications together? I don't think it is clear in current text.

>  showing how SYSLOG messages can be accessed via the SYSLOG-MSG-MIB?

Actually, I can live with current text.
But I have a feeling, at some aspects, syslog-snmp is verbose, like the figure, 
the definition; at the others, syslog-msg-mib is verbose, like "tunneling" ;)

>  not sure what you are looking for. Can you elaborate?

If I understand correctly, para2, sec7 recommends snmp-syslog-translator should
enforce consistent policy with SNMP. And the similar text should be added to
recommends syslog-snmp-translator should enfore consistent policy with SYSLOG.

IMO, SYSLOG does have its rules to say which host is expected to receive which
part of messages(filters). So, when SYSLOG messages are converted to SNMP notification,
the same rules should apply.

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Apr 2009 14:31:27 +0200

>    the same originator but MUST continue to use the same APP-NAME and

I do not think we need to repeat what is already said in RFC 5424. I
am not convinced that this text is needed.

> notifications together? I don't think it is clear in current text.

I will add a sentence somewhere that a notification maps to exactly
one SYSLOG message. It was not the intention to carry multiple SNMP
notifications in a single SYSLOG message.

> If I understand correctly, para2, sec7 recommends
> snmp-syslog-translator should enforce consistent policy with
> SNMP. And the similar text should be added to recommends
> syslog-snmp-translator should enfore consistent policy with SYSLOG.
> IMO, SYSLOG does have its rules to say which host is expected to
> receive which part of messages(filters). So, when SYSLOG messages
> are converted to SNMP notification, the same rules should apply.

I added one sentence and the last bullet in section 10 now reads:

   o  syslogMsgFacility, syslogMsgSeverity, syslogMsgVersion,
      syslogMsgTimeStamp, syslogMsgHostName, syslogMsgAppName,
      syslogMsgProcID, syslogMsgMsgID, syslogMsgMsg, syslogMsgFlags,
      syslogMsgSDParamValue: These objects carry the content of syslog
      messags and the syslog message oriented security considerations of
      [RFC5424] apply.  In particular, an attacker who gains access to
      SYSLOG messages via SNMP may use the knowledge gained from SYSLOG
      messages to compromise a machine or do other damage.  It is
      therefore desirable to configure SNMP access control rules
      enforcing a consistent security policy for SYSLOG messages.

/js

---

From: WashamFan <[email-masked]>
Date: Tue, 07 Apr 2009 15:52:42 +0800

(1)wrt/ the figure in page 6, there can be many SNMP notification originators,
but why not allow for many SYSLOG collectors?

nit:

some nits:
(3)sec4, para5:

(4)
--syslogMsgObjects(1)
     |
     +--syslogMsgSDTable(3)
        |

washam

---

From: WashamFan <[email-masked]>
Date: Thu, 09 Apr 2009 10:16:21 +0800

>  am not convinced that this text is needed.

Actually, I copy those statements from syslog-sign, and I don't think they
appear somewhere in RFC5424. We can take most of these statements for
granted except that they imply all messages containing the ssgin SDE have
the same MSGID whatever it would be. Does the doc has the same implication
as those statements? If yes, then no problem for me.

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2009 07:50:39 +0200

> as those statements? If yes, then no problem for me.

While the sign document perhaps has reasons for these additional
requirements to make signatures to work, I do not see a reason why the
SNMP mapping should require anything more than what is in RFC 5424.

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 10 Apr 2009 10:21:29 +0200

opsawg-syslog-msg-mib has references to a syslog receiver.

This term no longer exists being replaced by collector, relay and transport
receiver. From an architectural perspective, an SNMP NO or NR corresponds to
originator, relay or collector so the last is perhaps the best fit.

Likewise, opsawg-syslog-snmp has syslog receiver, syslog sender and SYSLOG
sender application (the last of which contradicts the terminology in
syslog-protocol:-).  Probably, collector and originator are appropriate.

Tom Petch

----- Original Message -----
From: "Scott O. Bradner" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 26, 2009 7:34 PM
Subject: [OPSAWG] WGLC on syslog/snmp IDs

> thanks
> Scott
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "David Harrington" <[email-masked]>
Date: Fri, 10 Apr 2009 14:42:36 -0400

Hi,

FYI. RFC5424 has the terminology that the syslog WG agreed to use.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of tom.petch
> Sent: Friday, April 10, 2009 4:21 AM
> To: [email-masked]; Scott O. Bradner
> Subject: Re: [OPSAWG] WGLC on syslog/snmp IDs
>