From kinerklan@charter.net Wed Jul 04 09:24:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I64px-0008Oo-IV; Wed, 04 Jul 2007 09:24:05 -0400 Received: from mtai01.charter.net ([209.225.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I64pu-0007D4-NH; Wed, 04 Jul 2007 09:24:05 -0400 Received: from aa01.charter.net ([10.20.200.153]) by mtai01.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20070704132402.XKII14158.mtai01.charter.net@aa01.charter.net>; Wed, 4 Jul 2007 09:24:02 -0400 Received: from fepweb05 ([10.20.200.55]) by aa01.charter.net with ESMTP id <20070704132402.OHPL9040.aa01.charter.net@fepweb05>; Wed, 4 Jul 2007 09:24:02 -0400 Message-ID: <533660929.1183555442103.JavaMail.root@fepweb05> Date: Wed, 4 Jul 2007 6:24:01 -0700 From: UK LOTTERY BOARD Reply-To: contactclaimsagentallen@yahoo.co.uk Subject: CERTIFIED WINNER!!! MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Sensitivity: Normal X-Originating-IP: from 192.168.1.199 by webmail.charter.net; Wed, 4 Jul 2007 9:23:59 -0400 X-Chzlrs: 0 X-Spam-Score: 2.2 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a REF No:UKNL-L/200-26937 BATCH No:2005MJL-01 TICKET No:20511465463-7644 SERIAL No:S/N-00168 LUCKY No: 887-13-865-37-10-83 CERTIFIED WINNER!!! We are pleased to inform you of the result of the winners of the UK NATIONAL LOTTERY ONLINE PROMO PROGRAMME, held on the 4th July, 2007.The process was carried out through a random selection from a database of over 250,000 email addresses drawn accross the world. You have therefore been approved for a lump sum pay out of 1,000,000 (One Million Pounds Sterling) in cash credited to file UKNL-L/200-26937.To file for your claim, please contact our claims agent; Mr. Allen M. Hamilton TEL:+44 701 113 8046 Email: directorallen_claimsdept@yahoo.co.uk Provide him with the information below: 1.Full Name: 2.Full Address: 3.Marital Status: 4.Occupation: 5.Age: 6.Sex: 7.Nationality: 8.Country Of Residence: 9.Telephone Number: Congratulations once more from all members and staff of this program. Sincerely, Mrs. Lisa Baker. From syslog-bounces@lists.ietf.org Thu Jul 05 10:46:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Sak-0000wK-JF; Thu, 05 Jul 2007 10:45:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Saj-0000ru-OU for syslog@ietf.org; Thu, 05 Jul 2007 10:45:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Saf-0001Tt-Bp for syslog@ietf.org; Thu, 05 Jul 2007 10:45:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 07:45:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEOhjEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,503,1175497200"; d="scan'208"; a="500314080:sNHT9416548886" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l65EjiLA020823 for ; Thu, 5 Jul 2007 07:45:44 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65EjeXI010047 for ; Thu, 5 Jul 2007 14:45:44 GMT Date: Thu, 5 Jul 2007 07:45:39 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=962; t=1183646744; x=1184510744; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20IESG=20Discusses=20and=20Comments |Sender:=20; bh=8t+CjshYAV8jk+JQTKR21Z52S/y+Uj1B2FIDZhTnQ+I=; b=GzEpPHfmhY7jpl90kw3AwsacvCYQyqQ7ogea8Tdpi6mmKyhzf4M3NfzpX1Hi9+iNJ0sgw8Sk 62zFfX92AuFXRnYqpBzJPouPe+Pj7Ta41tkwDJChdgpQralCryQ2bloN; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Syslog] IESG Discusses and Comments X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, David and I have been trying to address the open DISCUSSes on -syslog-protocol and -syslog-transport-udp. https://datatracker.ietf.org/idtracker/ballot/1800/ As an aside: Sam has reviewed -syslog-transport-tls and has asked for some modifications. Miao and Yuzhi are working on those and we expect to get that back to the WG for review soon. Until then, we're pushing forward with -protocol and -udp. I've identified 4 Discuss topics: - Source Address - UDP Length - UDP Checksum - Congestion Control For the first three I believe we have some resolution. The WG needs to verify this. There still seems to be an open issue with the last one. When I send these out, please comment. There are also many Comments from the IESG. Some have resulted in some moderate changes, mostly editorial, in the documents. Others I havn't addressed as those are not critical to progressing these documents. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 10:47:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Sbk-0002Ez-L5; Thu, 05 Jul 2007 10:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Sbj-0002EU-17 for syslog@ietf.org; Thu, 05 Jul 2007 10:46:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6SbU-0001kl-W8 for syslog@ietf.org; Thu, 05 Jul 2007 10:46:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 07:46:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEOhjEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,503,1175497200"; d="scan'208"; a="500314484:sNHT26861128" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l65EkiqV022469 for ; Thu, 5 Jul 2007 07:46:44 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65EkiXI010761 for ; Thu, 5 Jul 2007 14:46:44 GMT Date: Thu, 5 Jul 2007 07:46:43 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=890; t=1183646804; x=1184510804; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Discuss=20-=20Source=20Address |Sender:=20; bh=ARkf1xq4i8jPWUwhmG6hTxh4J9Ue7yRhgU2rml5Nu4Y=; b=MEcOXPAKEBdIxY2fnsT08f+mqoXLyziHcVC7KV2iBcJ57Qtx+8u6+4RTTAIbu6gInNFCM2ru bwJsJhN3RZcLG2QGjdskRRTEfQ3O47Ioh7sy1QRbZoiC06qHhHhqNd5l; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Syslog] Discuss - Source Address X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Discuss - Source Address Lars: draft-ietf-syslog-protocol-21, Section 5., paragraph 2: > If a syslog application is running on a machine > that has both statically and dynamically assigned addresses, then > that value SHOULD be from the statically assigned addresses. As an > alternative, the syslog application MAY use the IP address of the > interface that is used to send the message. DISCUSS: So if a machine has only a dynamic address, it should instead use 127.0.0.1 in syslog messages, because that's statically assigned? That doesn't seem to make sense. Also, in practice, it will be difficult for the syslog sender to determine which addresses are statically or dynamically assigned (think MobileIP or even HIP). Proposed Resolution: The author and the chairs recommend removing this paragraph. Any objection this this? _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 10:48:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Sck-0003m3-Ni; Thu, 05 Jul 2007 10:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Scj-0003ly-2F for syslog@ietf.org; Thu, 05 Jul 2007 10:48:01 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ScY-0001sC-LZ for syslog@ietf.org; Thu, 05 Jul 2007 10:48:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 05 Jul 2007 07:47:50 -0700 X-IronPort-AV: i="4.16,503,1175497200"; d="scan'208"; a="6735184:sNHT18352128" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l65ElnKt026902 for ; Thu, 5 Jul 2007 07:47:49 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65ElnXI011466 for ; Thu, 5 Jul 2007 14:47:49 GMT Date: Thu, 5 Jul 2007 07:47:49 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1037; t=1183646869; x=1184510869; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Discuss=20-=20UDP=20Length |Sender:=20; bh=J34dVDnOFHMgB8DIuLIthdtNkFQYk/PDEk1itf6ZRbo=; b=obFLO4BiDnObV3MEnGNrJ829kp9ZfyJS67NIxV/Hh2CATfZLRGuGx4zFaNX3aWEAJUYqEM8M lCfLf1eeZydH8GhvXDNOAMCw0TxvzDxPmb31sm3kHa40fIJx9UGptn4+; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Syslog] Discuss - UDP Length X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Discuss - UDP Length Lars: draft-ietf-syslog-transport-udp-09, Section 65535, paragraph 0: > This transport mapping supports transmission of syslog messages up to > 65535 octets in size. This limit stems from the maximum supported > UDP payload of 65535 octets specified in the RFC 768 [1]. DISCUSS: The RFC768 length field includes the UDP header, so the permitted payload size is 65535 minus the UDP header (and for IPv4, minus the IP header, because IPv4 has a 16-bit length field that also includes the header length.) Proposed Resolution: Change the paragraph to This transport mapping supports transmission of syslog messages up to 65535 octets minus the UDP header length. This limit stems from the maximum supported UDP size of 65535 octets specified in the RFC 768 [1]. For IPv4, the maximum payload size is 65535 octets minus the UDP header and minus the IP header because IPv4 has a 16-bit length field that also includes the header length. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 10:56:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6SlF-0005Tu-VM; Thu, 05 Jul 2007 10:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6SlF-0005Tp-Jo for syslog@ietf.org; Thu, 05 Jul 2007 10:56:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Sl6-0003WU-So for syslog@ietf.org; Thu, 05 Jul 2007 10:56:49 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Jul 2007 07:56:40 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOeijEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,503,1175497200"; d="scan'208"; a="177071220:sNHT112103883" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l65Eueir000567 for ; Thu, 5 Jul 2007 07:56:40 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l65Eudmp015733 for ; Thu, 5 Jul 2007 14:56:39 GMT Date: Thu, 5 Jul 2007 07:56:39 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4103; t=1183647400; x=1184511400; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Discuss=20-=20UDP=20Checksum |Sender:=20; bh=VVPpxpgUTyjun/eR2z49y9bi/QFoTc+8pL2fTwlNHRo=; b=XNYTcaq9tfoICtq7rKPrQuTIYX4ObOgJOcsNA4nqIwodO6vBXAKlP5uMGpbjgqcFMG/5cy8q SQUApV3HQkYTgcv8cAOCGmopZJ7Pqn1fKJtlFkRGAcncEGnwR54VUCZQ; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [Syslog] Discuss - UDP Checksum X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Discuss - UDP Checksum === Magnus: Discuss [2007-06-19]: UDP transport: Section 3.6: It is RECOMMENDED that syslog senders use valid UDP checksums when sending messages over IPv4 and IPv6. It is RECOMMENDED that syslog receivers check the checksums whenever they are present (i.e. the UDP header checksum field value is not 0) and discard messages with incorrect checksums. Note that this is typically accomplished by the UDP layer implementation, and some UDP implementations allow for checksum validation to be enabled or disabled. Why isn't these MUST? For IPv6 it is an MUST and for IPv4 does there exist a single reason not to use the UDP checksum? === Lars: draft-ietf-syslog-transport-udp-09, Section 3.6., paragraph 2: > It is RECOMMENDED that syslog senders use valid UDP checksums when > sending messages over IPv4 and IPv6. Agree with Tim's DISCUSS - this language weakens the MUST for IPv6. === Tim: Discuss [2007-06-19]: In syslog-transport-udp-09, Section 3.6 (UDP Checksums): The second and third paragraphs could be read as relaxing the requirements (specified in RFC 2460) for IPv6 nodes to generate and verify UDP checksums. It would be clearer if the text described the recommendations for IPv4 independently, and then noted the requirements inherited from RFC 2460 with respect to IPv6. === Discussion w/ Magnus: If I understand this correctly the issue that the first paragraph tries to address is the usage of the UDP checksum, rather than people setting checksums not matching the content of the packet. Because of that I would like to replace "valid" with "the" and remove the plural on checksums. By this response I assume that you had no motivation why one shouldn't use the checksum. If that is true, I would recommend staying at MUST strength. In fact I would probably prefer to have the RECOMMENDED to be a MUST also. Unless you have a reason why one wouldn't checksum the UDP syslog packets I would strongly recommend that it is turned on. > Our motivation was to not get too far into the way that UDP is known to > work. If the proper way to write the document is to say that UDP MUST be > checked then we'll gladly do that. Well, UDP for IPv4 does have this option of turning of the checksum. However, I am a strong believer that in most cases it is not the right thing to do. In the syslog case, bit-errors in the text message part may be fine. However, you don't want to have errors in the priority field. Thus throwing away thus packet is probably better than to have them end up in the wrong queue. As I see it moving form RECOMMENDED to MUST will probably not make much difference. You anyway need to write syslog receivers that are handling malformed messages. But it does allow a sender to not use the checksum if they want to. And if the WG is fine with that, having understood the potential issues with that then I am fine. I simply want to ensure that you are aware of the implications of what you write. Proposed resolution (Anton) Ok. If syslog receiver MUST check checksums, we need to also say what it must do in two cases: (a) checksum is not there (value 0) and (b) checksum is wrong. We used to recommend discard only for case B (when it is present and wrong) like this: "It is RECOMMENDED that syslog receivers check the checksums whenever they are present (i.e. the UDP header checksum field value is not 0) and discard messages with incorrect checksums. " I suggest we say something stronger in line with a MUST: syslog senders MUST use UDP checksums when sending messages over IPv4. syslog senders MUST use UDP checksums when sending messages over IPv6. syslog receivers MUST check the checksums and MUST discard messages with missing or incorrect checksums. Note that this is typically accomplished by the UDP layer implementation, and some UDP implementations allow for checksum validation to be enabled or disabled. Agreed? _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 10:59:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6SnN-0000YS-7W; Thu, 05 Jul 2007 10:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6SnM-0000YL-7z for syslog@ietf.org; Thu, 05 Jul 2007 10:59:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Sn7-0003ym-Fk for syslog@ietf.org; Thu, 05 Jul 2007 10:59:00 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 07:58:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJqjjEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,503,1175497200"; d="scan'208"; a="500318593:sNHT115882822" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l65EwiYO011728 for ; Thu, 5 Jul 2007 07:58:44 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l65Ewikb014236 for ; Thu, 5 Jul 2007 14:58:44 GMT Date: Thu, 5 Jul 2007 07:58:44 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2986; t=1183647524; x=1184511524; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Discuss=20-=20Congestion=20Control |Sender:=20; bh=EqxopROQDoCeRqLqtvzQ+l2dvhhscPEZv2aZ8PyH1+8=; b=DwYXE/pDuyON1JuvWZoIKMF8ceZYKJGR9XPOfGfO3uBKZ1h3vVKb1bdY1MabZhjHHaQoCfQz +Owq9KxgZv2H8ElJ4lOzdnv8oy//jhFxBQfDfA2E3FsfjRZbVV/234cU; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [Syslog] Discuss - Congestion Control X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Discuss - Congestion Control Magnus: But what I think is needed here is some clear and normative requirement on how to avoid and limit congestion. First of all I would like to see a restriction on the applicability of this transport to within a controlled environment unless the rate is capped to a level that is TCP friendly or the full path is provisioned to handle the traffic. There should also be a discussion on how one rate limits SYSLOG traffic. Magnus: If any higher rates of packets are to be sent over best effort networks then a feedback mechanism is needed. That would probably need to include forward path UDP packetization layer with sequence number to enable loss detection. Complemented with feedback traffic to enable rate control of outgoing traffic. That could also resolve the PMTUD issue. Lars: draft-ietf-syslog-protocol-21, Section 8.5., paragraph 2: > It may be desirable to use a transport with guaranteed delivery to > mitigate congestion. Reliable delivery and congestion control are orthogonal features. A reliable transport will not necessarily have congestion control, and vice versa. Lars: draft-ietf-syslog-protocol-21, Section 8.5., paragraph 3: > It may also be desirable to include rate-limiting features in syslog > originators and relays. This can reduce potential congestion > problems when message bursts happen. This is too weak a statement on congestion control. See DISCUSS above. Lars: Given the issues that the UDP transport has with congestion control, security and fragmentation, I'd like the document to recommend the TLS-based transport over the UDP-based one for general use, i.e., when the network is not specifically provisioned for this type of traffic. Prposed Resolution: + Place text in syslog-protocol, syslog-transport-tls, and syslog-transport-udp to state that - udp transport is to be used only where the network is specifically provisioned for this type of traffic, - tls is to be used in all cases where congestion issues may be a concern. + Remove the text in syslog-protocol which states that reliable delivery will mitigate congestion. Response from Lars: I'd like to see the actual text changes, but this proposal exactly captures what I'd like to see happen. Response from Magnus: This mostly addresses my concerns. I still think there is one major issue around this with congestion control. And that is some description on how to rate-limit your traffic. Either in UDP to some pre-configured threshold and in the case of TLS over TCP the rate actually available. There can occur situations where the amount of generated data will be larger than what can be transfered. How does one resolve this? I think it probably needs to be more text in syslog-protocol spec about this. How to use scope and prio to determine which messages to throw away or queue up (within limits). _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 13:21:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6V1K-0007U5-BX; Thu, 05 Jul 2007 13:21:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6V1I-0007Ta-Qh for syslog@ietf.org; Thu, 05 Jul 2007 13:21:32 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6V1I-0003pX-Ga for syslog@ietf.org; Thu, 05 Jul 2007 13:21:32 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2007 19:21:24 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKnEjEaQ/uCLh2dsb2JhbACBS41iAQEBCA4s X-IronPort-AV: i="4.16,504,1175464800"; d="scan'208"; a="147343900:sNHT26590254" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l65HLNrT019212; Thu, 5 Jul 2007 19:21:23 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp499.cisco.com [10.61.65.243]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65HLNTC001853; Thu, 5 Jul 2007 17:21:23 GMT Message-ID: <468D2892.9080304@cisco.com> Date: Thu, 05 Jul 2007 19:21:22 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Chris Lonvick Subject: Re: [Syslog] Discuss - Congestion Control References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1380; t=1183656083; x=1184520083; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20Discuss=20-=20Congestion=20Control |Sender:=20; bh=xpFmKy2A3lDZlGFQ0mOXIojQ7pRMLpirHJgoVDiHB+4=; b=L+078S3N7btkIaFTMWKV/nwMwmh3/eIPdX1SFhBai2X2b+tYIYhWDRHQwRcQIhkAnkqHqfr9 ihIBU+3NFgsAlgUzNPWUUsOwWe8TsdpYHXP1EziVSNe0H57Mi3wR0fSx; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, Magnus, > Response from Magnus: > This mostly addresses my concerns. I still think there is one major > issue around this with congestion control. And that is > some description on how to rate-limit your traffic. Either in UDP to > some pre-configured threshold and in the case of TLS > over TCP the rate actually available. There can occur situations where > the amount of generated data will be larger than > what can be transfered. How does one resolve this? I think it probably > needs to be more text in syslog-protocol spec about this. How to use > scope and prio to determine which messages to throw away or queue up > (within limits). > Most sources of potentially voluminous syslog messages have a rate limit mechanism already in as much as they will aggregate messages (the old "Last message repeated N times" thing). I propose that we add some wording along the lines of the following in syslog-udp: syslog generator implementors must be mindful of the downstream resources their messages will consume, both from a network and server standpoint. A single syslog source that has the capability to produce a flood of messages should aggregate and rate limit them in some appropriate fashion. An event count combined with rate limiting has been used very successfully in the past. How about that? _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 13:26:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6V5j-0002XJ-WA; Thu, 05 Jul 2007 13:26:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6V5i-0002Wy-Ph for syslog@ietf.org; Thu, 05 Jul 2007 13:26:06 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6V5i-0004Nm-CD for syslog@ietf.org; Thu, 05 Jul 2007 13:26:06 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6599684EB5; Thu, 5 Jul 2007 19:25:33 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30197-06; Thu, 5 Jul 2007 19:25:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5CCB86264; Thu, 5 Jul 2007 19:25:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 227982BD5DF; Thu, 5 Jul 2007 19:25:27 +0200 (CEST) Date: Thu, 5 Jul 2007 19:25:27 +0200 From: Juergen Schoenwaelder To: Chris Lonvick Subject: Re: [Syslog] Discuss - UDP Checksum Message-ID: <20070705172527.GA4214@elstar.local> Mail-Followup-To: Chris Lonvick , syslog@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, Jul 05, 2007 at 07:56:39AM -0700, Chris Lonvick wrote: > We used to recommend discard only for case B (when it is present and > wrong) like this: > > "It is RECOMMENDED that syslog receivers check the checksums whenever > they are present (i.e. the UDP header checksum field value is not 0) > and discard messages with incorrect checksums. " > > I suggest we say something stronger in line with a MUST: > > syslog senders MUST use UDP checksums when sending messages over IPv4. > syslog senders MUST use UDP checksums when sending messages over IPv6. > > syslog receivers MUST check the checksums and MUST discard messages > with missing or incorrect checksums. Note that this is typically > accomplished by the UDP layer implementation, and some UDP > implementations allow for checksum validation to be enabled or > disabled. Stupid question: Why is UDP checksumming discussed at all in the SYSLOG UDP transport mapping? People implementing syslog hardly have control over the UDP layer (and for sure not exclusively) and so if at all it only makes sense to me to have operational guidelines that UDP checksums are a good idea - but then again this would not be very much SYSLOG specific - so why discuss this at all in this document? Do we from now on want to have every UDP transport document state that UDP checksums are a good idea? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 14:30:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6W5y-0000Xq-Fl; Thu, 05 Jul 2007 14:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6W5x-0000Xa-A4 for syslog@ietf.org; Thu, 05 Jul 2007 14:30:25 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6W53-0006ej-B1 for syslog@ietf.org; Thu, 05 Jul 2007 14:30:25 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 11:29:28 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANLUjEarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,504,1175497200"; d="scan'208"; a="500391166:sNHT134828688" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l65ITSPd024924; Thu, 5 Jul 2007 11:29:28 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l65ITSGX020272; Thu, 5 Jul 2007 18:29:28 GMT Date: Thu, 5 Jul 2007 11:29:27 -0700 (PDT) From: Chris Lonvick To: Juergen Schoenwaelder Subject: Re: [Syslog] Discuss - UDP Checksum In-Reply-To: <20070705172527.GA4214@elstar.local> Message-ID: References: <20070705172527.GA4214@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1885; t=1183660168; x=1184524168; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Discuss=20-=20UDP=20Checksum |Sender:=20; bh=4lxKfvXwW3Z/etBGJTnYbhOWRH9UCQu7R9VENm3wrUE=; b=IRPbdnesGPuDD6Ga9l0nhPKph5W14Jet8bAogbLlOJqXUovgKmjZdPtOhYXHfP+Iwe27gqHf rHaZUpEvgWXOaR22MHhpypxMGlIGAISZxP7sgltH0pZlg70KHW798hnGBFR8N+/+dCjUVXIpfX gi8XrS/egZJ8l1OHdtAjK4A54=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Juergen, Good question. ..and not something that we'll be able to answer in our WG. I'll bring it up in the ietf@ietf list. Thanks, Chris On Thu, 5 Jul 2007, Juergen Schoenwaelder wrote: > On Thu, Jul 05, 2007 at 07:56:39AM -0700, Chris Lonvick wrote: > >> We used to recommend discard only for case B (when it is present and >> wrong) like this: >> >> "It is RECOMMENDED that syslog receivers check the checksums whenever >> they are present (i.e. the UDP header checksum field value is not 0) >> and discard messages with incorrect checksums. " >> >> I suggest we say something stronger in line with a MUST: >> >> syslog senders MUST use UDP checksums when sending messages over IPv4. >> syslog senders MUST use UDP checksums when sending messages over IPv6. >> >> syslog receivers MUST check the checksums and MUST discard messages >> with missing or incorrect checksums. Note that this is typically >> accomplished by the UDP layer implementation, and some UDP >> implementations allow for checksum validation to be enabled or >> disabled. > > Stupid question: Why is UDP checksumming discussed at all in the > SYSLOG UDP transport mapping? People implementing syslog hardly have > control over the UDP layer (and for sure not exclusively) and so if at > all it only makes sense to me to have operational guidelines that UDP > checksums are a good idea - but then again this would not be very much > SYSLOG specific - so why discuss this at all in this document? > > Do we from now on want to have every UDP transport document state that > UDP checksums are a good idea? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 14:52:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6WR0-0000DJ-CM; Thu, 05 Jul 2007 14:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6WQy-0008U5-Cb for syslog@ietf.org; Thu, 05 Jul 2007 14:52:08 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6WQ6-0001Qw-QI for syslog@ietf.org; Thu, 05 Jul 2007 14:52:08 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Jul 2007 11:51:14 -0700 X-IronPort-AV: i="4.16,504,1175497200"; d="scan'208"; a="6824570:sNHT22595724" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l65IpElj002013; Thu, 5 Jul 2007 11:51:14 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l65IpEGX025338; Thu, 5 Jul 2007 18:51:14 GMT Date: Thu, 5 Jul 2007 11:51:13 -0700 (PDT) From: Chris Lonvick To: Juergen Schoenwaelder Subject: Re: [Syslog] Discuss - UDP Checksum In-Reply-To: Message-ID: References: <20070705172527.GA4214@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3297; t=1183661474; x=1184525474; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Discuss=20-=20UDP=20Checksum |Sender:=20; bh=Ai9Z7jtdsi4BGR4qqqGoFtdZ0qs9UTgsvjyU8x7CI88=; b=rtUAvS7YoKUwNw2rLEYcSL5ok4uy6yH7JRBkZxqdJIxAm8nFrV4OebPMUr7LaFd5Vl04FxAX CIrRN2FJf+L2TMhqcg9NQgiaVs/EJ4blTkrHTrhF4M2FWNHU20kKiiye; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, On the other hand... ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-udp-guidelines-01.txt "UDP Usage Guidelines for Application Designers" (Lars Eggert is co-author). Section 3.4 is "Checksum Guidelines". It appears that there is enough question about this that specific guidance should be given in RFCs. Which brings us back to our original question. Is the proposed language below what the WG wants? A quick (and not thorough) check of RFCs which have "UDP" in their titles shows that RFC 3948, "UDP Encapsulation of IPsec ESP Packets ", pub. Jan 2005, does have specific guidance on the UDP checksum. To wit: === The UDP header is a standard [RFC0768] header, where o the Source Port and Destination Port MUST be the same as that used by IKE traffic, o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend on the UDP checksum being a zero value. === I'd like to hear from people who have current syslog/udp code. What works for you? Thanks, Chris On Thu, 5 Jul 2007, Chris Lonvick wrote: > Hi Juergen, > > Good question. ..and not something that we'll be able to answer in our WG. > I'll bring it up in the ietf@ietf list. > > Thanks, > Chris > > > On Thu, 5 Jul 2007, Juergen Schoenwaelder wrote: > >> On Thu, Jul 05, 2007 at 07:56:39AM -0700, Chris Lonvick wrote: >> >> > We used to recommend discard only for case B (when it is present and >> > wrong) like this: >> > >> > "It is RECOMMENDED that syslog receivers check the checksums whenever >> > they are present (i.e. the UDP header checksum field value is not 0) >> > and discard messages with incorrect checksums. " >> > >> > I suggest we say something stronger in line with a MUST: >> > >> > syslog senders MUST use UDP checksums when sending messages over >> > IPv4. >> > syslog senders MUST use UDP checksums when sending messages over >> > IPv6. >> > >> > syslog receivers MUST check the checksums and MUST discard messages >> > with missing or incorrect checksums. Note that this is typically >> > accomplished by the UDP layer implementation, and some UDP >> > implementations allow for checksum validation to be enabled or >> > disabled. >> >> Stupid question: Why is UDP checksumming discussed at all in the >> SYSLOG UDP transport mapping? People implementing syslog hardly have >> control over the UDP layer (and for sure not exclusively) and so if at >> all it only makes sense to me to have operational guidelines that UDP >> checksums are a good idea - but then again this would not be very much >> SYSLOG specific - so why discuss this at all in this document? >> >> Do we from now on want to have every UDP transport document state that >> UDP checksums are a good idea? >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 15:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Wvt-0003Dy-Jd; Thu, 05 Jul 2007 15:24:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Wvs-00036s-Dk for syslog@ietf.org; Thu, 05 Jul 2007 15:24:04 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Wvs-0007lY-0T for syslog@ietf.org; Thu, 05 Jul 2007 15:24:04 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A80C86279; Thu, 5 Jul 2007 21:23:55 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05448-03; Thu, 5 Jul 2007 21:23:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4177586523; Thu, 5 Jul 2007 21:23:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 970B62BD95A; Thu, 5 Jul 2007 21:23:48 +0200 (CEST) Date: Thu, 5 Jul 2007 21:23:48 +0200 From: Juergen Schoenwaelder To: Chris Lonvick Subject: Re: [Syslog] Discuss - UDP Checksum Message-ID: <20070705192348.GA4412@elstar.local> Mail-Followup-To: Chris Lonvick , syslog@ietf.org References: <20070705172527.GA4214@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, Jul 05, 2007 at 11:51:13AM -0700, Chris Lonvick wrote: > Which brings us back to our original question. Is the proposed language > below what the WG wants? As an implementor, I have a problem with the statement syslog senders MUST use UDP checksums when sending messages over IPv4 since on several platforms, I simply can't ensure this when I write a portable SYSLOG implementation. So I can either claim my code to be RFC compliant while in a real deployment it might not behave conforming to the RFC (depending on the kernel settings for example), or I tell the truth that I can never guarantee compliant behaviour of my implementation. So if we need to have language at all, what about syslog senders MUST NOT disable UDP checksums This is something I can implement much more easily since the default seems to be enabled on those platforms I am familiar with. ;-) Or alternatively go back to SHOULD syslog senders SHOULD use UDP checksums when sending messages over IPv4 with the likely non-obvious interpretation that you should enable / not disable checksums in your code but if the kernel bites you, you are still fine. My point is that if we put out requirements for implementations, lets do this in a way that a coder can reasonably implement them. /js [No, I am not implementing SYSLOG right now - but I am familiar with other protocols running over UDP and hence this got my attention.] -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 16:29:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6XxZ-0001VT-JS; Thu, 05 Jul 2007 16:29:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6XxW-0001Rs-83 for syslog@ietf.org; Thu, 05 Jul 2007 16:29:50 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6XxB-0004zI-NE for syslog@ietf.org; Thu, 05 Jul 2007 16:29:50 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id CEBDE9C00C; Thu, 5 Jul 2007 22:58:49 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08422-09; Thu, 5 Jul 2007 22:58:39 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id ABB159C00B; Thu, 5 Jul 2007 22:58:39 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Discuss - UDP Checksum X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Jul 2007 22:29:22 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2784B0@grfint2.intern.adiscon.com> In-Reply-To: <20070705192348.GA4412@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Discuss - UDP Checksum thread-index: Ace/OhbSEEhUMQ3USTiiiKRYBNmPBwACEoGQ References: <20070705172527.GA4214@elstar.local> <20070705192348.GA4412@elstar.local> From: "Rainer Gerhards" To: , "Chris Lonvick" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org [Strictly speaking as an implementor, not as a draft editor] I second Juergen's point of view. I go even further. When receiving, I take great care not to loose any message. Under stress conditions (e.g. low system memory), I accept lage deformations of the message. Checksums are my least concern and I wouldn't discard a message "just" because the checksum is invalid. I will defintely ignore any such MUST in a RFC, at least by default. I may, however, flag this message as being in error (which possibly means it ends up in a different bin). The reasoning behind all this is that a vital message might be lost forever and it is better to receive it in some degraded state. At least this is what my *actual* users are requesting. Rainer > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, July 05, 2007 9:24 PM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] Discuss - UDP Checksum >=20 > On Thu, Jul 05, 2007 at 11:51:13AM -0700, Chris Lonvick wrote: >=20 > > Which brings us back to our original question. Is the=20 > proposed language=20 > > below what the WG wants? >=20 > As an implementor, I have a problem with the statement >=20 > syslog senders MUST use UDP checksums when sending messages=20 > over IPv4 >=20 > since on several platforms, I simply can't ensure this when I write a > portable SYSLOG implementation. So I can either claim my code to be > RFC compliant while in a real deployment it might not behave > conforming to the RFC (depending on the kernel settings for example), > or I tell the truth that I can never guarantee compliant behaviour of > my implementation. >=20 > So if we need to have language at all, what about >=20 > syslog senders MUST NOT disable UDP checksums >=20 > This is something I can implement much more easily since the default > seems to be enabled on those platforms I am familiar with. ;-)=20 >=20 > Or alternatively go back to SHOULD >=20 > syslog senders SHOULD use UDP checksums when sending=20 > messages over IPv4 >=20 > with the likely non-obvious interpretation that you should enable / > not disable checksums in your code but if the kernel bites you, you > are still fine. >=20 > My point is that if we put out requirements for implementations, lets > do this in a way that a coder can reasonably implement them. >=20 > /js >=20 > [No, I am not implementing SYSLOG right now - but I am familiar with > other protocols running over UDP and hence this got my attention.] >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 17:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YeR-0000KM-KB; Thu, 05 Jul 2007 17:14:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YeP-0000KA-NI for syslog@ietf.org; Thu, 05 Jul 2007 17:14:09 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6YeP-0003hG-8V for syslog@ietf.org; Thu, 05 Jul 2007 17:14:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 14:14:08 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH77jEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="500441369:sNHT28148600" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l65LE8bE025574; Thu, 5 Jul 2007 14:14:08 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l65LE7mp021215; Thu, 5 Jul 2007 21:14:07 GMT Date: Thu, 5 Jul 2007 14:14:06 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] Discuss - UDP Checksum In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA2784B0@grfint2.intern.adiscon.com> Message-ID: References: <20070705172527.GA4214@elstar.local> <20070705192348.GA4412@elstar.local> <577465F99B41C842AAFBE9ED71E70ABA2784B0@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3925; t=1183670048; x=1184534048; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20[Syslog]=20Discuss=20-=20UDP=20Checksum |Sender:=20; bh=b5uZ47PGyj4TAQX2TKvKad/zI//DAe/Pqcqa9GgXwyI=; b=UnjY8q7uw7P6NbZKzJIczvPZ52rKFln7IyOuMS6JOPlXKtKj9rzlXc2Bs5e0fT5FgeWeEp3S Ws2VAjciPp8E80w5V8HcvGU35NNNcx617aOX1Fg1ux29HOxIKnDH3d7y; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, How about the following: syslog senders MUST NOT disable UDP checksums. syslog senders SHOULD use UDP checksums when sending messages over IPv4. syslog senders MUST use UDP checksums when sending messages over IPv6. syslog receivers should be lenient in what they receive. IPv4 receivers SHOULD check the UDP checksums. They SHOULD accept a syslog message with a zero checksum. They MAY discard messages with invalid checksums, or they MAY accept them and attempt to process them. IPv6 receivers MUST check the UDP checksums and MUST discard UDP packets containing a zero checksum. As a point to this, does anyone actually control the UDP subprocess so that their syslogd will receive corrupt syslog messages? That third sentence of the second paragraph could use some scrutiny. Thanks, Chris On Thu, 5 Jul 2007, Rainer Gerhards wrote: > [Strictly speaking as an implementor, not as a draft editor] > > I second Juergen's point of view. > > I go even further. When receiving, I take great care not to loose any > message. Under stress conditions (e.g. low system memory), I accept lage > deformations of the message. Checksums are my least concern and I > wouldn't discard a message "just" because the checksum is invalid. I > will defintely ignore any such MUST in a RFC, at least by default. I > may, however, flag this message as being in error (which possibly means > it ends up in a different bin). The reasoning behind all this is that a > vital message might be lost forever and it is better to receive it in > some degraded state. At least this is what my *actual* users are > requesting. > > Rainer > >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, July 05, 2007 9:24 PM >> To: Chris Lonvick >> Cc: syslog@ietf.org >> Subject: Re: [Syslog] Discuss - UDP Checksum >> >> On Thu, Jul 05, 2007 at 11:51:13AM -0700, Chris Lonvick wrote: >> >>> Which brings us back to our original question. Is the >> proposed language >>> below what the WG wants? >> >> As an implementor, I have a problem with the statement >> >> syslog senders MUST use UDP checksums when sending messages >> over IPv4 >> >> since on several platforms, I simply can't ensure this when I write a >> portable SYSLOG implementation. So I can either claim my code to be >> RFC compliant while in a real deployment it might not behave >> conforming to the RFC (depending on the kernel settings for example), >> or I tell the truth that I can never guarantee compliant behaviour of >> my implementation. >> >> So if we need to have language at all, what about >> >> syslog senders MUST NOT disable UDP checksums >> >> This is something I can implement much more easily since the default >> seems to be enabled on those platforms I am familiar with. ;-) >> >> Or alternatively go back to SHOULD >> >> syslog senders SHOULD use UDP checksums when sending >> messages over IPv4 >> >> with the likely non-obvious interpretation that you should enable / >> not disable checksums in your code but if the kernel bites you, you >> are still fine. >> >> My point is that if we put out requirements for implementations, lets >> do this in a way that a coder can reasonably implement them. >> >> /js >> >> [No, I am not implementing SYSLOG right now - but I am familiar with >> other protocols running over UDP and hence this got my attention.] >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 05 19:16:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aYy-0007oM-Cx; Thu, 05 Jul 2007 19:16:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aYw-0007UH-5I for syslog@ietf.org; Thu, 05 Jul 2007 19:16:38 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6aYs-0008RW-N2 for syslog@ietf.org; Thu, 05 Jul 2007 19:16:38 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F6BD84EB5; Fri, 6 Jul 2007 01:16:34 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19724-01; Fri, 6 Jul 2007 01:16:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C28DD86524; Fri, 6 Jul 2007 01:16:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2A7B12BDEE7; Fri, 6 Jul 2007 01:16:29 +0200 (CEST) Date: Fri, 6 Jul 2007 01:16:29 +0200 From: Juergen Schoenwaelder To: Chris Lonvick Subject: Re: [Syslog] Discuss - UDP Checksum Message-ID: <20070705231629.GA4735@elstar.local> Mail-Followup-To: Chris Lonvick , Rainer Gerhards , syslog@ietf.org References: <20070705192348.GA4412@elstar.local> <577465F99B41C842AAFBE9ED71E70ABA2784B0@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, Jul 05, 2007 at 02:14:06PM -0700, Chris Lonvick wrote: > How about the following: > > syslog senders MUST NOT disable UDP checksums. syslog senders SHOULD > use UDP checksums when sending messages over IPv4. syslog senders MUST > use UDP checksums when sending messages over IPv6. The last sentence is a bit like requiring that the IPv6 implementation your code happens to run on MUST be correct (and I have no clue how to turn this requirement into syslog code). > syslog receivers should be lenient in what they receive. IPv4 > receivers SHOULD check the UDP checksums. They SHOULD accept a > syslog message with a zero checksum. They MAY discard messages > with invalid checksums, or they MAY accept them and attempt to process > them. IPv6 receivers MUST check the UDP checksums and MUST discard UDP > packets containing a zero checksum. I am not sure the MAY discard or MAY accept sentence is needed. My proposal would be: syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders SHOULD use UDP checksums when sending messages. Note that RFC 2460 [RFC2460] mandates the use of UDP checksums when sending UDP datagrams over IPv6. syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog receivers SHOULD check UDP checksums and they SHOULD accept a syslog message with a zero checksum. Note that RFC 2460 [RFC2460] mandates the use of checksums for UDP over IPv6. By simply refering to the IPv6 requirement for UDP checksums, we avoid making this also a syslog requirement. I think we should not use MUST language for something that can only be implemented correctly below the syslog software layer. [Enough hair splitting for today. ;-] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jul 08 18:15:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7f2Q-0007yl-JF; Sun, 08 Jul 2007 18:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7f20-00071L-AZ; Sun, 08 Jul 2007 18:15:05 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7f1y-0001dW-GG; Sun, 08 Jul 2007 18:15:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 49AB226E77; Sun, 8 Jul 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7f1y-00027B-5S; Sun, 08 Jul 2007 18:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 08 Jul 2007 18:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-sign-22.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.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 : Signed syslog Messages Author(s) : J. Kelsey, et al. Filename : draft-ietf-syslog-sign-22.txt Pages : 36 Date : 2007-7-8 This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC xxxx, "The syslog Protocol". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-22.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-sign-22.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-sign-22.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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-8170747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-sign-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-sign-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-8170747.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Mon Jul 09 13:15:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wpc-00078T-Rj; Mon, 09 Jul 2007 13:15:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wpV-0006mo-PD; Mon, 09 Jul 2007 13:15:22 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7wpV-00050G-Hu; Mon, 09 Jul 2007 13:15:21 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 61D012ACAB; Mon, 9 Jul 2007 17:15:06 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7wpF-00047n-Nt; Mon, 09 Jul 2007 13:15:05 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 13:15:05 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-tc-mib-02.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.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 : Textual Conventions for Syslog Management Author(s) : G. Keeni Filename : draft-ietf-syslog-tc-mib-02.txt Pages : 13 Date : 2007-7-9 This MIB module defines textual conventions to represent facility and severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-02.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-tc-mib-02.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-tc-mib-02.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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-9123953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-tc-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-tc-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9123953.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Mon Jul 09 13:15:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wph-0007HA-9Q; Mon, 09 Jul 2007 13:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wpW-0006mz-No; Mon, 09 Jul 2007 13:15:22 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7wpW-00050M-GP; Mon, 09 Jul 2007 13:15:22 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 54D1A2ACAD; Mon, 9 Jul 2007 17:15:07 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7wpG-00047v-AO; Mon, 09 Jul 2007 13:15:06 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 13:15:06 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-16.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.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 Filename : draft-ietf-syslog-device-mib-16.txt Pages : 57 Date : 2007-7-9 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-16.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-16.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-16.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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-9124126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9124126.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Tue Jul 10 13:57:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Jxg-0001uQ-Lc; Tue, 10 Jul 2007 13:57:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Jxd-0001u2-Ky for syslog@ietf.org; Tue, 10 Jul 2007 13:57:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Jxd-0004Kw-B0 for syslog@ietf.org; Tue, 10 Jul 2007 13:57:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2007 13:57:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOhkk0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175486400"; d="scan'208"; a="125689466:sNHT33021634" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6AHvGar004592; Tue, 10 Jul 2007 13:57:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6AHun7C017605; Tue, 10 Jul 2007 17:57:16 GMT Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 13:57:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Discuss - UDP Checksum Date: Tue, 10 Jul 2007 13:57:55 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731220350071B@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <20070705231629.GA4735@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Discuss - UDP Checksum Thread-Index: Ace/WpWrjPqC4vr3Tg+KvfhQe0uKVgDvg49w References: <20070705192348.GA4412@elstar.local><577465F99B41C842AAFBE9ED71E70ABA2784B0@grfint2.intern.adiscon.com> <20070705231629.GA4735@elstar.local> From: "Anton Okmyanskiy \(aokmians\)" To: , "Chris Lonvick \(clonvick\)" X-OriginalArrivalTime: 10 Jul 2007 17:57:02.0630 (UTC) FILETIME=[B8434C60:01C7C31B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3282; t=1184090236; x=1184954236; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=20=22Anton=20Okmyanskiy=20\(aokmians\)=22=20 |Subject:=20RE=3A=20[Syslog]=20Discuss=20-=20UDP=20Checksum |Sender:=20 |To:=20, =0A=20=20=20=20=20=20=20=20 =22Chris=20Lonvick=20\(clonvick\)=22=20; bh=RicRJz2n/scpcQcMmk4s2oBmV5jKbedZo3vNAcThYi8=; b=GzSMarj0JBq4T6YYvqMdx+Q2QsaknXYr5GKFP8OCObbxMCqmGg2fJjNAJnQmOYd1hhqtS9PF Wh9ScbJd5qghqKZYjtnoTF083/aE1SlCU63ND74ImPOLG18YPZeCBMDl; Authentication-Results: rtp-dkim-2; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I agree with Juergen and Rainer that we could use less specification here since it is a different layer. How about we replace both paragraphs with this: "Syslog senders are RECOMMENDED to use UDP checksums when sending messages over IPv4. Proper UDP checksum insertion and verification is already required by IPv6 RFC 1883." Let's be silent on what the receiver has to do since it may not have any control. I think if we put something like "Syslog receivers MAY accept syslog message with invalid or zero checksums", it would directly contradict IPv6 RFC, which says: "IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error." Anton. =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, July 05, 2007 4:16 PM > To: Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: Re: [Syslog] Discuss - UDP Checksum >=20 > On Thu, Jul 05, 2007 at 02:14:06PM -0700, Chris Lonvick wrote: >=20 > > How about the following: > > > > syslog senders MUST NOT disable UDP checksums. syslog=20 > senders SHOULD > > use UDP checksums when sending messages over IPv4. =20 > syslog senders MUST > > use UDP checksums when sending messages over IPv6. >=20 > The last sentence is a bit like requiring that the IPv6=20 > implementation your code happens to run on MUST be correct=20 > (and I have no clue how to turn this requirement into syslog code). >=20 > > syslog receivers should be lenient in what they receive. IPv4 > > receivers SHOULD check the UDP checksums. They SHOULD accept a > > syslog message with a zero checksum. They MAY discard messages > > with invalid checksums, or they MAY accept them and=20 > attempt to process > > them. IPv6 receivers MUST check the UDP checksums and=20 > MUST discard UDP > > packets containing a zero checksum. >=20 > I am not sure the MAY discard or MAY accept sentence is needed. >=20 > My proposal would be: >=20 > syslog senders MUST NOT disable UDP checksums. IPv4 syslog > senders SHOULD use UDP checksums when sending messages. Note that > RFC 2460 [RFC2460] mandates the use of UDP checksums when sending > UDP datagrams over IPv6. >=20 > syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog > receivers SHOULD check UDP checksums and they SHOULD accept a > syslog message with a zero checksum. Note that RFC 2460 [RFC2460] > mandates the use of checksums for UDP over IPv6. >=20 > By simply refering to the IPv6 requirement for UDP checksums,=20 > we avoid making this also a syslog requirement. I think we=20 > should not use MUST language for something that can only be=20 > implemented correctly below the syslog software layer. >=20 > [Enough hair splitting for today. ;-] >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 11 10:12:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cvS-0003LM-UI; Wed, 11 Jul 2007 10:12:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cvR-0003LF-N4 for syslog@ietf.org; Wed, 11 Jul 2007 10:12:17 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cvN-0001Hd-93 for syslog@ietf.org; Wed, 11 Jul 2007 10:12:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Jul 2007 07:12:12 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJaBlEarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,527,1175497200"; d="scan'208"; a="180198602:sNHT182513673" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6BECCP1002248; Wed, 11 Jul 2007 07:12:12 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6BEC3mp020505; Wed, 11 Jul 2007 14:12:03 GMT Date: Wed, 11 Jul 2007 07:12:03 -0700 (PDT) From: Chris Lonvick To: "Anton Okmyanskiy (aokmians)" Subject: RE: [Syslog] Discuss - UDP Checksum In-Reply-To: <98AE08B66FAD1742BED6CB9522B731220350071B@xmb-rtp-20d.amer.cisco.com> Message-ID: References: <20070705192348.GA4412@elstar.local><577465F99B41C842AAFBE9ED71E70ABA2784B0@grfint2.intern.adiscon.com> <20070705231629.GA4735@elstar.local> <98AE08B66FAD1742BED6CB9522B731220350071B@xmb-rtp-20d.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3676; t=1184163132; x=1185027132; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20[Syslog]=20Discuss=20-=20UDP=20Checksum |Sender:=20; bh=n+gpnjRCECdRPjGjtl2HULeG0q0ewPyNF7V+e877PrM=; b=aZIZrWkyoowPNtIb/o1uFsS/BqhVr4pjfuSYcBpBgZqZJRKhd7U5NNobA3PBTPKC40J4wE+v uG2KwcosadpssO81ju6SND/q6B67esSLny7VtwTbirVmbiK/5VwPeA96rPw9N9b3cB9dYhcx8n FoPe9EzVFaJtyHW4wuUaADCMg=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I don't think that addresses the IESG concerns as well as Juergen's proposal. I'd like to wrap this up. I don't think that there's any disagreement that we need something like this. Would anyone with any other thoughts please send them in. David and I will determine consensus tomorrow. :-) Thanks, Chris On Tue, 10 Jul 2007, Anton Okmyanskiy (aokmians) wrote: > I agree with Juergen and Rainer that we could use less specification > here since it is a different layer. How about we replace both > paragraphs with this: > > "Syslog senders are RECOMMENDED to use UDP checksums when sending > messages over IPv4. Proper UDP checksum insertion and verification is > already required by IPv6 RFC 1883." > > Let's be silent on what the receiver has to do since it may not have any > control. I think if we put something like "Syslog receivers MAY accept > syslog message with invalid or zero checksums", it would directly > contradict IPv6 RFC, which says: > > "IPv6 receivers must discard UDP packets containing a zero checksum, and > should log the error." > > Anton. > >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, July 05, 2007 4:16 PM >> To: Chris Lonvick (clonvick) >> Cc: syslog@ietf.org >> Subject: Re: [Syslog] Discuss - UDP Checksum >> >> On Thu, Jul 05, 2007 at 02:14:06PM -0700, Chris Lonvick wrote: >> >>> How about the following: >>> >>> syslog senders MUST NOT disable UDP checksums. syslog >> senders SHOULD >>> use UDP checksums when sending messages over IPv4. >> syslog senders MUST >>> use UDP checksums when sending messages over IPv6. >> >> The last sentence is a bit like requiring that the IPv6 >> implementation your code happens to run on MUST be correct >> (and I have no clue how to turn this requirement into syslog code). >> >>> syslog receivers should be lenient in what they receive. IPv4 >>> receivers SHOULD check the UDP checksums. They SHOULD accept a >>> syslog message with a zero checksum. They MAY discard messages >>> with invalid checksums, or they MAY accept them and >> attempt to process >>> them. IPv6 receivers MUST check the UDP checksums and >> MUST discard UDP >>> packets containing a zero checksum. >> >> I am not sure the MAY discard or MAY accept sentence is needed. >> >> My proposal would be: >> >> syslog senders MUST NOT disable UDP checksums. IPv4 syslog >> senders SHOULD use UDP checksums when sending messages. Note that >> RFC 2460 [RFC2460] mandates the use of UDP checksums when sending >> UDP datagrams over IPv6. >> >> syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog >> receivers SHOULD check UDP checksums and they SHOULD accept a >> syslog message with a zero checksum. Note that RFC 2460 [RFC2460] >> mandates the use of checksums for UDP over IPv6. >> >> By simply refering to the IPv6 requirement for UDP checksums, >> we avoid making this also a syslog requirement. I think we >> should not use MUST language for something that can only be >> implemented correctly below the syslog software layer. >> >> [Enough hair splitting for today. ;-] >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 11 10:16:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8czD-0008DK-It; Wed, 11 Jul 2007 10:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8czC-0008DF-F6 for syslog@ietf.org; Wed, 11 Jul 2007 10:16:10 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cz7-0001N7-RW for syslog@ietf.org; Wed, 11 Jul 2007 10:16:10 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 Jul 2007 07:16:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIeClEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,527,1175497200"; d="scan'208"; a="7883248:sNHT35310264" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6BEG5C2017231 for ; Wed, 11 Jul 2007 07:16:05 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6BEG4XI019597 for ; Wed, 11 Jul 2007 14:16:04 GMT Date: Wed, 11 Jul 2007 07:16:04 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5546; t=1184163365; x=1185027365; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20DISCUSS=20in=20draft-ietf-syslog-protocol=20-=20conge nstion=20control=0A=20(fwd) |Sender:=20; bh=wfR1UEcaeJGyElSgLEqC5yqnA+9IysSBjznJnc3yYd4=; b=tiKlqYZpd/IozVHctxTY8LprvW5Fa1iwf2JZeonvmrrq8x4jcvYoWtYoXg7XYxw73MQiEHVp 2y8oR4LIMWo0qK66W+N+z1e2aNTfTbtN7BzRTyC3p25uSkIPB8zYO7v7; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, Here is clarification of what Magnus wants. We have so far received Eliot's proposal but I don't think that addresses the concern. I would like to hear from everyone. Do we want to push back on Magnus, or can someone propose some text around this? Thanks, Chris ---------- Forwarded message ---------- Date: Fri, 06 Jul 2007 18:08:12 +0200 From: Magnus Westerlund To: David Harrington Cc: Chris Lonvick , Lars Eggert Subject: Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) Hi David, I think you are missunderstanding things here. But thanks for protesting and not accepting crap. But let me make clear what I actually think is needed in regards to syslog to make it a working protocol to deploy. First, this starts as an issue with TLS over TCP and the syslog base protocol. It can also arise teorethically for UDP, but as I understand not in practice for todays usage. When you are using TCP, in case the syslog sender generates events at an rate that is higher than available rate over the path used there will be build up of a queue. So I would like to have some words somewhere saying what you do when you build up a queue of messages that should be transmitted, but the queue simply keeps growing. What do I do? To me this situation implies that one starts discarding syslog messages and starts with the least important ones. So I would like to have a paragraph on this. I also included UDP in this in the case that you actually have reserved or determined that syslog is allowed to use a particular amount of bandwidth, but not more. In this case it could be possible that one implements a rate limiter and run into exactly the same issue as for TCP. Please do understand that if syslog was designed from scratch today it wouldn't get awy without a congestion control that guarantees that it isn't missbehaving in any situation. But being an "old" protocol we are accepting less than that. However, we do require it to contain the limitations and assumptions that it can be safely operated with. Using it as it currently is used is not an issue because the networks it is used in has many magnitudes more bandwidth that syslog generates. However, what would happen if some one starts using syslog in low-powered, low-bitrate sensor network for carrying some information. In that situation syslog becomes a potential threat to the stability of the network as it doesn't react at all to congestion if run over UDP. Network failures are also sitation that are problematic to ensure that the inteded resources are available. Thus we do like to protect the utility of what resources do exist. So the repeat: Please seriously consider adding a paragraph about how one can thinn a queue of syslog messages in the base protocol. This as I think it potentially applies to any transport. Also consider when updating the UDP draft and adds what has been discussed with Lars, to add a single sentece with a reference the above paragraph as a method to keep the traffic within the allowed resources. Regards Magnus David Harrington skrev: > > > Hi Magnus, > > Syslog is a fire-and-forget protocol. We have no feedback mechanism > that permits us to recognize congestion and rate limit traffic based > on that feedback. > > Syslog is not a brand new protocol; it is widely used in the industry, > and other aspects of standardization has been handled through POSIX > and BSD standardization. The industry has expressed no interest in > making this a two-way protocol. This protocol is widely used by > operators, amd I have seen no demand from operators to make this a > two-way protocol, or any demand to resolve congestion control for > syslog, because congestion caused by syslog apparently is not a > problem in the real world. > > We had discussion of rate-limiting during the IETF Last Call. We > actually had suggestions for ways to rate-limit syslog in the earlier > document, but the IETF community rejected our having that text in the > document because syslog is a fire-and-forget protocol, so there is no > reliable mechanism for detecting congestion. The IETF commmunity did > not ask us to make syslog two-way, so we could add rate limiting to > the protocol; they asked us to keep syslog working as is, and remove > the unreliable recommendations to rate limit. > > You are placing a whole new requirement, that no implementers or > operators are asking for, on a protocol that is already widely > implemented and deployed. Where is the customer demand for this? > > I am concerned you might drive the syslog community to not work within > the IETF, where they came to develop a standard message format and a > secure transport, not to change the basic nature of the protocol. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 12 10:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zMg-0001U3-3l; Thu, 12 Jul 2007 10:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zMe-0001TU-8l for syslog@ietf.org; Thu, 12 Jul 2007 10:09:52 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8zMY-0003Ut-OC for syslog@ietf.org; Thu, 12 Jul 2007 10:09:52 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jul 2007 16:09:44 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACfSlUaQ/uCKh2dsb2JhbACBS41xAQEBCA4s X-IronPort-AV: i="4.16,533,1175464800"; d="scan'208"; a="147907877:sNHT27178022" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6CE9hJe011651; Thu, 12 Jul 2007 16:09:43 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp578.cisco.com [10.61.66.66]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6CE9dTC012011; Thu, 12 Jul 2007 14:09:39 GMT Message-ID: <4696361E.6090309@cisco.com> Date: Thu, 12 Jul 2007 16:09:34 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Chris Lonvick Subject: Re: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=935; t=1184249384; x=1185113384; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20Re=3A=20DISCUSS=20in=20draft-ietf-syslog-p rotocol=20-=20congenstion=0A=20control=20(fwd) |Sender:=20; bh=Eo3jDNwlJOeO2MobnBBzDZoaRyrotlrVlrCJcNoVo3E=; b=sYL0qlAAMfllb+OGSf59R5SrhoDSidvL6wLU8bpK3ZvjBWbZ7DdzmEnmmttItlshBU9cI6m7 bWQapSseNt4DObSouFgC9u+amGYC8/dYwdTyONAQJq7TIX+lm+O8Eq2U; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris Lonvick wrote: > Hi Folks, > > Here is clarification of what Magnus wants. We have so far received > Eliot's proposal but I don't think that addresses the concern. > I agree. My concern was downstream resources. Magnus' concern is the syslog "application". This is complex because there are at least three cases to consider: * syslog generator blocks on a full input queue - what to do? There is generally no way for the application to detect the condition prior to blocking. * non-blocking syslog generator gets an input queue error - the best it can do is signal back to the application. What syslog implementation actually does this? * a non-blocking syslog relay starts getting input queue errors. It has no application intelligence. Is it reasonable for it to just start dropping messages with high log_levels, and hope for the best? Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 12 12:33:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91c1-0002eG-CN; Thu, 12 Jul 2007 12:33:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91c0-0002ds-2Z for syslog@ietf.org; Thu, 12 Jul 2007 12:33:52 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I91bz-0002MO-OK for syslog@ietf.org; Thu, 12 Jul 2007 12:33:51 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 Jul 2007 09:33:51 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANb0lUarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,533,1175497200"; d="scan'208"; a="8204139:sNHT14499396" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6CGXpAw030060; Thu, 12 Jul 2007 09:33:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6CGXgXP020184; Thu, 12 Jul 2007 16:33:51 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 09:33:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstioncontrol (fwd) Date: Thu, 12 Jul 2007 09:33:30 -0700 Message-ID: In-Reply-To: <4696361E.6090309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstioncontrol (fwd) Thread-Index: AcfEjlkLrMS0kpg0SSKOyBx1HbEjMQAEitSQ From: "Steve Chang \(schang99\)" To: "Eliot Lear" , "Chris Lonvick \(clonvick\)" X-OriginalArrivalTime: 12 Jul 2007 16:33:42.0204 (UTC) FILETIME=[689A57C0:01C7C4A2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1974; t=1184258031; x=1185122031; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=schang99@cisco.com; z=From:=20=22Steve=20Chang=20\(schang99\)=22=20 |Subject:=20RE=3A=20[Syslog]=20Re=3A=20DISCUSS=20in=20draft-ietf-syslog-p rotocol=20-=20congenstioncontrol=20(fwd) |Sender:=20; bh=WZmfpxoEv7ZBnYeqgFFub08hkGWUy9DrA+/vo+8PfZo=; b=WSfR2WtjT/VkqbDI7BsjmdbSBURkWNeWF5GZQCjYTjXzzyNPQofjU4mHO1JzMUZOvjQzFS49 miwIQPPqFX0A8/YGLqY5YGlJ4qRWJqFQhU3L3gqo7WU3iC2tHhvdkYQH; Authentication-Results: sj-dkim-3; header.From=schang99@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I think this protocol should only address the concerns for the syslog=20 messages delivered out from its originating box. We should not get into the syslog application to regulate how it should behave. Besides, there are typically syslog relay devices before the messages reach its target receiver boxes to make it much more complex. We should let users determine, via configurations, what syslog messages=20 are of concerns/interests to them instead of having this protocol stating=20 a policy dictating what messages to be dropped.=20 Steve > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Thursday, July 12, 2007 7:10 AM > To: Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: Re: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - > congenstioncontrol (fwd) >=20 > Chris Lonvick wrote: > > Hi Folks, > > > > Here is clarification of what Magnus wants. We have so far received > > Eliot's proposal but I don't think that addresses the concern. > > >=20 > I agree. My concern was downstream resources. Magnus' concern is the > syslog "application". This is complex because there are at least three > cases to consider: >=20 > * syslog generator blocks on a full input queue - what to do? There > is generally no way for the application to detect the condition > prior to blocking. > * non-blocking syslog generator gets an input queue error - the best > it can do is signal back to the application. What syslog > implementation actually does this? > * a non-blocking syslog relay starts getting input queue errors. It > has no application intelligence. Is it reasonable for it to just > start dropping messages with high log_levels, and hope for the best? >=20 > Eliot >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 12 13:31:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92Vv-0004qW-Ix; Thu, 12 Jul 2007 13:31:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92Vu-0004qP-Qa for syslog@ietf.org; Thu, 12 Jul 2007 13:31:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I92Vu-0000Xb-4d for syslog@ietf.org; Thu, 12 Jul 2007 13:31:38 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2007 13:31:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALsBlkZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,533,1175486400"; d="scan'208"; a="65022863:sNHT38176148" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6CHVJRO020480 for ; Thu, 12 Jul 2007 13:31:19 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6CHVFs4013566 for ; Thu, 12 Jul 2007 17:31:19 GMT Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:31:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) Date: Thu, 12 Jul 2007 13:32:10 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731220355860A@xmb-rtp-20d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) Thread-Index: AcfDxgzwvtFqQLUGRfyER+OWFxIfIAA4aiqA References: From: "Anton Okmyanskiy \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 12 Jul 2007 17:31:17.0270 (UTC) FILETIME=[73FB9360:01C7C4AA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8022; t=1184261479; x=1185125479; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=20=22Anton=20Okmyanskiy=20\(aokmians\)=22=20 |Subject:=20RE=3A=20[Syslog]=20Re=3A=20DISCUSS=20in=20draft-ietf-syslog-p rotocol=20-=20congenstion=20control=20(fwd) |Sender:=20 |To:=20=22Chris=20Lonvick=20\(clonvick\)=22=20, =20; bh=RQfe8ylQ5eLWNGTVoIXXXAr9DgLR5HLDpA2KrdvYSO4=; b=EauMtO4mOd6P17ikcqSuQ+0dlsFP8iF7Foc9sQ5GJr4f5Z5UKH9+/pyLo2b0HlHrag5ppwbY j+t4MKFgYg4p9u6qiSrWN/w58yi3TVSlQvpDg2JZ/HneHnYViFXwNL77; Authentication-Results: rtp-dkim-2; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris: Can we ask Mangus to provide suggested text? He mentioned it is just a paragraph. This would make it a bit easier to get to the point of what/how he wants addressed and evaluate if we agree with it. If his suggested text is not too demanding on implementations, but rather a recommendation, it is easier to accept it. =20 Is he now concerned with syslog reliability (dropping of arbitrary messages due to congestion and queue overfill) instead of previously raised concern of syslog being a bad citizen and causing congestion for others? For end-to-end reliability, we have a whole section describing many aspects we did not intend to address in UDP draft.=20 Why is there an assumption of blocking application? Maybe my syslog application writes messages to file first, returns to client app and then asynchronously transmits them while listening for ICMP errors. I also don't think we intended to cover any end-to-end guarantees from application perspective. Even reliable network transport (TCP) does not means reliable application-to-application delivery. We had the app-level-ack discussion and dismissed it. =20 So, yes, messages are not guaranteed to be delivered to their final destination and processed there. They can be dropped, they can get corrupted, receiver may crash right after getting message but before processing it, relay may fail, etc.=20 Thanks, Anton.=20 > -----Original Message----- > From: Chris Lonvick (clonvick)=20 > Sent: Wednesday, July 11, 2007 7:16 AM > To: syslog@ietf.org > Subject: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol -=20 > congenstion control (fwd) >=20 > Hi Folks, >=20 > Here is clarification of what Magnus wants. We have so far=20 > received Eliot's proposal but I don't think that addresses=20 > the concern. >=20 > I would like to hear from everyone. Do we want to push back=20 > on Magnus, or can someone propose some text around this? >=20 > Thanks, > Chris >=20 >=20 > ---------- Forwarded message ---------- > Date: Fri, 06 Jul 2007 18:08:12 +0200 > From: Magnus Westerlund > To: David Harrington > Cc: Chris Lonvick , Lars Eggert=20 > > Subject: Re: DISCUSS in draft-ietf-syslog-protocol -=20 > congenstion control (fwd) >=20 > Hi David, >=20 > I think you are missunderstanding things here. But thanks for=20 > protesting and not accepting crap. But let me make clear=20 > what I actually think is needed in regards to syslog to make=20 > it a working protocol to deploy. >=20 > First, this starts as an issue with TLS over TCP and the=20 > syslog base protocol.=20 > It can also arise teorethically for UDP, but as I understand=20 > not in practice for todays usage. When you are using TCP, in=20 > case the syslog sender generates events at an rate that is=20 > higher than available rate over the path used there will be=20 > build up of a queue. So I would like to have some words=20 > somewhere saying what you do when you build up a queue of=20 > messages that should be transmitted, but the queue simply=20 > keeps growing. What do I do? To me this situation implies=20 > that one starts discarding syslog messages and starts with=20 > the least important ones. So I would like to have a paragraph on this. >=20 > I also included UDP in this in the case that you actually=20 > have reserved or determined that syslog is allowed to use a=20 > particular amount of bandwidth, but not more. In this case it=20 > could be possible that one implements a rate limiter and run=20 > into exactly the same issue as for TCP. >=20 > Please do understand that if syslog was designed from scratch=20 > today it wouldn't get awy without a congestion control that=20 > guarantees that it isn't missbehaving in any situation. But=20 > being an "old" protocol we are accepting less than that.=20 > However, we do require it to contain the limitations and=20 > assumptions that it can be safely operated with. Using it as=20 > it currently is used is not an issue because the networks it=20 > is used in has many magnitudes more bandwidth that syslog=20 > generates. However, what would happen if some one starts=20 > using syslog in low-powered, low-bitrate sensor network for=20 > carrying some information. In that situation syslog becomes a=20 > potential threat to the stability of the network as it=20 > doesn't react at all to congestion if run over UDP. Network=20 > failures are also sitation that are problematic to ensure=20 > that the inteded resources are available. Thus we do like to=20 > protect the utility of what resources do exist. >=20 > So the repeat: >=20 > Please seriously consider adding a paragraph about how one=20 > can thinn a queue of syslog messages in the base protocol.=20 > This as I think it potentially applies to any transport. >=20 > Also consider when updating the UDP draft and adds what has=20 > been discussed with Lars, to add a single sentece with a=20 > reference the above paragraph as a method to keep the traffic=20 > within the allowed resources. >=20 > Regards >=20 > Magnus >=20 >=20 >=20 > David Harrington skrev: > > > > > > Hi Magnus, > > > > Syslog is a fire-and-forget protocol. We have no feedback=20 > mechanism =20 > > that permits us to recognize congestion and rate limit=20 > traffic based =20 > > on that feedback. > > > > Syslog is not a brand new protocol; it is widely used in the=20 > > industry, and other aspects of standardization has been handled=20 > > through POSIX and BSD standardization. The industry has=20 > expressed no=20 > > interest in making this a two-way protocol. This protocol=20 > is widely=20 > > used by operators, amd I have seen no demand from=20 > operators to make=20 > > this a two-way protocol, or any demand to resolve=20 > congestion control=20 > > for syslog, because congestion caused by syslog apparently=20 > is not a =20 > > problem in the real world. >=20 > > > > We had discussion of rate-limiting during the IETF Last Call. We =20 > > actually had suggestions for ways to rate-limit syslog in=20 > the earlier =20 > > document, but the IETF community rejected our having that=20 > text in the =20 > > document because syslog is a fire-and-forget protocol, so=20 > there is no =20 > > reliable mechanism for detecting congestion. The IETF=20 > commmunity did =20 > > not ask us to make syslog two-way, so we could add rate=20 > limiting to =20 > > the protocol; they asked us to keep syslog working as is,=20 > and remove =20 > > the unreliable recommendations to rate limit. > > > > You are placing a whole new requirement, that no implementers or =20 > > operators are asking for, on a protocol that is already widely =20 > > implemented and deployed. Where is the customer demand for this? > > > > I am concerned you might drive the syslog community to not work=20 > > within the IETF, where they came to develop a standard=20 > message format=20 > > and a secure transport, not to change the basic nature of=20 > the protocol. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > >=20 > --=20 >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 12 14:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9318-0005FK-EL; Thu, 12 Jul 2007 14:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9315-0005Df-9j; Thu, 12 Jul 2007 14:03:51 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9310-0007Dg-S2; Thu, 12 Jul 2007 14:03:51 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070712180343m130023q7ie>; Thu, 12 Jul 2007 18:03:44 +0000 From: "David Harrington" To: Date: Thu, 12 Jul 2007 14:02:08 -0400 Message-ID: <000001c7c4ae$c45ecfd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iBBBEA0MA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'IETF discussion list' Subject: [Syslog] Working Group Last Call: syslog-sign-22 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This message officially starts the Syslog Working Group Last Call for the following document: Signed syslog Messages (draft-ietf-syslog-sign-22.txt) http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-22.txt The Working Group Last Call for these documents will end August 9. This is a four-week WGLC designed to accommodate those who are busy dealing with commitments surrounding IETF69. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From dfhhryw464wsg@yahoo.co.jp Sun Jul 15 11:06:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5g9-0000Vd-7I for syslog-archive@lists.ietf.org; Sun, 15 Jul 2007 11:06:33 -0400 Received: from 236.138.132.202.dynamic.ttn.net ([202.132.138.236] helo=lists.ietf.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IA5fs-00031d-1Z for syslog-archive@lists.ietf.org; Sun, 15 Jul 2007 11:06:33 -0400 From: =?ISO-2022-JP?B?GyRCOzNLXD0kMGwbKEI=?= Subject: =?ISO-2022-JP?B?GyRCJTUlXiE8JS0lYyVzJVohPCVzQ2YhKhsoQg==?= To: X-Spam-Score: 4.6 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------------------------------------- キャンペーンコード：FGKT20-903995 ------------------------------------- 現在、キャンペーン中につきコキ放題！ ウェブブラウザ（ＩＥ）さえあればどこからでも視聴可！ 設定が一切無いので初心者でも簡単に視聴出来ます。 サンプルも多数用意してあります。 　　　↓↓↓↓ http://www.nnili.com/?bc=ie&me=HH9P6sPHbW8OQ4a5QHfLYss3H7fHS6PH86PL69HH696 ━━━━━━━━━━━━━━━━━━━━━━━━━ 新作ＡＶから幻のポルノまで 盗撮・フェチ・イタズラなんでも揃っています。 激ヤバの流出モノも期間限定ですが公開中！　お早めにね♪ http://www.nnili.com/?bc=ie&me=HH9P6sPHbW8OQ4a5QHfLYss3H7fHS6PH86PL69HH696 ━━━━━━━━━━━━━━━━━━━━━━━━━ ※注意　１８歳未満の方は視聴出来ません。ご了承下さい。 　配信拒否はこちらまで cancel@nnili.com From syslog-bounces@lists.ietf.org Wed Jul 18 10:47:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAo4-0000od-SG; Wed, 18 Jul 2007 10:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAo2-0000oI-QL for syslog@ietf.org; Wed, 18 Jul 2007 10:47:11 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAo1-00035R-9L for syslog@ietf.org; Wed, 18 Jul 2007 10:47:10 -0400 Received: from pc6 (1Cust159.tnt5.lnd4.gbr.da.uu.net [62.188.134.159]) by ranger.systems.pipex.net (Postfix) with SMTP id E9C6DE00065C; Wed, 18 Jul 2007 15:47:05 +0100 (BST) Message-ID: <00cd01c7c941$6cabbcc0$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , "syslog" References: Subject: Re: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) Date: Wed, 18 Jul 2007 14:15:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This topic may be being driven by draft-ietf-tsvwg-udp-guidelines-02 by Eggert/Fairhurst. Worth a peruse; quoting out of context (is syslog bulk or not?), it contains such as "If an application or upper-layer protocol chooses not to use a congestion-controlled transport protocol, it SHOULD control the rate at which it sends UDP messages to a destination host. "Applications that perform bulk transmission of data to a peer over UDP SHOULD implement TCP-Friendly Rate Control (TFRC) [RFC3448], window-based, TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles. "A second class of applications cannot maintain an RTT estimate for a destination, because the destination does not send return traffic. Such applications SHOULD NOT send more than one UDP message every 3 seconds, and SHOULD consider if they can use an even less aggressive rate when possible." and on the checksum issue "Applications SHOULD enable UDP checksums, although [RFC0793] permits the option to disable their use. "A special class of applications derive benefit from having partially damaged payloads delivered rather than discarded when using paths that include error-prone links. Such applications can tolerate payload corruption and MAY choose to use the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of basic UDP" Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Wednesday, July 11, 2007 4:16 PM Subject: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) > Hi Folks, > > Here is clarification of what Magnus wants. We have so far received > Eliot's proposal but I don't think that addresses the concern. > > I would like to hear from everyone. Do we want to push back on Magnus, or > can someone propose some text around this? > > Thanks, > Chris > > > ---------- Forwarded message ---------- > Date: Fri, 06 Jul 2007 18:08:12 +0200 > From: Magnus Westerlund > To: David Harrington > Cc: Chris Lonvick , Lars Eggert > Subject: Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) > > Hi David, > > I think you are missunderstanding things here. But thanks for protesting and > not accepting crap. But let me make clear what I actually think is needed in > regards to syslog to make it a working protocol to deploy. > > First, this starts as an issue with TLS over TCP and the syslog base protocol. > It can also arise teorethically for UDP, but as I understand not in practice > for todays usage. When you are using TCP, in case the syslog sender generates > events at an rate that is higher than available rate over the path used there > will be build up of a queue. So I would like to have some words somewhere > saying what you do when you build up a queue of messages that should be > transmitted, but the queue simply keeps growing. What do I do? To me this > situation implies that one starts discarding syslog messages and starts with > the least important ones. So I would like to have a paragraph on this. > > I also included UDP in this in the case that you actually have reserved or > determined that syslog is allowed to use a particular amount of bandwidth, but > not more. In this case it could be possible that one implements a rate limiter > and run into exactly the same issue as for TCP. > > Please do understand that if syslog was designed from scratch today it wouldn't > get awy without a congestion control that guarantees that it isn't missbehaving > in any situation. But being an "old" protocol we are accepting less than that. > However, we do require it to contain the limitations and assumptions that it > can be safely operated with. Using it as it currently is used is not an issue > because the networks it is used in has many magnitudes more bandwidth that > syslog generates. However, what would happen if some one starts using syslog in > low-powered, low-bitrate sensor network for carrying some information. In that > situation syslog becomes a potential threat to the stability of the network as > it doesn't react at all to congestion if run over UDP. Network failures are > also sitation that are problematic to ensure that the inteded resources are > available. Thus we do like to protect the utility of what resources do exist. > > So the repeat: > > Please seriously consider adding a paragraph about how one can thinn a queue of > syslog messages in the base protocol. This as I think it potentially applies to > any transport. > > Also consider when updating the UDP draft and adds what has been discussed with > Lars, to add a single sentece with a reference the above paragraph as a method > to keep the traffic within the allowed resources. > > Regards > > Magnus > > > > David Harrington skrev: > > > > > > Hi Magnus, > > > > Syslog is a fire-and-forget protocol. We have no feedback mechanism > > that permits us to recognize congestion and rate limit traffic based > > on that feedback. > > > > Syslog is not a brand new protocol; it is widely used in the industry, > > and other aspects of standardization has been handled through POSIX > > and BSD standardization. The industry has expressed no interest in > > making this a two-way protocol. This protocol is widely used by > > operators, amd I have seen no demand from operators to make this a > > two-way protocol, or any demand to resolve congestion control for > > syslog, because congestion caused by syslog apparently is not a > > problem in the real world. > > > > > We had discussion of rate-limiting during the IETF Last Call. We > > actually had suggestions for ways to rate-limit syslog in the earlier > > document, but the IETF community rejected our having that text in the > > document because syslog is a fire-and-forget protocol, so there is no > > reliable mechanism for detecting congestion. The IETF commmunity did > > not ask us to make syslog two-way, so we could add rate limiting to > > the protocol; they asked us to keep syslog working as is, and remove > > the unreliable recommendations to rate limit. > > > > You are placing a whole new requirement, that no implementers or > > operators are asking for, on a protocol that is already widely > > implemented and deployed. Where is the customer demand for this? > > > > I am concerned you might drive the syslog community to not work within > > the IETF, where they came to develop a standard message format and a > > secure transport, not to change the basic nature of the protocol. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > -- > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 18 12:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCQ0-0004j9-My; Wed, 18 Jul 2007 12:30:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCPz-0004j3-5i for syslog@ietf.org; Wed, 18 Jul 2007 12:30:27 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBCPx-0007Db-PL for syslog@ietf.org; Wed, 18 Jul 2007 12:30:27 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2007 18:30:25 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACLdnUaQ/uCLh2dsb2JhbACPRAEBCQon X-IronPort-AV: i="4.16,551,1175464800"; d="scan'208"; a="148398700:sNHT29465396" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6IGUOjP015882; Wed, 18 Jul 2007 18:30:24 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp652.cisco.com [10.61.66.140]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6IGUOkt002557; Wed, 18 Jul 2007 16:30:24 GMT Message-ID: <469E4016.20702@cisco.com> Date: Wed, 18 Jul 2007 18:30:14 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "tom.petch" Subject: Re: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) References: <00cd01c7c941$6cabbcc0$0601a8c0@pc6> In-Reply-To: <00cd01c7c941$6cabbcc0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=468; t=1184776224; x=1185640224; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20Re=3A=20DISCUSS=20in=20draft-ietf-syslog-p rotocol=20-=20congenstion=0A=20control=20(fwd) |Sender:=20; bh=hN3NmCPIJRGMDu0p9AD7Qgqi8blDKso7HnoduUUkkcw=; b=d+PMl/+WOgqBbSCoWe6eC0vexd+B5UZ0/iWwYftMeNWSi9KiqPlcDcHv8LWKhS8kc9EBrDXN qDjlaqoIOFLhvl4C7zte/Pwg7i93YEQXzsCdDrFZZD4PcWuBX0V/ekx4; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org tom.petch wrote: > "A second class of applications cannot maintain an RTT estimate for a > destination, because the destination does not send return traffic. Such > applications SHOULD NOT send more than one UDP message every 3 seconds, and > SHOULD consider if they can use an even less aggressive rate when possible." > So much for voice multicast? 3 seconds is a vast period of time. SNMP doesn't meet this requirement either. Nor should it. > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jul 28 10:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEn2b-0003ML-Dx; Sat, 28 Jul 2007 10:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEn2a-0003M4-7U for syslog@ietf.org; Sat, 28 Jul 2007 10:13:08 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEn2Z-0000Im-Sg for syslog@ietf.org; Sat, 28 Jul 2007 10:13:08 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070728141307b1200ddh5fe>; Sat, 28 Jul 2007 14:13:07 +0000 From: "David Harrington" To: Date: Sat, 28 Jul 2007 09:12:57 -0500 Message-ID: <022701c7d121$688ac7c0$79aa1cac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iBBBEA0MAMdjl8w X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Syslog] Working Group Last Call: syslog-sign-22 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Thursday, July 12, 2007 1:02 PM To: syslog@ietf.org Cc: 'IETF discussion list' Subject: Working Group Last Call: syslog-sign-22 Hi, This message is to remind readers about the Syslog Working Group Last Call for the following document: Signed syslog Messages (draft-ietf-syslog-sign-22.txt) http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-22.txt The Working Group Last Call for these documents will end August 9. This is a four-week WGLC designed to accommodate those who are busy dealing with commitments surrounding IETF69. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog