From clonvick@cisco.com Fri Jun 4 00:41:26 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88BB43A68D8 for ; Fri, 4 Jun 2010 00:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.998 X-Spam-Level: X-Spam-Status: No, score=-11.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy8Nv9TYUGvC for ; Fri, 4 Jun 2010 00:41:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0A38A3A698C for ; Fri, 4 Jun 2010 00:41:25 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 04 Jun 2010 07:41:11 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o547fBga023126 for ; Fri, 4 Jun 2010 07:41:11 GMT Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 00:41:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB03B9.4D8B1665" X-OriginalArrivalTime: 03 Jun 2010 19:51:31.0737 (UTC) FILETIME=[2A071890:01CB0356] X-IronPort-AV: E=Sophos; i="4.53,356,1272844800"; d="scan'208"; a="194859467" X-from-outside-Cisco: 64.170.98.32 Errors-To: wgchairs-bounces@ietf.org Delivered-To: wgchairs@core3.amsl.com X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.9 X-Original-To: wgchairs@ietf.org X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUBAL+kB0xAqmIglGdsb2JhbACDGZsRFQEBAQEJCwgJEQUdpTqJFJEAgSaBOIFKbgSDSA Content-class: urn:content-classes:message Date: Fri, 4 Jun 2010 00:41:11 -0700 Message-ID: <1BA601B02314084980FE9D0630FE9793053F8F3A@xmb-sjc-227.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 78 - Meeting and Sponsorship Information Thread-Index: AcsDViqKz0a4iajGRo+KzP/BvrhuawAYyMMd From: "Chris Lonvick (clonvick)" To: Subject: [Syslog] FW: IETF 78 - Meeting and Sponsorship Information X-BeenThere: syslog@ietf.org Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 07:41:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB03B9.4D8B1665 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RnlpLCBDaHJpcw0KDQoNCg0KIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAJSUVU RiBTZWNyZXRhcmlhdCBbbWFpbHRvOmlldGYtc2VjcmV0YXJpYXRAaWV0Zi5vcmddDQpTZW50OglU aHVyc2RheSwgSnVuZSAwMywgMjAxMCAxMjo1MSBQTSBQYWNpZmljIFN0YW5kYXJkIFRpbWUNClRv OglXb3JraW5nIEdyb3VwIENoYWlycw0KU3ViamVjdDoJSUVURiA3OCAtIE1lZXRpbmcgYW5kIFNw b25zb3JzaGlwIEluZm9ybWF0aW9uIA0KDQpXb3JraW5nIEdyb3VwIENoYWlycywNCg0KQ2FuIHlv dSBwbGVhc2UgZm9yd2FyZCB0aGlzIG1lc3NhZ2UgdG8geW91ciBpbmRpdmlkdWFsIHdvcmtpbmcg Z3JvdXANCmVtYWlscyBsaXN0cy4gIFdlIHdhbnQgdG8gZW5zdXJlIHRoYXQgYXMgbWFueSBwZW9w bGUgYXMgcG9zc2libGUgYXJlIGF3YXJlDQpvZiB0aGUgc3BvbnNvcnNoaXAgb3Bwb3J0dW5pdGll cyBhdmFpbGFibGUgYXQgSUVURiBtZWV0aW5ncy4NCg0KVGhhbmsgeW91Lg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo3OHRoIElFVEYgTWVldGluZyANCk1hYXN0 cmljaHQsIE5ldGhlcmxhbmRzDQpKdWx5IDI1LTMwLCAyMDEwIA0KIA0KMS4gU3BvbnNvcnNoaXAg T3Bwb3J0dW5pdGllcw0KMi4gUmVnaXN0cmF0aW9uIFR5cGVzDQozLiBWaXNhcyBhbmQgTGV0dGVy cyBvZiBJbnZpdGF0aW9uDQo0LiBBY2NvbW1vZGF0aW9ucyAmIEJyZWFrZmFzdCBJbmZvcm1hdGlv bg0KNS4gSUVURiA3OSAoQmVpamluZykgVmlzYSBJbmZvcm1hdGlvbg0KDQoxKSBTcG9uc29yc2hp cCBPcHBvcnR1bml0aWVzDQpUaGVyZSBhcmUgc3RpbGwgc3BvbnNvcnNoaXAgb3Bwb3J0dW5pdGll cyBhbmQgYmVuZWZpdHMgZm9yIGhpZ2ggcHJvZmlsZQ0KY29tcGFueS9vcmdhbml6YXRpb25hbCBl eHBvc3VyZSBhdCB0aGUgdXBjb21pbmcgSUVURiBtZWV0aW5nIGluDQpNYWFzdHJpY2h0LCBOZXRo ZXJsYW5kcyBmcm9tIEp1bHkgMjUtMzAsIDIwMTAuICBBbGwgc3BvbnNvcnNoaXAgZmVlcyBnbw0K ZGlyZWN0bHkgdG8gZnVuZCB0aGUgb3BlcmF0aW9ucyBvZiB0aGUgSUVURi4gIFNlZSB0aGUgb3B0 aW9ucyBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy83OC9pbmRleC5odG1sIFNwb25z b3JzaGlwIE9wcG9ydHVuaXRpZXMNCnVuZGVyIEdlbmVyYWwuICBFYWNoIG9mIHRoZSBzcG9uc29y c2hpcCBvcHRpb25zIHByb3ZpZGUgZXh0ZW5kZWQgYW5kDQpyZXBlYXQgZXhwb3N1cmUgYXQgdGhp cyB3ZWVrbG9uZyBtZWV0aW5nLiAgIA0KDQpQbGVhc2UgY29udGFjdCBEcmV3IER2b3JzaGFrLCBk dm9yc2hha0Bpc29jLm9yZywgd2l0aCBhbnkgcXVlc3Rpb25zDQphbmQvb3IgdG8gcmVzZXJ2ZSB5 b3VyIG9yZ2FuaXphdGlvbnMgc3BvdC4gIFRoYW5rcyBpbiBhZHZhbmNlIGZvcg0Kc3VwcG9ydGlu ZyB0aGUgY3JpdGljYWwgd29yayBvZiB0aGUgSUVURiENCg0KMikgUmVnaXN0ZXIgb25saW5lIGF0 OiAgaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5ncy83OC8NCg0KMykgTGV0dGVycyBvZiBJbnZp dGF0aW9uIGFuZCBWaXNhcyANCkxldHRlcnMgb2YgSW52aXRhdGlvbg0KQWZ0ZXIgeW91IGNvbXBs ZXRlIHRoZSBtZWV0aW5nIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLCB5b3Ugd2lsbCBiZSBnaXZlbiB0 aGUNCm9wdGlvbiB0byByZXF1ZXN0IGEgbGV0dGVyIG9mIGludml0YXRpb24uIFlvdSBjYW4gcmVx dWVzdCB0aGUgTGV0dGVyIG9mDQpJbnZpdGF0aW9uIGFzIHNvb24gYXMgeW91IGZpbmlzaCByZWdp c3RyYXRpb24sIG9yIGF0IGEgbGF0ZXIgdGltZSBieQ0KZm9sbG93aW5nIHRoZSBsaW5rIHByb3Zp ZGVkIGluIHRoZSBjb25maXJtYXRpb24gZW1haWwuDQoNClZpc2FzDQpQbGVhc2UgY2hlY2sgdGhl IE5ldGhlcmxhbmRzIE1pbmlzdHJ5IG9mIEZvcmVpZ24gQWZmYWlycyBzaXRlDQooaHR0cDovL3d3 dy5taW5idXphLm5sL2VuL1NlcnZpY2VzL0NvbnN1bGFyX1NlcnZpY2VzL1Zpc2EpIGZvciBsaXN0 IG9mDQpjb3VudHJpZXMgd2l0aCB2aXNhIGV4ZW1wdGlvbnMuDQoNCldlIHJlY29tbWVuZCB5b3Ug Z2l2ZSB5b3Vyc2VsZiBhdCBsZWFzdCBvbmUgbW9udGggdG8gY29tcGxldGUgdGhlIHZpc2ENCnBy b2Nlc3MuDQoNCjQpIEFjY29tbW9kYXRpb25zICYgQnJlYWtmYXN0IEluZm9ybWF0aW9uDQpodHRw Oi8vd3d3LmlldGYub3JnL21lZXRpbmcvNzgvaG90ZWwuaHRtbA0KDQo1KSBJZiB5b3Ugd2FudCB0 byBzdGFydCBwbGFubmluZyBmb3IgeW91ciB0cmlwIHRvIElFVEYgNzkgaW4gQmVpamluZywgd2UN CmhhdmUgdmlzYSBpbmZvcm1hdGlvbiBvbmxpbmUgaGVyZToNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv bWVldGluZy83OS92aXNhLmh0bWwNCg0KT25seSA1MiBkYXlzIHVudGlsIElFVEYgNzghDQoNCg== ------_=_NextPart_001_01CB03B9.4D8B1665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTUuMTAiPg0KPFRJVExFPkZXOiBJRVRGIDc4 IC0gTWVldGluZyBhbmQgU3BvbnNvcnNoaXAgSW5mb3JtYXRpb24gPC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCg0KPFA+ PEZPTlQgU0laRT0yPkZ5aSwgQ2hyaXM8QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQombmJzcDstLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4NCkZyb206ICZuYnNwOyBJRVRGIFNlY3JldGFyaWF0 IFs8QSBIUkVGPSJtYWlsdG86aWV0Zi1zZWNyZXRhcmlhdEBpZXRmLm9yZyI+bWFpbHRvOmlldGYt c2VjcmV0YXJpYXRAaWV0Zi5vcmc8L0E+XTxCUj4NClNlbnQ6Jm5ic3A7Jm5ic3A7IFRodXJzZGF5 LCBKdW5lIDAzLCAyMDEwIDEyOjUxIFBNIFBhY2lmaWMgU3RhbmRhcmQgVGltZTxCUj4NClRvOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXb3JraW5nIEdyb3VwIENoYWlyczxCUj4NClN1YmplY3Q6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElFVEYgNzggLSBNZWV0 aW5nIGFuZCBTcG9uc29yc2hpcCBJbmZvcm1hdGlvbjxCUj4NCjxCUj4NCldvcmtpbmcgR3JvdXAg Q2hhaXJzLDxCUj4NCjxCUj4NCkNhbiB5b3UgcGxlYXNlIGZvcndhcmQgdGhpcyBtZXNzYWdlIHRv IHlvdXIgaW5kaXZpZHVhbCB3b3JraW5nIGdyb3VwPEJSPg0KZW1haWxzIGxpc3RzLiZuYnNwOyBX ZSB3YW50IHRvIGVuc3VyZSB0aGF0IGFzIG1hbnkgcGVvcGxlIGFzIHBvc3NpYmxlIGFyZSBhd2Fy ZTxCUj4NCm9mIHRoZSBzcG9uc29yc2hpcCBvcHBvcnR1bml0aWVzIGF2YWlsYWJsZSBhdCBJRVRG IG1lZXRpbmdzLjxCUj4NCjxCUj4NClRoYW5rIHlvdS48QlI+DQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08QlI+DQo3OHRoIElFVEYgTWVldGluZzxCUj4NCk1hYXN0 cmljaHQsIE5ldGhlcmxhbmRzPEJSPg0KSnVseSAyNS0zMCwgMjAxMDxCUj4NCjxCUj4NCjEuIFNw b25zb3JzaGlwIE9wcG9ydHVuaXRpZXM8QlI+DQoyLiBSZWdpc3RyYXRpb24gVHlwZXM8QlI+DQoz LiBWaXNhcyBhbmQgTGV0dGVycyBvZiBJbnZpdGF0aW9uPEJSPg0KNC4gQWNjb21tb2RhdGlvbnMg JmFtcDsgQnJlYWtmYXN0IEluZm9ybWF0aW9uPEJSPg0KNS4gSUVURiA3OSAoQmVpamluZykgVmlz YSBJbmZvcm1hdGlvbjxCUj4NCjxCUj4NCjEpIFNwb25zb3JzaGlwIE9wcG9ydHVuaXRpZXM8QlI+ DQpUaGVyZSBhcmUgc3RpbGwgc3BvbnNvcnNoaXAgb3Bwb3J0dW5pdGllcyBhbmQgYmVuZWZpdHMg Zm9yIGhpZ2ggcHJvZmlsZTxCUj4NCmNvbXBhbnkvb3JnYW5pemF0aW9uYWwgZXhwb3N1cmUgYXQg dGhlIHVwY29taW5nIElFVEYgbWVldGluZyBpbjxCUj4NCk1hYXN0cmljaHQsIE5ldGhlcmxhbmRz IGZyb20gSnVseSAyNS0zMCwgMjAxMC4mbmJzcDsgQWxsIHNwb25zb3JzaGlwIGZlZXMgZ288QlI+ DQpkaXJlY3RseSB0byBmdW5kIHRoZSBvcGVyYXRpb25zIG9mIHRoZSBJRVRGLiZuYnNwOyBTZWUg dGhlIG9wdGlvbnMgYXQ6PEJSPg0KPEEgSFJFRj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5n Lzc4L2luZGV4Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy83OC9pbmRleC5odG1s PC9BPiBTcG9uc29yc2hpcCBPcHBvcnR1bml0aWVzPEJSPg0KdW5kZXIgR2VuZXJhbC4mbmJzcDsg RWFjaCBvZiB0aGUgc3BvbnNvcnNoaXAgb3B0aW9ucyBwcm92aWRlIGV4dGVuZGVkIGFuZDxCUj4N CnJlcGVhdCBleHBvc3VyZSBhdCB0aGlzIHdlZWtsb25nIG1lZXRpbmcuJm5ic3A7Jm5ic3A7PEJS Pg0KPEJSPg0KUGxlYXNlIGNvbnRhY3QgRHJldyBEdm9yc2hhaywgZHZvcnNoYWtAaXNvYy5vcmcs IHdpdGggYW55IHF1ZXN0aW9uczxCUj4NCmFuZC9vciB0byByZXNlcnZlIHlvdXIgb3JnYW5pemF0 aW9ucyBzcG90LiZuYnNwOyBUaGFua3MgaW4gYWR2YW5jZSBmb3I8QlI+DQpzdXBwb3J0aW5nIHRo ZSBjcml0aWNhbCB3b3JrIG9mIHRoZSBJRVRGITxCUj4NCjxCUj4NCjIpIFJlZ2lzdGVyIG9ubGlu ZSBhdDombmJzcDsgPEEgSFJFRj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5ncy83OC8iPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZ3MvNzgvPC9BPjxCUj4NCjxCUj4NCjMpIExldHRlcnMg b2YgSW52aXRhdGlvbiBhbmQgVmlzYXM8QlI+DQpMZXR0ZXJzIG9mIEludml0YXRpb248QlI+DQpB ZnRlciB5b3UgY29tcGxldGUgdGhlIG1lZXRpbmcgcmVnaXN0cmF0aW9uIHByb2Nlc3MsIHlvdSB3 aWxsIGJlIGdpdmVuIHRoZTxCUj4NCm9wdGlvbiB0byByZXF1ZXN0IGEgbGV0dGVyIG9mIGludml0 YXRpb24uIFlvdSBjYW4gcmVxdWVzdCB0aGUgTGV0dGVyIG9mPEJSPg0KSW52aXRhdGlvbiBhcyBz b29uIGFzIHlvdSBmaW5pc2ggcmVnaXN0cmF0aW9uLCBvciBhdCBhIGxhdGVyIHRpbWUgYnk8QlI+ DQpmb2xsb3dpbmcgdGhlIGxpbmsgcHJvdmlkZWQgaW4gdGhlIGNvbmZpcm1hdGlvbiBlbWFpbC48 QlI+DQo8QlI+DQpWaXNhczxCUj4NClBsZWFzZSBjaGVjayB0aGUgTmV0aGVybGFuZHMgTWluaXN0 cnkgb2YgRm9yZWlnbiBBZmZhaXJzIHNpdGU8QlI+DQooPEEgSFJFRj0iaHR0cDovL3d3dy5taW5i dXphLm5sL2VuL1NlcnZpY2VzL0NvbnN1bGFyX1NlcnZpY2VzL1Zpc2EiPmh0dHA6Ly93d3cubWlu YnV6YS5ubC9lbi9TZXJ2aWNlcy9Db25zdWxhcl9TZXJ2aWNlcy9WaXNhPC9BPikgZm9yIGxpc3Qg b2Y8QlI+DQpjb3VudHJpZXMgd2l0aCB2aXNhIGV4ZW1wdGlvbnMuPEJSPg0KPEJSPg0KV2UgcmVj b21tZW5kIHlvdSBnaXZlIHlvdXJzZWxmIGF0IGxlYXN0IG9uZSBtb250aCB0byBjb21wbGV0ZSB0 aGUgdmlzYTxCUj4NCnByb2Nlc3MuPEJSPg0KPEJSPg0KNCkgQWNjb21tb2RhdGlvbnMgJmFtcDsg QnJlYWtmYXN0IEluZm9ybWF0aW9uPEJSPg0KPEEgSFJFRj0iaHR0cDovL3d3dy5pZXRmLm9yZy9t ZWV0aW5nLzc4L2hvdGVsLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy83OC9ob3Rl bC5odG1sPC9BPjxCUj4NCjxCUj4NCjUpIElmIHlvdSB3YW50IHRvIHN0YXJ0IHBsYW5uaW5nIGZv ciB5b3VyIHRyaXAgdG8gSUVURiA3OSBpbiBCZWlqaW5nLCB3ZTxCUj4NCmhhdmUgdmlzYSBpbmZv cm1hdGlvbiBvbmxpbmUgaGVyZTo8QlI+DQo8QSBIUkVGPSJodHRwOi8vd3d3LmlldGYub3JnL21l ZXRpbmcvNzkvdmlzYS5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvNzkvdmlzYS5o dG1sPC9BPjxCUj4NCjxCUj4NCk9ubHkgNTIgZGF5cyB1bnRpbCBJRVRGIDc4ITxCUj4NCjxCUj4N CjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01CB03B9.4D8B1665-- From clonvick@cisco.com Mon Jun 7 10:19:50 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DFF3A6DC6 for ; Mon, 7 Jun 2010 10:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgSHLRj6oMUj for ; Mon, 7 Jun 2010 10:19:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2998828C3C4 for ; Mon, 7 Jun 2010 08:44:08 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAJapDEyrR7H+/2dsb2JhbACSLQEBjBhxpEqaAYUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="541038850" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2010 15:16:43 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o57FGh62007583 for ; Mon, 7 Jun 2010 15:16:43 GMT Date: Mon, 7 Jun 2010 08:16:42 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Resolving Open Issues in syslog/dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:19:50 -0000 Hi Folks, I'm going to send around a bunch-o-emails about the issues that were raised from the IETF Last Call and from the IESG reviews. Please respond to each keeping the subject line so that I can keep track of things. if I don't see any discussion on comments and nits, I'll leave it to the authors to agree upon changes. I _DO_ want to see discussion on the IESG DISCUSS issues. Many thanks to Sean for keeping this discussion going while I was taking care of the day job. :-) Thanks, Chris From clonvick@cisco.com Mon Jun 7 10:20:21 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0F73A6EB5 for ; Mon, 7 Jun 2010 10:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJM4Wsw+cRgW for ; Mon, 7 Jun 2010 10:20:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9D2A828C4AD for ; Mon, 7 Jun 2010 08:45:17 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAEuqDEyrR7H+/2dsb2JhbACSLQGMGXGkXpoChRcEg0o X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="332793115" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2010 15:18:05 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o57FI5tB008812 for ; Mon, 7 Jun 2010 15:18:05 GMT Date: Mon, 7 Jun 2010 08:18:05 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 2 - Fragmentation X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:20:21 -0000 Issue 2 - Fragmentation Joe summarized: Tim Evans brought up the problem of fragmentation and reordering that may not be taken care of by the DTLS layer. I'm not sure I fully understand this issue. It seems that there is an issue here. The issue seems to be that a SYSLOG application message can span multiple DTLS records. Is it feasible to restrict this behavior? Pasi wrote the following: vvv I would prefer to keep syslog-over-DTLS-over-UDP as similar to RFC 5246 (syslog-over-UDP) as possible -- i.e. don't add any kind of fragmentation/reassembly in syslog layer. Both syslog-over-UDP and syslog-over-DTLS-over-UDP already support messages up to ~64K; they're just not very efficient if your MTU is small (and you need IP layer fragmentation). But for administrators that know they'll need efficient transport of large messages, we already have a solution: RFC 5425. ^^^ Tom Petch responded to Pasi with: vvv >The maximum size of a single DTLS record is 2^14 bytes (this limit >comes from TLS). Where?:-) TLS provides fragmentation and says that "length MUST NOT exceed 2^14." [RFC5246 s6.2.1] so that the upper layers can send larger messages which TLS then fragments for them. DTLS provides fragmentation for handshake messages [RFC4347 s3.2.3] but not for the record layer; rather it says, " As in TLS 1.1, the length should not exceed 2^14." should not, no MUST NOT as in [RFC5246] (and draft-ietf-tls-rfc4347-bis has the same text) So while 65535 byte messages are not generally acceptable, where the users know their network and its MTU, then we should let them do what they know best. I see the main use of syslog in switched Enterprise LAN where large MTU are a commonplace. ^^^ Pasi responded with: vvv RFC 4346 (from which this text comes from) mostly did not use RFC2119 keywords, but instead informal language like the lowercase "should not" you quoted. AFAIK it was meant to express a strict limit, not a recommendation (this is implied by other text in the spec, and as you noticed, we clarified this in RFC 5246). But even though DTLS records are limited to 2^14 bytes, syslog messages are not! The current spec seems to support 64K (minus some small number of overhead) just fine -- the message will be split to multiple DTLS records (max. 2^14 bytes each), but those DTLS records are then combined to a single UDP datagram. ^^^ Tim wrote something (badly formatted) and Pasi responded: vvv Tim Evens wrote: >> But even though DTLS records are limited to 2^14 bytes, syslog >> messages are not! The current spec seems to support 64K (minus some >> small number of overhead) just fine -- the message will be split to >> multiple DTLS records (max. 2^14 bytes each), but those DTLS >> records are then combined to a single UDP datagram. > > Ahh... Only if DTLS sequence numbers are used and if they are > implemented using a reorder queueing method can a message be split > into "chunks" that are transmitted over multiple DTLS records. No -- even if you split a message to multiple DTLS records, all those records are sent in a *single* UDP datagram, in order. So there's no need to queue/reorder packets based on DTLS sequence numbers. (The one UDP datagram might, of course, get fragmented to several IP packets, but this happens below UDP and DTLS, so DTLS sequence numbers are not involved...) ^^^ Tim wrote: Interesting because RFC4347 IMHO states clearly that IP fragmentation (IP not UDP) must be avoided and thus dtls must determine the MTU. Final word from Pasi was: RFC 4347 does strongly recommend avoiding IP fragmentation (which doesn't necessarily work all that great through broken middleboxes, and won't lead to good performance), but it does not forbid it. ACTION: WG consensus is to support very large syslog messages. Authors need to explain this in the document. From clonvick@cisco.com Mon Jun 7 10:20:21 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBC93A6EB4 for ; Mon, 7 Jun 2010 10:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.37 X-Spam-Level: X-Spam-Status: No, score=-8.37 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+wAzsPgKr5t for ; Mon, 7 Jun 2010 10:20:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CFB963A694E for ; Mon, 7 Jun 2010 08:45:17 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAEuqDEyrR7Hu/2dsb2JhbACSLQEBjBhxpF6aAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="332793201" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2010 15:18:26 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o57FIQew023285 for ; Mon, 7 Jun 2010 15:18:26 GMT Date: Mon, 7 Jun 2010 08:18:26 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 3 - Text revision from GENART review X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:20:21 -0000 Issue 3 - Text revision from GENART review >From Miguel Garcia (GENART review) - In Section 5.3, the last sentence of the first paragraph reads: "When the DTLS handshake has finished, the transport sender MAY then send the first syslog message." I think what you really want to say is: "The transport sender MUST NOT send any syslog message before the DTLS handshake has successfully completed." Proposal supported by Russ Housley ACTION: No opposition to this seen. Authors to incorporate. From clonvick@cisco.com Mon Jun 7 10:21:06 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542B43A6DDE for ; Mon, 7 Jun 2010 10:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.515 X-Spam-Level: X-Spam-Status: No, score=-9.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI3JuRozpBSq for ; Mon, 7 Jun 2010 10:21:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6074628C5AA for ; Mon, 7 Jun 2010 08:48:33 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAP6qDEyrR7H+/2dsb2JhbACSLQEBjBhxpGGaAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="225532749" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2010 15:20:57 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o57FKvqS011361 for ; Mon, 7 Jun 2010 15:20:57 GMT Date: Mon, 7 Jun 2010 08:20:56 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 11 - Adrian Farrel DISCUSS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:21:06 -0000 Issue 11 - Security Adrian Farrel DISCUSS Discuss: I am not a security expert so I would like to discuss with the Security ADs whether this work shouldn't also discuss (automatic) key management in the context of RFC 4107. Sean reported that after a short chat session during the call Adrian cleared. STATUS: RESOLVED From clonvick@cisco.com Mon Jun 7 10:23:25 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404523A6A1B for ; Mon, 7 Jun 2010 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.486 X-Spam-Level: X-Spam-Status: No, score=-8.486 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35o3K171hyO3 for ; Mon, 7 Jun 2010 10:23:24 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 568F93A6B18 for ; Mon, 7 Jun 2010 09:02:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFANKpDEyrR7Ht/2dsb2JhbACSLQGMGXGkS5oBhRcEg0o X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="140531839" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 15:17:38 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o57FHbSU008129 for ; Mon, 7 Jun 2010 15:17:37 GMT Date: Mon, 7 Jun 2010 08:17:37 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 1 - COMMENT from Alexy X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:23:25 -0000 Issue 1 - COMMENT from Alexy Comment: 5.4.1. Message Size There is no upper limit for a message length per se. As stated in [RFC4347], each DTLS record MUST fit within a single DTLS datagram. When mapping onto different transports, DTLS has different record size limitations. The application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over the transport in use. The message size SHOULD NOT exceed the DTLS maximum record size limitation of 2^14 bytes. Why is this "SHOULD NOT" and not a "MUST NOT"? The quoted requirement from [RFC4347] doesn't seem to give any excuses. Tom Petch wrote: vvv On the question of maximum size, I think we should not change the text. RFC4347 has a should not and not a must not so I think that we need a good reason to change. And in fact, the opposite is true. There has been pressure on the syslog list to allow 65,535 byte messages - healthcare as I recall - so limiting the size to 2**14 would exclude a known application ^^^ Sean wrote: vvv On avoiding long packets: A.4 of syslog (RFC5424), I believe, addresses this. Additionally, syslog over UDP (RFC5426) also addresses this. Both are normative references. ^^^ Sean wrote: vvv The text from RFC 4347 is: length Identical to the length field in a TLS 1.1 record. As in TLS 1.1, the length should not exceed 2^14. I think they're not trying to up the requirements in RFC 4347. They are however using 2119 language ;) ^^^ Tom also wrote: vvv I see that this I-D had entered 'Revised I-D needed' which I would like to progress. I see several comments about maximum record size, including a suggestion that we should make the 'SHOULD NOT' a 'MUST NOT' exceed 2**14. I am dead set against this change. We had a clear requirment, early on, to allow 65k messages, and I think it wrong to MUST NOT that requirement. The text in the other I-Ds is a compromise to strke a balance between this and having everything fit in 576 byte; I think we have the balance right. ^^^ Rainer strongly agrees with this and gives examples from use. Pasi wrote: vvv I haven't followed this discussion in detail, but it looks like there's some confusion about the basic "units" of transmission. As far as I can tell, we have four different layers: - a syslog message (SYSLOG-FRAME in ABNF) - a DTLS record - a UDP datagram - an IP packet As noted in Section 5.4, "It is possible that multiple syslog messages be contained in one DTLS record, or that a syslog message be transferred in multiple DTLS records." The maximum size of a single DTLS record is 2^14 bytes (this limit comes from TLS). One DTLS record must fit in one UDP datagram, but one UDP datagram can contain more than one DTLS record. The maximum size of UDP datagram is 64K (this limit comes from UDP), but it can be fragmented to multiple IP packets as needed. There's one additional restriction that I'm not sure is really mentioned anywhere: A single syslog message has to fit in a single UDP datagram. So while it can be split to multiple DTLS records, all those records have to be in a single UDP datagram (so the syslog layer does not reassemble syslog message pieces from multiple UDP datagrams -- SYSLOG-FRAME does not have sufficient information to do this anyway). In addition to the "hard" size limits (coming from DTLS and UDP), we probably need a recommendation saying that it's better if you can avoid IP fragmentation -- but this is precisely the same as normal syslog-over-UDP (minus the small overhead from DTLS). ^^^ Robert Horn wrote: In this case, could the requirement be rephrased in syslog over dtls. Rather than imply that the 2**14 limit is de novo in syslog, a phrasing like "RFC 4347 limits the size of DTLS message bodies to 2**14 bytes" would be preferable. The limit will still be an issue for some parts of healthcare and this kind of phrasing points to the real source of the limit. Then, if some later version of DTLS changes that limit, the syslog over dtls would inherit that change. This would be consistent with the approach taken in syslog over UDP, where the size limits are recommendations up until the hard limit for the size of a UDP message, and it is made clear that UDP is the reason for the hard limit. ACTION: Authors need to clarify this and obtain WG consensus. From clonvick@cisco.com Mon Jun 7 10:23:26 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012C33A6A71 for ; Mon, 7 Jun 2010 10:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.689 X-Spam-Level: X-Spam-Status: No, score=-9.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejuEjXyEK0eg for ; Mon, 7 Jun 2010 10:23:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6B7FB28C74D for ; Mon, 7 Jun 2010 09:02:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAP6qDEyrRN+K/2dsb2JhbACSLQEBjBhxpGGaAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="140532582" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 15:19:03 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o57FJ34r015827 for ; Mon, 7 Jun 2010 15:19:03 GMT Date: Mon, 7 Jun 2010 08:19:03 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 5 - Reference X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:23:26 -0000 Issue 5 - Reference >From Miguel Garcia (GENART review) - Section 5.3, second paragraph. It would be nice to have a reference to the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. Tom Petch responded: In passing, there was a request for a reference for the ciphersuite, which could be covered by adding 'as specified there' after 'cipher suite'. ACTION: Authors to review and incorporate a change. From clonvick@cisco.com Mon Jun 7 10:23:26 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357783A6A71 for ; Mon, 7 Jun 2010 10:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.096 X-Spam-Level: X-Spam-Status: No, score=-9.096 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vul6pu5KNtd for ; Mon, 7 Jun 2010 10:23:24 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 677BC28C74C for ; Mon, 7 Jun 2010 09:02:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAP6qDEyrRN+K/2dsb2JhbACSLQEBjBhxpGGaAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="140532476" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 15:18:50 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o57FIoLe015726 for ; Mon, 7 Jun 2010 15:18:50 GMT Date: Mon, 7 Jun 2010 08:18:50 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 4 - Service code subregistry X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:23:26 -0000 Issue 4 - Service code subregistry >From Miguel Garcia (GENART review) - I noticed that IANA picked well their actions. However, it would be better if, in the second paragraph of Section 8, you specified that the registry where IANA needs to operate is the "Service Code subregisty of the Datagram Congestion Control Protocol (DCCP) Parameters registry". Also, Lars COMMENT: Section 8., paragraph 1: > IANA is requested to assign a registered UDP and DCCP port number for > syslog over DTLS. The same value as for syslog over TLS (6514) is > requested. Do you also want the same service name (i.e., syslog-tls) for 6514/udp and 6514/dccp? Sean wrote: vvv So I thought the service code/name was for this registry: http://www.iana.org/assignments/service-codes/service-codes.xhtml That's the part where we register: 1398361159 SYLG Syslog Protocol [RFCTBD] I think you're suggesting that we also need to update the following registry: http://www.iana.org/assignments/port-numbers If that's true, then yes we'd like to update: OLD: # 6514/udp Reserved NEW: syslog-tls 6514/udp Syslog over DTLS [RFC TBD] syslog-tls 6514/dccp Syslog over DTLS [RFC TBD] ^^^ Lars responded vvv Service *names* and service *codes* are different things. Service codes are DCCP-only things living at the registry at the URL = above. Service names are currently defined in several registries, which will be = unified by draft-ietf-tsvwg-iana-ports to be into the first column of = the port numbers table. The current IANA instructions in the ID only say what port you want for = syslog-over-DTLS but not which servive *name*. Lars > If that's true, then yes we'd like to update: > > OLD: > > 6514/udp Reserved > > NEW: > > syslog-tls 6514/udp Syslog over DTLS > [RFC TBD] > syslog-tls 6514/dccp Syslog over DTLS > [RFC TBD] That's exactly what needs to be added. Stick it into an RFC Editor Note? ^^^ Sean's proposed resolution: #5) Add sentence about keyword/service name for the following registry http://www.iana.org/assignments/port-numbers in Section 8: OLD: IANA is requested to assign a registered UDP and DCCP port number for syslog over DTLS. The same value as for syslog over TLS (6514) is requested. IANA is requested to assign the service code SYLG to syslog for use with DCCP. The allocation in the service code registry should be as follows: 1398361159 SYLG Syslog Protocol [RFCTBD] NEW: IANA is requested to assign a registered UDP and DCCP port number and keyword for syslog over DTLS. The same values as for syslog over TLS (syslog-tls and 6514) are requested. That is, update the registry as follows: syslog-tls 6514/udp Syslog over DTLS [RFC TBD] syslog-tls 6514/dccp Syslog over DTLS [RFC TBD] IANA is also requested to assign the service code SYLG to syslog for use with DCCP. The allocation in the service code registry should be as follows: 1398361159 SYLG Syslog Protocol [RFCTBD] ACTION: Authors to review and incorporate this proposal. From clonvick@cisco.com Mon Jun 7 10:23:26 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4BC28C0F7 for ; Mon, 7 Jun 2010 10:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.842 X-Spam-Level: X-Spam-Status: No, score=-9.842 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNZ9TSbCPjF7 for ; Mon, 7 Jun 2010 10:23:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7478E28C74E for ; Mon, 7 Jun 2010 09:02:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAP6qDExAaHte/2dsb2JhbACSLQEBjBhxpGGaAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="140532699" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 15:19:16 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o57FJFl1028891 for ; Mon, 7 Jun 2010 15:19:15 GMT Date: Mon, 7 Jun 2010 08:19:14 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 6 - Reference 2 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:23:26 -0000 Issue 6 - Reference 2 >From Miguel Garcia (GENART review) - Section 5.4.1: It would be nice to add a formal reference to RFC 5425 when it is mentioned. ACTION: Authors to review and incorporate a change if needed. From clonvick@cisco.com Mon Jun 7 10:23:26 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2EF328C103 for ; Mon, 7 Jun 2010 10:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.937 X-Spam-Level: X-Spam-Status: No, score=-9.937 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl0Iy+Gl-YhA for ; Mon, 7 Jun 2010 10:23:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8196628C74F for ; Mon, 7 Jun 2010 09:02:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAP6qDEyrRN+K/2dsb2JhbACSLQEBjBhxpGGaAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="140533019" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 15:19:44 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o57FJi5Q016213 for ; Mon, 7 Jun 2010 15:19:44 GMT Date: Mon, 7 Jun 2010 08:19: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 Subject: [Syslog] Issue 8 - Tim Polk DISCUSS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:23:27 -0000 Issue 8 - Tim Polk DISCUSS Discuss: There seems to be an essential disconnect between the conformance rquirements and the deployment guidance in this specification The second paragraph of Section 6 Congestion Control states: DCCP has congestion control. For this reason the syslog over DTLS over DCCP option is recommended in preference to the syslog over the DTLS over UDP option. However, in Section 5.1, Transport DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. For alignment with Section 6, it would seem that "MUST support DTLS over DCCP" would be more appropriate. Proposed resolution by Sean: vvv As noted by Lars (before my time on either the IESG or syslog list): If DCCP is available (not usually the case) running DTLS over it is trivial, so you could also make this a MUST. DCCP support itself is obviously not a MUST. Maybe what we really ought to be saying is Section 6 (which is just about congestion control): DCCP has congestion control. For this reason when DCCP is available, syslog over DTLS over DCCP is recommended in preference to the syslog over the DTLS over UDP option. and we leave Section 5 alone? ^^^ Tim Polk responded: vvv I will defer to Lars on this one. Since we can't make DCCP support a MUST, your suggested text for Section 6 would resolve what remains of my issue. ^^^ ACTION: Authors to review proposed resolution and discuss on list. From clonvick@cisco.com Mon Jun 7 10:23:27 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA2E28C10E for ; Mon, 7 Jun 2010 10:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.011 X-Spam-Level: X-Spam-Status: No, score=-10.011 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-f8A8AGEg0b for ; Mon, 7 Jun 2010 10:23:26 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8CF4028C755 for ; Mon, 7 Jun 2010 09:02:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAP6qDEyrRN+J/2dsb2JhbACSLQEBjBhxpGGaAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="140533857" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 15:21:09 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o57FL9YR027494 for ; Mon, 7 Jun 2010 15:21:09 GMT Date: Mon, 7 Jun 2010 08:21:09 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 12 - nit X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:23:27 -0000 Issue 12 - nit I must have missed this somewhere - Sean wrote: #1.1) Section 5.1 OLD: Transports, such as UDP or DCCP do not provide session multiplexing and session-demultiplexing. NEW: Transports such as UDP or DCCP do not provide session multiplexing and session-demultiplexing. ACTION: Authors to review and incorporate. From clonvick@cisco.com Mon Jun 7 10:23:27 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6A528C103 for ; Mon, 7 Jun 2010 10:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.769 X-Spam-Level: X-Spam-Status: No, score=-8.769 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLC+ubz4IGuN for ; Mon, 7 Jun 2010 10:23:26 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8955228C752 for ; Mon, 7 Jun 2010 09:02:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAP6qDEyrR7Ht/2dsb2JhbACSLQGMGXGkYZoChRcEg0o X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="140533622" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 15:20:45 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o57FKj0S010908 for ; Mon, 7 Jun 2010 15:20:45 GMT Date: Mon, 7 Jun 2010 08:20:45 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 10 - Jari Arrko DISCUSS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:23:27 -0000 Issue 10 - Jari Arrko DISCUSS Discuss: This is an excellent document and I was ready to post a Yes vote on the ballot. However, there is one detail. The document says: When mapping onto different transports, DTLS has different record size limitations. The application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over the transport in use. The message size SHOULD NOT exceed the DTLS maximum record size limitation of 2^14 bytes. To be consistent with RFC 5425, in establishing a baseline for interoperability, this specification requires that a transport receiver MUST be able to process messages with a length up to and including 2048 octets. Transport receivers SHOULD be able to process messages with lengths up to and including 8192 octets. This guidance seems quite weak in terms of avoiding excessive fragmentation. Or am I misunderstanding how DTLS records map to UDP packets? I am assuming its a 1-1 mapping, but maybe I'm mistaken. In any case, the document should say something about tuning applications and configurations to avoid excessively long packets due to inefficiencies and other problems that fragmentation may cause. ^^^^ Sean proposes: vvv As this I-D is about two transports and they do somethings differently, I suggest we point to both sets of considerations. How about a multi-pronged approach: #1) Specifically mention UDP/DCCP message size/length text in 5.1. WRT DCCP and tuning, RFC 4340 (DCCP) says "A DCCP application interface SHOULD let the application discover DCCP's current" maximum packet size. So I'm not sure we should go stronger (i.e., make it a MUST). In the text below, RFC 5426 is syslog over UDP: OLD: When mapping onto different transports, DTLS has different record size limitations. The application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over the transport in use. The message size SHOULD NOT exceed the DTLS maximum record size limitation of 214 bytes. ... NEW When mapping onto different transports, DTLS has different record size limitations. For UDP, see section 3.2 of [RFC5426]. For DCCP, the application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over DCCP, as specified in [RFC4340]. The message size SHOULD NOT exceed the DTLS maximum record size limitation of 214 bytes. ... #2) Add new text in Section 5.1 that points to the syslog message fragmentation implementation guidance: See section A.2 of [RFC5424] for implementation guidance on message length, including fragmentation. ^^^ Sean's proposed resolution: Jari's points about message size/length/fragmentation in Section 5.4.1: OLD: DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. Transports, such as UDP or DCCP do not provide session multiplexing and session-demultiplexing. In such cases, the application implementer provides this functionality by mapping a unique combination of the remote address, remote port number, local address and local port number to a session. NEW: When mapping onto different transports, DTLS has different record size limitations. For UDP, see section 3.2 of [RFC5426]. For DCCP, the application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over DCCP, as specified in [RFC4340]. Regardless of the transport, the message size SHOULD NOT exceed the DTLS maximum record size limitation of 214 bytes. To be consistent with RFC 5425, in establishing a baseline for interoperability, this specification requires that a transport receiver MUST be able to process messages with a length up to and including 2048 octets. Transport receivers SHOULD be able to process messages with lengths up to and including 8192 octets. See section A.2 of [RFC5424] for implementation guidance on message length, including fragmentation. ACTION: Authors to review and discuss on list before committing to a plan. From clonvick@cisco.com Mon Jun 7 10:23:27 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979B428C103 for ; Mon, 7 Jun 2010 10:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.025 X-Spam-Level: X-Spam-Status: No, score=-8.025 tagged_above=-999 required=5 tests=[AWL=-1.375, BAYES_40=-0.185, FRT_STRONG2=1.535, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9ux-ZOhXcsY for ; Mon, 7 Jun 2010 10:23:26 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 95BAD28C757 for ; Mon, 7 Jun 2010 09:02:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAP6qDEyrRN+J/2dsb2JhbACSLQEBjBhxpGGaAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="140533987" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2010 15:21:22 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o57FLMDS027626 for ; Mon, 7 Jun 2010 15:21:22 GMT Date: Mon, 7 Jun 2010 08:21:21 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 13 - DCCP? X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:23:27 -0000 Issue 13 - DCCP? Tom Petch wrote: vvv Another issue that came up from the IESG is the relative roles of UDP and DCCP as a substrate. In this context, the discussions on tsvwg which Lars is steering about SCTP, DCCP and UDP make interesting reading, with some contributors asserting that the only way to get a packet through a complex network is with UDP, that SCTP and DCCP are (comparative) failures that just don't get recognised widely enough. Certainly my (limited) view is that UDP is the MUST HAVE, the one that will give maximum interoperability so while DCCP is technically superior, making it the MUST implement will simply cause this I-D to be ignored by most. I haven't seen any response from Lars on this issue. ^^^ DBH responded: vvv Lars provided advice quite a while back. I concur with his advice. Implementers MUST implement support for DCCP (which should require minimal changes from support for UDP), so that if DCCP is available, and the operator chooses to use DCCPP, the implementation will work with DCCP. I view this as very similar to our standard security posture - stroing security is MUST implement, so it is available if the operator wants it. The operator is not required to use it. ^^^ ACTION: None - I think this is resolved. From clonvick@cisco.com Mon Jun 7 10:25:13 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFDC3A68BF for ; Mon, 7 Jun 2010 10:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.885 X-Spam-Level: X-Spam-Status: No, score=-9.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8OdvAlWJ8HM for ; Mon, 7 Jun 2010 10:25:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F14033A6A28 for ; Mon, 7 Jun 2010 09:10:22 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAP6qDEyrRN+K/2dsb2JhbACSLQEBjBhxpGGaAoUXBINK X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="208312927" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2010 15:19:29 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o57FJTmw016076 for ; Mon, 7 Jun 2010 15:19:29 GMT Date: Mon, 7 Jun 2010 08:19:29 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 7 - text X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:25:14 -0000 Issue 7 - text >From Miguel Garcia (GENART review) - Third paragraph in Secction 6: s/udp/UDP ACTION: Authors to review and change. From clonvick@cisco.com Mon Jun 7 10:25:14 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F463A68BF for ; Mon, 7 Jun 2010 10:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.64 X-Spam-Level: X-Spam-Status: No, score=-8.64 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lowhjcq6bRte for ; Mon, 7 Jun 2010 10:25:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1C6C528C8B9 for ; Mon, 7 Jun 2010 09:10:29 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAP6qDEyrRN+J/2dsb2JhbACSLQGMGXGkYZoCgnqCHQSDSg X-IronPort-AV: E=Sophos;i="4.53,378,1272844800"; d="scan'208";a="208313337" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2010 15:20:09 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o57FK9KT027017 for ; Mon, 7 Jun 2010 15:20:09 GMT Date: Mon, 7 Jun 2010 08:20:09 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:25:14 -0000 Issue 9 - Tim Polk COMMENT Comment: Given that disclosure is one of the primary threats described in Section 4, shouldn't the security considerations prohibit the use of cipher suites with NULL encryption? Prpposed resolution by Sean: vvv A.5 of RFC 5246, which is where the cipher suites for both TLS and DTLS end up pointing and is included in this I-Ds security considerations, includes the following: TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS connection during the first handshake on that channel, but MUST NOT be negotiated, as it provides no more protection than an unsecured connection. I could see how this might be worth repeating, but waned to make you aware it was in RFC 5246. ^^^ Tim responded: vvv Thanks for pointing out that text; that is helpful but not sufficient, though. I am actually worried about cipher suites that have authenticatio= n & integrity but NULL encryption as well. There are a bunch of those: CipherSuite TLS_RSA_WITH_NULL_MD5 =3D { 0x00,0x01 }; CipherSuite TLS_RSA_WITH_NULL_SHA =3D { 0x00,0x02 }; CipherSuite TLS_RSA_WITH_NULL_SHA256 =3D { 0x00,0x3B }; 0x00,0x2C TLS_PSK_WITH_NULL_SHA [RFC4785] 0x00,0x2D TLS_DHE_PSK_WITH_NULL_SHA [RFC4785] 0x00,0x2E TLS_RSA_PSK_WITH_NULL_SHA 0xC0,0x06 TLS_ECDHE_ECDSA_WITH_NULL_SHA [RFC4492] ...among others. (Pardon the formatting, pulled some from 5246 and others from the iana registry...) ^^^ Sean responsed: vvv Ah! I see your point now. How about we tweak the last paragraph in section 5.3 (obviously I'd like author input on this): OLD: Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. NEW: Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a minimum support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL encryption, integrity, or authentication algorithms. ^^^ Sean's proposed resolution: vvv #3) Tim's point about restricting NULL cipher suites. At the end of section 5.3: OLD: Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. NEW: Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a minimum support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL encryption, integrity, or authentication algorithms. ^^^ Tom Petch responded: vvv I disagree. The threat of disclosure comes from RFC5425 s2 "Some data in syslog messages is sensitive and may be useful to an attacker, such as the password of an authorized administrator or user." but the fact that someone, somewhere may put a password in a syslog message I do not see as grounds for requiring everyone else in the world to encrypt everything. Encryption is a pain, it costs, and we should not require it unless it can be justified; these are remote, low-powered network boxes we are talking about, not enterprise servers. So while I agree we should require authentication, I see no justification for encryption. ^^^ Action: I'd like to get some additional discussion going on this. ============================================== issue 9A - Sean also suggested this: vvv #3) Tim's point about restricting NULL cipher suites. At the end of section 5.3: OLD: Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. NEW: Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a minimum support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL encryption, integrity, or authentication algorithms. ^^^ ACTION: Waiting on discussion for Issue 9. =============================================== Issue 9B - Sean also suggests: #6) Section 9. Tim pointed out that because this I-D relies on self-signed certificates it needs to say something about certificates (I looked in DTLS/TLS and they don't point to 5280), keeping the private key private, generating good random #s, and taking care when installing trust anchors. Most of this is in RFC 5280 so if we add it to the first line of the security considerations we're good except for the make a good private key and installing the trust anchor. Suggested text below: OLD: The security considerations in [RFC5425], [RFC5246] and [RFC4347] apply to this document. NEW (yes I reordered them so Alfred won't complain later): The security considerations in [RFC4347], [RFC5246], [RFC5425], and [RFC5280] apply to this document. and we should add two new paragraphs: 9.2 Private Key Generation Transport receiver and transport sender implementations generate their own key pairs. An inadequate random number generator (RNG) or an inadequate pseudo-random number generator (PRNG) to generate these keys can result in little or no security. See [RFC4086] for random number generation guidance. 9.3 Trust Anchor Installation and Storage Trust anchor installation and storage is critical. Transmission of a trust anchor, especially self-signed certificates used as trust anchors, from transport receiver to transport sender for installation requires an out-of-band step(s). Care must be taken to ensure the installed trust anchor is in fact the correct trust anchor. The fingerprint mechanism in Section 5.3.1 can be used by the transport sender to ensure the transport receiver's self-signed certificate is properly installed. Trust anchor information must be securely stored. Changes to trust anchor information can cause acceptance of certificates that should be rejected. ACTION: I'm also going to ask for more discussion on this. From ietfc@btconnect.com Tue Jun 8 03:03:41 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E12D28C155 for ; Tue, 8 Jun 2010 03:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY9jqUihaeGk for ; Tue, 8 Jun 2010 03:03:40 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 534B628C121 for ; Tue, 8 Jun 2010 03:03:40 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr13.btconnect.com with SMTP id FJY64740; Tue, 8 Jun 2010 11:03:34 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C0E1567.012B, actions=tag Message-ID: <01d601cb06e9$02b5b300$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Chris Lonvick" , References: Date: Tue, 8 Jun 2010 10:56:21 +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-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0206.4C0E1576.0341,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Syslog] Issue 6 - Reference 2 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:03:41 -0000 Presumably this is s5.4.1 where we lack the [ ] that are present in all other references to RFC5425. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, June 07, 2010 5:19 PM Subject: [Syslog] Issue 6 - Reference 2 > Issue 6 - Reference 2 > > From Miguel Garcia (GENART review) > > - Section 5.4.1: It would be nice to add a formal reference to RFC 5425 > when it is mentioned. > > > ACTION: Authors to review and incorporate a change if needed. > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfc@btconnect.com Tue Jun 8 03:03:42 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2C028C164 for ; Tue, 8 Jun 2010 03:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MABLeTpXrgSq for ; Tue, 8 Jun 2010 03:03:40 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 534CC28C152 for ; Tue, 8 Jun 2010 03:03:40 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr13.btconnect.com with SMTP id FJY64728; Tue, 8 Jun 2010 11:03:33 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C0E1567.012B, actions=tag Message-ID: <01d401cb06e9$0227cae0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Chris Lonvick" , References: Date: Tue, 8 Jun 2010 10:22:57 +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-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0204.4C0E1576.0025,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:03:42 -0000 I see two separate issues here, trust anchor and mandatory encryption, and it is the latter I am absolutely against. Just because someone, somewhere in the world may send confidential data in a syslog message does not mean the IETF must REQUIRE everyone, everywhere in the world to encrypt everything. It's ...... The IESG had a go at SNMP over this but SNMP got its oar in decades ago by specifying that authnopriv(acy) was a part of SNMP, and so it has remained, as the mechanics of security have evolved. If that is ok for SNMP, with all the important data it carries, I think it suitable for syslog ie NULL encryption is fine and we would be doing our users an injustice to deny them the option. The argument based on our mention of disclosure as a threat in RFC5425 I find spurious; it means that encryption must be an option, not that everyone must use it all the time. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, June 07, 2010 5:20 PM Subject: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT > Issue 9 - Tim Polk COMMENT > > Comment: > Given that disclosure is one of the primary threats described in Section > 4, shouldn't the security considerations prohibit the use of cipher suites > with NULL encryption? > > Prpposed resolution by Sean: > vvv > A.5 of RFC 5246, which is where the cipher suites for both TLS and > DTLS end up pointing and is included in this I-Ds security > considerations, includes the following: > > TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a > TLS connection during the first handshake on that channel, but MUST > NOT be negotiated, as it provides no more protection than an > unsecured connection. > > I could see how this might be worth repeating, but waned to make you > aware it was in RFC 5246. > ^^^ > > Tim responded: > vvv > Thanks for pointing out that text; that is helpful but not sufficient, > though. I am actually worried about cipher suites that have > authenticatio= > n > & integrity but NULL encryption as well. There are a bunch of those: > > CipherSuite TLS_RSA_WITH_NULL_MD5 =3D { 0x00,0x01 }; > CipherSuite TLS_RSA_WITH_NULL_SHA =3D { 0x00,0x02 }; > CipherSuite TLS_RSA_WITH_NULL_SHA256 =3D { 0x00,0x3B }; > 0x00,0x2C TLS_PSK_WITH_NULL_SHA [RFC4785] > 0x00,0x2D TLS_DHE_PSK_WITH_NULL_SHA [RFC4785] > 0x00,0x2E TLS_RSA_PSK_WITH_NULL_SHA > 0xC0,0x06 TLS_ECDHE_ECDSA_WITH_NULL_SHA [RFC4492] > > ...among others. > > (Pardon the formatting, pulled some from 5246 and others from the iana > registry...) > ^^^ > > Sean responsed: > vvv > Ah! I see your point now. How about we tweak the last paragraph in > section 5.3 (obviously I'd like author input on this): > > OLD: > > Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the > mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. > > NEW: > > Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a > minimum support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are > supported, then implementations MUST NOT negotiate a cipher suite > that employs NULL encryption, integrity, or authentication > algorithms. > ^^^ > > Sean's proposed resolution: > vvv > #3) Tim's point about restricting NULL cipher suites. At the end of > section 5.3: > > OLD: > > Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the > mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. > > NEW: > > Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a > minimum support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are > supported, then implementations MUST NOT negotiate a cipher suite > that employs NULL encryption, integrity, or authentication > algorithms. > ^^^ > > Tom Petch responded: > vvv > I disagree. The threat of disclosure comes from RFC5425 s2 > "Some data in syslog messages is sensitive and may be > useful to an attacker, such as the password of an authorized > administrator or user." > but the fact that someone, somewhere may put a password in a syslog > message I do not see as grounds for requiring everyone else in the world > to encrypt everything. Encryption is a pain, it costs, and we should not > require it > unless it can be justified; these are remote, low-powered network boxes > we are talking about, not enterprise servers. > > So while I agree we should require authentication, I see no > justification for encryption. > ^^^ > > Action: I'd like to get some additional discussion going on this. > > > ============================================== > issue 9A - > > Sean also suggested this: > vvv > #3) Tim's point about restricting NULL cipher suites. At the end of > section 5.3: > > OLD: > > Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the > mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. > > NEW: > > Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a > minimum support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are > supported, then implementations MUST NOT negotiate a cipher suite > that employs NULL encryption, integrity, or authentication > algorithms. > ^^^ > > ACTION: Waiting on discussion for Issue 9. > > =============================================== > Issue 9B - > Sean also suggests: > #6) Section 9. Tim pointed out that because this I-D relies on > self-signed certificates it needs to say something about certificates > (I looked in DTLS/TLS and they don't point to 5280), keeping the > private key private, generating good random #s, and taking care when > installing trust anchors. Most of this is in RFC 5280 so if we add it > to the first line of the security considerations we're good except for > the make a good private key and installing the trust anchor. > Suggested text below: > > OLD: > > The security considerations in [RFC5425], [RFC5246] and [RFC4347] > apply to this document. > > NEW (yes I reordered them so Alfred won't complain later): > > The security considerations in [RFC4347], [RFC5246], [RFC5425], and > [RFC5280] apply to this document. > > and we should add two new paragraphs: > > 9.2 Private Key Generation > > Transport receiver and transport sender implementations > generate their own key pairs. An inadequate random number > generator (RNG) or an inadequate pseudo-random number generator > (PRNG) to generate these keys can result in little or no security. > See [RFC4086] for random number generation guidance. > > 9.3 Trust Anchor Installation and Storage > > Trust anchor installation and storage is critical. Transmission of > a trust anchor, especially self-signed certificates used as trust > anchors, from transport receiver to transport sender for > installation requires an out-of-band step(s). Care must be taken to > ensure the installed trust anchor is in fact the correct trust > anchor. The fingerprint mechanism in Section 5.3.1 can be > used by the transport sender to ensure the transport receiver's > self-signed certificate is properly installed. Trust anchor > information must be securely stored. Changes to trust anchor > information can cause acceptance of certificates that should > be rejected. > > > ACTION: I'm also going to ask for more discussion on this. > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfc@btconnect.com Tue Jun 8 03:04:42 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582FB28C16C for ; Tue, 8 Jun 2010 03:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlljr2m3wwUn for ; Tue, 8 Jun 2010 03:04:41 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id BFD6128C152 for ; Tue, 8 Jun 2010 03:04:40 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr13.btconnect.com with SMTP id FJY64634; Tue, 8 Jun 2010 11:03:19 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C0E1567.012B, actions=tag Message-ID: <01d301cb06e9$01ec4880$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Chris Lonvick" , References: Date: Tue, 8 Jun 2010 10:05:30 +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-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0209.4C0E1575.0280,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Syslog] Issue 8 - Tim Polk DISCUSS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:04:42 -0000 Yes, I agree with this, that DCCP is recommended but only if it is available (which I do not expect it to be:-) so update to s.6, leave s.5 alone. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, June 07, 2010 5:19 PM Subject: [Syslog] Issue 8 - Tim Polk DISCUSS > Issue 8 - Tim Polk DISCUSS > > Discuss: > There seems to be an essential disconnect between the conformance > rquirements and the deployment guidance in this specification > > The second paragraph of Section 6 Congestion Control states: > > DCCP has congestion control. For this reason the syslog over DTLS > over DCCP option is recommended in preference to the syslog over the > DTLS over UDP option. > > However, in Section 5.1, Transport > > DTLS can run over multiple transports. Implementations of this > specification MUST support DTLS over UDP and SHOULD support DTLS over > DCCP [RFC5238]. > > For alignment with Section 6, it would seem that "MUST support DTLS over > DCCP" would be more appropriate. > > Proposed resolution by Sean: > vvv > As noted by Lars (before my time on either the IESG or syslog list): > > If DCCP is available (not usually the case) running DTLS over it is > trivial, so you could also make this a MUST. DCCP support itself is > obviously not a MUST. > > Maybe what we really ought to be saying is Section 6 (which is just > about congestion control): > > DCCP has congestion control. For this reason when DCCP is available, > syslog over DTLS over DCCP is recommended in preference to the syslog > over the DTLS over UDP option. > > and we leave Section 5 alone? > ^^^ > > Tim Polk responded: > vvv > I will defer to Lars on this one. Since we can't make DCCP support a > MUST, your suggested text for Section 6 would resolve what remains of my > issue. > ^^^ > > ACTION: Authors to review proposed resolution and discuss on list. > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfc@btconnect.com Tue Jun 8 03:04:42 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5B728C152 for ; Tue, 8 Jun 2010 03:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fIKEmAPZulP for ; Tue, 8 Jun 2010 03:04:41 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 1492128C169 for ; Tue, 8 Jun 2010 03:04:40 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr13.btconnect.com with SMTP id FJY64738; Tue, 8 Jun 2010 11:03:33 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C0E1567.012B, actions=tag Message-ID: <01d501cb06e9$02835860$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Chris Lonvick" , References: Date: Tue, 8 Jun 2010 10:36:45 +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-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0203.4C0E1576.02FA,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Syslog] Issue 2 - Fragmentation X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:04:42 -0000 Issues 1, 2 and 10 seem to me to be linked, about maximum message sizes and fragmentation. Pasi's reply below surprises me and I was thinking to raise it on the TLS list to confirm that that is the usual understanding, namely that RFC4347 is imprecise in its use of RFC2119 language, and that large messages are segmented by DTLS but then reassembled into a single UDP datagram for transmission. 65kbyte messages are a requirement for syslog and I think that we should support them over DTLS in the least risky manner, ie avoiding seg/frag/../mentation where possible. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, June 07, 2010 5:18 PM Subject: [Syslog] Issue 2 - Fragmentation > Issue 2 - Fragmentation > > Joe summarized: > Tim Evans brought up the problem of fragmentation and reordering that > may not be taken care of by the DTLS layer. I'm not sure I fully > understand this issue. It seems that there is an issue here. The issue > seems to be that a SYSLOG application message can span multiple DTLS > records. Is it feasible to restrict this behavior? > > Pasi wrote the following: > vvv > I would prefer to keep syslog-over-DTLS-over-UDP as similar to RFC 5246 > (syslog-over-UDP) as possible -- i.e. don't add any kind of > fragmentation/reassembly in syslog layer. Both syslog-over-UDP and > syslog-over-DTLS-over-UDP already support messages up to ~64K; they're > just not very efficient if your MTU is small (and you need IP layer > fragmentation). But for administrators that know they'll need efficient > transport of large messages, we already have a solution: RFC 5425. > ^^^ > > Tom Petch responded to Pasi with: > vvv > >The maximum size of a single DTLS record is 2^14 bytes (this limit > >comes from TLS). > > > Where?:-) > > TLS provides fragmentation and says that > "length MUST NOT exceed 2^14." [RFC5246 s6.2.1] > so that the upper layers can send larger messages which TLS then fragments > for them. > > DTLS provides fragmentation for handshake messages [RFC4347 s3.2.3] but > not for the record layer; rather it says, > " As in TLS 1.1, the length should not exceed 2^14." > > should not, no MUST NOT as in [RFC5246] > (and draft-ietf-tls-rfc4347-bis has the same text) > > So while 65535 byte messages are not generally acceptable, where the users > know their network and its MTU, then we should let them do what they know > best. I see the main use of syslog in switched Enterprise LAN where large > MTU are a commonplace. > ^^^ > > Pasi responded with: > vvv > RFC 4346 (from which this text comes from) mostly did not use > RFC2119 keywords, but instead informal language like the > lowercase "should not" you quoted. AFAIK it was meant to > express a strict limit, not a recommendation (this is implied > by other text in the spec, and as you noticed, we clarified > this in RFC 5246). > > But even though DTLS records are limited to 2^14 bytes, syslog > messages are not! The current spec seems to support 64K (minus > some small number of overhead) just fine -- the message will be > split to multiple DTLS records (max. 2^14 bytes each), but those > DTLS records are then combined to a single UDP datagram. > ^^^ > > Tim wrote something (badly formatted) and Pasi responded: > vvv > Tim Evens wrote: > >> But even though DTLS records are limited to 2^14 bytes, syslog > >> messages are not! The current spec seems to support 64K (minus some > >> small number of overhead) just fine -- the message will be split to > >> multiple DTLS records (max. 2^14 bytes each), but those DTLS > >> records are then combined to a single UDP datagram. > > > > Ahh... Only if DTLS sequence numbers are used and if they are > > implemented using a reorder queueing method can a message be split > > into "chunks" that are transmitted over multiple DTLS records. > > No -- even if you split a message to multiple DTLS records, all those > records are sent in a *single* UDP datagram, in order. So there's > no need to queue/reorder packets based on DTLS sequence numbers. > > (The one UDP datagram might, of course, get fragmented to several > IP packets, but this happens below UDP and DTLS, so DTLS sequence > numbers are not involved...) > ^^^ > > Tim wrote: > Interesting because RFC4347 IMHO states clearly that IP fragmentation > (IP not UDP) must be avoided and thus dtls must determine the MTU. > > Final word from Pasi was: > RFC 4347 does strongly recommend avoiding IP fragmentation > (which doesn't necessarily work all that great through broken > middleboxes, and won't lead to good performance), but it > does not forbid it. > > ACTION: WG consensus is to support very large syslog messages. Authors > need to explain this in the document. > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfc@btconnect.com Tue Jun 8 03:06:55 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0777D28C155 for ; Tue, 8 Jun 2010 03:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, FRT_STRONG2=1.535] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RfGHFW+Nsci for ; Tue, 8 Jun 2010 03:06:54 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 17D3928C152 for ; Tue, 8 Jun 2010 03:06:52 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr13.btconnect.com with SMTP id FJY64745; Tue, 8 Jun 2010 11:03:34 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C0E1567.012B, actions=tag Message-ID: <01d701cb06e9$02f8d680$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Chris Lonvick" , "syslog" References: Date: Tue, 8 Jun 2010 10:59:41 +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-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0202.4C0E1577.0068,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Syslog] Issue 13 - DCCP? X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:06:55 -0000 I can't make sense of this. Using DCCP has nothing to do with strong security so I presume that dbh is really referring to flow control and saying because flow control may be an issue, everyone MUST implement DCCP (which means that a whole load of RFC are invalid because they require UDP and do not require DCCP!). I see this as issue 8, for which I see the resolution as DCCP is better than UDP and SHOULD be used when it is available (which I do not expect it to be). I do not think that we should go beyond that. Where for example is MUST implement of DTLS/DCCP in the latest SNMP transport document, draft-ietf-isms-dtls-tm with which dbh has been heavily involved? Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, June 07, 2010 5:21 PM Subject: [Syslog] Issue 13 - DCCP? > Issue 13 - DCCP? > > Tom Petch wrote: > vvv > Another issue that came up from the IESG is the relative roles of UDP and > DCCP as a substrate. In this context, the discussions on tsvwg which Lars > is steering about SCTP, DCCP and UDP make interesting reading, with some > contributors asserting that the only way to get a packet through a complex > network is with UDP, that SCTP and DCCP are (comparative) failures that > just don't get recognised widely enough. > > Certainly my (limited) view is that UDP is the MUST HAVE, the one that > will give maximum interoperability so while DCCP is technically superior, > making it the MUST implement will simply cause this I-D to be ignored by > most. > > I haven't seen any response from Lars on this issue. > ^^^ > > DBH responded: > vvv > Lars provided advice quite a while back. I concur with his advice. > > Implementers MUST implement support for DCCP (which should require > minimal changes from support for UDP), > so that if DCCP is available, and the operator chooses to use DCCPP, > the implementation will work with DCCP. > > I view this as very similar to our standard security posture - stroing > security is MUST implement, so it is available if the operator wants > it. The operator is not required to use it. > ^^^ > > ACTION: None - I think this is resolved. > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From turners@ieca.com Tue Jun 8 13:44:44 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94BC3A6802 for ; Tue, 8 Jun 2010 13:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk3ilOFEdo0s for ; Tue, 8 Jun 2010 13:44:43 -0700 (PDT) Received: from smtp114.biz.mail.sp1.yahoo.com (smtp114.biz.mail.sp1.yahoo.com [69.147.92.227]) by core3.amsl.com (Postfix) with SMTP id 4064D3A67C0 for ; Tue, 8 Jun 2010 13:44:43 -0700 (PDT) Received: (qmail 79737 invoked from network); 8 Jun 2010 20:44:42 -0000 Received: from thunderfish.local (turners@96.231.124.63 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 08 Jun 2010 13:44:41 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 6CWM4KoVM1nTJ_ckv04UlmZWOubI7UGM7xerfWF9BJYyiSswJiq.gpk.EQha7hpuUA_d1s3OD_VisBpeSwbh_H0vrT.ssqDiEMsA0sAMpFkM57RVL6Bqbapxk1I_WrH6QuD8mv_5Wa5DPUQfuUDXAZZolZ.mnz4wEzxrd6QXWWaNLf9Ld7FWd6_gIi0gxmoKE3hK1PRwGDqhtRwOWyk6PQF9s7_KNarlTrQ5RtBJvgCNRgAllJ3HRB13EiEF7452YWmtl6BKJ3klEyqIgtxbZk9E8l56g1vqjXkxiUbWXsXAlZSIrMUDppokgGTYSnVPvw7CG2YGNlWvaMZc9Wd3KA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0EABB8.30306@ieca.com> Date: Tue, 08 Jun 2010 16:44:40 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "t.petch" References: <01d401cb06e9$0227cae0$4001a8c0@gateway.2wire.net> In-Reply-To: <01d401cb06e9$0227cae0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: Re: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 20:44:45 -0000 t.petch wrote: > I see two separate issues here, trust anchor and mandatory encryption, and it is > the latter I am absolutely against. Just because someone, somewhere in the > world may send confidential data in a syslog message does not mean the IETF must > REQUIRE everyone, everywhere in the world to encrypt everything. It's ...... > > The IESG had a go at SNMP over this but SNMP got its oar in decades ago by > specifying that authnopriv(acy) was a part of SNMP, and so it has remained, as > the mechanics of security have evolved. > > If that is ok for SNMP, with all the important data it carries, I think it > suitable for syslog ie NULL encryption is fine and we would be doing our users > an injustice to deny them the option. > > The argument based on our mention of disclosure as a threat in RFC5425 I find > spurious; it means that encryption must be an option, not that everyone must use > it all the time. > > Tom, Ah see I'm not sure Tim was thinking along these line. I suspect Tim is thinking is here's yet another protocol saying we're going to use TLS/DTLS and they're not saying anything about the interesting things that can happen with TLS/DTLS (e.g., negotiating NULL confidentiality algorithms). If the WG isn't always using DTLS for confidentiality, then Section 4 needs to say that. Maybe adding something like the following before the note: However, confidentiality is not always required for syslog over DTLS because [insert reason here]. I think you'll need to add some text that says if confidentiality is required, the NULL cipher suites MUST NOT negotiate NULL encryption ciphers. I'm hoping that we can keep the part about MUST NOT support NULL integrity and authentication algorithms in Section 5.3. But, add a new last sentence that says something like: When confidentiality is provided by [insert mechanism here], then NULL encryption algorithms MAY be negotiated. spt > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Monday, June 07, 2010 5:20 PM > Subject: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT > > >> Issue 9 - Tim Polk COMMENT >> >> Comment: >> Given that disclosure is one of the primary threats described in Section >> 4, shouldn't the security considerations prohibit the use of cipher suites >> with NULL encryption? >> >> Prpposed resolution by Sean: >> vvv >> A.5 of RFC 5246, which is where the cipher suites for both TLS and >> DTLS end up pointing and is included in this I-Ds security >> considerations, includes the following: >> >> TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a >> TLS connection during the first handshake on that channel, but MUST >> NOT be negotiated, as it provides no more protection than an >> unsecured connection. >> >> I could see how this might be worth repeating, but waned to make you >> aware it was in RFC 5246. >> ^^^ >> >> Tim responded: >> vvv >> Thanks for pointing out that text; that is helpful but not sufficient, >> though. I am actually worried about cipher suites that have >> authenticatio= >> n >> & integrity but NULL encryption as well. There are a bunch of those: >> >> CipherSuite TLS_RSA_WITH_NULL_MD5 =3D { 0x00,0x01 }; >> CipherSuite TLS_RSA_WITH_NULL_SHA =3D { 0x00,0x02 }; >> CipherSuite TLS_RSA_WITH_NULL_SHA256 =3D { 0x00,0x3B }; >> 0x00,0x2C TLS_PSK_WITH_NULL_SHA [RFC4785] >> 0x00,0x2D TLS_DHE_PSK_WITH_NULL_SHA [RFC4785] >> 0x00,0x2E TLS_RSA_PSK_WITH_NULL_SHA >> 0xC0,0x06 TLS_ECDHE_ECDSA_WITH_NULL_SHA [RFC4492] >> >> ...among others. >> >> (Pardon the formatting, pulled some from 5246 and others from the iana >> registry...) >> ^^^ >> >> Sean responsed: >> vvv >> Ah! I see your point now. How about we tweak the last paragraph in >> section 5.3 (obviously I'd like author input on this): >> >> OLD: >> >> Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the >> mandatory to implement cipher suite, which is >> TLS_RSA_WITH_AES_128_CBC_SHA. >> >> NEW: >> >> Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a >> minimum support the mandatory to implement cipher suite, which is >> TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are >> supported, then implementations MUST NOT negotiate a cipher suite >> that employs NULL encryption, integrity, or authentication >> algorithms. >> ^^^ >> >> Sean's proposed resolution: >> vvv >> #3) Tim's point about restricting NULL cipher suites. At the end of >> section 5.3: >> >> OLD: >> >> Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the >> mandatory to implement cipher suite, which is >> TLS_RSA_WITH_AES_128_CBC_SHA. >> >> NEW: >> >> Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a >> minimum support the mandatory to implement cipher suite, which is >> TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are >> supported, then implementations MUST NOT negotiate a cipher suite >> that employs NULL encryption, integrity, or authentication >> algorithms. >> ^^^ >> >> Tom Petch responded: >> vvv >> I disagree. The threat of disclosure comes from RFC5425 s2 >> "Some data in syslog messages is sensitive and may be >> useful to an attacker, such as the password of an authorized >> administrator or user." >> but the fact that someone, somewhere may put a password in a syslog >> message I do not see as grounds for requiring everyone else in the world >> to encrypt everything. Encryption is a pain, it costs, and we should not >> require it >> unless it can be justified; these are remote, low-powered network boxes >> we are talking about, not enterprise servers. >> >> So while I agree we should require authentication, I see no >> justification for encryption. >> ^^^ >> >> Action: I'd like to get some additional discussion going on this. >> >> >> ============================================== >> issue 9A - >> >> Sean also suggested this: >> vvv >> #3) Tim's point about restricting NULL cipher suites. At the end of >> section 5.3: >> >> OLD: >> >> Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the >> mandatory to implement cipher suite, which is >> TLS_RSA_WITH_AES_128_CBC_SHA. >> >> NEW: >> >> Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a >> minimum support the mandatory to implement cipher suite, which is >> TLS_RSA_WITH_AES_128_CBC_SHA. If additional cipher suites are >> supported, then implementations MUST NOT negotiate a cipher suite >> that employs NULL encryption, integrity, or authentication >> algorithms. >> ^^^ >> >> ACTION: Waiting on discussion for Issue 9. >> >> =============================================== >> Issue 9B - >> Sean also suggests: >> #6) Section 9. Tim pointed out that because this I-D relies on >> self-signed certificates it needs to say something about certificates >> (I looked in DTLS/TLS and they don't point to 5280), keeping the >> private key private, generating good random #s, and taking care when >> installing trust anchors. Most of this is in RFC 5280 so if we add it >> to the first line of the security considerations we're good except for >> the make a good private key and installing the trust anchor. >> Suggested text below: >> >> OLD: >> >> The security considerations in [RFC5425], [RFC5246] and [RFC4347] >> apply to this document. >> >> NEW (yes I reordered them so Alfred won't complain later): >> >> The security considerations in [RFC4347], [RFC5246], [RFC5425], and >> [RFC5280] apply to this document. >> >> and we should add two new paragraphs: >> >> 9.2 Private Key Generation >> >> Transport receiver and transport sender implementations >> generate their own key pairs. An inadequate random number >> generator (RNG) or an inadequate pseudo-random number generator >> (PRNG) to generate these keys can result in little or no security. >> See [RFC4086] for random number generation guidance. >> >> 9.3 Trust Anchor Installation and Storage >> >> Trust anchor installation and storage is critical. Transmission of >> a trust anchor, especially self-signed certificates used as trust >> anchors, from transport receiver to transport sender for >> installation requires an out-of-band step(s). Care must be taken to >> ensure the installed trust anchor is in fact the correct trust >> anchor. The fingerprint mechanism in Section 5.3.1 can be >> used by the transport sender to ensure the transport receiver's >> self-signed certificate is properly installed. Trust anchor >> information must be securely stored. Changes to trust anchor >> information can cause acceptance of certificates that should >> be rejected. >> >> >> ACTION: I'm also going to ask for more discussion on this. >> >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From turners@ieca.com Tue Jun 8 13:46:37 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B283A67C0 for ; Tue, 8 Jun 2010 13:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx8vrkTWUOdL for ; Tue, 8 Jun 2010 13:46:37 -0700 (PDT) Received: from smtp114.biz.mail.sp1.yahoo.com (smtp114.biz.mail.sp1.yahoo.com [69.147.92.227]) by core3.amsl.com (Postfix) with SMTP id 7F88C3A6802 for ; Tue, 8 Jun 2010 13:46:36 -0700 (PDT) Received: (qmail 82509 invoked from network); 8 Jun 2010 20:46:38 -0000 Received: from thunderfish.local (turners@96.231.124.63 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 08 Jun 2010 13:46:38 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: oImAdz4VM1nCEU6CZ9RarC9c6yP8jmkE4Ki9UeASVwbmDrETS0Vv8eJjRuY403tGb04jfRmD3jM51UkauxH8Oz1vdvZtdVItbUhtYgo59Bhmi7x2Vtf.pAAw4kPqTF1s_WoYQ2RJDsVFJLI4zSSLrzHUNU6BTXhydrr.0zaFYXEVvG1UFdGDMFDKLPg_2pnDNoY9ijyI4oSdAhUGXrDmHSoqTsTOiMcswGh4vKE6EhPmeOnp.gxx8xbGH4TuCjiUMsyrDx3fAApG7bbIGDP6QgW51An_CTssHkUQ4STyFLw8pUYZ.R01tvsJd5lg0_gf6nnuyncLpfZe_7La7SI_2w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0EAC2C.5050105@ieca.com> Date: Tue, 08 Jun 2010 16:46:36 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "t.petch" References: <01d601cb06e9$02b5b300$4001a8c0@gateway.2wire.net> In-Reply-To: <01d601cb06e9$02b5b300$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: Re: [Syslog] Issue 6 - Reference 2 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 20:46:37 -0000 I think that's what he's asking for too. spt t.petch wrote: > Presumably this is s5.4.1 where we lack the [ ] that are present in all other > references to RFC5425. > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Monday, June 07, 2010 5:19 PM > Subject: [Syslog] Issue 6 - Reference 2 > > >> Issue 6 - Reference 2 >> >> From Miguel Garcia (GENART review) >> >> - Section 5.4.1: It would be nice to add a formal reference to RFC 5425 >> when it is mentioned. >> >> >> ACTION: Authors to review and incorporate a change if needed. >> >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From clonvick@cisco.com Tue Jun 8 19:07:17 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF183A688F for ; Tue, 8 Jun 2010 19:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.594 X-Spam-Level: X-Spam-Status: No, score=-9.594 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sWxWNX2134S for ; Tue, 8 Jun 2010 19:07:16 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A2CC23A685B for ; Tue, 8 Jun 2010 19:07:16 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG+TDkyrRN+K/2dsb2JhbACeRHGlUZl8hRYEg0c X-IronPort-AV: E=Sophos;i="4.53,387,1272844800"; d="scan'208";a="141377932" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2010 02:07:17 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o5927H2P024335; Wed, 9 Jun 2010 02:07:17 GMT Date: Tue, 8 Jun 2010 19:07:17 -0700 (PDT) From: Chris Lonvick To: Sean Turner In-Reply-To: <4C0EAC2C.5050105@ieca.com> Message-ID: References: <01d601cb06e9$02b5b300$4001a8c0@gateway.2wire.net> <4C0EAC2C.5050105@ieca.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: syslog@ietf.org Subject: Re: [Syslog] Issue 6 - Reference 2 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 02:07:17 -0000 Hi, Joe has the token for Editor role. Yup; let's just make this change and make it DONE. :-) Thanks, Chris On Tue, 8 Jun 2010, Sean Turner wrote: > I think that's what he's asking for too. > > spt > > t.petch wrote: >> Presumably this is s5.4.1 where we lack the [ ] that are present in all >> other >> references to RFC5425. >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Chris Lonvick" >> To: >> Sent: Monday, June 07, 2010 5:19 PM >> Subject: [Syslog] Issue 6 - Reference 2 >> >> >> > Issue 6 - Reference 2 >> > >> > From Miguel Garcia (GENART review) >> > >> > - Section 5.4.1: It would be nice to add a formal reference to RFC 5425 >> > when it is mentioned. >> > >> > >> > ACTION: Authors to review and incorporate a change if needed. >> > >> > _______________________________________________ >> > Syslog mailing list >> > Syslog@ietf.org >> > https://www.ietf.org/mailman/listinfo/syslog >> >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog >> > From clonvick@cisco.com Tue Jun 8 19:25:59 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1613A6851 for ; Tue, 8 Jun 2010 19:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkcj9oS2uWbU for ; Tue, 8 Jun 2010 19:25:58 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 09A583A67B2 for ; Tue, 8 Jun 2010 19:25:58 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFuYDkyrRN+K/2dsb2JhbACeRHGlLZl8hRYEg0c X-IronPort-AV: E=Sophos;i="4.53,387,1272844800"; d="scan'208";a="209162915" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2010 02:25:59 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o592Pxcn028706; Wed, 9 Jun 2010 02:25:59 GMT Date: Tue, 8 Jun 2010 19:25:59 -0700 (PDT) From: Chris Lonvick To: Sean Turner In-Reply-To: <4C0EABB8.30306@ieca.com> Message-ID: References: <01d401cb06e9$0227cae0$4001a8c0@gateway.2wire.net> <4C0EABB8.30306@ieca.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: syslog@ietf.org Subject: Re: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 02:25:59 -0000 Hi, inline On Tue, 8 Jun 2010, Sean Turner wrote: > t.petch wrote: >> I see two separate issues here, trust anchor and mandatory encryption, and > Tom, > > Ah see I'm not sure Tim was thinking along these line. I suspect Tim is > thinking is here's yet another protocol saying we're going to use TLS/DTLS > and they're not saying anything about the interesting things that can happen > with TLS/DTLS (e.g., negotiating NULL confidentiality algorithms). If the WG > isn't always using DTLS for confidentiality, then Section 4 needs to say > that. Maybe adding something like the following before the note: > > However, confidentiality is not always required for syslog over DTLS because > [insert reason here]. ..because section 8.8. (Message Observation) in RFC 5424 says: vvvv While there are no strict guidelines pertaining to the MSG format, most syslog messages are generated in human-readable form with the assumption that capable administrators should be able to read them and understand their meaning. The syslog protocol does not have mechanisms to provide confidentiality for the messages in transit. In most cases, passing clear-text messages is a benefit to the operations staff if they are sniffing the packets from the wire. The operations staff may be able to read the messages and associate them with other events seen from other packets crossing the wire to track down and correct problems. Unfortunately, an attacker may also be able to observe the human-readable contents of syslog messages. The attacker may then use the knowledge gained from those messages to compromise a machine or do other damage. Operators are advised to use a secure transport mapping to avoid this problem. ^^^^ > > I think you'll need to add some text that says if confidentiality is > required, the NULL cipher suites MUST NOT negotiate NULL encryption ciphers. > > I'm hoping that we can keep the part about MUST NOT support NULL integrity > and authentication algorithms in Section 5.3. But, add a new last sentence > that says something like: > > When confidentiality is provided by [insert mechanism here], then NULL > encryption algorithms MAY be negotiated. Let's change that to: When confidentiality is desired but without the overhead of using DTLS encryption, then it may be provided by provisioning a physically secured network. In that case the NULL encryption algorithm may be negotiated. Does that work? That may take care of 9 and 9A. What about 9B? >> > =============================================== >> > Issue 9B - >> > Sean also suggests: >> > #6) Section 9. Tim pointed out that because this I-D relies on >> > self-signed certificates it needs to say something about certificates >> > (I looked in DTLS/TLS and they don't point to 5280), keeping the >> > private key private, generating good random #s, and taking care when >> > installing trust anchors. Most of this is in RFC 5280 so if we add it >> > to the first line of the security considerations we're good except for >> > the make a good private key and installing the trust anchor. >> > Suggested text below: >> > >> > OLD: >> > >> > The security considerations in [RFC5425], [RFC5246] and [RFC4347] >> > apply to this document. >> > >> > NEW (yes I reordered them so Alfred won't complain later): >> > >> > The security considerations in [RFC4347], [RFC5246], [RFC5425], and >> > [RFC5280] apply to this document. >> > >> > and we should add two new paragraphs: >> > >> > 9.2 Private Key Generation >> > >> > Transport receiver and transport sender implementations >> > generate their own key pairs. An inadequate random number >> > generator (RNG) or an inadequate pseudo-random number generator >> > (PRNG) to generate these keys can result in little or no security. >> > See [RFC4086] for random number generation guidance. >> > >> > 9.3 Trust Anchor Installation and Storage >> > >> > Trust anchor installation and storage is critical. Transmission of >> > a trust anchor, especially self-signed certificates used as trust >> > anchors, from transport receiver to transport sender for >> > installation requires an out-of-band step(s). Care must be taken to >> > ensure the installed trust anchor is in fact the correct trust >> > anchor. The fingerprint mechanism in Section 5.3.1 can be >> > used by the transport sender to ensure the transport receiver's >> > self-signed certificate is properly installed. Trust anchor >> > information must be securely stored. Changes to trust anchor >> > information can cause acceptance of certificates that should >> > be rejected. >> > >> > >> > ACTION: I'm also going to ask for more discussion on this. Thanks, Chris From prvs=769c0e9c9=robert.horn@agfa.com Wed Jun 9 05:14:04 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2793A685A; Wed, 9 Jun 2010 05:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvXzO5si4Lvx; Wed, 9 Jun 2010 05:14:03 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id 39B4F3A696E; Wed, 9 Jun 2010 05:13:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,391,1272837600"; d="scan'208";a="102493214" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 09 Jun 2010 14:13:55 +0200 In-Reply-To: To: clonvick@cisco.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Wed, 9 Jun 2010 08:10:25 -0400 Content-Type: text/plain; charset="US-ASCII" Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 12:14:04 -0000 > > > > I think you'll need to add some text that says if confidentiality is > > required, the NULL cipher suites MUST NOT negotiate NULL encryption ciphers. > > > > I'm hoping that we can keep the part about MUST NOT support NULL integrity > > and authentication algorithms in Section 5.3. But, add a new lastsentence > > that says something like: > > > > When confidentiality is provided by [insert mechanism here], then NULL > > encryption algorithms MAY be negotiated. > > Let's change that to: > When confidentiality is desired but without the overhead of using DTLS > encryption, then it may be provided by provisioning a physically > secured network. In that case the NULL encryption algorithm may be > negotiated. > > Does that work? > Those words could work. It would be better if the phrase "physically secured network" were "appropriately secured network". I'm thinking about people who are using VLAN and other low level hardware technologies. Someone who understands the issues can decide whether their low level hardware approach is a suitable equivalent to "physically secured" so this is less imprtant. Either wording results in implementations that can be configured to meet the need. Kind Regards, Robert Horn | Agfa HealthCare Research Scientist | HE/Technology Office T +1 978 897 4860 Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 07660-2199, United States http://www.agfa.com/healthcare/ Click on link to read important disclaimer: http://www.agfa.com/healthcare/maildisclaimer From ietfdbh@comcast.net Wed Jun 9 11:14:03 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E193A67B4 for ; Wed, 9 Jun 2010 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_05=-1.11, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akAVjqrIdttp for ; Wed, 9 Jun 2010 11:14:02 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by core3.amsl.com (Postfix) with ESMTP id 04C3F3A67E7 for ; Wed, 9 Jun 2010 11:14:01 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id TnCq1e0020xGWP85FuE49x; Wed, 09 Jun 2010 18:14:04 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta12.westchester.pa.mail.comcast.net with comcast id TuE31e00f2JQnJT3YuE4F7; Wed, 09 Jun 2010 18:14:04 +0000 From: "David Harrington" To: "'t.petch'" , "'Chris Lonvick'" , References: <01d301cb06e9$01ec4880$4001a8c0@gateway.2wire.net> Date: Wed, 9 Jun 2010 14:14:02 -0400 Message-ID: <035901cb07ff$8a9bc3b0$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 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <01d301cb06e9$01ec4880$4001a8c0@gateway.2wire.net> Thread-index: AcsG8gXWLLhLyAlwSyGVO5zBzgVlqABCpT0Q Cc: iesg@ietf.org Subject: Re: [Syslog] Issue 8 - Tim Polk DISCUSS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 18:14:03 -0000 Hi, This syslog/dtls/dccp issue revolves around mandatory-to-implement but not mandatory-to-use. The draft recommends using syslog/DTLS over DCCP when DCCP is available. If DCCP is available in an environment, the environment probably demands congestion awareness and control. The RECOMMEND is not about whether DCCP is available at implementation-time, but whether DCCP is available at use-time. If implementations don't include support for the ***interface*** between (syslog/DTLS) and (DCCP), then even if DCCP is available at use-time, users won't be able to use it. This is similar to the MUST implement/SHOULD use advice in section 7 of BCP 61 (RFC3365). A MUST-implement does not say that the implementer MUST implement DCCP, only the interface to DCCP. The interface between (syslog/DTLS) and (DCCP) should be MUST implement, so that when DCCP is available in the user environment, syslog can use it. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of t.petch > Sent: Tuesday, June 08, 2010 4:06 AM > To: Chris Lonvick; syslog@ietf.org > Subject: Re: [Syslog] Issue 8 - Tim Polk DISCUSS > > Yes, I agree with this, that DCCP is recommended but only if > it is available > (which I do not expect it to be:-) so update to s.6, leave s.5 alone. > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Monday, June 07, 2010 5:19 PM > Subject: [Syslog] Issue 8 - Tim Polk DISCUSS > > > > Issue 8 - Tim Polk DISCUSS > > > > Discuss: > > There seems to be an essential disconnect between the conformance > > rquirements and the deployment guidance in this specification > > > > The second paragraph of Section 6 Congestion Control states: > > > > DCCP has congestion control. For this reason the > syslog over DTLS > > over DCCP option is recommended in preference to the > syslog over the > > DTLS over UDP option. > > > > However, in Section 5.1, Transport > > > > DTLS can run over multiple transports. Implementations of this > > specification MUST support DTLS over UDP and SHOULD > support DTLS over > > DCCP [RFC5238]. > > > > For alignment with Section 6, it would seem that "MUST > support DTLS over > > DCCP" would be more appropriate. > > > > Proposed resolution by Sean: > > vvv > > As noted by Lars (before my time on either the IESG or syslog list): > > > > If DCCP is available (not usually the case) running DTLS > over it is > > trivial, so you could also make this a MUST. DCCP > support itself is > > obviously not a MUST. > > > > Maybe what we really ought to be saying is Section 6 (which is just > > about congestion control): > > > > DCCP has congestion control. For this reason when DCCP > is available, > > syslog over DTLS over DCCP is recommended in preference > to the syslog > > over the DTLS over UDP option. > > > > and we leave Section 5 alone? > > ^^^ > > > > Tim Polk responded: > > vvv > > I will defer to Lars on this one. Since we can't make DCCP > support a > > MUST, your suggested text for Section 6 would resolve what > remains of my > > issue. > > ^^^ > > > > ACTION: Authors to review proposed resolution and discuss on list. > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From ietfc@btconnect.com Tue Jun 15 04:22:53 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B9E28C119 for ; Tue, 15 Jun 2010 04:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEYBhUHQainN for ; Tue, 15 Jun 2010 04:22:53 -0700 (PDT) Received: from c2beaomr03.btconnect.com (c2beaomr03.btconnect.com [213.123.26.181]) by core3.amsl.com (Postfix) with ESMTP id A43ED3A68B2 for ; Tue, 15 Jun 2010 04:22:52 -0700 (PDT) Received: from pc6 (host81-153-11-165.range81-153.btcentralplus.com [81.153.11.165]) by c2beaomr03.btconnect.com with SMTP id MBT80205; Tue, 15 Jun 2010 12:22:47 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=0001.0A0B0301.4C176287.0084, actions=tag Message-ID: <006a01cb0c74$39bfc580$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Chris Lonvick" , References: Date: Tue, 15 Jun 2010 11:56:04 +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-Junkmail-Status: score=10/50, host=c2beaomr03.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0208.4C17628E.02A1,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Syslog] Issue 7 - text X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 11:22:53 -0000 looks like a good change to me Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, June 07, 2010 5:19 PM Subject: [Syslog] Issue 7 - text > Issue 7 - text > > From Miguel Garcia (GENART review) > > - Third paragraph in Secction 6: s/udp/UDP > > ACTION: Authors to review and change. > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfc@btconnect.com Tue Jun 15 04:22:55 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629D528C125 for ; Tue, 15 Jun 2010 04:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy0SvcNVg08Z for ; Tue, 15 Jun 2010 04:22:54 -0700 (PDT) Received: from c2beaomr03.btconnect.com (c2beaomr03.btconnect.com [213.123.26.181]) by core3.amsl.com (Postfix) with ESMTP id 4F14628C119 for ; Tue, 15 Jun 2010 04:22:54 -0700 (PDT) Received: from pc6 (host81-153-11-165.range81-153.btcentralplus.com [81.153.11.165]) by c2beaomr03.btconnect.com with SMTP id MBT80231; Tue, 15 Jun 2010 12:22:51 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=0001.0A0B0301.4C176287.0084, actions=tag Message-ID: <006c01cb0c74$3a4dada0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Chris Lonvick" , References: Date: Tue, 15 Jun 2010 11:56:48 +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-Junkmail-Status: score=10/50, host=c2beaomr03.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0207.4C176291.03B1,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Syslog] Issue 3 - Text revision from GENART review X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 11:22:55 -0000 looks good to me Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, June 07, 2010 5:18 PM Subject: [Syslog] Issue 3 - Text revision from GENART review > Issue 3 - Text revision from GENART review > > From Miguel Garcia (GENART review) > - In Section 5.3, the last sentence of the first paragraph reads: > > "When the DTLS handshake has > finished, the transport sender MAY then send the first syslog > message." > > I think what you really want to say is: > > "The transport sender MUST NOT send any syslog message before the > DTLS handshake has successfully completed." > > Proposal supported by Russ Housley > > ACTION: No opposition to this seen. Authors to incorporate. > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfc@btconnect.com Tue Jun 15 04:22:55 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724CA28C119 for ; Tue, 15 Jun 2010 04:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbGxbfxp-X20 for ; Tue, 15 Jun 2010 04:22:54 -0700 (PDT) Received: from c2beaomr03.btconnect.com (c2beaomr03.btconnect.com [213.123.26.181]) by core3.amsl.com (Postfix) with ESMTP id 7535928C11A for ; Tue, 15 Jun 2010 04:22:54 -0700 (PDT) Received: from pc6 (host81-153-11-165.range81-153.btcentralplus.com [81.153.11.165]) by c2beaomr03.btconnect.com with SMTP id MBT80229; Tue, 15 Jun 2010 12:22:51 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=0001.0A0B0301.4C176287.0084, actions=tag Message-ID: <006b01cb0c74$3a0a8a20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Chris Lonvick" , References: Date: Tue, 15 Jun 2010 11:56:25 +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-Junkmail-Status: score=10/50, host=c2beaomr03.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0203.4C176291.00C4,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Syslog] Issue 12 - nit X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 11:22:55 -0000 looks good to me Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, June 07, 2010 5:21 PM Subject: [Syslog] Issue 12 - nit > Issue 12 - nit > > I must have missed this somewhere - Sean wrote: > > > #1.1) Section 5.1 > > OLD: > > Transports, such as UDP or DCCP do not provide session multiplexing > and session-demultiplexing. > > NEW: > > Transports such as UDP or DCCP do not provide session multiplexing and > session-demultiplexing. > > ACTION: Authors to review and incorporate. > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfc@btconnect.com Tue Jun 15 04:22:58 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65BD3A68AC for ; Tue, 15 Jun 2010 04:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrjeOdPNsKsj for ; Tue, 15 Jun 2010 04:22:56 -0700 (PDT) Received: from c2beaomr03.btconnect.com (c2beaomr03.btconnect.com [213.123.26.181]) by core3.amsl.com (Postfix) with ESMTP id 92BD028C12B for ; Tue, 15 Jun 2010 04:22:56 -0700 (PDT) Received: from pc6 (host81-153-11-165.range81-153.btcentralplus.com [81.153.11.165]) by c2beaomr03.btconnect.com with SMTP id MBT80233; Tue, 15 Jun 2010 12:22:52 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=0001.0A0B0301.4C176287.0084, actions=tag Message-ID: <006d01cb0c74$3a893000$4001a8c0@gateway.2wire.net> From: "t.petch" To: , References: Date: Tue, 15 Jun 2010 12:18:40 +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-Junkmail-Status: score=10/50, host=c2beaomr03.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0204.4C176293.023B,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: syslog@ietf.org Subject: Re: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 11:22:58 -0000 I agree with Robert that privacy can be achieved by means other than encryption, but disagree that privacy is a MUST operationally. As Chris pointed out, we have already said this in RFC5424 "In most cases, passing clear-text messages is a benefit to the operations staff if they are sniffing the packets from the wire. " which means I think we should say "Implementations MUST support DTLS 1.1 [RFC4347] and MUST at a minimum support the mandatory to implement cipher suite , which is TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]. If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL integrity or authentication algorithms. Where privacy is REQUIRED, then implementations must either negotiate a cipher suite that employs a non-NULL encryption algorithm or else achieve privacy by other means, such as a physically secured network. However, as [RFC5424] section 8 points out 'In most cases, passing clear-text messages is a benefit to the operations staff if they are sniffing the packets from the wire.' and so where privacy is not a requirement, then it is advantageous to use a NULL encryption algorithm. Tom Petch ----- Original Message ----- From: To: Cc: ; Sent: Wednesday, June 09, 2010 2:10 PM Subject: Re: [Syslog] Issue 9, 9a, and 9b - from a Tim Polk COMMENT > > > > > > I think you'll need to add some text that says if confidentiality is > > > required, the NULL cipher suites MUST NOT negotiate NULL encryption > ciphers. > > > > > > I'm hoping that we can keep the part about MUST NOT support NULL > integrity > > > and authentication algorithms in Section 5.3. But, add a new > lastsentence > > > that says something like: > > > > > > When confidentiality is provided by [insert mechanism here], then NULL > > > > encryption algorithms MAY be negotiated. > > > > Let's change that to: > > When confidentiality is desired but without the overhead of using > DTLS > > encryption, then it may be provided by provisioning a physically > > secured network. In that case the NULL encryption algorithm may be > > negotiated. > > > > Does that work? > > > > Those words could work. It would be better if the phrase "physically > secured network" were "appropriately secured network". I'm thinking about > people who are using VLAN and other low level hardware technologies. > Someone who understands the issues can decide whether their low level > hardware approach is a suitable equivalent to "physically secured" so this > is less imprtant. Either wording results in implementations that can be > configured to meet the need. > > Kind Regards, > > Robert Horn | Agfa HealthCare > Research Scientist | HE/Technology Office > T +1 978 897 4860 > > Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, > 07660-2199, United States > http://www.agfa.com/healthcare/ > Click on link to read important disclaimer: > http://www.agfa.com/healthcare/maildisclaimer > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From clonvick@cisco.com Fri Jun 18 15:23:33 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00E83A6970 for ; Fri, 18 Jun 2010 15:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.162 X-Spam-Level: X-Spam-Status: No, score=-9.162 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSttTaYXANEW for ; Fri, 18 Jun 2010 15:23:32 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B60833A67EA for ; Fri, 18 Jun 2010 15:23:32 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMGAGaOG0yrR7Hu/2dsb2JhbACScQEBjCJxqECaTYUbBINS X-IronPort-AV: E=Sophos;i="4.53,441,1272844800"; d="scan'208";a="146774203" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 18 Jun 2010 22:23:38 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5IMNcRY025249 for ; Fri, 18 Jun 2010 22:23:38 GMT Date: Fri, 18 Jun 2010 15:23:38 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 22:23:34 -0000 Hi Folks, Here's where we stand on the open issues: Issue 1 - COMMENT from Alexy STATUS: One note from Tom Petch on this (combining Issues 1, 2, and 10). See Issue 10. Issue 2 - Fragmentation STATUS: Same as Issue 1. Issue 3 - Text revision from GENART review STATUS: Joe to compose text. Issue 4 - Service code subregistry STATUS: I havn't seen any review on the list but the thread was pretty conclusive. Joe to incorporate text into a new revision. Issue 5 - Reference STATUS: Joe to incorporate text proposed by Tom. Issue 6 - Reference 2 STATUS: Joe to revise ID with proposed text. Issue 7 - text STATUS: Joe to revise ID. Issue 8 - Tim Polk DISCUSS STATUS: Discussed by Tom and David. Joe to incorporate changes. Issue 9, 9a, and 9b - from a Tim Polk COMMENT STATUS: It looks like 9 and 9a have been discussed and Tom has proposed text to resolve them. Sean proposed text on 9b. I'd like some discussion on that. Issue 10 - Jari Arrko DISCUSS STATUS: Same as Issue 1. Is the text proposed by Sean good to cover all of this Issue, Issue 1 and Issue 2? Issue 11 - Adrian Farrel DISCUSS STATUS: CLOSED Issue 12 - nit STATUS: Tom agrees with this, Joe to revise text in a new ID. Issue 13 - DCCP? STATUS: With no discussion, I'm closing this. Just FYI to all, Joe has been swamped with the day job but he'll look at the issues as soon as he can. Thanks, Chris From clonvick@cisco.com Fri Jun 18 20:35:32 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAA23A6874 for ; Fri, 18 Jun 2010 20:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.127 X-Spam-Level: X-Spam-Status: No, score=-9.127 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wbfPc-L4v1L for ; Fri, 18 Jun 2010 20:35:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 267373A6873 for ; Fri, 18 Jun 2010 20:35:31 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAP7XG0yrR7Hu/2dsb2JhbACScQGMJHGoCJoshRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,442,1272844800"; d="scan'208";a="547209216" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2010 03:35:37 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5J3ZbkX026518 for ; Sat, 19 Jun 2010 03:35:37 GMT Date: Fri, 18 Jun 2010 20:35:36 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] secdir review of draft-ietf-syslog-dtls-05 (fwd) X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 03:35:32 -0000 Hi Folks, This one slipped past me. :-( Don't comment on this as I'm going to open up three additional issues which I think will be easy to resolve. Thanks, Chris -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Monday, May 17, 2010 6:13 PM To: draft-ietf-syslog-dtls.all@tools.ietf.org Cc: secdir@ietf.org; iesg@ietf.org Subject: secdir review of draft-ietf-syslog-dtls-05 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other comments. This document defines a DTLS transport for syslog. The document is well-written, clear, and seems to serve a worthwhile purpose. Although the security considerations section is brief (mainly just referring to the security considerations in RFC 5425, RFC 5246, and RFC 4347), it is largely adequate. I see only one omission. One difference between the security considerations for syslog over DTLS and those for syslog over TLS (unnoted in the current Security Considerations section) is that DTLS does not provide retransmission. If an attacker can cause a packet to be dropped (especially one carrying significant information about an attack), the transport receiver may not consider this a significant event and so the syslog server may be completely unaware of the occurrence. This contrasts with syslog over TLS where a dropped packet would be retransmitted until acknowledged or until the TLS connection goes down (indicating to the transport sender and receiver and perhaps to the syslog client and server that a significant event has occurred). Maybe it would be a good idea to recommend that the transport receiver notice gaps in the DTLS sequence numbers and notify the syslog server. Still, this is not as good from a security standpoint as syslog over TLS since none of the client code will be aware that the dropped message was not received. At least, there should be a discussion of this issue in the Security Considerations section of this document. In addition to this concern, I have noticed a few areas that could use some clarification and maybe some fixes. Section 5.3 says "Implementations MUST support the denial of service countermeasures defined by DTLS." That's good but it's not clear whether this means that these countermeasures MUST always be enabled. Since that is not explicitly stated, it seems that a server could have those countermeasures enabled by default and a client could have them disabled by default. That would result in a client and server that would not interoperate until the administrator tracked down the problem and changed their configuration. I suggest that the document be changed to require not only that implementations support these countermeasures but that they be enabled by default. Section 7 says "The security policies for syslog over DTLS are the same as those described in [RFC5425]." Does that mean that all the normative text in section 5 of RFC 5425 applies to implementations of this document as well? I hope so but if that's the intent, it should be explicitly stated (for example by adding the text "and all the normative requirements of section 5 of [RFC5425] apply"). Once these issues are addressed, I'm sure that the document will be a worthwhile and relatively secure addition to the RFC series. Congratulations and thanks to the editors/authors for their work. Thanks, Steve From clonvick@cisco.com Fri Jun 18 20:41:42 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52223A6934 for ; Fri, 18 Jun 2010 20:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.871 X-Spam-Level: X-Spam-Status: No, score=-9.871 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsqDf-IIqCcT for ; Fri, 18 Jun 2010 20:41:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D82703A6933 for ; Fri, 18 Jun 2010 20:41:41 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMGADbZG0yrR7H+/2dsb2JhbACScQEBjCNxqAOaLYUbBINU X-IronPort-AV: E=Sophos;i="4.53,442,1272844800"; d="scan'208";a="547211123" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2010 03:41:47 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5J3flWT027821 for ; Sat, 19 Jun 2010 03:41:47 GMT Date: Fri, 18 Jun 2010 20:41:47 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 14 - Unreliable Delivery X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 03:41:42 -0000 SECDIR Reviewer comments: One difference between the security considerations for syslog over DTLS and those for syslog over TLS (unnoted in the current Security Considerations section) is that DTLS does not provide retransmission. If an attacker can cause a packet to be dropped (especially one carrying significant information about an attack), the transport receiver may not consider this a significant event and so the syslog server may be completely unaware of the occurrence. This contrasts with syslog over TLS where a dropped packet would be retransmitted until acknowledged or until the TLS connection goes down (indicating to the transport sender and receiver and perhaps to the syslog client and server that a significant event has occurred). Maybe it would be a good idea to recommend that the transport receiver notice gaps in the DTLS sequence numbers and notify the syslog server. Still, this is not as good from a security standpoint as syslog over TLS since none of the client code will be aware that the dropped message was not received. At least, there should be a discussion of this issue in the Security Considerations section of this document. My comments back to the reviewer and the IESG: ===vvv=== It's discussed in section 5.4 (Unreliable Delivery - in the Security Considerations section) in RFC 5426 and throughout Section 3.1 (Loss-Insensitive Messaging) in RFC 4347. I'm thinking that it would be good to note this in Section 4 (Using DTLS to Secure Syslog) in the draft. Overall, the community is comfortable with the loss of information as they've been using syslog/udp for many years and know the problems with that. RFC 5424 also notes that implementers who wish a lossless stream should be using tls/tcp as their transport. From that, it's probably best to reference RFC 5848 (referenced as draft-ietf-syslog-sign in the draft) which can also provide an indication of loss of messages. " ===^^^^=== ACTION: I'd like to get some discussion going on this. Do people think that this is good? Thanks, Chris From clonvick@cisco.com Fri Jun 18 20:44:28 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0FC93A6933 for ; Fri, 18 Jun 2010 20:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.906 X-Spam-Level: X-Spam-Status: No, score=-9.906 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OrcNGIkbj80 for ; Fri, 18 Jun 2010 20:44:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DD73C3A6873 for ; Fri, 18 Jun 2010 20:44:27 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMGAKPZG0yrR7Ht/2dsb2JhbACScQEBjCNxqAaaKoUbBINU X-IronPort-AV: E=Sophos;i="4.53,442,1272844800"; d="scan'208";a="336643957" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 19 Jun 2010 03:44:34 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5J3iXpX002604 for ; Sat, 19 Jun 2010 03:44:33 GMT Date: Fri, 18 Jun 2010 20:44:33 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 15 - DoS measures X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 03:44:29 -0000 SECDIR reviewer said: Section 5.3 says "Implementations MUST support the denial of service countermeasures defined by DTLS." That's good but it's not clear whether this means that these countermeasures MUST always be enabled. Since that is not explicitly stated, it seems that a server could have those countermeasures enabled by default and a client could have them disabled by default. That would result in a client and server that would not interoperate until the administrator tracked down the problem and changed their configuration. I suggest that the document be changed to require not only that implementations support these countermeasures but that they be enabled by default. My response was: "Good catch." ACTION: Comments? Thanks, Chris From clonvick@cisco.com Fri Jun 18 20:45:25 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03E43A6A3B for ; Fri, 18 Jun 2010 20:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.937 X-Spam-Level: X-Spam-Status: No, score=-9.937 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whf7KI4uq1I4 for ; Fri, 18 Jun 2010 20:45:25 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ED70D3A6873 for ; Fri, 18 Jun 2010 20:45:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMGAFbaG0yrR7H+/2dsb2JhbACScQEBjCNxqAGaKoUbBINU X-IronPort-AV: E=Sophos;i="4.53,442,1272844800"; d="scan'208";a="547212296" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2010 03:45:31 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5J3jUAp029074 for ; Sat, 19 Jun 2010 03:45:31 GMT Date: Fri, 18 Jun 2010 20:45:30 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Issue 16 - Security Policies X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 03:45:25 -0000 SECDIR reviewer said: Section 7 says "The security policies for syslog over DTLS are the same as those described in [RFC5425]." Does that mean that all the normative text in section 5 of RFC 5425 applies to implementations of this document as well? I hope so but if that's the intent, it should be explicitly stated (for example by adding the text "and all the normative requirements of section 5 of [RFC5425] apply"). My comment back to the reviewer and the IESG was: "That is the intent and the added text looks good." ACTION: Comments? Thanks, Chris From jsalowey@cisco.com Sun Jun 20 21:33:43 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF283A6A13 for ; Sun, 20 Jun 2010 21:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUFTgttqCHWq for ; Sun, 20 Jun 2010 21:33:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9864E3A63CB for ; Sun, 20 Jun 2010 21:33:36 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJeIHkyrRN+J/2dsb2JhbACfBnGmV5k6hRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,450,1272844800"; d="scan'208";a="262865198" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2010 04:33:43 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o5L4XgqC005102 for ; Mon, 21 Jun 2010 04:33:43 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Jun 2010 21:33:39 -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 Date: Sun, 20 Jun 2010 21:33:34 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Issue 16 - Security Policies Thread-Index: AcsPYhcvcrCinBiKSnyyihVrtIdK+wBmIPLA References: From: "Joseph Salowey (jsalowey)" To: "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 21 Jun 2010 04:33:39.0831 (UTC) FILETIME=[EC0CA070:01CB10FA] Subject: Re: [Syslog] Issue 16 - Security Policies X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 04:33:43 -0000 OK with me.=20 > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf > Of Chris Lonvick (clonvick) > Sent: Friday, June 18, 2010 8:46 PM > To: syslog@ietf.org > Subject: [Syslog] Issue 16 - Security Policies >=20 > SECDIR reviewer said: >=20 > Section 7 says "The security policies for syslog over DTLS are the > same as those described in [RFC5425]." Does that mean that all the > normative text in section 5 of RFC 5425 applies to implementations > of this document as well? I hope so but if that's the intent, it > should be explicitly stated (for example by adding the text "and > all the normative requirements of section 5 of [RFC5425] apply"). >=20 > My comment back to the reviewer and the IESG was: > "That is the intent and the added text looks good." >=20 > ACTION: Comments? >=20 > Thanks, > Chris > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From jsalowey@cisco.com Sun Jun 20 21:38:18 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FFC3A6A16 for ; Sun, 20 Jun 2010 21:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a+ZyN1HsrIo for ; Sun, 20 Jun 2010 21:38:16 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5C15E3A68CD for ; Sun, 20 Jun 2010 21:38:15 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEqJHkyrR7Hu/2dsb2JhbACfBnGmW5k6hRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,450,1272844800"; d="scan'208";a="147292459" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2010 04:38:22 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5L4cMrS000754 for ; Mon, 21 Jun 2010 04:38:22 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Jun 2010 21:38:21 -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 Date: Sun, 20 Jun 2010 21:38:20 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Issue 15 - DoS measures Thread-Index: AcsPYcG4Ma57ayVxS2eRluiN0N3SjQBmS3uQ References: From: "Joseph Salowey (jsalowey)" To: "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 21 Jun 2010 04:38:21.0962 (UTC) FILETIME=[943666A0:01CB10FB] Subject: Re: [Syslog] Issue 15 - DoS measures X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 04:38:18 -0000 > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf > Of Chris Lonvick (clonvick) > Sent: Friday, June 18, 2010 8:45 PM > To: syslog@ietf.org > Subject: [Syslog] Issue 15 - DoS measures >=20 > SECDIR reviewer said: >=20 > Section 5.3 says "Implementations MUST support the denial of service > countermeasures defined by DTLS." That's good but it's not clear > whether this means that these countermeasures MUST always be enabled. > Since that is not explicitly stated, it seems that a server could > have those countermeasures enabled by default and a client could > have them disabled by default. That would result in a client and > server that would not interoperate until the administrator tracked > down the problem and changed their configuration. I suggest that > the document be changed to require not only that implementations > support these countermeasures but that they be enabled by default. >=20 [Joe] The countermeasures are always supported, it's up to the server whether to invoke them or not, the client will always follow the protocol. I don't think there is an interoperability problem here. This is probably a case where we discuss too much DTLS details in the draft. I would suggest changing: OLD: When these countermeasures are enabled, the transport receiver responds with a DTLS Hello Verify Request containing a cookie. New: When these countermeasures are used, the transport receiver responds with a DTLS Hello Verify Request containing a cookie. Joe > My response was: > "Good catch." >=20 > ACTION: Comments? >=20 > Thanks, > Chris > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From jsalowey@cisco.com Sun Jun 20 21:47:35 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EF33A6A1C for ; Sun, 20 Jun 2010 21:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.386 X-Spam-Level: X-Spam-Status: No, score=-10.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3Wx20g56Afm for ; Sun, 20 Jun 2010 21:47:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 224443A63CB for ; Sun, 20 Jun 2010 21:47:34 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKKLHkyrR7Hu/2dsb2JhbACfBnGmW5k5hRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,450,1272844800"; d="scan'208";a="215125124" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2010 04:47:41 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5L4leTi004893 for ; Mon, 21 Jun 2010 04:47:40 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Jun 2010 21:47:40 -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 Date: Sun, 20 Jun 2010 21:47:38 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Issue 14 - Unreliable Delivery Thread-Index: AcsPYV1Np+8gRVsBR/2KBN8/XCljXABmm+fA References: From: "Joseph Salowey (jsalowey)" To: "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 21 Jun 2010 04:47:40.0629 (UTC) FILETIME=[E1343850:01CB10FC] Subject: Re: [Syslog] Issue 14 - Unreliable Delivery X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 04:47:35 -0000 > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf > Of Chris Lonvick (clonvick) > Sent: Friday, June 18, 2010 8:42 PM > To: syslog@ietf.org > Subject: [Syslog] Issue 14 - Unreliable Delivery >=20 > SECDIR Reviewer comments: >=20 > One difference between the security considerations for syslog over > DTLS and those for syslog over TLS (unnoted in the current Security > Considerations section) is that DTLS does not provide retransmission. > If an attacker can cause a packet to be dropped (especially one > carrying significant information about an attack), the transport > receiver may not consider this a significant event and so the syslog > server may be completely unaware of the occurrence. This contrasts > with syslog over TLS where a dropped packet would be retransmitted > until acknowledged or until the TLS connection goes down (indicating > to the transport sender and receiver and perhaps to the syslog client > and server that a significant event has occurred). Maybe it would be > a good idea to recommend that the transport receiver notice gaps in > the DTLS sequence numbers and notify the syslog server. Still, this > is not as good from a security standpoint as syslog over TLS since > none of the client code will be aware that the dropped message was > not received. At least, there should be a discussion of this issue > in the Security Considerations section of this document. >=20 > My comments back to the reviewer and the IESG: > =3D=3D=3Dvvv=3D=3D=3D > It's discussed in section 5.4 (Unreliable Delivery - in the Security > Considerations section) in RFC 5426 and throughout Section 3.1 > (Loss-Insensitive Messaging) in RFC 4347. I'm thinking that it would be > good to note this in Section 4 (Using DTLS to Secure Syslog) in the draft. >=20 > Overall, the community is comfortable with the loss of information as > they've been using syslog/udp for many years and know the problems with > that. RFC 5424 also notes that implementers who wish a lossless stream > should be using tls/tcp as their transport. From that, it's probably best > to reference RFC 5848 (referenced as draft-ietf-syslog-sign in the draft) > which can also provide an indication of loss of messages. " > =3D=3D=3D^^^^=3D=3D=3D >=20 > ACTION: I'd like to get some discussion going on this. Do people think > that this is good? >=20 [Joe] I think it would be good to add a security consideration. How about: "9.x Message Loss The transports described in this document are unreliable. It is possible for messages to be lost or removed by an attacker without the knowledge of the receiver. [RFC 5424] notes that implementers who wish a lossless stream should be using tls/tcp as their transport. In addition, the use of [RFC 5848] can also provide an indication of message. "=20 > Thanks, > Chris > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From jsalowey@cisco.com Sun Jun 20 22:08:34 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DDC3A6A25 for ; Sun, 20 Jun 2010 22:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.404 X-Spam-Level: X-Spam-Status: No, score=-10.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hzi3G3hOrZYu for ; Sun, 20 Jun 2010 22:08:33 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 031723A697B for ; Sun, 20 Jun 2010 22:08:33 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFKQHkyrR7Ht/2dsb2JhbACfBnGmWJk6hRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,451,1272844800"; d="scan'208";a="147302836" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2010 05:08:39 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5L58aSQ024823 for ; Mon, 21 Jun 2010 05:08:36 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Jun 2010 22:08:36 -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 Date: Sun, 20 Jun 2010 22:08:35 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Status of syslog/dtls ISSUES Thread-Index: AcsPNOqImq/7A9KKTdSEYHvwIIT8VgByTtqA References: From: "Joseph Salowey (jsalowey)" To: "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 21 Jun 2010 05:08:36.0664 (UTC) FILETIME=[CDDBF380:01CB10FF] Subject: Re: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 05:08:34 -0000 Most of this looks pretty straight forward:=20 > Issue 8 - Tim Polk DISCUSS > STATUS: Discussed by Tom and David. Joe to incorporate changes. >=20 [Joe] For this one I have Section 5 as: "Implementations of this specification MUST support DTLS over UDP and MUST support DTLS over DCCP [RFC5238] if the DCCP transport is available at run-time." And section 6 as: " DCCP has congestion control. For this reason, when DCCP is available, the syslog over DTLS over DCCP option is RECOMMENDED in preference to the syslog over the DTLS over UDP option." I'm think the RECOMMENDED in the section 6 needs to be replaced with something else, I'm not quite sure what. =20 > Issue 9, 9a, and 9b - from a Tim Polk COMMENT > STATUS: It looks like 9 and 9a have been discussed and Tom has proposed > text to resolve them. Sean proposed text on 9b. I'd like some discussion > on that. >=20 [Joe] I'm not sure 9b is necessary, but I don't think it causes harm. I'd modify the text to say " implementations often generate their own key pairs" since its possible for the generation to be done outside the implementation. =20 > Issue 10 - Jari Arrko DISCUSS > STATUS: Same as Issue 1. Is the text proposed by Sean good to cover all > of this Issue, Issue 1 and Issue 2? >=20 [Joe] I incorporated the text, I'm not sure it covers all the issues, I think Tom initiated some discussion on the TLS list, but I don't think it changes the result. =20 From ietfdbh@comcast.net Mon Jun 21 05:23:47 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D603A6988 for ; Mon, 21 Jun 2010 05:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.322 X-Spam-Level: X-Spam-Status: No, score=-0.322 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B4afai6CCIR for ; Mon, 21 Jun 2010 05:23:46 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id 7BE2E3A67A3 for ; Mon, 21 Jun 2010 05:23:46 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id YbBL1e0010ldTLk5EcPt81; Mon, 21 Jun 2010 12:23:54 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta04.westchester.pa.mail.comcast.net with comcast id YcPt1e0052JQnJT3QcPtnH; Mon, 21 Jun 2010 12:23:53 +0000 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , "'Chris Lonvick \(clonvick\)'" , References: Date: Mon, 21 Jun 2010 08:22:20 -0400 Message-ID: <496FD167F610474CB8B42191E536451A@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsPYV1Np+8gRVsBR/2KBN8/XCljXABmm+fAABATLNA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Syslog] Issue 14 - Unreliable Delivery X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 12:23:47 -0000 Hi, I think that text looks good, except I think you lost the last word. I assume the last sentence was meant to end with "loss". You also might want to mention syslog-sign by name, not just RFC# dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey > (jsalowey) > Sent: Monday, June 21, 2010 12:48 AM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: Re: [Syslog] Issue 14 - Unreliable Delivery > > > > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf > > Of Chris Lonvick (clonvick) > > Sent: Friday, June 18, 2010 8:42 PM > > To: syslog@ietf.org > > Subject: [Syslog] Issue 14 - Unreliable Delivery > > > > SECDIR Reviewer comments: > > > > One difference between the security considerations for syslog over > > DTLS and those for syslog over TLS (unnoted in the current Security > > Considerations section) is that DTLS does not provide > retransmission. > > If an attacker can cause a packet to be dropped (especially one > > carrying significant information about an attack), the transport > > receiver may not consider this a significant event and so > the syslog > > server may be completely unaware of the occurrence. This contrasts > > with syslog over TLS where a dropped packet would be retransmitted > > until acknowledged or until the TLS connection goes down > (indicating > > to the transport sender and receiver and perhaps to the > syslog client > > and server that a significant event has occurred). Maybe it > would be a > > good idea to recommend that the transport receiver notice > gaps in the > > DTLS sequence numbers and notify the syslog server. Still, > this is not > > as good from a security standpoint as syslog over TLS since none of > > the client code will be aware that the dropped message was not > > received. At least, there should be a discussion of this > issue in the > > Security Considerations section of this document. > > > > My comments back to the reviewer and the IESG: > > ===vvv=== > > It's discussed in section 5.4 (Unreliable Delivery - in the > Security > > Considerations section) in RFC 5426 and throughout Section 3.1 > > (Loss-Insensitive Messaging) in RFC 4347. I'm thinking > that it would > be > > good to note this in Section 4 (Using DTLS to Secure Syslog) in the > draft. > > > > Overall, the community is comfortable with the loss of > information > as > > they've been using syslog/udp for many years and know the problems > with > > that. RFC 5424 also notes that implementers who wish a lossless > stream > > should be using tls/tcp as their transport. From that, > it's probably > best > > to reference RFC 5848 (referenced as draft-ietf-syslog-sign in the > draft) > > which can also provide an indication of loss of messages. " > > ===^^^^=== > > > > ACTION: I'd like to get some discussion going on this. Do people > think > > that this is good? > > > [Joe] I think it would be good to add a security consideration. How > about: > > "9.x Message Loss > > The transports described in this document are unreliable. It > is possible for messages to be lost or removed by an attacker > without the knowledge of the receiver. [RFC 5424] notes that > implementers who wish a lossless stream should be using > tls/tcp as their transport. In addition, the use of [RFC > 5848] can also provide an indication of message. " > > > > Thanks, > > Chris > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfdbh@comcast.net Mon Jun 21 08:47:41 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C412F3A694C for ; Mon, 21 Jun 2010 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNOa5EZsrn-g for ; Mon, 21 Jun 2010 08:47:39 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id A26893A68B2 for ; Mon, 21 Jun 2010 08:47:38 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta04.westchester.pa.mail.comcast.net with comcast id Yavb1e0091vXlb854fnmeT; Mon, 21 Jun 2010 15:47:46 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id Yfnm1e0022JQnJT3dfnmKm; Mon, 21 Jun 2010 15:47:46 +0000 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , "'Chris Lonvick \(clonvick\)'" , References: Date: Mon, 21 Jun 2010 11:46:13 -0400 Message-ID: <7BAF434C75E14B86A044A0D72B7ADCE2@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsPNOqImq/7A9KKTdSEYHvwIIT8VgByTtqAABYKvqA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 15:47:41 -0000 Hi, The proposed text is: "Implementations of this specification MUST support DTLS over UDP and MUST support DTLS over DCCP [RFC5238] if the DCCP transport is available at run-time." So if I am an implementer, and I have no idea whether my customers will have DCCP available at runtime, MUST I implement those DCCP-related things that are specified in this document? Even if I see no customer demand for DCCP, and assume it will NOT be available at runtime, MUST my implementation support the service code SYLG? If I don't implement support for this, and the customer DOES NOT have DCCP at runtime, is my implementation compliant to this spec? If I don't implement support for this, and the customer DOES have DCCP at runtime, is my implementation still compliant to this spec? dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey > (jsalowey) > Sent: Monday, June 21, 2010 1:09 AM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: Re: [Syslog] Status of syslog/dtls ISSUES > > Most of this looks pretty straight forward: > > Issue 8 - Tim Polk DISCUSS > > STATUS: Discussed by Tom and David. Joe to incorporate changes. > > > [Joe] For this one I have Section 5 as: > > "Implementations of this > specification MUST support DTLS over UDP and MUST support DTLS over > DCCP [RFC5238] if the DCCP transport is available at run-time." > > And section 6 as: > > " DCCP has congestion control. For this reason, when DCCP is > available, the syslog over DTLS over DCCP option is RECOMMENDED in > preference to the syslog over the DTLS over UDP option." > > I'm think the RECOMMENDED in the section 6 needs to be > replaced with something else, I'm not quite sure what. > > > Issue 9, 9a, and 9b - from a Tim Polk COMMENT > > STATUS: It looks like 9 and 9a have been discussed and Tom has > proposed > > text to resolve them. Sean proposed text on 9b. I'd like some > discussion > > on that. > > > [Joe] I'm not sure 9b is necessary, but I don't think it causes harm. > I'd modify the text to say " implementations often generate > their own key pairs" since its possible for the generation to > be done outside the implementation. > > > Issue 10 - Jari Arrko DISCUSS > > STATUS: Same as Issue 1. Is the text proposed by Sean good to cover > all > > of this Issue, Issue 1 and Issue 2? > > > [Joe] I incorporated the text, I'm not sure it covers all the > issues, I think Tom initiated some discussion on the TLS > list, but I don't think it changes the result. > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From jon@callas.org Mon Jun 21 09:07:31 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FA03A69DD for ; Mon, 21 Jun 2010 09:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfexutwKudj6 for ; Mon, 21 Jun 2010 09:07:31 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id 067033A6861 for ; Mon, 21 Jun 2010 09:07:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id F116E2E067 for ; Mon, 21 Jun 2010 09:13:07 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 21083-07 for ; Mon, 21 Jun 2010 09:13:01 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 787A02E03F for ; Mon, 21 Jun 2010 09:13:01 -0700 (PDT) Received: from [10.0.23.9] ([66.93.68.163]) by keys.merrymeet.com (PGP Universal service); Mon, 21 Jun 2010 09:00:25 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 21 Jun 2010 09:00:25 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Jon Callas In-Reply-To: Date: Mon, 21 Jun 2010 09:07:25 -0700 Message-Id: References: To: Chris Lonvick X-Mailer: Apple Mail (2.1081) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: Maia Mailguard Cc: syslog@ietf.org Subject: Re: [Syslog] Issue 14 - Unreliable Delivery X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 16:07:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > It's discussed in section 5.4 (Unreliable Delivery - in the Security Cons= iderations section) in RFC 5426 and throughout Section 3.1 (Loss-Insensitiv= e Messaging) in RFC 4347. I'm thinking that it would be good to note this = in Section 4 (Using DTLS to Secure Syslog) in the draft. >=20 > Overall, the community is comfortable with the loss of information as t= hey've been using syslog/udp for many years and know the problems with that= . RFC 5424 also notes that implementers who wish a lossless stream should = be using tls/tcp as their transport. From that, it's probably best to refe= rence RFC 5848 (referenced as draft-ietf-syslog-sign in the draft) which ca= n also provide an indication of loss of messages. " > =3D=3D=3D^^^^=3D=3D=3D >=20 > ACTION: I'd like to get some discussion going on this. Do people think t= hat this is good? I think a note somewhere reminding people that DTLS is unreliable, and that= syslog-sign protects both reliable and unreliable transports is reasonable= , but I wouldn't spend more than a sentence on each. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFMH4yZsTedWZOD3gYRApWxAKDSm83JTiS9VAZW2Cu69HE77KOCfgCgrGvc Z+SgfJhFZU8V3QouAhTMY3Y=3D =3DPW/f -----END PGP SIGNATURE----- From jsalowey@cisco.com Mon Jun 21 09:39:12 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013D628C0F4 for ; Mon, 21 Jun 2010 09:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnPSiyd4a5JV for ; Mon, 21 Jun 2010 09:39:10 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CE4103A6A86 for ; Mon, 21 Jun 2010 09:39:10 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAoyH0yrR7Hu/2dsb2JhbACfBXGpTposhRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,454,1272844800"; d="scan'208";a="147643751" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2010 16:39:17 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5LGdHFd001370; Mon, 21 Jun 2010 16:39:17 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 09:39:02 -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 Date: Mon, 21 Jun 2010 09:38:59 -0700 Message-ID: In-Reply-To: <7BAF434C75E14B86A044A0D72B7ADCE2@23FX1C1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Status of syslog/dtls ISSUES Thread-Index: AcsPNOqImq/7A9KKTdSEYHvwIIT8VgByTtqAABYKvqAAAmmuAA== References: <7BAF434C75E14B86A044A0D72B7ADCE2@23FX1C1> From: "Joseph Salowey (jsalowey)" To: "David Harrington" , "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 21 Jun 2010 16:39:02.0340 (UTC) FILETIME=[417C7840:01CB1160] Subject: Re: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 16:39:12 -0000 What text would you suggest? =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, June 21, 2010 8:46 AM > To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Status of syslog/dtls ISSUES >=20 > Hi, >=20 > The proposed text is: > "Implementations of this > specification MUST support DTLS over UDP and MUST support DTLS over > DCCP [RFC5238] if the DCCP transport is available at run-time." >=20 > So if I am an implementer, and I have no idea whether my customers > will have DCCP available at runtime, MUST I implement those > DCCP-related things that are specified in this document? >=20 > Even if I see no customer demand for DCCP, and assume it will NOT be > available at runtime, MUST my implementation support the service code > SYLG? >=20 > If I don't implement support for this, and the customer DOES NOT have > DCCP at runtime, is my implementation compliant to this spec? >=20 > If I don't implement support for this, and the customer DOES have DCCP > at runtime, is my implementation still compliant to this spec? >=20 > dbh >=20 >=20 > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey > > (jsalowey) > > Sent: Monday, June 21, 2010 1:09 AM > > To: Chris Lonvick (clonvick); syslog@ietf.org > > Subject: Re: [Syslog] Status of syslog/dtls ISSUES > > > > Most of this looks pretty straight forward: > > > Issue 8 - Tim Polk DISCUSS > > > STATUS: Discussed by Tom and David. Joe to incorporate changes. > > > > > [Joe] For this one I have Section 5 as: > > > > "Implementations of this > > specification MUST support DTLS over UDP and MUST support DTLS > over > > DCCP [RFC5238] if the DCCP transport is available at run-time." > > > > And section 6 as: > > > > " DCCP has congestion control. For this reason, when DCCP is > > available, the syslog over DTLS over DCCP option is RECOMMENDED > in > > preference to the syslog over the DTLS over UDP option." > > > > I'm think the RECOMMENDED in the section 6 needs to be > > replaced with something else, I'm not quite sure what. > > > > > Issue 9, 9a, and 9b - from a Tim Polk COMMENT > > > STATUS: It looks like 9 and 9a have been discussed and Tom has > > proposed > > > text to resolve them. Sean proposed text on 9b. I'd like some > > discussion > > > on that. > > > > > [Joe] I'm not sure 9b is necessary, but I don't think it causes > harm. > > I'd modify the text to say " implementations often generate > > their own key pairs" since its possible for the generation to > > be done outside the implementation. > > > > > Issue 10 - Jari Arrko DISCUSS > > > STATUS: Same as Issue 1. Is the text proposed by Sean good to > cover > > all > > > of this Issue, Issue 1 and Issue 2? > > > > > [Joe] I incorporated the text, I'm not sure it covers all the > > issues, I think Tom initiated some discussion on the TLS > > list, but I don't think it changes the result. > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > From ietfdbh@comcast.net Mon Jun 21 14:23:08 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F2A3A68E1 for ; Mon, 21 Jun 2010 14:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkXlePTzkzlh for ; Mon, 21 Jun 2010 14:23:06 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 9F0543A684E for ; Mon, 21 Jun 2010 14:23:06 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id YfDU1e0031uE5Es53lPE7h; Mon, 21 Jun 2010 21:23:14 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta16.westchester.pa.mail.comcast.net with comcast id YlPD1e00Y2JQnJT3clPE2Y; Mon, 21 Jun 2010 21:23:14 +0000 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , "'Chris Lonvick \(clonvick\)'" , References: <7BAF434C75E14B86A044A0D72B7ADCE2@23FX1C1> Date: Mon, 21 Jun 2010 17:21:53 -0400 Message-ID: <064AFA0A3ACE48D5B27CF27213DCF40A@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsPNOqImq/7A9KKTdSEYHvwIIT8VgByTtqAABYKvqAAAmmuAAAJvEcQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 21:23:08 -0000 How about "Implementations of this specification MUST support DTLS over UDP and MUST support the DTLS over DCCP [RFC5238] features of this specification." I'm not sure what else is necessary, but there are only two DCCP things mentioned in this spec - the CCIDs and SYSL service name. The CCID text is already written using RFC2119 language. dbh > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Monday, June 21, 2010 12:39 PM > To: David Harrington; Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > What text would you suggest? > > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, June 21, 2010 8:46 AM > > To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); > syslog@ietf.org > > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > > > Hi, > > > > The proposed text is: > > "Implementations of this > > specification MUST support DTLS over UDP and MUST > support DTLS over > > DCCP [RFC5238] if the DCCP transport is available at run-time." > > > > So if I am an implementer, and I have no idea whether my customers > > will have DCCP available at runtime, MUST I implement those > > DCCP-related things that are specified in this document? > > > > Even if I see no customer demand for DCCP, and assume it > will NOT be > > available at runtime, MUST my implementation support the > service code > > SYLG? > > > > If I don't implement support for this, and the customer > DOES NOT have > > DCCP at runtime, is my implementation compliant to this spec? > > > > If I don't implement support for this, and the customer > DOES have DCCP > > at runtime, is my implementation still compliant to this spec? > > > > dbh > > > > > > > -----Original Message----- > > > From: syslog-bounces@ietf.org > > > [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey > > > (jsalowey) > > > Sent: Monday, June 21, 2010 1:09 AM > > > To: Chris Lonvick (clonvick); syslog@ietf.org > > > Subject: Re: [Syslog] Status of syslog/dtls ISSUES > > > > > > Most of this looks pretty straight forward: > > > > Issue 8 - Tim Polk DISCUSS > > > > STATUS: Discussed by Tom and David. Joe to incorporate changes. > > > > > > > [Joe] For this one I have Section 5 as: > > > > > > "Implementations of this > > > specification MUST support DTLS over UDP and MUST support DTLS > > over > > > DCCP [RFC5238] if the DCCP transport is available at run-time." > > > > > > And section 6 as: > > > > > > " DCCP has congestion control. For this reason, when DCCP is > > > available, the syslog over DTLS over DCCP option is RECOMMENDED > > in > > > preference to the syslog over the DTLS over UDP option." > > > > > > I'm think the RECOMMENDED in the section 6 needs to be > replaced with > > > something else, I'm not quite sure what. > > > > > > > Issue 9, 9a, and 9b - from a Tim Polk COMMENT > > > > STATUS: It looks like 9 and 9a have been discussed and Tom has > > > proposed > > > > text to resolve them. Sean proposed text on 9b. I'd like some > > > discussion > > > > on that. > > > > > > > [Joe] I'm not sure 9b is necessary, but I don't think it causes > > harm. > > > I'd modify the text to say " implementations often generate their > > > own key pairs" since its possible for the generation to be done > > > outside the implementation. > > > > > > > Issue 10 - Jari Arrko DISCUSS > > > > STATUS: Same as Issue 1. Is the text proposed by Sean good to > > cover > > > all > > > > of this Issue, Issue 1 and Issue 2? > > > > > > > [Joe] I incorporated the text, I'm not sure it covers all the > > > issues, I think Tom initiated some discussion on the TLS > list, but > > > I don't think it changes the result. > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@ietf.org > > > https://www.ietf.org/mailman/listinfo/syslog > > > > From jsalowey@cisco.com Mon Jun 21 15:25:54 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E8B3A6ABD for ; Mon, 21 Jun 2010 15:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlHC7GjtBy-B for ; Mon, 21 Jun 2010 15:25:53 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8D8733A67C2 for ; Mon, 21 Jun 2010 15:25:53 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO2DH0yrR7H+/2dsb2JhbACfB3GpBZpEhRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,456,1272844800"; d="scan'208";a="547952068" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2010 22:26:00 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5LMQ0Po002454; Mon, 21 Jun 2010 22:26:00 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 15:26:00 -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 Date: Mon, 21 Jun 2010 15:25:58 -0700 Message-ID: In-Reply-To: <064AFA0A3ACE48D5B27CF27213DCF40A@23FX1C1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Status of syslog/dtls ISSUES Thread-Index: AcsPNOqImq/7A9KKTdSEYHvwIIT8VgByTtqAABYKvqAAAmmuAAAJvEcQAAHZEUA= References: <7BAF434C75E14B86A044A0D72B7ADCE2@23FX1C1> <064AFA0A3ACE48D5B27CF27213DCF40A@23FX1C1> From: "Joseph Salowey (jsalowey)" To: "David Harrington" , "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 21 Jun 2010 22:26:00.0497 (UTC) FILETIME=[BA132210:01CB1190] Subject: Re: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:25:54 -0000 I think DCCP features isn't really much clearer. Perhaps the following would be better, "Implementations of this specification MUST support DTLS over UDP and MUST support the DTLS over DCCP [RFC5238] CCIDs and service name specified in this document." This still seems to mandate a DCCP implementation to be compliant with the spec. =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, June 21, 2010 2:22 PM > To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Status of syslog/dtls ISSUES >=20 > How about >=20 > "Implementations of this > specification MUST support DTLS over UDP and MUST support the DTLS > over > DCCP [RFC5238] features of this specification." >=20 > I'm not sure what else is necessary, but there are only two DCCP > things mentioned in this spec - the CCIDs and SYSL service name. The > CCID text is already written using RFC2119 language. >=20 > dbh >=20 > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Monday, June 21, 2010 12:39 PM > > To: David Harrington; Chris Lonvick (clonvick); syslog@ietf.org > > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > > > What text would you suggest? > > > > > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Monday, June 21, 2010 8:46 AM > > > To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); > > syslog@ietf.org > > > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > > > > > Hi, > > > > > > The proposed text is: > > > "Implementations of this > > > specification MUST support DTLS over UDP and MUST > > support DTLS over > > > DCCP [RFC5238] if the DCCP transport is available at run-time." > > > > > > So if I am an implementer, and I have no idea whether my customers >=20 > > > will have DCCP available at runtime, MUST I implement those > > > DCCP-related things that are specified in this document? > > > > > > Even if I see no customer demand for DCCP, and assume it > > will NOT be > > > available at runtime, MUST my implementation support the > > service code > > > SYLG? > > > > > > If I don't implement support for this, and the customer > > DOES NOT have > > > DCCP at runtime, is my implementation compliant to this spec? > > > > > > If I don't implement support for this, and the customer > > DOES have DCCP > > > at runtime, is my implementation still compliant to this spec? > > > > > > dbh > > > > > > > > > > -----Original Message----- > > > > From: syslog-bounces@ietf.org > > > > [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey > > > > (jsalowey) > > > > Sent: Monday, June 21, 2010 1:09 AM > > > > To: Chris Lonvick (clonvick); syslog@ietf.org > > > > Subject: Re: [Syslog] Status of syslog/dtls ISSUES > > > > > > > > Most of this looks pretty straight forward: > > > > > Issue 8 - Tim Polk DISCUSS > > > > > STATUS: Discussed by Tom and David. Joe to incorporate > changes. > > > > > > > > > [Joe] For this one I have Section 5 as: > > > > > > > > "Implementations of this > > > > specification MUST support DTLS over UDP and MUST support > DTLS > > > over > > > > DCCP [RFC5238] if the DCCP transport is available at > run-time." > > > > > > > > And section 6 as: > > > > > > > > " DCCP has congestion control. For this reason, when DCCP is > > > > available, the syslog over DTLS over DCCP option is > RECOMMENDED > > > in > > > > preference to the syslog over the DTLS over UDP option." > > > > > > > > I'm think the RECOMMENDED in the section 6 needs to be > > replaced with > > > > something else, I'm not quite sure what. > > > > > > > > > Issue 9, 9a, and 9b - from a Tim Polk COMMENT > > > > > STATUS: It looks like 9 and 9a have been discussed and Tom > has > > > > proposed > > > > > text to resolve them. Sean proposed text on 9b. I'd like > some > > > > discussion > > > > > on that. > > > > > > > > > [Joe] I'm not sure 9b is necessary, but I don't think it causes > > > harm. > > > > I'd modify the text to say " implementations often generate > their > > > > own key pairs" since its possible for the generation to be done > > > > outside the implementation. > > > > > > > > > Issue 10 - Jari Arrko DISCUSS > > > > > STATUS: Same as Issue 1. Is the text proposed by Sean good to > > > cover > > > > all > > > > > of this Issue, Issue 1 and Issue 2? > > > > > > > > > [Joe] I incorporated the text, I'm not sure it covers all the > > > > issues, I think Tom initiated some discussion on the TLS > > list, but > > > > I don't think it changes the result. > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@ietf.org > > > > https://www.ietf.org/mailman/listinfo/syslog > > > > > > From ietfdbh@comcast.net Mon Jun 21 16:23:20 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649EC3A68D3 for ; Mon, 21 Jun 2010 16:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zdM3wRyL5mG for ; Mon, 21 Jun 2010 16:23:19 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id 09DD33A6828 for ; Mon, 21 Jun 2010 16:23:18 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id YigR1e00416LCl05CnPTQH; Mon, 21 Jun 2010 23:23:27 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta06.westchester.pa.mail.comcast.net with comcast id YnPS1e00E2JQnJT3SnPSw3; Mon, 21 Jun 2010 23:23:26 +0000 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , "'Chris Lonvick \(clonvick\)'" , References: <7BAF434C75E14B86A044A0D72B7ADCE2@23FX1C1> <064AFA0A3ACE48D5B27CF27213DCF40A@23FX1C1> Date: Mon, 21 Jun 2010 19:22:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsPNOqImq/7A9KKTdSEYHvwIIT8VgByTtqAABYKvqAAAmmuAAAJvEcQAAHZEUAAAo3woA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 23:23:20 -0000 It doesn't. And you can be explicit about that if you want. dbh > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Monday, June 21, 2010 6:26 PM > To: David Harrington; Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > I think DCCP features isn't really much clearer. Perhaps the > following would be better, > > "Implementations of this specification MUST support DTLS over > UDP and MUST support the DTLS over DCCP [RFC5238] CCIDs and > service name specified in this document." > > This still seems to mandate a DCCP implementation to be compliant with > the spec. > > > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, June 21, 2010 2:22 PM > > To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); > syslog@ietf.org > > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > > > How about > > > > "Implementations of this > > specification MUST support DTLS over UDP and MUST > support the DTLS > > over > > DCCP [RFC5238] features of this specification." > > > > I'm not sure what else is necessary, but there are only two DCCP > > things mentioned in this spec - the CCIDs and SYSL service > name. The > > CCID text is already written using RFC2119 language. > > > > dbh > > > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Monday, June 21, 2010 12:39 PM > > > To: David Harrington; Chris Lonvick (clonvick); syslog@ietf.org > > > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > > > > > What text would you suggest? > > > > > > > > > > -----Original Message----- > > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Monday, June 21, 2010 8:46 AM > > > > To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); > > > syslog@ietf.org > > > > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > > > > > > > Hi, > > > > > > > > The proposed text is: > > > > "Implementations of this > > > > specification MUST support DTLS over UDP and MUST > > > support DTLS over > > > > DCCP [RFC5238] if the DCCP transport is available at > run-time." > > > > > > > > So if I am an implementer, and I have no idea whether > my customers > > > > > > will have DCCP available at runtime, MUST I implement those > > > > DCCP-related things that are specified in this document? > > > > > > > > Even if I see no customer demand for DCCP, and assume it > > > will NOT be > > > > available at runtime, MUST my implementation support the > > > service code > > > > SYLG? > > > > > > > > If I don't implement support for this, and the customer > > > DOES NOT have > > > > DCCP at runtime, is my implementation compliant to this spec? > > > > > > > > If I don't implement support for this, and the customer > > > DOES have DCCP > > > > at runtime, is my implementation still compliant to this spec? > > > > > > > > dbh > > > > > > > > > > > > > -----Original Message----- > > > > > From: syslog-bounces@ietf.org > > > > > [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey > > > > > (jsalowey) > > > > > Sent: Monday, June 21, 2010 1:09 AM > > > > > To: Chris Lonvick (clonvick); syslog@ietf.org > > > > > Subject: Re: [Syslog] Status of syslog/dtls ISSUES > > > > > > > > > > Most of this looks pretty straight forward: > > > > > > Issue 8 - Tim Polk DISCUSS > > > > > > STATUS: Discussed by Tom and David. Joe to incorporate > > changes. > > > > > > > > > > > [Joe] For this one I have Section 5 as: > > > > > > > > > > "Implementations of this > > > > > specification MUST support DTLS over UDP and MUST support > > DTLS > > > > over > > > > > DCCP [RFC5238] if the DCCP transport is available at > > run-time." > > > > > > > > > > And section 6 as: > > > > > > > > > > " DCCP has congestion control. For this reason, when DCCP is > > > > > available, the syslog over DTLS over DCCP option is > > RECOMMENDED > > > > in > > > > > preference to the syslog over the DTLS over UDP option." > > > > > > > > > > I'm think the RECOMMENDED in the section 6 needs to be > > > replaced with > > > > > something else, I'm not quite sure what. > > > > > > > > > > > Issue 9, 9a, and 9b - from a Tim Polk COMMENT > > > > > > STATUS: It looks like 9 and 9a have been discussed and Tom > > has > > > > > proposed > > > > > > text to resolve them. Sean proposed text on 9b. I'd like > > some > > > > > discussion > > > > > > on that. > > > > > > > > > > > [Joe] I'm not sure 9b is necessary, but I don't think > it causes > > > > harm. > > > > > I'd modify the text to say " implementations often generate > > their > > > > > own key pairs" since its possible for the generation > to be done > > > > > outside the implementation. > > > > > > > > > > > Issue 10 - Jari Arrko DISCUSS > > > > > > STATUS: Same as Issue 1. Is the text proposed by > Sean good to > > > > cover > > > > > all > > > > > > of this Issue, Issue 1 and Issue 2? > > > > > > > > > > > [Joe] I incorporated the text, I'm not sure it covers all the > > > > > issues, I think Tom initiated some discussion on the TLS > > > list, but > > > > > I don't think it changes the result. > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/syslog > > > > > > > > > From clonvick@cisco.com Tue Jun 22 17:11:07 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3AEF3A68C4 for ; Tue, 22 Jun 2010 17:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.966 X-Spam-Level: X-Spam-Status: No, score=-9.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWrs8oKC5vej for ; Tue, 22 Jun 2010 17:11:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6E9923A68B5 for ; Tue, 22 Jun 2010 17:11:05 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,463,1272844800"; d="scan'208";a="148335123" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Jun 2010 00:11:13 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5N0BDwT001181; Wed, 23 Jun 2010 00:11:13 GMT Date: Tue, 22 Jun 2010 17:11:12 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org, "Joseph Salowey (jsalowey)" In-Reply-To: Message-ID: References: <7BAF434C75E14B86A044A0D72B7ADCE2@23FX1C1> <064AFA0A3ACE48D5B27CF27213DCF40A@23FX1C1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 00:11:07 -0000 Hi Folks, How about this: - We leave Section 5 just as it is: CURRENT: DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. Transports, such as UDP or DCCP do not provide session multiplexing and session-demultiplexing. In such cases, the application implementer provides this functionality by mapping a unique combination of the remote address, remote port number, local address and local port number to a session. - We modify Section 6 as follows: CURRENT: DCCP has congestion control. For this reason the syslog over DTLS over DCCP option is recommended in preference to the syslog over the DTLS over UDP option. Implementations of syslog over DTLS over DCCP MUST support CCID 3 and SHOULD support CCID 2 to ensure interoperability. PROPOSED: DCCP has congestion control but is not widely deployed at the time of this writing. Since it does have congestion control, whereas UDP does not, syslog over DTLS over DCCP is recommended in preference to the syslog over DTLS over UDP. Implementations of syslog over DTLS over DCCP MUST support CCID 3 and SHOULD support CCID 2 to ensure interoperability. Please get your comments in quickly as we'd like to close this out. Thanks, Chris On Mon, 21 Jun 2010, Joseph Salowey (jsalowey) wrote: > I think DCCP features isn't really much clearer. Perhaps the following > would be better, > > "Implementations of this specification MUST support DTLS over UDP and > MUST support the DTLS over > DCCP [RFC5238] CCIDs and service name specified in this document." > > This still seems to mandate a DCCP implementation to be compliant with > the spec. > > > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Monday, June 21, 2010 2:22 PM >> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); > syslog@ietf.org >> Subject: RE: [Syslog] Status of syslog/dtls ISSUES >> >> How about >> >> "Implementations of this >> specification MUST support DTLS over UDP and MUST support the DTLS >> over >> DCCP [RFC5238] features of this specification." >> >> I'm not sure what else is necessary, but there are only two DCCP >> things mentioned in this spec - the CCIDs and SYSL service name. The >> CCID text is already written using RFC2119 language. >> >> dbh >> >>> -----Original Message----- >>> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] >>> Sent: Monday, June 21, 2010 12:39 PM >>> To: David Harrington; Chris Lonvick (clonvick); syslog@ietf.org >>> Subject: RE: [Syslog] Status of syslog/dtls ISSUES >>> >>> What text would you suggest? >>> >>> >>>> -----Original Message----- >>>> From: David Harrington [mailto:ietfdbh@comcast.net] >>>> Sent: Monday, June 21, 2010 8:46 AM >>>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); >>> syslog@ietf.org >>>> Subject: RE: [Syslog] Status of syslog/dtls ISSUES >>>> >>>> Hi, >>>> >>>> The proposed text is: >>>> "Implementations of this >>>> specification MUST support DTLS over UDP and MUST >>> support DTLS over >>>> DCCP [RFC5238] if the DCCP transport is available at run-time." >>>> >>>> So if I am an implementer, and I have no idea whether my customers >> >>>> will have DCCP available at runtime, MUST I implement those >>>> DCCP-related things that are specified in this document? >>>> >>>> Even if I see no customer demand for DCCP, and assume it >>> will NOT be >>>> available at runtime, MUST my implementation support the >>> service code >>>> SYLG? >>>> >>>> If I don't implement support for this, and the customer >>> DOES NOT have >>>> DCCP at runtime, is my implementation compliant to this spec? >>>> >>>> If I don't implement support for this, and the customer >>> DOES have DCCP >>>> at runtime, is my implementation still compliant to this spec? >>>> >>>> dbh >>>> >>>> >>>>> -----Original Message----- >>>>> From: syslog-bounces@ietf.org >>>>> [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey >>>>> (jsalowey) >>>>> Sent: Monday, June 21, 2010 1:09 AM >>>>> To: Chris Lonvick (clonvick); syslog@ietf.org >>>>> Subject: Re: [Syslog] Status of syslog/dtls ISSUES >>>>> >>>>> Most of this looks pretty straight forward: >>>>>> Issue 8 - Tim Polk DISCUSS >>>>>> STATUS: Discussed by Tom and David. Joe to incorporate >> changes. >>>>>> >>>>> [Joe] For this one I have Section 5 as: >>>>> >>>>> "Implementations of this >>>>> specification MUST support DTLS over UDP and MUST support >> DTLS >>>> over >>>>> DCCP [RFC5238] if the DCCP transport is available at >> run-time." >>>>> >>>>> And section 6 as: >>>>> >>>>> " DCCP has congestion control. For this reason, when DCCP is >>>>> available, the syslog over DTLS over DCCP option is >> RECOMMENDED >>>> in >>>>> preference to the syslog over the DTLS over UDP option." >>>>> >>>>> I'm think the RECOMMENDED in the section 6 needs to be >>> replaced with >>>>> something else, I'm not quite sure what. >>>>> >>>>>> Issue 9, 9a, and 9b - from a Tim Polk COMMENT >>>>>> STATUS: It looks like 9 and 9a have been discussed and Tom >> has >>>>> proposed >>>>>> text to resolve them. Sean proposed text on 9b. I'd like >> some >>>>> discussion >>>>>> on that. >>>>>> >>>>> [Joe] I'm not sure 9b is necessary, but I don't think it causes >>>> harm. >>>>> I'd modify the text to say " implementations often generate >> their >>>>> own key pairs" since its possible for the generation to be done >>>>> outside the implementation. >>>>> >>>>>> Issue 10 - Jari Arrko DISCUSS >>>>>> STATUS: Same as Issue 1. Is the text proposed by Sean good to >>>> cover >>>>> all >>>>>> of this Issue, Issue 1 and Issue 2? >>>>>> >>>>> [Joe] I incorporated the text, I'm not sure it covers all the >>>>> issues, I think Tom initiated some discussion on the TLS >>> list, but >>>>> I don't think it changes the result. >>>>> >>>>> _______________________________________________ >>>>> Syslog mailing list >>>>> Syslog@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/syslog >>>>> >>> > > From clonvick@cisco.com Tue Jun 22 19:18:45 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C243A6835 for ; Tue, 22 Jun 2010 19:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.785 X-Spam-Level: X-Spam-Status: No, score=-8.785 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aBazWNoqf8V for ; Tue, 22 Jun 2010 19:18:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D12F23A67EA for ; Tue, 22 Jun 2010 19:18:43 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GAPMLIUyrRN+K/2dsb2JhbACSewEBjClxqQ2aOIUbBINX X-IronPort-AV: E=Sophos;i="4.53,464,1272844800"; d="scan'208";a="337676792" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2010 02:18:51 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o5N2IpCM009181 for ; Wed, 23 Jun 2010 02:18:51 GMT Date: Tue, 22 Jun 2010 19:18:51 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Syslog] Udate on open issues - 22 June 2010 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 02:18:45 -0000 Hi Folks, We're getting close so I wanted to let everyone know where we are with these. I'd like to close these out by this FRIDAY, 25 June 2010. Here's where we stand on the open issues: Issue 1 - COMMENT from Alexy STATUS: Combined with Issue 10 Issue 2 - Fragmentation STATUS: Combined with Issue 10 Issue 3 - Text revision from GENART review STATUS: Joe composed text. Issue 4 - Service code subregistry STATUS: Tacit approval from the WG. Joe using proposed text. Issue 5 - Reference STATUS: Tacit approval from the WG. Joe using proposed text. Issue 6 - Reference 2 STATUS: Sean agrees with proposed text. Joe to incorporate. Issue 7 - text STATUS: Joe using proposed text. Issue 8 - Tim Polk DISCUSS STATUS: Discussion ongoing. Looking for resolution. Issue 9, 9a, and 9b - from a Tim Polk COMMENT STATUS: 9 and 9a discussed and resolved. Joe proposed text for 9b. Issue 10 - Jari Arrko DISCUSS STATUS: Same as Issus 1 and 2. Joe using proposed text. Issue 11 - Adrian Farrel DISCUSS STATUS: CLOSED Issue 12 - nit STATUS: Joe using proposed text. Issue 13 - DCCP? STATUS: CLOSED Issue 14 - Unreliable Delivery STATUS: Joe proposed text. David approved and Jon agreed to add a sentence. Issue 15 - DoS measures STATUS: Joe explained the situation and proposed text. Issue 16 - Security Policies STATUS: Joe agrees with the proposed text. Thanks, Chris From ietfdbh@comcast.net Tue Jun 22 20:25:31 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546063A69F0 for ; Tue, 22 Jun 2010 20:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=1.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOkaHUeBgyJk for ; Tue, 22 Jun 2010 20:25:29 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 539AE3A6A33 for ; Tue, 22 Jun 2010 20:25:29 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id ZCdu1e0041c6gX858FRdtT; Wed, 23 Jun 2010 03:25:37 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta23.westchester.pa.mail.comcast.net with comcast id ZFRd1e00B2JQnJT3jFRdDf; Wed, 23 Jun 2010 03:25:37 +0000 From: "David Harrington" To: "'Chris Lonvick'" , , "'Joseph Salowey \(jsalowey\)'" References: <7BAF434C75E14B86A044A0D72B7ADCE2@23FX1C1> <064AFA0A3ACE48D5B27CF27213DCF40A@23FX1C1> Date: Tue, 22 Jun 2010 23:24:17 -0400 Message-ID: <51448FF6705842B788A0C4B522DB9630@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsSaJg5mjCSvseQS/m0BLKPhXspMwAE/xXw Cc: tim.polk@nist.gov Subject: Re: [Syslog] Status of syslog/dtls ISSUES X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 03:25:31 -0000 Hi, Tim, your orignal concern was that the section 5 advice and the section 6 advice didn't align: a RECOMMENDED to use should be accompanied by a mandatory-to-implement. I agree there should be mandatory support for syslog/dtls to provide an interace to DCCP, so that when DCCP is available it can be used. But apparently the WG doesn't agree. Good luck getting operators to use it, even when DCCP is available, if implementers don't implement the necessary interface to call DCCP from syslog/DTLS. I have not seen any technical arguments as to why this cannot be done. But I recused, since I am chair of syslog, so this is not my DISCUSS. I recommend the following as a compromise position: Leave section 5 as is: CURRENT: DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. Transports, such as UDP or DCCP do not provide session multiplexing and session-demultiplexing. In such cases, the application implementer provides this functionality by mapping a unique combination of the remote address, remote port number, local address and local port number to a session. section 6: CURRENT: DCCP has congestion control. For this reason the syslog over DTLS over DCCP option is recommended in preference to the syslog over the DTLS over UDP option. Implementations of syslog over DTLS over DCCP MUST support CCID 3 and SHOULD support CCID 2 to ensure interoperability. NEW: DCCP has congestion control. If DCCP is available, syslog over DTLS over DCCP is RECOMMENDED in preference to syslog over DTLS over UDP. Implementations of syslog over DTLS over DCCP MUST support CCID 3 and SHOULD support CCID 2 to ensure interoperability. This provides clear guidance to implementers that they SHOULD implement, and to users that they SHOULD use it if available. (I find this much better than "MUST implement if DCCP is available at runtime", since an implementer would not necessarily know if DCCP would be available at runtime.) dbh > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Tuesday, June 22, 2010 8:11 PM > To: syslog@ietf.org; Joseph Salowey (jsalowey) > Cc: David Harrington > Subject: RE: [Syslog] Status of syslog/dtls ISSUES > > Hi Folks, > > How about this: > > - We leave Section 5 just as it is: > CURRENT: > DTLS can run over multiple transports. Implementations of this > specification MUST support DTLS over UDP and SHOULD > support DTLS over > DCCP [RFC5238]. Transports, such as UDP or DCCP do not provide > session multiplexing and session-demultiplexing. In such > cases, the > application implementer provides this functionality by mapping a > unique combination of the remote address, remote port > number, local > address and local port number to a session. > > - We modify Section 6 as follows: > CURRENT: > DCCP has congestion control. For this reason the syslog over DTLS > over DCCP option is recommended in preference to the > syslog over the > DTLS over UDP option. Implementations of syslog over > DTLS over DCCP > MUST support CCID 3 and SHOULD support CCID 2 to ensure > interoperability. > PROPOSED: > DCCP has congestion control but is not widely deployed at > the time of > this writing. Since it does have congestion control, > whereas UDP does > not, syslog over DTLS over DCCP is recommended in > preference to the > syslog over DTLS over UDP. Implementations of syslog > over DTLS over > DCCP MUST support CCID 3 and SHOULD support CCID 2 to ensure > interoperability. > > Please get your comments in quickly as we'd like to close this out. > > Thanks, > Chris > > > On Mon, 21 Jun 2010, Joseph Salowey (jsalowey) wrote: > > > I think DCCP features isn't really much clearer. Perhaps the > > following would be better, > > > > "Implementations of this specification MUST support DTLS > over UDP and > > MUST support the DTLS over DCCP [RFC5238] CCIDs and service name > > specified in this document." > > > > This still seems to mandate a DCCP implementation to be > compliant with > > the spec. > > > > > > > >> -----Original Message----- > >> From: David Harrington [mailto:ietfdbh@comcast.net] > >> Sent: Monday, June 21, 2010 2:22 PM > >> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); > > syslog@ietf.org > >> Subject: RE: [Syslog] Status of syslog/dtls ISSUES > >> > >> How about > >> > >> "Implementations of this > >> specification MUST support DTLS over UDP and MUST support the > >> DTLS over > >> DCCP [RFC5238] features of this specification." > >> > >> I'm not sure what else is necessary, but there are only two DCCP > >> things mentioned in this spec - the CCIDs and SYSL service > name. The > >> CCID text is already written using RFC2119 language. > >> > >> dbh > >> > >>> -----Original Message----- > >>> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > >>> Sent: Monday, June 21, 2010 12:39 PM > >>> To: David Harrington; Chris Lonvick (clonvick); syslog@ietf.org > >>> Subject: RE: [Syslog] Status of syslog/dtls ISSUES > >>> > >>> What text would you suggest? > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Harrington [mailto:ietfdbh@comcast.net] > >>>> Sent: Monday, June 21, 2010 8:46 AM > >>>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick); > >>> syslog@ietf.org > >>>> Subject: RE: [Syslog] Status of syslog/dtls ISSUES > >>>> > >>>> Hi, > >>>> > >>>> The proposed text is: > >>>> "Implementations of this > >>>> specification MUST support DTLS over UDP and MUST > >>> support DTLS over > >>>> DCCP [RFC5238] if the DCCP transport is available at > run-time." > >>>> > >>>> So if I am an implementer, and I have no idea whether my > customers > >> > >>>> will have DCCP available at runtime, MUST I implement those > >>>> DCCP-related things that are specified in this document? > >>>> > >>>> Even if I see no customer demand for DCCP, and assume it > >>> will NOT be > >>>> available at runtime, MUST my implementation support the > >>> service code > >>>> SYLG? > >>>> > >>>> If I don't implement support for this, and the customer > >>> DOES NOT have > >>>> DCCP at runtime, is my implementation compliant to this spec? > >>>> > >>>> If I don't implement support for this, and the customer > >>> DOES have DCCP > >>>> at runtime, is my implementation still compliant to this spec? > >>>> > >>>> dbh > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: syslog-bounces@ietf.org > >>>>> [mailto:syslog-bounces@ietf.org] On Behalf Of Joseph Salowey > >>>>> (jsalowey) > >>>>> Sent: Monday, June 21, 2010 1:09 AM > >>>>> To: Chris Lonvick (clonvick); syslog@ietf.org > >>>>> Subject: Re: [Syslog] Status of syslog/dtls ISSUES > >>>>> > >>>>> Most of this looks pretty straight forward: > >>>>>> Issue 8 - Tim Polk DISCUSS > >>>>>> STATUS: Discussed by Tom and David. Joe to incorporate > >> changes. > >>>>>> > >>>>> [Joe] For this one I have Section 5 as: > >>>>> > >>>>> "Implementations of this > >>>>> specification MUST support DTLS over UDP and MUST support > >> DTLS > >>>> over > >>>>> DCCP [RFC5238] if the DCCP transport is available at > >> run-time." > >>>>> > >>>>> And section 6 as: > >>>>> > >>>>> " DCCP has congestion control. For this reason, when DCCP is > >>>>> available, the syslog over DTLS over DCCP option is > >> RECOMMENDED > >>>> in > >>>>> preference to the syslog over the DTLS over UDP option." > >>>>> > >>>>> I'm think the RECOMMENDED in the section 6 needs to be > >>> replaced with > >>>>> something else, I'm not quite sure what. > >>>>> > >>>>>> Issue 9, 9a, and 9b - from a Tim Polk COMMENT > >>>>>> STATUS: It looks like 9 and 9a have been discussed and Tom > >> has > >>>>> proposed > >>>>>> text to resolve them. Sean proposed text on 9b. I'd like > >> some > >>>>> discussion > >>>>>> on that. > >>>>>> > >>>>> [Joe] I'm not sure 9b is necessary, but I don't think it causes > >>>> harm. > >>>>> I'd modify the text to say " implementations often generate > >> their > >>>>> own key pairs" since its possible for the generation to be done > >>>>> outside the implementation. > >>>>> > >>>>>> Issue 10 - Jari Arrko DISCUSS > >>>>>> STATUS: Same as Issue 1. Is the text proposed by Sean good to > >>>> cover > >>>>> all > >>>>>> of this Issue, Issue 1 and Issue 2? > >>>>>> > >>>>> [Joe] I incorporated the text, I'm not sure it covers all the > >>>>> issues, I think Tom initiated some discussion on the TLS > >>> list, but > >>>>> I don't think it changes the result. > >>>>> > >>>>> _______________________________________________ > >>>>> Syslog mailing list > >>>>> Syslog@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/syslog > >>>>> > >>> > > > >