A YANG Data Model for Syslog Configuration
draft-ietf-netmod-syslog-model-27
Yes
No Objection
Note: This ballot was opened for revision 22 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
On the specific question in the Shepherd writeup:
---
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
Yes, the model initially had defined support for configuring
Syslog over TPC (RFC 6587). However, after reviewing the
reasoning for why RFC 6587 was made HISTORIC, as decided to
remove the support. Some stated that their companies support
Syslog over TCP and now they would have to augment this model
with a vendor-specific extension. There may be a subtle
distinction between IETF defining an insecure protocol versus
defining a data model to configure, amongst other things, an
insecure protocol. We believe we did the right thing, from
an IETF perspective, but please double-check this.
---
I *personally* would have preferred that Syslog over TCP be included, as it is something which is in use by people, and having a single standard (with notes on why you might not want to use this) is better than an augmented one -- but, if the WG discussed this, then process was followed, and my preference is in the rough...
(Benoît Claise; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
One quick comment on the model for the console:
+--rw console! {console-action}?
| +--rw facility-filter
| | +--rw facility-list* [facility severity]
| | +--rw facility union
| | +--rw severity union
| | +--rw advanced-compare {select-adv-compare}?
| | +--rw compare? enumeration
| | +--rw action? enumeration
| +--rw pattern-match? string {select-match}?
Syslog can be (and frequently is) configured to log to "console" on a non-default tty. It's not clear from this model how this would be configured or indicated. Is the assumption here that all non-default-console tty logging would be handled by the "file" portion of the tree? If so, it would be worth indicating so explicitly, and noting that such an approach is limited to those systems that present ttys as a part of the filesystem. Alternately, it might make sense to add a tty field to the "console" subtree to report/configure this value.
(Alexey Melnikov; former steering group member) No Objection
Thank you for this document. I agree with Kathleen that risks of disabling syslog logging in order to hide system compromise needs to be discussed. I also prefer for TCP to be documented, if used in real world. Some minor comments: 1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when you mention it for the first time. 2) On page 19: Example: compare->equals and action->no-match means messages that have a severity that is not equal to the specified severity will be logged."; Do you mean "action->block" instead of "action->no-match"? 3) When logging to file: how is the file name constructed from the name file: URI if multiple files are preserved by the system? E.g. if the log file is rotated daily and 5 last files are preserved, how does each individual filename look? If I understood how this is used, this needs more clarification. 4) Nit: on page 18, typo in "spectify"
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
https://mozphab-ietf.devsvcdev.mozaws.net/D4614 It's not a problem with this document, but I took a quick look at draft-ietf-netconf-tls-client-server and I've got some concerns. Here are a few examples: - You can set the cipher suite but not key sizes and groups You can - say sort of incoherent things in TLS like "I support TLS 1.0 and TLS 1.2 but not TLS 1.1" (there is no way to negotiate this in TLS 1.2) I'll try to get a chance to give this a real review, but I wanted to mention it before I forgot. We are using definitions of syslog protocol from [RFC5424] in this RFC. Not a big deal, but this introduction feels like it ought to say what the document is about, not just about syslog. The severity is one of type syslog-severity, all severities, or none. None is a special case that can be used to disable a filter. When filtering severity, the default comparison is that messages of the This seems to be the first use of the term filter to mean this entity subtree, implementations MUST NOT specify a private key that is used for any other purpose. It seems like the data that syslog writes is sensitive, so the ability to write a destination reflects a high degree of risk.
(Kathleen Moriarty; former steering group member) No Objection
I agree with the SecDir review and thanks for responding to the review. I have one additional suggestion to make sure the points made from this review are clear to the reader. Thanks in advance!
SecDir Review text & response:
Security Comments
* I think almost all writable data nodes here are sensitive, because a network
attacker's first move is to block any logging on the host, and many of the data
nodes here can be used for this purpose.
[clw1] I will reword the security section to include all writeable nodes as sensitive.
[KMM] Thank you, I think it would be helpful to also note the reason is this case with an extra sentence or two.
Something to the effect of:
Logging in particular is used to assess the state of systems and can be used to indicate a network compromise. If logging were to be disabled through malicious means, attacks may not be readily detectable.
* Re: readable data nodes, I'm not
sure which are sensitive, and the document should give an example or two rather
than just say "some". Otherwise the security advice is not actionable. One
example: "remote" sections leak information about other hosts in the network.
[clw1] This text was lifted from another model. I will review the readable nodes and update.
[KMM] Thanks
* Write operations... can have a negative effect on network operations. - I would
add "and on network security", because logs are often used to detect security
breaches.
[clw1] I will add this phrase.
[KMM] I see this was added, thanks. Please consider the above 2 sentences.
* Also add an advice, similar to the one on "pattern match", that the
private key used for signing log messages MUST NOT be used for any other
purpose, and that the implementation of this data node must ensure this
property (I'm not sure how). The rationale: if the TLS private key is used, for
example, this could result in a signing oracle for TLS and eventually a MITM
attack.
[clw1] I will add this advice.
[KMM] Thanks for adding this advice.
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection