From mailman-bounces@willers.employees.org Tue Mar 1 08:08:33 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21924 for ; Tue, 1 Mar 2005 08:08:32 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id D6FB75D0B3 for ; Tue, 1 Mar 2005 05:02:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: www.employees.org mailing list memberships reminder From: mailman-owner@willers.employees.org To: syslog-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Mar 2005 05:00:47 -0800 Precedence: bulk X-BeenThere: mailman@www.employees.org X-Mailman-Version: 2.1.4 List-Id: mailman.www.employees.org X-List-Administrivia: yes Sender: mailman-bounces@willers.employees.org Errors-To: mailman-bounces@willers.employees.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your www.employees.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, *INCLUDING UNSUBSCRIBING*, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@www.employees.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www.employees.org. Thanks! Passwords for syslog-archive@lists.ietf.org: List Password // URL ---- -------- syslog-sec@www.employees.org widuza http://www.employees.org/mailman/options/syslog-sec/syslog-archive%40lists.ietf.org From syslog-sec-bounces@willers.employees.org Thu Mar 17 14:19:18 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09411 for ; Thu, 17 Mar 2005 14:19:17 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 67AB25C80D; Thu, 17 Mar 2005 11:19:16 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by willers.employees.org (Postfix) with ESMTP id E5EDE5C793 for ; Wed, 16 Mar 2005 12:50:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07615; Wed, 16 Mar 2005 15:50:13 -0500 (EST) Message-Id: <200503162050.PAA07615@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Mar 2005 15:50:13 -0500 X-Mailman-Approved-At: Thu, 17 Mar 2005 11:19:15 -0800 X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Cc: syslog-sec@employees.org Subject: [Syslog-sec] I-D ACTION:draft-ietf-syslog-device-mib-06.txt X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Syslog Management Information Base Author(s) : G. Keeni, B. Pape Filename : draft-ietf-syslog-device-mib-06.txt Pages : 37 Date : 2005-3-16 This memo provides a MIB module that can be used to monitor and manage syslog processes. It defines objects that allow the collection of information related to syslog processes, it also defines objects that can be used to monitor and/or control syslog processes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-device-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-device-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec --NextPart-- From syslog-sec-bounces@willers.employees.org Thu Mar 17 16:02:24 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20216 for ; Thu, 17 Mar 2005 16:02:24 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 27E545C806; Thu, 17 Mar 2005 13:02:25 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by willers.employees.org (Postfix) with ESMTP id 2BF8E5C770 for ; Thu, 17 Mar 2005 13:02:23 -0800 (PST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2HL2Hl03961 for ; Thu, 17 Mar 2005 16:02:17 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Mar 2005 16:02:18 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402D3000E@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part 1 Date: Thu, 17 Mar 2005 16:02:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi Here is part one of my response .... > > G2 - Not much is said about change control and backwards > compatibility other > than the discussion buried in A.2 which seems to imply there > isn't any. I > propose the following: > > G.2.1. Make a statement to set expectations about change > control within the > body of the document. > > G.2.2. Suggest two levels of expectations - one for the > header, which is > governed by the version number and one for the SD-PARAMs > which should be > somewhat independent of it. I recommend that people try not > to break things > in the SD area within a version and between versions. Same > name has same > general semantics. If not a MUST, this needs to be a SHOULD. > I vote for > MUST. I added some descriptive text to 6.2.1 (VERSION). But I think it already covered that no header modifications are allowed. So some folks on this list might reject this as a duplicate. I think the only duplication in the text is in the way it was phrased. Suggest the following replacement. "The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include addition or removal of fields or a change syntax or semantics of existing fields. This document uses a VERSION value of "1". The VERSION values are IANA-assigned (Section 10.1). " For STRUCTURED-DATA, I have added the following new section: ### 6.3.4 Change Control Once SD-IDs and PARAM-NAMEs are defined in a specification and their IANA assignment has been done, syntax and semantics of these objects MUST NOT be altered. So they begin to exist with their initial definition and are never allowed to change. Should a change to an existing object be needed, a new one MUST be created. It is advised to use a name the reflects the close relationship between the two objects. For example, if the semantics of the "tzKnown" PARAM-NAME were to be changed, a good name for the new element would be "tzKnown2". ### This behaviours should not be made so specific to the ones allocated by IANA. And the bit about the naming does not seem necessary. Suggest the following replacement: " 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." > S1. In section 6, what is the relationship between Facility > and MSG-ID? They > seem to serve the same purpose. Is Facility just historical? > Is MSG-ID what > we need to use moving forward? (see G3) I added this text to the description of FACILITY: #### It is RECOMMENDED that the facility reflects a type of subsystem, something that a number of different messages might be issued from. So it is a kind of corase group. #### Does this clarify? Do we need to add similar text to MSGID (in that it identifies a specific message)? To keep it short, I've not done this yet. Now I'm left wondering how this relates to a category. > > S2. Is the length of SENDER-NAME and SENDER-INST sensible? > SENDER-INST seems > way too short. Consider needing to name something which is > the concatenation > of two IP addresses. It does not fit. Remember this is the > encoding the > string, not the integer. We will end up forcing people to > make up something > which does fit instead of using something existing. Actually, SENDER-NAME and -INST are not meant to be IP addresses. We have HOSTNAME and ORIGIN for that. SENDER-NAME and -INST should identify the type of sender, most probably a process name or something similar (like "postfix", "su" in current messages in TAG). I think the size is sufficient for this purpose. Given the size limitation we have in UDP based syslog, I would like to keep the HEADER size as small as possible. Obviously, we should not sacrifice things for a short size, but I think we do not need the longer sizes here. ; Fri, 18 Mar 2005 13:40:25 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B36D15C7A5; Fri, 18 Mar 2005 10:40:25 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by willers.employees.org (Postfix) with ESMTP id 7D8295C79A for ; Fri, 18 Mar 2005 10:40:24 -0800 (PST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2IIeHk29669 for ; Fri, 18 Mar 2005 13:40:17 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Mar 2005 13:40:17 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402D87367@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: IRE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part II Date: Fri, 18 Mar 2005 13:40:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi Part II of my response > > S3. In section 6.1, we need some guidelines on how to truncate > SD-BOUNDARIES. Can the structured data become non-compliant or must it > still be valid? If > within the message part, is it just arbitrary? Should we indicate > truncation has occurred in the header or at the very end of > the message? Do > we need to leave room for some extra characters at the end to > signify the > message has been truncated? This is being discussed in a separate thread. I'll respond to the separate thread > > S4. In section 6.1, this should really only recommend > truncation. Delete the > bit about dropping the message or indicate that it is only > dropped when > truncation cannot result in a valid message. That assumes we > think that is a > possibility, if not, lose the bit about dropping all together. I am not fully with you here. The "drop it" rule was added for receivers in embedded devices. Among others, it was argued that it might not be possible to receive the full message. Though we currently do not have a trailer, it can be argued that in this case the trailer could not be received and thus not only the payload, but the message itself would be truncated. It was assumed that embedded devices might prefer to drop the message instead of truncating it. Also, with the UDP transport, it is sheer reality that messages can be dropped on the network, especially if the network itself is experiencing troubles. So allowing a device to drop a message larger than 480 bytes could/should encourage implementers to keep them shorter than that. Of course, it can be argued that this is something that should be moved to security considerations or implementers notes - where it also is present. The two arguments together, however, seem to justify the "drop rule". I have to admit, though, that I am not very strong with this argument. If you feel this is really bad, please press again for change, I think a good argument can break my current one. What we need to get to is predictability. I had suggested that the only reason to allow a message to be dropped would be in the case that truncation can not be performed in a manner that could result in a valid message. You have suggested a second, where the system has enough resources to process messages to a given MTU, but not enough to perform truncation. I'm not sure how valid this case is, but if we feel it is, then we should phrase it in these sort of terms to increase the predictability of it all. > > S7. In relation to section 6.2.3, do we want to add a section called > 'Relationship to the Alarm MIB' so we can discuss the mapping of > severities? This is something that has come up in private discussions > since these do > differ somewhat from ever popular OSI severities. I could > write this section > up if there is interest. Terribly useful in the case of > someone logging > alarms. > This has been added - text proposed to WG, some feedback received but should be further reviewed Um. I seem to have missed this. Let me propose the following text "Relation to the Alarm MIB" The Alarm MIB [RFC3877] 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 ITU perceived severities relate to the syslog severities as follows: A value of 'cleared' for ITUPerceivedSeverity corresponds to a syslog severity of 'notice'. A value of 'indeterminate' for ITUPerceivedSeverity corresponds to a syslog severity of 'notice'. A value of 'critical' for ITUPerceivedSeverity corresponds to a syslog severity of 'critical'. A value of 'major' for ITUPerceivedSeverity corresponds to a syslog severity of 'error'. A value of 'minor' for ITUPerceivedSeverity corresponds to a syslog severity of 'error'. A value of 'warning' for ITUPerceivedSeverity corresponds to a syslog severity of 'warning'. " > > S9 In section 6.2.6, have we not already identified the device via > hostname? Should this not just be application? Should we rename it to > reflect this? This is very similar to a comment Anton Okmianski made. He suggested that SENDER-NAME and SENDER-INST be renamed to APP-NAME and PROCESS. Please see my arguments at http://www.employees.org/pipermail/syslog-sec/2005-January/000092.html After reading your post, I begin to think that Anton was right and we should rename this. What do you think? I can support APP-NAME, but not PROCESS, since I don't think process id will make sense in most of the cases I expect to see. How about APP-INST? > S10. In section 6.2.7, it includes the operating system > process ID? Does > this make sense in the typical IETF problem space? What about > multi-computer > network element? Can we just delete this part of the description? The idea in recommending a process id is that we need some relative uniqueness to detect restarts of the syslog daemon. So we do not necessarily need the process ID, we need something that changes when the instance of the sender changes. Of course, this is not absolutely vital (just helpful), this is why we allow the "-" nil value. I still say either remove the bit about the process ID or indicate only that it may be a process ID. "The APP-INST uniquely identifies one of multiple instances of APP-NAME that may be running. For example, it may be a process ID." Ideally I'd also like to suggest it might be a virtual router ID, but I'm not sure that is correct. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Fri Mar 18 14:41:16 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15697 for ; Fri, 18 Mar 2005 14:41:16 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id C6B1E5C774; Fri, 18 Mar 2005 11:41:15 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by willers.employees.org (Postfix) with ESMTP id 3427C5C731 for ; Fri, 18 Mar 2005 11:41:13 -0800 (PST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2IJegZ07942 for ; Fri, 18 Mar 2005 14:40:42 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Mar 2005 14:40:42 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402D87456@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part III Date: Fri, 18 Mar 2005 14:40:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi Part III of my response. This is the last of the series, but I owe one more on the truncation thread. > > S18. In section 6.5, the example, the 2 space thing is > inconsistent with > previous use of "-" character to indicate no value. Is there > a reason for > this and why is this buried in an example? This is a result of the ABNF. So far, we have not defined that the non-existence of any STRUCTURED-DATA must be denoted by anything. As such, it is SP SP, ultimately leading to two SP after each other. If you feel we should explicitly denote missing STRUCTURED-DATA (and nobody objects), I can add this. "-" would be appropriate in this case, because it is used everywhere else in the draft for this purpose. No, the structured data should just not be there if it is optional and not supported. What I was referring to was text like the following in 6.2.7: "The dash ("-") is a reserved SENDER-INST field value that MUST only be used to indicate an unidentified instance." and in section 6.5 "Note the two SP characters following MSGID. The second SP character is the STRUCTURED-DATA delimiter. It tells that no STRUCTURED-DATA is present in this message." What I was trying to do was 1) Get us to realize the syntax between the two was different and ensure we had a good reason for that 2) Get the description of this interpretation of the two SP character moved up into a more appropriate part of the document > > S19. In section 7, suggest new optional SD-PARAM called > sequence ID, whose > scope is a sub-domain of a network element. Reset on reboot. > Also, perhaps > one for sysUptime. I like this idea, but ask for some clarification. For "sequenceID", I assume it should be incremented for each message sent? Is that right? If so, I'd suggest an unsigned 32 bit integer with automatic rollover/reset to 0 after the maximum value is reached. As far as sysUptime is concerned, I think we should stick with the SNMP definition of the number of milliseconds since boot, with a max value of 4294967295 and automatic reset to zero thereafter. Is this understanding correct? For both, I think it would not be appropriate to add them to the "origin" SD-ID. Maybe it would make sense to add a "meta" SD-ID which can hold information somewhat describing the message. Any comments would be appreciated, including SD-ID name suggestions. Yes, you are correct - in addition to being reset on reboot, the sequence ID needs to define its roll-over behaviour. I agree they don't belong in origin, but I'm not sure 'meta' is the correct SD-ID. I can't think of anything better at the moment though. Go with that until someone else can think of something more clever. > S21. As a general comment to the 7.1.* sections, it would > seem that the > optionality of the parameter has been confused with the > optionality of its > behaviour. If the SD-PARAM is present, the behaviour MUST be > as described. Actually, I thought this was in the question. Maybe this is a language issue. Could you point me to what exactly makes the behaviour optional (it was not intended to be). Since section 7.1 indicates the optionality of timeQuality, the text in 7.1.1 needs to be written such that if you support timeQuality, then this is way that tzKnown MUST be supported. If tzKnown is considered optional even if timeQuality is supported, then a separate statement indicating that it SHOULD be support should be made and the following sentences reworked to be 'if it is support...' "The "tzKnown" parameter indicates if the original sender knows its time zone. If it does so, the value "1" MUST be used. If the time zone information is in doubt, the value "0" MUST be used. If the sender knows its time zone but decides to emit time in UTC, the value "1" MUST be used (because the time zone is known)." > > S22. In section 7.2.2, is this really identifying the > enterprise and not the > actual device type like something like sysObjectId would? > Actual device type > would be more useful. > > S23. In section 7.2.3, how does software differ from > sender-name where they > talk about an application? S22 and S23 deserve a single answer. Yes, it is an enterprise, but the idea is that we have the enterprise, the name of the software as well as its version. That should uniquely identify who is talking and in what (freeform MSG) format. If Enterprise is equal to ACME and ACME makes two products: 1) rocket powered roller blades and 2) electronic roadrunner traps, is this field identifying 'acme' in both cases or is it acme.rocket or acme.trap depending on the product? Keep in mind that both products run some of the same software and some software unique to their own unique applications. I suspect it is the latter, although the term enterprise is typically used in IETF to mean the former. > > S24. In section 8, a general note on the security > considerations section is > that a lot of the content is not. The non-security > considerations content > should be moved elsewhere or reworked to be an actual security > consideration. Also, there appears to be requirements buried > in here, which > also does not seem appropriate. > > S24.1 The last paragraph in section 8.1 is not a security > consideration. I think it is, but I may be wrong: my intention was to warn against too verbose logging, because it is very often seen that logging is turned off if it is too verbose. Does this really not fit in here? The text in question is " Besides this risk, diagnostic message, if they occur too frequently, can become meaningless. Common practice is to turn off diagnostic logging if it is too verbose. This potentially removes important diagnostic information which could aid the operator." It doesn't really say what you are saying. Plus, intelligent filtering can ensure the correct bits are what gets filtered out. > S24.2 The third paragraph in section 8.2 defines requirements. I think I can simply change the "SHOULD NOT" to lower case - storage is beyond the scope of this document. Or should I actually drop it - but it *is* a very important security issue... I seem to have a very different definition of a security considerations section than you do. I can't advise. > S24.4 Sections 8.4, 8.5, 8.6 & 8.7 don't appear to be security > considerations. Why is 8.4 not a security consideration? [honest question, not suggestively meant ;)] 8.5 to 7.7 are carried over from RFC 3164. They are security considerations there, too. Why shouldn't they apply here? You have not commented on 8.6. Ok. perhaps this would help: For each of the sections ask yourself 'why is this a security' consideration and ensure the answer gets published. Also make sure you don't define requirements (upper or lower case). > S24.5 Also the last sentence in the first paragraph of 8.4 > seems completely > off topic. syslog is simplex delivery. nobody will notice if the message is lost. This is telling the fact and informing the implementer that the protocol might not be suitable for a specific application. Should I still drop it? Again, ensure the 'why this is a security consideration' is included. > > S25. In section 8.12, the last sentence, what is it saying? > What does a > reliable transport mapping mechanism have to do with operator > error? This > claims that 'Using a reliable transport mapping can guard > against these > problems' How? A reliable transport mechanism with notifications (e.g. RFC 3195/COOKED) can detect such loops. Thus it can guard against them. Add to draft. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Wed Mar 23 12:20:47 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09150 for ; Wed, 23 Mar 2005 12:20:46 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 309305C7E0; Wed, 23 Mar 2005 09:20:46 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 046115C7DC for ; Wed, 23 Mar 2005 09:20:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 805041B0077; Wed, 23 Mar 2005 18:20:37 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11263-05; Wed, 23 Mar 2005 18:20:32 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 036321B0074; Wed, 23 Mar 2005 18:20:30 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 18:20:20 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part 1 Date: Wed, 23 Mar 2005 18:20:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061CE6@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part 1 Thread-Index: AcUrNLHE80k6nAJpSwidjHvdUXL0FAEkwSYg From: "Rainer Gerhards" To: "Sharon Chisholm" X-OriginalArrivalTime: 23 Mar 2005 17:20:20.0059 (UTC) FILETIME=[96D962B0:01C52FCC] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Sharon, many thanks for the comments. Special thanks for the text suggestions, which are very helpful. Please browse through this post, the main questions are towards the end of it. I will try to follow up at least your second post tomorrow. After that, I am out of office for the week after easter (until april, 4th). Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Sharon Chisholm > Sent: Thursday, March 17, 2005 10:02 PM > > Here is part one of my response .... >=20 > > >=20 > > G2 - Not much is said about change control and backwards > > compatibility other > > than the discussion buried in A.2 which seems to imply there=20 > > isn't any. I > > propose the following: > >=20 > > G.2.1. Make a statement to set expectations about change > > control within the > > body of the document. > >=20 > > G.2.2. Suggest two levels of expectations - one for the > > header, which is > > governed by the version number and one for the SD-PARAMs=20 > > which should be > > somewhat independent of it. I recommend that people try not=20 > > to break things > > in the SD area within a version and between versions. Same=20 > > name has same > > general semantics. If not a MUST, this needs to be a SHOULD.=20 > > I vote for > > MUST. >=20 > I added some descriptive text to 6.2.1 (VERSION). But I think=20 > it already > covered that no header modifications are allowed. So some=20 > folks on this list > might reject this as a duplicate. > >=20 > I think the only duplication in the text is in the way it was phrased. > Suggest the following replacement. >=20 > "The VERSION field denotes the version of the syslog protocol > specification. The version number MUST be incremented for any new > syslog protocol specification that changes any part of the HEADER > format. Changes include addition or removal of fields or a change=20 > syntax or semantics of existing fields. This document uses=20 > a VERSION > value of "1". The VERSION > values are IANA-assigned (Section 10.1). " >=20 changed >=20 > > For STRUCTURED-DATA, I have added the following new section: >=20 > ### > 6.3.4 Change Control >=20 > Once SD-IDs and PARAM-NAMEs are defined in a specification=20 > and their > IANA assignment has been done, syntax and semantics of=20 > these objects > MUST NOT be altered. So they begin to exist with their initial > definition and are never allowed to change. Should a change to an > existing object be needed, a new one MUST be created. It=20 > is advised > to use a name the reflects the close relationship between the two > objects. > For example, if the semantics of the "tzKnown" PARAM-NAME=20 > were to be > changed, a good name for the new element would be "tzKnown2". ### >=20 > >=20 > This behaviours should not be made so specific to the ones=20 > allocated by > IANA. And the bit about the naming does not seem necessary.=20 > Suggest the following replacement: >=20 > " Once SD-IDs and PARAM-NAMEs are defined, syntax and=20 > semantics of these > objects > MUST NOT be altered. Should a change to an > existing object be desired, a new one MUST be created and=20 > the old one > remain unchanged." changed >=20 > > > S1. In section 6, what is the relationship between Facility > > and MSG-ID? They > > seem to serve the same purpose. Is Facility just historical?=20 > > Is MSG-ID what > > we need to use moving forward? (see G3) >=20 > I added this text to the description of FACILITY: >=20 > #### > It is RECOMMENDED that the facility > reflects a type of subsystem, something that a number of=20 > different messages > might be issued from. So it is a kind of corase group. #### >=20 > Does this clarify? Do we need to add similar text to MSGID (in that it > identifies a specific message)? To keep it short, I've not=20 > done this yet. >=20 > >=20 > Now I'm left wondering how this relates to a category.=20 Yes, you are right. It is a category. But it is not a fixed one, the administrator can assign it. How about this text: #### 6.2.2 FACILITY FACILITY is an integer in the range from 0 to 2,147,483,647. It can be used for filtering by the receiver. It is a category, allowing a corase grouping of messages. There exist some traditional FACILITY code semantics for the codes in the range from 0 to 23. These semantics are not closely followed by all senders, and practice has shown that common semantics for message categories are hard to establish. Therefore, no specific semantics for FACILITY codes are specified or implied in this document. There is no relationship between MSGID (Section 6.2.8) and FACILITY, because MSGID identifies a specific message whereas FACILITY specifies a corase message group and is expected to be operator assigned most-often. #### We could add an example that MSGIDs 1000 to 2000 could have a specific FACILITY assigned to "authentication realted messages" where MSGId 2001 to 3000 have a specific FACILITY assigned to "linkUpDown messages". A key point is that FACILITY is often operator assigned (as it is currently) and the operator uses this mostly for filtering. In real-world case of Unix syslogd, facility often tells syslogd the log file a message is to be written to. So it is extremely common that this is customized. >=20 > > >=20 > > S2. Is the length of SENDER-NAME and SENDER-INST sensible? > > SENDER-INST seems > > way too short. Consider needing to name something which is=20 > > the concatenation > > of two IP addresses. It does not fit. Remember this is the=20 > > encoding the > > string, not the integer. We will end up forcing people to=20 > > make up something > > which does fit instead of using something existing. >=20 > Actually, SENDER-NAME and -INST are not meant to be IP=20 > addresses. We have > HOSTNAME and ORIGIN for that. SENDER-NAME and -INST should=20 > identify the type > of sender, most probably a process name or something similar (like > "postfix", "su" in current messages in TAG). I think the size=20 > is sufficient > for this purpose. Given the size limitation we have in UDP=20 > based syslog, I > would like to keep the HEADER size as small as possible. Obviously, we > should not sacrifice things for a short size, but I think we=20 > do not need the > longer sizes here. > =20 > I think you misunderstood my example. This was not the IP=20 > address of the > originator, but a pair of IP addresses that indicated the instance of > something which is referenced using a set of (different) IP=20 > address. What > exactly is a 'process name' suppose to be in IETF land? While=20 > I appreciate > the need for backwards compatibility with deployed syslog, I=20 > think we need > to understand how this naming can be used in a router and how=20 > it maps to > traditional IETF naming. I think some of the more intuitive=20 > ways we have to > name things won't fit in the size indicated. Or is instance=20 > really not an > instance and that is the disconnect? Probably you are right, this is the disconnect. An instance in my point of view is something that others might call a reboot ID. It is a number or string that identifies a given "incarnation" of a the syslog sender. Let me provide some examples: On a router, it might actually be a reboot ID, generated each time the system is reset. On a general-purpose device (with a general purpose OS), it identifies a specific instantiation of the syslog sender process. To use an easy to grip real world example: when you start syslogd on Unix, the first one is instance 4711 (whatever the actual number is is irrelevant). Then you stop syslogd and restart it. Now its ID is 8753 (again, the actual value is irrelevant). I am saying the actual values are irrelevant because duplicates might occur (after another restart, syslogd might again have 4711 - even on successive restarts it might get the same ID). This field is meant as a shortcut to identify a new "instantiation", but not a definite or formal ID. Does this bring us any further? >=20 > Sharon Chisholm > Nortel=20 > Ottawa, Ontario > Canada > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Wed Mar 23 15:26:21 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00942 for ; Wed, 23 Mar 2005 15:26:21 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 7F6F25C7B4; Wed, 23 Mar 2005 12:26:21 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by willers.employees.org (Postfix) with ESMTP id EC8375C7CB for ; Wed, 23 Mar 2005 12:26:19 -0800 (PST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2NKQC521407 for ; Wed, 23 Mar 2005 15:26:12 -0500 (EST) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2NKQBf05176 for ; Wed, 23 Mar 2005 15:26:11 -0500 (EST) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Mar 2005 15:26:11 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402E34B98@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Date: Wed, 23 Mar 2005 15:26:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Syslog-sec] MSGID Versus Facility versus Category X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi Ok. Is this the difference then for the three fields: Facility: Administratively assigned bucket Category: Fixed bucket Message ID: The very smallest grouping of things without getting into instance-specific information? Sharon -------------------- > > > > S1. In section 6, what is the relationship between Facility > > and MSG-ID? They > > seem to serve the same purpose. Is Facility just historical? > > Is MSG-ID what > > we need to use moving forward? (see G3) > > I added this text to the description of FACILITY: > > #### > It is RECOMMENDED that the facility > reflects a type of subsystem, something that a number of > different messages > might be issued from. So it is a kind of corase group. #### > > Does this clarify? Do we need to add similar text to MSGID (in that it > identifies a specific message)? To keep it short, I've not > done this yet. > > > > Now I'm left wondering how this relates to a category. Yes, you are right. It is a category. But it is not a fixed one, the administrator can assign it. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Wed Mar 23 15:33:56 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01673 for ; Wed, 23 Mar 2005 15:33:55 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 8FBBE5C826; Wed, 23 Mar 2005 12:33:56 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by willers.employees.org (Postfix) with ESMTP id 9C8815C7FC for ; Wed, 23 Mar 2005 12:33:54 -0800 (PST) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2NKXq123628 for ; Wed, 23 Mar 2005 15:33:52 -0500 (EST) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2NKXo928782 for ; Wed, 23 Mar 2005 15:33:51 -0500 (EST) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Mar 2005 15:33:51 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402E34BAD@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Date: Wed, 23 Mar 2005 15:33:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi Ok. My current thinking on message truncation is that we want to encourage the dropping of the SD-PARAMS and the retention of the message text. This is the more unique bit and makes for much simpler truncation. We can add a bit to the header if we want or indicate that if the SD-PARAM list is blank, then truncation may have occurred. Ok. a bit in the header is probably better. So, the preference is 1) No truncation 2) Truncation by dropping SD-PARAMS; 3) If 2) not sufficient, truncate message 4) In the case that truncation cannot result in a valid message then dropping. Note that given the current truncation algorithm, this may not actually occur. Sharon -----Original Message----- From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] Sent: Tuesday, February 15, 2005 7:42 AM To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Sharon, > If truncation is required, then the point of truncation be > determined. If it > is within the message text, then the truncation bit be set within the > message header and the message be sent with its reduced size. > If the point > of truncation is somewhere before the message text, then this > message be > discarded. I am not sure if it is appropriate to drop the message completely. At least the drop should be optional (maybe with a rule that the truncated message should not further be forwarded). I am concerned because I think we might loose vital information in this case. As an alternate approach, the "truncation information field" could have three values: n - no truncation occured m - truncation im MSG part s - truncation in STRUCTURED-DATA part that would convey enough information to the (ultimate) receiver so that it can decide how to act on a message. Comments? Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Wed Mar 23 15:39:02 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02193 for ; Wed, 23 Mar 2005 15:39:01 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 8E67B5C810; Wed, 23 Mar 2005 12:39:02 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by willers.employees.org (Postfix) with ESMTP id 4F26D5C7FC for ; Wed, 23 Mar 2005 12:39:01 -0800 (PST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2NKcs124934 for ; Wed, 23 Mar 2005 15:38:54 -0500 (EST) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2NKca812096 for ; Wed, 23 Mar 2005 15:38:36 -0500 (EST) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Mar 2005 15:38:36 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402E34BBF@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Date: Wed, 23 Mar 2005 15:38:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Syslog-sec] Sender-INST X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi I think you just need to add some of this text to the document. It seems that this field is not terribly useful to me, but perhaps for other applications. Also, renaming the field should help. Sharon ---------- > > > > > > S2. Is the length of SENDER-NAME and SENDER-INST sensible? > > SENDER-INST seems > > way too short. Consider needing to name something which is > > the concatenation > > of two IP addresses. It does not fit. Remember this is the > > encoding the > > string, not the integer. We will end up forcing people to > > make up something > > which does fit instead of using something existing. > > Actually, SENDER-NAME and -INST are not meant to be IP > addresses. We have > HOSTNAME and ORIGIN for that. SENDER-NAME and -INST should > identify the type > of sender, most probably a process name or something similar (like > "postfix", "su" in current messages in TAG). I think the size > is sufficient > for this purpose. Given the size limitation we have in UDP > based syslog, I > would like to keep the HEADER size as small as possible. Obviously, we > should not sacrifice things for a short size, but I think we > do not need the > longer sizes here. > > I think you misunderstood my example. This was not the IP > address of the > originator, but a pair of IP addresses that indicated the instance of > something which is referenced using a set of (different) IP > address. What > exactly is a 'process name' suppose to be in IETF land? While > I appreciate > the need for backwards compatibility with deployed syslog, I > think we need > to understand how this naming can be used in a router and how > it maps to > traditional IETF naming. I think some of the more intuitive > ways we have to > name things won't fit in the size indicated. Or is instance > really not an > instance and that is the disconnect? Probably you are right, this is the disconnect. An instance in my point of view is something that others might call a reboot ID. It is a number or string that identifies a given "incarnation" of a the syslog sender. Let me provide some examples: On a router, it might actually be a reboot ID, generated each time the system is reset. On a general-purpose device (with a general purpose OS), it identifies a specific instantiation of the syslog sender process. To use an easy to grip real world example: when you start syslogd on Unix, the first one is instance 4711 (whatever the actual number is is irrelevant). Then you stop syslogd and restart it. Now its ID is 8753 (again, the actual value is irrelevant). I am saying the actual values are irrelevant because duplicates might occur (after another restart, syslogd might again have 4711 - even on successive restarts it might get the same ID). This field is meant as a shortcut to identify a new "instantiation", but not a definite or formal ID. Does this bring us any further? _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec