Subject: [Syslog-sec] Chair Review Comments of draft-ietf-syslog-protocol-13

From: Chris Lonvick <[email-masked]>
Date: Tue, 5 Jul 2005 07:00:40 -0700 (PDT)

Hi Folks,

I've done a review of draft-ietf-syslog-protocol-13 and have the following
comments.  I'd like to ask Rainer to incorporate them along with any other
final comments and publish a new version.  Once this is in the ID
repository I will call for WG Last Call for two weeks.  If we don't get
any major issues from that then I'll submit it to the IESG with the
recommendation that it be considered for publication.  I'll be doing a
review of syslog-transport-udp as well.

References are not allowed in the Abstract.  Suggest change:
   This document has been written with the spirit of RFC 3164 [14] in
to:
   This document has been written with the spirit of tradition syslog in
Keeping the reference in the Introduction is OK.

"Conventions Used in This Document" should be:
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
(That's how it's written in RFC 2119.)  In some cases the keyword
"optional" should be in uppercase in the document - like in several places
in Section 7.

Double dashes in Basic Pricipals are not to be used.  Suggest change
   o  Relays may send all or some of the messages that they receive to a
      subsequent relay or collector.  They may also store -- or
      otherwise locally process -- some or all messages without
      forwarding.  In those cases, they are acting as both a collector
      and a relay.
to:
   o  Relays may send all or some of the messages that they receive to a
      subsequent relay or collector.  They may also store or otherwise
      locally process some or all messages without forwarding.  In those
      cases, they are acting as both a collector and a relay.
Also, this is not entirely clear.  Perhaps it should be changed to:
   o  Relays may send all or some of the messages that they receive to a
      subsequent relay or collector.  They may also store or otherwise
      locally process some or all messages without forwarding.  In the
      case where a receiver stores some messages and relays some
      messages, it is acting as both a collector and a relay.

Watch the contignuity of the diagram 1 and its title.  Make sure that
they are not separated by a page break.  The RFC editor will also
watch this.

In Section 6.1 "Message Length", the following paragraphs may be clearer
if they are reversed:
   If the last SD-ELEMENT of a message is deleted, the STRUCTURED-DATA
   field MUST be changed to "-" to indicate empty STRUCTURED-DATA.

   When a receiver or initial sender truncates a message, the TRUNCATE
   (Section 6.2.4) field MUST be updated.  In the case of a receiver,
   please note that this will break eventually existing digital
   signatures.  This is irrelevant, as the truncation itself breaks the
   signature.  So no extra harm is done by updating the TRUNCATE field.
Also, the clause
   please note that this will break eventually existing digital
   signatures.
should be changed to:
   please note that this will break message integrity checking
   mechanisms such as digital signatures.

Would it be appropriate in Section 6.2.1 "VERSION" to describe that
the VERSION field can only be changed by STANDARDS ACTIONS as defined
in RFC 2434?  Also, the VERSION needs to be registered with IANA and needs
to be stated in the instructions to the IANA.

In Section 6.2.2 "FACILITY", the value of the facility should not
have commas.
   FACILITY is an integer in the range from 0 to 2,147,483,647.  It can
change to:
   FACILITY is an integer in the range from 0 to 2147483647.  It can

If diagram 1 has a title, then so should the diagram (or table) in Section
6.2.3 "SEVERITY".

The list in Section 6.2.3.1 "Relation to Alarm MIB" may be better
represented in a table.

The table in Section 6.2.4 "TRUNCATE" should have a title.

Grammar in Section 6.3.3 "SD-PARAM":
   MAY drop the message.  It is RECOMMENDED that the receiver logs a
   diagnostic on reception of invalid escape sequences.
should be changed to:
   MAY drop the message.  It is RECOMMENDED that the receiver log a
   diagnostic message on receipt of a message with an invalid escape
   sequence.

Section 6.3.4 "Change Control" should either be move to the IANA
Considerations or be duplicated there.
   Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of
   these objects MUST NOT be altered.  Should a change to an existing
   object be desired, a new one MUST be created and the old one remain
   unchanged.
A slight change may make it more readable:
   Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of
   these objects MUST NOT be altered.  Should a change to an existing
   object be desired, a new SD-ID MUST be created and the old one remain
   unchanged.

In Section 7.3.1 "sequenceId", commas should be removed from the number.
   message up to a maximum value of 2,147,483,647.  If that value is
should be changed to:
   message up to a maximum value of 2147483647.  If that value is

Grammar in Section 8.4
   In case a sender includes user-supplied data within a syslog message,
   it should limit the size of that data.  Otherwise, an attacker may
   provide large data in the hope to exploit this potential weakness.
should be changed to:
   A sender should limit the size of any user-supplied data within a
   syslog message.  If it does not, an attacker may provide large data in
   hopes of exploiting a potential weakness.
