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

["t.petch" <[e-mail]>]

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