Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Sep 2005 12:04:28 +0200

Dear Sam & WG,

many thanks for your review of syslog-protocol and the questions raised.

Below, I have given answers to many of the questions. Some of them
include suggestions of how we could change the ID. I would appreciate if
WG members could read through this mail, even though it is quite large.
I intend to make some changes as outlined in my answers and feedback is
vitally important to get this going.

I have also provided some answers not leading to changes. I hope I have
summed up everything correctly. If somebody thinks differently, please
let us know.

There are some questions where I need to do further research. I have
preferred to just flag them and leave them unanswered, so that the rest
of the process can continue.

Sam: I would appreciate if you could comment on the answers to 3 and 7
and tell me if you can agree with this point of view.

Best regards,
Rainer Gerhards 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Monday, September 19, 2005 3:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14
> 
> 
> 
> Hi.  A few weeks ago you submitted draft-ietf-syslog-protocol-14 for
> publication as a proposed standard.  The first step in that process is
> review by the responsible AD, me.
> 
> 
> here are my comments.  The working group needs to respond to these
> comments; responses can come in the form of answers to questions,
> disagreement, proposed changes, etc.
> 
> 1) Has the ABNF been validated?  Which parser was used?  I'm
>    particularly concerned about the handling of escaping in sd-values.
>    If the ABNF is used directly to generate a parser, will it
>    correctly handle the escaped text?  Is the handling of the escaping
>    issue in this spec consistent with handling in other specs?

The IETF-recommended ABNF validator at
http://www.apps.ietf.org/abnf.html was used. Also used was APG
(http://www.coasttocoastresearch.com/), both returning no diagnostics.
However, I have not tried to generate a parser implementation and check
its handling of the escaped text. I will do further checks in this
regards and post an update when I am through with that.

> 
> 2) You do not discuss Unicode security at all.  I suggest that people
>     in the working group read Unicode TR 36 and also consider the
>     implications of the Unicode security presentation given at the
>     last SAAG presentation.  particularly consider comments from
>     operators concerned about Unicode characters interacting with
>     existing scripts.  Then write up a security considerations
>     section.  You need to at least explain the security risks
>     associated with your choice to support all Unicode characters.  It
>     would be a good idea to discuss other alternatives that were
>     considered and to explain why this choice was made.

I will follow your advise and post comments/updates once I have them.

> 
> 
> 3) Backward compatibility and versioning are not really discussed.
>    You define semantics of the version field but these semantics
>    require the sender to be configured with the version that the
>    receiver will support.  Is this extensibility model acceptable to
>    people who will deploy this protocol?  Also, it seems that this
>    extensibility model means that making a change that requires a
>    version number bump is very costly.  Structured data seems like the
>    major extensibility mechanism that does not require a version
>    number bump.  Is this mechanism sufficient to make sure version
>    bumps will be infrequent?

The core problem with version number coexistence is that syslog traffic
is simplex. So it is not possible to have the sender and receiver
negotiate on a specific version (which would obviously relieve many of
the costs associated with it).

We are still using a header that is depending on the field positions and
avoids multi-line entities. The reasons are:

- keep as consistent with traditional syslog as possible
- allow coexistence with existing syslog implementations
  (as outlined in section A.1)
- keep the header as small as possible - we have severe size
  restrictions in syslog based on the need to fit a message into
  a single IPv4 UDP packet without fragmentation (message are allowed
  to be longer, but this probably reduces reliability in a
troubleshooting
  case in a broken network)

Given the simplex nature and the header structure, it has been WG
concensus that the currently specified versioning is acceptable and not
a major drawback.

I also think that a version number bump - by its nature - is not
costlier than in other protocols. That it actually is costlier stems
back to the fact that the sender must be correctly (and manually)
configured, something that other protocols handle during initial
connection negotiation. Extending syslog to include a negotiation phase
and thus becoming a (half)duplex protocol would solve the issue;
however, it would bear a much higher cost in terms of acceptence of the
new protocol. Many implementors and users I have talked to  inisit on
the simple "send it and forget it" nature of the syslog protocol. If we
would change that considerably, I would strongly expect to loose a lot
of acceptance. As a side-note, the added complexity is also the major
thing hindering real-world acceptance of RFC 3195. We tried to avoid
this problem in syslog-protocol, obviously at some cost. Here it is the
need to manually configure the sender.

On the frequency of version number bumps, we assume that the current
header provides every information needed in the forseeable future (of
course, "forseeable future" is a weak term...). We expect that most
needs can be addressed by structured data entries. For example,
syslog-sign is expected to use structured data and so is RFC 3195bis, if
there is need for extensions. 

> 4) The working group has adopted the very restrictive standards action
>    IANA policy for  structured data.  Why is such a restrictive policy
>    chosen?