(Rainer may consider adding something about rate limiting here as well.)

In the Instructions to IANA, it should be noted how additional
SD-PARAM names are added.  For example, how would one go about adding
a new SD-PARAM to describe the timezone on Mars to the timeQuality
SD-ID?  In that case, the SD-ID is not being changed, only a new SD-PARAM
is being added.

The instructions to the IANA should give a table of SD-IDs and their
known SD-PARAMS.
SD-ID                        SD-PARAM

timeQuality                                       OPTIONAL
                             tzKnown              OPTIONAL
                             isSynced             OPTIONAL
                             syncAccuracy         OPTIONAL

origin                                            OPTIONAL
                             ip                   OPTIONAL
                             enterpriseId         OPTIONAL
                             software             OPTIONAL
                             swVersion            OPTIONAL

meta                                              OPTIONAL
                             sequenceId           OPTIONAL
                             sysUpTime            OPTIONAL

The IANA seems to like maintaining tables better than just textual
registries.

Thanks,
Chris
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 11 Jul 2005 09:33:11 +0200

> The IANA section needs to be very clear.  The IANA people 
> really only look
> there for their instructions.

I have re-worked the IANA Considerations a little. Some information is
now a duplicate of the HEADER description, but in the light of Chris'
comment, this makes sense to me. The text also contains a change related
to Chris issue with x- PARAM-NAMES - see below. 

The new text is as follows:

###
9.  IANA Considerations

9.1  VERSION

   IANA must maintain a registry of VERSION values as described in
   Section 6.2.1.  Version numbers MUST be incremented for any new
   syslog protocol specification that changes any part of the HEADER.
   Changes include addition or removal of fields or a change of syntax
   or semantics of existing fields.

   VERSION numbers must be registered via the Standards Action method as
   described in RFC 2434 [9].  IANA must register the VERSIONs shown in
   table 4 below.

       VERSION     FORMAT
       1           according to this document

        Table 4. IANA-registered VERSIONs.

9.2  SD-IDs

   IANA must maintain a registry of Structured Data ID (SD-ID) values
   together with their associated PARAM-NAME values as described in
   Section 7.

   New SD-ID and new PARAM-NAME values must be registered through the
   Standards Action method as described in RFC 2434 [9].

   Once SD-IDs and SD-PARAMs are defined, syntax and semantics of these
   objects MUST NOT be altered.  Should a change to an existing object
   be desired, a new SD-ID or SD-PARAM MUST be created and the old one
   remain unchanged.

   SD-IDs and PARAM-NAMEs with the prefatory string "x-" (without the
   quotes) are reserved for experimental use.  IANA must not register
   any SD-ID or PARAM-NAME with the prefatory string "x-" for any other
   use.

   IANA must register the SD-IDs and PARAM-NAMEs shown in table 5 below.

       SD-ID              PARAM-NAME
       timeQuality                           OPTIONAL
                          tzKnown            OPTIONAL
                          isSynced           OPTIONAL
                          syncAccuracy       OPTIONAL

       origin                                OPTIONAL
                          ip                 OPTIONAL
                          enterpriseId       OPTIONAL
                          software           OPTIONAL
                          swVersion          OPTIONAL

       meta                                  OPTIONAL
                          sequenceId         OPTIONAL
                          sysUpTime          OPTIONAL

       x- (prefatory      RESERVED for experimental SD-IDs
           string)

       (any)              x- (prefatory      reserved for experimental
                              string)        PARAM-NAMEs

          Table 5. IANA-registered SD-IDs and their PARAM-NAMEs.
###

> 
> 
> >
> > However, this raises a question: should we allow 
> experimental SD-PARAMs
> > in standardized SD-IDs? Or should these only be allowed in 
> experimental
> > SD-IDs (x-)?
> 
> That's a question for the WG.
> 
> WG Chair hat OFF:
> I'd suggest putting in a quick statement about allowing 
> "x-<SD-PARAMs>" in
> any SD-IDs.
> Eveyone:  Get your thoughts in quickly on this.

I agree to Chris suggestion. I have modified the text as follows:

###
6.3.3  SD-PARAM

   Each SD-PARAM consist of a name, referred to as PARAM-NAME, and a
   value, referred to as PARAM-VALUE.

   PARAM-NAME is case-sensitive.  IANA controls all PARAM-NAMEs, with
   the exception of those in experimental SD-IDs or those with the
   prefatory string "x-" (without the quotes).  PARAM-NAMEs with the
   prefatory string x- are set aside for experimental purposes.  They
   can be specified in any SD-ID.  The PARAM-NAME scope is within a
   specific SD-ID.  Thus, an equally-named PARAM-NAME contained in two
   different SD-IDs is not the same.
###

I will publish this version tomorrow if I do not receive any more
comments requesting change.

Rainer