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

[Chris Lonvick <[e-mail]>]

Hi,

Tim - I just rejected your latest post (it got to be way to large when you 
attached your previous posts as PDFs).

All - things can be read on the archive.
  http://www.ietf.org/mail-archive/web/syslog/current/maillist.html

And, apologies to all, I've gotten caught up in the day job and can't read 
these things yet.  Hopefully over the weekend.  :-)

Thanks,
Chris

On Tue, 25 May 2010, t.petch wrote:

> Tim
>
> I am getting your e-mails but struggling to read them, since they are a
> concatenated pipe of text, no fragmentation here.
>
> When I look at the source, it is in quoted-printable UTF8 and
> whereever I might expect a hard break, I see =A0.
>
> If I edit =A0 to =0A, then hard breaks appear where I expect them.
>
> Curious.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Tim Evens" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, May 25, 2010 4:14 PM
> Subject: RE: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls
>
>
> Correct, in RFC5426 the max size is 64K which is the max length in UDP. UDP
> sizes of greater than MTU are only achievable via IP layer fragmentation, as you
> also indicated. I'm under the impression that DTLS does NOT support IPv4
> fragmentation since in RFC4347 it states in Section 4.1.1 "Each DTLS record MUST
> fit within a single datagram. In order to avoid IP fragmentation [MOGUL], DTLS
> implementations SHOULD determine the MTU and send records smaller than the MTU.
> DTLS implementations SHOULD provide a way for applications to determine the
> value of the PMTU (or, alternately, the maximum application datagram size, which
> is the PMTU minus the DTLS per-record overhead). If the application attempts to
> send a record larger than the MTU, the DTLS implementation SHOULD generate an
> error, thus avoiding sending a packet which will be fragmented."While UDP
> supports message sizes in excess of 1500 bytes, the implementation as defined in
> this draft using DTLS does not. It does not require or use DTLS sequence numbers
> nor does DTLS allow for fragmentation. How exactly does this draft support
> message sizes larger than the MTU considering these restrictions? Few layer 2
> implementations support MTU sizes greater than 9K. Even with GigabitEthernet
> Jumbo frames (9K) the end-to-end MTU is still limited as the frame/packet
> traverses various devices. Only GigabitEthernet requires optional support for
> jumbo frames, while FastEthernet does not. Most 10/100 interfaces only support a
> maximum of 2K frame MTU, while Gig and TenGig support 9K. -----Original
> Message-----From: [e-mail]: 05/25/2010 02:45 AMTo:
> [e-mail], [e-mail], [e-mail]:
> [e-mail]: RE: [Syslog] AD review discuss/comments for
> draft-ietf-syslog-dtls         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.  Best regards, Pasi    From: ext Tim
> Evens [[e-mail]] Sent: Monday, May 24, 2010 7:34 PM To:
> [e-mail]; [e-mail]; Eronen Pasi (Nokia-NRC/Helsinki) Cc:
> [e-mail] Subject: Re: [Syslog] AD review discuss/comments for
> draft-ietf-syslog-dtls     Right. I wrote the following a couple weeks back:
> "… an application may not directly write to the network where UDP/DTLS would be
> used as a transport. More likely, the application will write to a regular file
> or FIFO/PIPE that may support a larger message size. The application that reads
> this message  may be the application that sends the messages via UDP/DTLS. It
> would be more meaningful if the application writing the message controls the
> truncation or if the transport application sending the message onto the network
> can correctly break up the message  into parts to fit the transport message size
> limitations. RFC5424 doesn't detail SD elements or methods for splitting
> messages. Transports have size constraints and will require messages to be
> truncated or split. For example, the CISCO-SYSLOG-MIB defines  that a message
> larger than 255 characters will be truncated to 254 characters with a '*' as the
> 255th character. "   To your point there are multiple units, but I would lump
> three of those units together as "transport" units considering they all have to
> do with the transportation of the message on the network.    In my opinion, this
> draft assumes that the application logging the message will some how size the
> message to fit within a single DTLS record/packet. This assumption is
> problematic, as mentioned above the application writing the actual SYSLOG-MSG
> per  RFC5424 has no way of knowing which transport is being used and what
> limitations those transports impose. For example, in my experience and in my
> opinion, there will be more than one syslog receiver/collector. Remote syslog
> receivers/collectors may require  different transports. One may use UDP/DTLS
> while the other uses TCP. Therefore, the original syslog message of say 1480
> bytes may be written to the network twice, one using UDP/DTLS and the other
> using TCP. The message that is transported using TCP will  be receive in full
> without any issues, while the one with DTLS will have to be truncated to the MTU
> size limitations.    RFC4347 (DTLS) refers to RFC4346 (TLS 1.1 obsoleted by
> RFC5246 TLS 1.2) for record layer implementation. More specifically, as defined
> in RFC4346 Section 6.2.1, "The record layer fragments information blocks into
> TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client
> message boundaries are not preserved in the record layer (i.e., multiple client
> messages of the same ContentType MAY be coalesced into a single TLSPlaintext
> record, or a single message MAY be fragmented across several records)."   It's
> possible for TLS 1.1 and 1.2 to support message block (chunks) as defined
> because the underlining transport is TCP providing ordered message delivery,
> whereas RFC4347 (DTLS) can use UDP which does not provide ordered delivery. DTLS
> introduces a sequence  number field in the record structure, which if
> implemented for reordering, the receiver could reorder the DTLS records so that
> the original message blocks are concatenated back to form the original
> SYSLOG-MSG.    This probably leads to why in this draft in Section 5.1 it states
> that when using DTLS sequence numbers "… it may not assure that all the messages
> are delivered in order when mapping on the UDP transport."   The reason is that
> with TCP there is a retransmission for lost segments, whereas UDP does not
> implement retransmissions. Therefore, if a DTLS sequence is dropped/lost or not
> received within the allotted queue buffer time, the DTLS application doesn't
> have anyway of knowing if seq X1 and seq X3 can be correctly put together. How
> it would it know to discard X1 and X3 since X2 was lost? In either case, this
> too is problematic, which leads back to why the SYSLOG-MSG will have to fit
> within a single DTLS  record. Thus the SYSLOG-MSG will in most cases always be
> less than 1460 bytes due to MTU DTLS/MTU limitations. The application SHOULD NOT
> assume that using the RFC5424 recommended minimum of 480 octets is sufficient as
> the IPv4 MTU still can be less than  that.   I believe that this could be solved
> if this draft were to be updated to require that the DTLS implementation reorder
> using DTLS sequence numbers using a queue size of at least 5 or more DTLS
> packets/records. In addition, Section 5.4 would need a new  field in the
> SYSLOG-FRAME to include a FRAME-ID. This FRAME-ID would serve as a way for the
> DTLS implementation to know which DTLS records need to be discarded in the event
> of packet loss.    For example:   FRAME-ID = NILVALUE / ("+" / "-")
> NONZERO-DIGIT 1*15DIGIT; uint48*   +/- is used to indicate more message blocks
> to come or not. "+" indicates more to follow, "-" indicates last block.   Use
> NILVALUE if SYSLOG-MSG is not split across multiple DTLS records, otherwise use
> first DTLS sequence number in DTLS record sequence as FRAME-ID.   This is an
> example only of a possible FRAME-ID.   *Instead of using 1*15DIGIT, it could be
> 6OCTET=uint48, which would reduce the overall size.   Example Use:   DTLS seq
> 1 - SYSLOG-FRAME-ID=+1001 <SYSLOG-MSG> DTLS seq 2 - SYSLOG-FRAME-ID=+1001
> <SYSLOG-MSG> --> dropped by network --> DTLS seq 3 - SYSLOG-FRAME-ID=+1001
> <SYSLOG-MSG> DTLS seq 4 - SYSLOG-FRAME-ID=-1001 <SYSLOG-MSG> DTLS seq 5 -
> SYSLOG-FRAME-ID - <SYSLOG-MSG> DTLS seq 6 - SYSLOG-FRAME-ID - <SYSLOG-MSG>
> Using a buffer/queue size of 5 DTLS records/packets, the DTLS implementation
> would have been holding DTLS seq 1, 2, and 4 waiting for 3. When it received seq
> 5 and 6, it reaches its buffer size and therefore discards DTLS seq 1,2,4 since
> they all have  SYSLOG-FRAME-ID of 1001. DTLS seq 5 and 6 are processed.
> Thanks, Tim      -----Original Message----- From: [e-mail] Date:
> 05/24/2010 04:23 AM To: [e-mail], [e-mail] CC:
> [e-mail] Subject: Re: [Syslog] AD review discuss/comments for
> draft-ietf-syslog-dtls   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).  Best regards, Pasi   ________________________________________ From:
> [e-mail] [[e-mail]] On Behalf Of ext Sean Turner
> [[e-mail]] Sent: Saturday, May 22, 2010 6:16 PM To: t.petch Cc: syslog
> Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls
> t.petch wrote: > 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.  Tom,  My response to Alexey was that this I-D borrows that
> particular requirement from RFC4347 and that this I-D shouldn't be upping the
> requirement. If it's okay with you, I'll forward him your response. The way I
> read his comment was that he's just asking why - he's not really requesting a
> change.  spt _______________________________________________ Syslog mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/syslog
> _______________________________________________ Syslog mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/syslog
>
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/syslog
>