The "Standards Action" requirement was introduced as a late change
without much discussion. We primarily did this to keep it consistent
with the requirement for VERSION
(http://www.mail-archive.com/syslog-sec%40www.employees.org/msg00269.htm
l). I admit this should have received more thourough thinking.

Most probably it is better to keep with the original "Specification
Required" requirement.

> 
> 
> 5) I don't think x- as a prefix is such a good idea for vendor use SD.
>    It seems like that some way of identifying the vendor would be
>    better; possibly something based on OIDs, enterprise numbers, or
>    domain names.  The problem with a flat namespace for vendors is
>    what do you do about collisions.

We have seen the problem with collisions, but accepted it. Again, the
prime reasoning is the worst-case-size limitation. The longer the
prefix, the less space is left for actual message content. It obviously
is good to have a discussion on what is more desirable: short overhead
size or low avoidance of name space problems.

After re-reading and re-thinking based on your comment, a compromise
would probably be to use the vendor's enterprise numbers (same as in
section 7.2.2, preferably without sub-identifiers) as the prefix for
vendor extensions. So a vendor extension would not be "x-extension" but
"19406-extension" (19406 is the enterprise id of the company I work for,
I use it as a sample to avoid hitting someone else's id). The extra
overhead in size should be acceptable if we look at what we gain on
safety in namespace collisions. Optionally (if the vendor sees need),
sub-identifiers could be used, leading to things like
"19406.1.32.4.7.89-extension" - obviously this needs more space and thus
should be avoided if it does not create any issues for the vendor (but I
guess we would see such things quite often).

> 6) I'm concerned about the use of x- param names in sd-ids that are
>     not experimental.  As I read the spec, any x- param name can be
>     used in any sd-id regardless of whether the specification for that
>     sd-id permits the param-name.  However the specification of an
>     sd-id must define the non-x-param names valid with that sd-id.  It
>     seems like this will be used as a way to extend sd-ids after the
>     fact rather than defining a new sd-id as required elsewhere in the
>     text.  Is this really desirable?

This is a very good question. The consensus ([too?] quickly reached) was
that vendor-extension (and experimental ones) to standard SD-IDs are
useful. The reasoning behind this is that if a vendor intends to provide
information that is logically closely related to a standard SD-ID, it
would be useful to include it with that SD-ID. This would keep the
message both shorter and better readble than when a completely new
(vendor-specific) SD-ID is used for that purpose. So this mechanism
should be used to include not-yet-supported, closely related information
into a standard SD-ID. Of course, what is "closely related" depends. So
this mechanism could easily be abused.

If I look at your comment 5) above, I also begin to have some other
concern. For the same reasoning, we would have to replace the "x-" with
something vendor specific down here, too. Even if we go for the compact
enterprise-id, adding it to potentially multiple SD-PARAMs causes a lot
of overhead.

Given this whole picture, it probably makes sense to disallow x- params.
An alternative might be that the vendor uses a SD-ID with the same name
as the standard one but with its prefix (e.g. "19406-origin"), then add
the new SD-PARAMs without any further prefix.

> 7) What sort of review has this spec received from the vendor
>    community that generates syslog messages and the operator community
>    that consumes them?  Will this specification actually be useful to
>    the Internet community?  Has the review been wide enough that we
>    believe we are headed in the right direction?

There are many syslog vendors on this list as well as some (but few
given the total base) from the operator community. Review outside of the
WG has been sparse. I tried to receive comments from several Internet
discussion lists on syslog and/or closely related topics. However, the
result was very weak. There were some reponses that people are not
interested in any IETF work at all, not interested in protocol details
and/or not willing to look at an ID.

>From other discussions in the operator community, the following needs
are often voiced. They are not targeted towards a specific standards but
toward desired improvements in syslog in general. They are (order is NOT
relevant):

1. more security for the syslog protocol
2. a simple, reliable transmission protocol
3. a better timestamp including year and higher precision time
4. a better hostname, FQDN strongly desired
5. standardization of the message content

Syslog-protocol directly addresses 3 and 4. While 5 is not directly
adressed, it is believed that structured data can be used to address
this problem in the long term (please note that message content itself
is beyond the current charter of the WG). By providing a better message
id in syslog-protocol, we also hope to address some of 5. Issues 1 and 2
are also not directly adressed. However, we think that removing many
ambiguities and subtle differences in current RFCs (and
industry-standard implementations) will definitley help with 1. For the
same reason, the new layered architecture is designed to aid adding new
transports with minimal impact on existing applications and standards.
For this reason, I think 2 is also addressed, even if very indirectly.

