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

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 7 Jul 2005 16:42:31 +0200

Hi Chris & all,

thanks for the comments. I have integrated them. While doing so, some
points were raised. I would appreciate if you could go through my reply
below. There are some question in it. I have also added comments related
to Didier's posting on message truncation. They are at the end of this
posting.

I will hold the protocol-14 update to see if I receive some replies to
this posting. If I hear nothing, I will post on monday. 

Sorry this has become a large posting, but I would prefer to get some
feedback before I post the next release (given the fact we are close to
final call).

Rainer
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Chris Lonvick
> Sent: Tuesday, July 05, 2005 4:01 PM
> To: [email-masked]
> Subject: [Syslog-sec] Chair Review Comments of 
> draft-ietf-syslog-protocol-13
> 
> 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.

done

> 
> 
> "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.
> 

done (including 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.
> 

changed to the text you suggested (directly above this sentence)

> 
> 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.

I needed to squeze it a little, but I think it is still readable well
enough. Don't like the idea to drop one of the scenarios...

> 
> 
> 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.
> 

done

> 
> 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.

I've changed it to "Standards Action" in 9.1. Do you think I actually
need to repeat this in 6.2.1?

Does 9.2 also require "Standards Action" or is "Specification Required"
(as it is currently) sufficient? I am a bit in doubt, maybe it's better
to keep this consistent.

> 
> 
> 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

done

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

done

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

I have changed the layout and included Sharon's latest comment on the
mappings. I hope the mapping is now acceptable to all. The new text is
as follows:

###
6.2.3.1  Relation to Alarm MIB

   The Alarm MIB RFC3877 [11] defines ITU perceived severities which are
   useful to be able to relate to the syslog severities, particularly in
   the case where alarms are being logged.  The ITUPerceivedSeverity
   corresponds to a syslog SEVERITY as shown in table 2 below.

              ITU Perceivedi Severity     syslog SEVERITY
              Critical                    Alert
              Major                       Critical
              Minor                       Error
              Warning                     Warning
              Indeterminate               Notice
              Cleared                     Notice

           Table 2. ITUPerceivedSeverity to syslog SEVERITY mapping.
###

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

done
> 
> 
> 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.

done

> 
> 
> 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.
> 

done with a slight change:

###
a new SD-ID or PARAM-NAME MUST be created and the
   old one remain unchanged.
###

duplicated to IANA considerations, but mentioning only SD-IDs there.
Which brings up the question: must we put PARAM-Names under
IANA-Control, too? It kind of looks so...

> 
> 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

done
> 
> 
> 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.

done

> (Rainer may consider adding something about rate limiting 
> here as well.)

I have included some information on rate limiting a bit later, in 8.6.
The suggested text is:

###
8.6  Reliable Delivery

   Because there is no mechanism described within this document to
   ensure delivery, and the underlying transport may be unreliable
   (e.g., UDP), some messages may be lost.  They may either be dropped
   through network congestion, or they may be maliciously intercepted
   and discarded.  The consequences of dropping one or more syslog
   messages cannot be determined.  If the messages are simple status
   updates, then their non-receipt may either not be noticed, or it may
   cause an annoyance for the system operators.  On the other hand, if
   the messages are more critical, then the administrators may not
   become aware of a developing and potentially serious problem.
   Messages may also be intercepted and discarded by an attacker as a
   way to hide unauthorized activities.

   It may be desirable to use a transport with guaranteed delivery, to
   mitigate congestion.

   It may also be desirable to include rate-limiting features in syslog
   senders.  This can reduce potential congestion problems when message
   bursts happen.
###

I think talking about rate-limiting on the receiver's side does not make
so much sense, as it will result in message loss in any case (at least
with UDP transport).  Do you think the proposed text is OK?

> 
> 
> 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.

I have changed the text to cover this:

###
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 may be registered through the
   Specification Required 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.

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

I have also changed the SD-PARAM description:

###
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.  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.
###

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-)?

> 
> 
> 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.
> 

Chris, I am not sure if the "must" below must be in upper case (as it is
no protocol related thing). I'd appreciate your advise:

###
  IANA must register the SD-IDs shown in table 4 below.
###    ^^^^

Regarding Didier's comments on the truncation process, I have added the
following section:

###
A.3  Message Truncation

   As outlined in Section 6.1, messages may be subject to truncation.
   In this case, the TRUNCATE field must be updated as specified in
   Section 6.2.4.  Implementors must keep in mind that the TRUNCATE
   field is a variable-sized entity.  Thus, its size requirement (in
   octets) may grow during truncation.  For example, if a relay
   truncates the MSG part of a message previously not truncated, the
   TRUNCATE field value changes from 0 to 10, taking up one additional
   octet of space.  As such, it is necessary to truncate one additional
   octet from the MSG to make room for the now-expanded HEADER.

   Similar reformatting may be necessary if a relay is operator-
   instructed to perform header modifications, e.g. to change the
   FACILITY or SEVERITY of a message before forwarding it.
###

I have also changed the values of the TRUNCATE bits to something that I
think making it less likely to grow:

###
6.2.4  TRUNCATE

   The TRUNCATE field is used to indicate if the message has been
   truncated since it was sent or generated by an application.  Such a
   truncation might happen on the initial sender and any receiver,
   including receivers on interim systems (relays).  Values in the
   TRUNCATE field are made up of bits.  Each of this bits has been
   assigned a specific value so that there is no doubt about bit
   ordering.  The values described in table 3 below MUST be used.

            VALUE     Meaning
              1       all or some SD-ELEMENTs were truncated
              2       all or part of MSG was truncated
              4       truncation occurred at the receiver
              8       truncation occurred at an interim system
             16       truncation occurred at the initial sender

            Table 3. TRUNCATE values.
###
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 8 Jul 2005 09:22:59 -0700 (PDT)

Hi Rainer,

I've snipped much of your posting and answered questions below.

> need to repeat this in 6.2.1?

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

> (as it is currently) sufficient? I am a bit in doubt, maybe it's better

Be consistent.

> IANA-Control, too? It kind of looks so...

Yup.  :)

> with UDP transport).  Do you think the proposed text is OK?

Looks good to me.

> in standardized SD-IDs? Or should these only be allowed in experimental

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.

>   IANA must register the SD-IDs shown in table 4 below.

You can leave it lowercase.

Thanks,
Chris