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

From: "Tim Evens" <[email-masked]>
Date: Tue, 11 May 2010 18:20:40 -0400

See inline marked <tievens>-----Original Message-----From: "tom.petch" [[email-masked]]Date: 05/08/2010 12:17 PMTo: [email-masked], [email-masked], [email-masked], "Tim Evens" CC: [email-masked]: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls---- Original Message ----- From: "Tim Evens" <[email-masked]>; Sent: Wednesday, May 05, 2010 10:02 PM   Hopefully this isn't too late for a review comment...It appears to me that DTLS as a SYSLOG-MSG transport introduces a new variable that isn't present with traditional TCP and UDP based transports with regards to SYSLOG-MSG fragments.  IP/UDP transport allows for IPv4 based fragmentation, even though it should be avoided for several reasons, there could be useful and valid application uses for fragmenting UDP packets.  <tp>  True, but RFC5426 says  "It is RECOMMENDED that syslog senders restrict message sizes such    that IP datagrams do not exceed the smallest MTU of the network in    use.  This avoids datagram fragmentation and possible issues    surrounding fragmentation such as incorrect MTU discovery.     Fragmentation can be undesirable because it increases the risk of the    message being lost due to loss of just one datagram fragment.  Syslog    has no acknowledgement facility, and therefore there is no effective    way to handle retransmission.  This makes it impossible for syslog to    utilize packetization layer path MTU discovery [9].  When network MTU    is not known in advance, the safest assumption is to restrict    messages to 480 octets for IPv4 and 1180 octets for IPv6."  so my take has always been, forget fragmentation, or use TCP.  I would apply that to a DTLS mapping. <tievens>The problem persists in that logging from within 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.   I suppose it might be out of scope for this draft with regards for how the transport implementer handles a message that meets RFC5424, but cannot fit within the constraints of UDP/DTLS packet size limitations. In section 5.4.1 it states that "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." If a single syslog message can't span multiple DTLS records and if DTLS doesn't support packet level fragmentation, then the message size will always be less than MTU + transport overhead.  Am I reading that correctly? If that's correct, a method will need to be defined and implemented in order to handle the truncation of the valid RFC5424 message when transporting it over UDP/DTLS.  </tievens> Tom Petch </tp>  IP/TCP as a transport supports message segments that can span multiple packets. Per RFC4347 section 4.1.1, "each DTLS record MUST fit within a single datagram." DTLS introduces a sequence_number field to the record layer, which facilitates reassembly providing the receiving station queues and reorders. In this draft, section 5.1 suggests that it's optional for the implementer to adopt a queue mechanism to resolve reordering. Later in section 5.4 it suggests that a single SYSLOG-MSG can be transferred in multiple DTLS records.  If it is optional to implement DTLS sequence numbers, how does the originator of the SYSLOG-MSG know that the collector will not reorder messages? If the originator knows that the collector will not reorder DTLS fragments, then it can truncate messages prior to transmission. In lieu of truncation, the originator could generate multiple SYSLOG-MSG's using structured data that enables the collector to piece them together.  There doesn't appear to be a SYSLOG-FRAME ID as part of each DTLS application-data record. If a message of say 1400 bytes is sent in 3 packets/DTLS records, and if packet 2 of the 3 was dropped by the network, how does the collector know that those packets were to be concatenated as a single SYSLOG-MSG? Without a SYSLOG-FRAME identifier, the collector would have to assume invalid based on messages not structured per RFC5424. Also, if there is no frame ID and sequence reordering isn't implemented, a out-of-sequence DTLS record could possibly inadvertently be prepended or appended to the wrong message, causing a valid message to be corrupt. It seems this would be moot if when using DTLS a SYSLOG-MSG must not span multiple DTLS records. Thanks,Tim -----Original Message-----From: "Chris Lonvick" [[email-masked]]Date: 05/03/2010 06:49 AM To: "tom.petch" , "Joe Salowey" , "Sean Turner" CC: [email-masked] Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls Hi,  I'm good with that as well.  Joe, can you edit and resubmit a new ID?  Sean, if this covers all of your edits, when can we expect to see it on  the IESG agenda, and when can we see IETF LC? Thanks, Chris  On Tue, 27 Apr 2010, tom.petch wrote:

---

From: "t.petch" <[email-masked]>
Date: Fri, 21 May 2010 18:37:52 +0200

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 Petch

---

From: "Rainer Gerhards" <[email-masked]>
Date: Sat, 22 May 2010 13:36:50 +0200

Hi all,

sorry I was offline a long time for good, but not to mention here, reason. I
will unfortunately be very partly available in the next few days. But I would
at least like to back Tom's argument. Bit first let me admit that I could not
follow the whole discussion, so I may have missed a point that actually
demands a MUST. Out of the context of Tom's posting, I don't think so.

In practice, there are some applications that require more than 16KB within a
single message, namely IHE and maybe some other applications that log
application-data rather than system management data. In RFC5424, we thought
we have a good compromise by specifying a not-too-large to be supported size
but did not set an upper limit. This was done in the spirit that transports
should not impose any limits except if absolutely necessary.

So if dtls can work with 64K (and my understanding is it can), we should
permit it to use this max size. If that comes, for example, at the cost of
fragmentation and potential message loss, so be it for those applications
that need this functionality. After all, folks have been warnend (RFC5424),
but we should not limit those in need AND ready to accept the extra risk.

Speaking as an implementer, I know for sure that if some large-enough
customer approaches us to support 64K messages, we will definitely do that,
if it is possible. I guess the same is true for other implementers. If the
customer needs it and wants to pay for it, one will implement it -- then as a
private extension of the standard. So looking at the real world, removing
that ability from the standard will not result in removing the capability.
The only thing that it will potentially remove is interoperability of
different implementations that do it anyways...

My 2cts, and once again my apologies for not being able to follow more
timely.

Rainer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of t.petch
> Sent: Friday, May 21, 2010 6:38 PM
> To: [email-masked]; Chris Lonvick
> Cc: syslog
> Subject: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog

---

From: Sean Turner <[email-masked]>
Date: Sat, 22 May 2010 11:16:20 -0400

> 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

---

From: <[email-masked]>
Date: Mon, 24 May 2010 09:54:01 +0200

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

Tom,

spt

---

From: [email-masked]
Date: Mon, 24 May 2010 10:13:23 -0400

> really requesting a change.
 
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.

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: "t.petch" <[email-masked]>
Date: Mon, 24 May 2010 18:35:40 +0200

----- Original Message -----
From: "Sean Turner" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Chris Lonvick" <[email-masked]>; "syslog"
<[email-masked]>
Sent: Saturday, May 22, 2010 5:16 PM
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls

> really requesting a change.

Sean

Right, but after Alexey's comment there was one from Joe saying "let's make this
change it seems reasonable", so my reaction was, no, this is not reasonable!

We may want to tinker with the text, but a "MUST NOT exceed 2**14" I see as
going too far.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Tue, 25 May 2010 11:31:07 +0200

---- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 24, 2010 9:54 AM

comes from TLS).

<tp>
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.

Tom Petch

</tp>

One DTLS record must fit in one UDP datagram, but one
UDP datagram can contain more than one DTLS record.

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

Tom,

spt
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog=

---

From: <[email-masked]>
Date: Tue, 25 May 2010 12:53:42 +0200

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.

Best regards,
Pasi

________________________________________
From: ext t.petch [[email-masked]]
Sent: Tuesday, May 25, 2010 12:31 PM
To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
Cc: [email-masked]
Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dtls

---- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 24, 2010 9:54 AM

<tp>
Where?:-)

Tom Petch

</tp>

Best regards,
Pasi

Tom,

spt

---

From: "t.petch" <[email-masked]>
Date: Tue, 25 May 2010 14:19:17 +0200

Another outstanding issue is the question of NULL options in the
ciphersuites with Tim Polk suggesting something along the lines of

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.

The justification is that
"disclosure is one of the primary threats described in Section 4,"

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.

In passing, there was a request for a reference for the ciphersuite,
which could be covered by adding
'as specified there' after 'cipher suite'.

Tom Petch