Looking at the implementor community, the new layered architecture and
strict header specification greatly eases the task of developing syslog
solutions.

With currently-existing RFCs, there is a lot guesswork of what is
contained in which header field. This is well-known throughout the
communities, many applications provide different settings to select
different header and message interpretation. Also, RFC3195 did specify a
subtly different header than RFC 3164 did and syslog-sign was scheduled
to use even another slightly different header. As an implementor, you
had to support at least three different parsers/generators for mostly
the same thing. The lack of a common format also made it impossible to
transfer syslog-sign message via RFC 3195 because they required
different header formats. This discussion lead to the initial idea of
the layered architecture which then lead to syslog-protocol. With
syslog-protocol, there now  is a single format specification (though
with the versioning issue you pointed out) that  provides the base
format for all other standards to come (RFC 3195bis, syslog-sign,
whatever...). This consistency greatly enhances the ability to reuse
code in implementations.

Given these arguments, I belive that syslog-protocol will be useful to
the Internet community in general and of benefit to the implementor and
operator community.

Regarding the review, participation on the WG mailing list is
unfortunately lower than we would like to have it. However,
syslog-protocol has seen dramatically increasing discussion and review
in the months before WG last call. You might want to quickly browse the
mail archive at:

http://www.mail-archive.com/syslog-sec%40www.employees.org/

Even with the limited direct end user comments on the draft, I consider
the review to have been sufficiently enough. Maybe Chris can further
comment on that.

> 
> 
> thanks for your responses,
> 
> --Sam
> 
> _______________________________________________
> Syslog-sec mailing list
> [email-masked]
> http://www.employees.org/mailman/listinfo/syslog-sec
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 25 Sep 2005 18:32:20 -0700 (PDT)

Hi,

Let's coordinate our discussions on these issues.  We can keep Sam out of 
these discussions until we get our responses together.  I'll put out notes 
to the list on each issue and we can see how we want to address each.

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 25 Sep 2005 18:50:46 -0700 (PDT)

Hi Rainer,

> there is need for extensions.

I think that Sam is also saying is that it would be appropriate to have a 
section on what happens when we have the following situations:

- old style (RFC 3164) reciever receiving new style messages
- new style reciever recieveing 3164 messages.

And perhaps we should also examine what a Version 1 receiver would do with 
a theoretical Version 2 message.  Maybe if we feel that we've covered 
everything, we might not need a version?

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 25 Sep 2005 19:08:01 -0700 (PDT)

Hi Again,

> the new SD-PARAMs without any further prefix.

Another alternative would be to use the precedent set (and already 
accepted by the IESG) in the SSH IDs.  This would mean that the 
IANA-registered SD-ID params could not use the "@" character.  See section 
6 of draft-ietf-secsh-architecture-22.txt and Section 4.6.1 of 
draft-ietf-secsh-assignednumbers-12.txt.

This would allow something like
    [origin [email-masked]="1"]
or even
    [[email-masked] foo="bar"]

Thanks,
Chris

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Sep 2005 14:31:05 -0400

Hi.  Sorry about the delay.

Your proposed directions seem reasonable.  However based on your
comments on operator input I'm going to request explicit review from
the ops directorate.

I'd like to give some proposed constraints on the solutions for the
sd-ids and parameters.

1) It seems like it should be relatively easy to add vendor
   extensions.  Mechanisms for doing this include a liberal IANA
   policy, vendor prefixes or vendor suffixes (like ssh).

2) It may be desirable to have a way to extend sd-ids with
   vendor-specific parameters.  However if such a mechanism exists,
   there also needs to be a way to extend sd-ids with standards track
   parameters.  I.E. it seems silly for it to be more inconvenient for
   the IETF to extend something than a vendor.  Possible ways of
   handling this are to allow standards track specifications to update
   the list of sd-params for sd-id, creating a special notation for
   after-the-fact extensions (a special prefix, @ietf.org suffix,
   etc), or removing the mechanism for vendor extensions to sd-params
   completely.

3) Namespace uniqueness should be considered.  How important this is
    depends on how difficult it is to get a name registered.  For
    example with a liberal IANA policy like first-come-first-serve or
    specification required, x- may be a fine prefix for sd-ids.  A
    vendor concerned by namespace conflicts can just register an
    extension.  However if the iANA policy is going to be more
    restrictive, then mechanisms such as those discussed on the list
    become more important.  It is likely that with a liberal IANA
    policy mechanisms for vendor-specific sd-parameters may still be
    important.

Your original proposal as well as the ssh-style proposal do meet these
constraints.  However there may be options that better meet your
desires to make messages small.  For this reason, I've tried to
explicitly enumerate what I consider the constraints to be.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Sep 2005 14:31:05 -0400

--Sam