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

From: "Tim Evens" <[email-masked]>
Date: Tue, 25 May 2010 10:14:40 -0400

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: [email-masked]: 05/25/2010 02:45 AMTo: [email-masked], [email-masked], [email-masked]: [email-masked]: 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 [[email-masked]] Sent: Monday, May 24, 2010 7:34 PM To: [email-masked]; [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki) Cc: [email-masked] 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: [email-masked] Date: 05/24/2010 04:23 AM To: [email-masked], [email-masked] CC: [email-masked] 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: [email-masked] [[email-masked]] On Behalf Of ext Sean Turner [[email-masked]] 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 [email-masked] https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email-masked] https://www.ietf.org/mailman/listinfo/syslog

---

From: "t.petch" <[email-masked]>
Date: Tue, 25 May 2010 20:35:24 +0200

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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: [email-masked]: 05/25/2010 02:45 AMTo:
[email-masked], [email-masked], [email-masked]:
[email-masked]: 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 [[email-masked]] Sent: Monday, May 24, 2010 7:34 PM To:
[email-masked]; [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki) Cc:
[email-masked] 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: [email-masked] Date:
05/24/2010 04:23 AM To: [email-masked], [email-masked] CC:
[email-masked] 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:
[email-masked] [[email-masked]] On Behalf Of ext Sean Turner
[[email-masked]] 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
[email-masked] https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________ Syslog mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/syslog

---

From: <[email-masked]>
Date: Wed, 26 May 2010 08:03:01 +0200

Tim Evens wrote:
> 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."

AFAIK when running DTLS over UDP, "datagram" here refers to UDP
datagrams, not IP packets (and one UDP datagram can be split
to several IP packets).

Best regards,
Pasi

---

From: Tim Evens <[email-masked]>
Date: Tue, 25 May 2010 23:16:55 -0700

Interesting because RFC4347 IMHO states clearly that IP fragmentation  
(IP not UDP) must be avoided and thus dtls must determine the MTU.

** Sent from my tiny phone keyboard **

---

From: <[email-masked]>
Date: Wed, 26 May 2010 08:23:41 +0200

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.

Best regards,
Pasi
________________________________________
From: ext Tim Evens [[email-masked]]
Sent: Wednesday, May 26, 2010 9:16 AM
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 26 May 2010 08:13:32 -0700 (PDT)

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:

> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog
>