Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls

"Tim Evens" <tim@evensweb.com> Tue, 25 May 2010 14:26 UTC

Return-Path: <tim@evensweb.com>
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 8C76B3A74E7 for <syslog@core3.amsl.com>; Tue, 25 May 2010 07:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.057
X-Spam-Level: *
X-Spam-Status: No, score=1.057 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 SUjMhgb3I+kH for <syslog@core3.amsl.com>; Tue, 25 May 2010 07:26:53 -0700 (PDT)
Received: from outbound3.bluetie.com (outbound3.bluetie.com [206.65.163.13]) by core3.amsl.com (Postfix) with ESMTP id C57683A729B for <syslog@ietf.org>; Tue, 25 May 2010 07:24:11 -0700 (PDT)
Received: from web3.nyc1.bluetie.com ([10.102.1.187]) by outbound3.bluetie.com with bizsmtp id MqQ31e0044258dW01qQ335; Tue, 25 May 2010 10:24:03 -0400
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=1.1 cv=9a3w/t1JzCufGMGo8phnWiRF/rANpT4CXr2jTnyFA9M= c=1 sm=1 a=YtVw0_ETJMMA:10 a=uEzv4HemXiYA:10 a=YkQXWpjeXptGWEpL3VMA:9 a=taP0p1IePwkHRt3H0esA:7 a=ApPqIbMOabFULZ0TJuYLvyyHTSkA:4 a=QEXdDO2ut3YA:10 a=9qxNCY_qAAAA:8 a=bXa9qGGSC5oe9P5eCGQA:9 a=GnGaybXoEc53MaII4CAA:7 a=fp_LebUmua2G5dsgA8XY2qeIt9EA:4 a=1pxjJC3EenQA:10 a=ZexAb3Vcgjt8ZV0CTeya/g==:117
Received: from web3.nyc1.bluetie.com (localhost.localdomain [127.0.0.1]) by web3.nyc1.bluetie.com (Postfix) with ESMTP id 290FE30048; Tue, 25 May 2010 10:24:00 -0400 (EDT)
Message-ID: <20100525102400.30396@web3.nyc1.bluetie.com>
X-HTTP-Received: from tim.evensweb [24.19.97.0] by web3.nyc1.bluetie.com (BlueTie WebMail ); Tue, 25 May 2010 10:24:00 -0400
X-Mailer: BlueTie MTA
Date: Tue, 25 May 2010 10:24:00 -0400
To: ietfc@btconnect.com, turners@ieca.com, Pasi.Eronen@nokia.com
From: Tim Evens <tim@evensweb.com>
Importance: normal
Content-Type: multipart/alternative; boundary="1784811518-1274797440=:30396"
MIME-Version: 1.0
Cc: syslog@ietf.org
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2010 14:26:56 -0000

See inline...-----Original Message-----From: Pasi.Eronen@nokia.comDate: 05/25/2010 03:54 AMRFC 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. <tievens> 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. This leads to the issue of what happens when a packet is dropped?   Even if you follow the DTLS sequence numbers, UDP and DTLS do not support retransmission, thus that lost packet is lost forever. This would lead to one message "chunk" being concatenated with a different message altogether.  This is why I was suggesting a SYSLOG-FRAME-ID. </tievens> Best regards, Pasi