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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-630072926-1274886812=:24171
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi,

Tim - I just rejected your latest post (it got to be way to large when you=
=20
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=
=20
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 =3DA0.
>
> If I edit =3DA0 to =3D0A, then hard breaks appear where I expect them.
>
> Curious.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Tim Evens" <[email protected]>
> To: <[email protected]>; <[email protected]>; <[email protected]>
> Cc: <[email protected]>
> Sent: Tuesday, May 25, 2010 4:14 PM
> Subject: RE: [Syslog] AD review discuss/comments for draft-ietf-syslog-dt=
ls
>
>
> Correct, in RFC5426 the max size is 64K which is the max length in UDP. U=
DP
> 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 reco=
rd MUST
> fit within a single datagram. In order to avoid IP fragmentation [MOGUL],=
 DTLS
> implementations SHOULD determine the MTU and send records smaller than th=
e MTU.
> DTLS implementations SHOULD provide a way for applications to determine t=
he
> value of the PMTU (or, alternately, the maximum application datagram size=
, which
> is the PMTU minus the DTLS per-record overhead). If the application attem=
pts to
> send a record larger than the MTU, the DTLS implementation SHOULD generat=
e an
> error, thus avoiding sending a packet which will be fragmented."While UDP
> supports message sizes in excess of 1500 bytes, the implementation as def=
ined 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 suppor=
t
> message sizes larger than the MTU considering these restrictions? Few lay=
er 2
> implementations support MTU sizes greater than 9K. Even with GigabitEther=
net
> 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 su=
pport a
> maximum of 2K frame MTU, while Gig and TenGig support 9K. -----Original
> Message-----From: [email protected]: 05/25/2010 02:45 AMTo:
> [email protected], [email protected], [email protected]:
> [email protected]: RE: [Syslog] AD review discuss/comments for
> draft-ietf-syslog-dtls         I would prefer to keep syslog-over-DTLS-ov=
er-UDP
> as similar to RFC 5246 (syslog-over-UDP) as possible -- i.e. don't add an=
y 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 j=
ust not
> very efficient if your MTU is small (and you need IP layer fragmentation)=
=2E  But
> for administrators that know they'll need efficient transport of large me=
ssages,
> we already  have a solution: RFC 5425.  Best regards, Pasi    From: ext T=
im
> Evens [[email protected]] Sent: Monday, May 24, 2010 7:34 PM To:
> [email protected]; [email protected]; Eronen Pasi (Nokia-NRC/Helsinki) C=
c:
> [email protected] Subject: Re: [Syslog] AD review discuss/comments for
> draft-ietf-syslog-dtls     Right. I wrote the following a couple weeks ba=
ck:
> "=E2=80=A6 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=
=2E It
> would be more meaningful if the application writing the message controls =
the
> truncation or if the transport application sending the message onto the n=
etwork
> can correctly break up the message  into parts to fit the transport messa=
ge size
> limitations. RFC5424 doesn't detail SD elements or methods for splitting
> messages. Transports have size constraints and will require messages to b=
e
> truncated or split. For example, the CISCO-SYSLOG-MIB defines  that a mes=
sage
> 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 h=
ave to
> do with the transportation of the message on the network.    In my opinio=
n, 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 sy=
slog
> receivers/collectors may require  different transports. One may use UDP/D=
TLS
> while the other uses TCP. Therefore, the original syslog message of say 1=
480
> bytes may be written to the network twice, one using UDP/DTLS and the oth=
er
> 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 d=
efined
> 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. Clien=
t
> message boundaries are not preserved in the record layer (i.e., multiple =
client
> messages of the same ContentType MAY be coalesced into a single TLSPlaint=
ext
> 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 delive=
ry,
> whereas RFC4347 (DTLS) can use UDP which does not provide ordered deliver=
y. DTLS
> introduces a sequence  number field in the record structure, which if
> implemented for reordering, the receiver could reorder the DTLS records s=
o 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 "=E2=80=A6 it may not assure that a=
ll the messages
> are delivered in order when mapping on the UDP transport."   The reason i=
s that
> with TCP there is a retransmission for lost segments, whereas UDP does no=
t
> implement retransmissions. Therefore, if a DTLS sequence is dropped/lost =
or not
> received within the allotted queue buffer time, the DTLS application does=
n't
> have anyway of knowing if seq X1 and seq X3 can be correctly put together=
=2E 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 f=
it
> within a single DTLS  record. Thus the SYSLOG-MSG will in most cases alwa=
ys be
> less than 1460 bytes due to MTU DTLS/MTU limitations. The application SHO=
ULD NOT
> assume that using the RFC5424 recommended minimum of 480 octets is suffic=
ient 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 fo=
r the
> DTLS implementation to know which DTLS records need to be discarded in th=
e event
> of packet loss.    For example:   FRAME-ID =3D NILVALUE / ("+" / "-")
> NONZERO-DIGIT 1*15DIGIT; uint48*   +/- is used to indicate more message b=
locks
> to come or not. "+" indicates more to follow, "-" indicates last block.  =
 Use
> NILVALUE if SYSLOG-MSG is not split across multiple DTLS records, otherwi=
se 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 co=
uld be
> 6OCTET=3Duint48, which would reduce the overall size.   Example Use:   DT=
LS seq
> 1 - SYSLOG-FRAME-ID=3D+1001 <SYSLOG-MSG> DTLS seq 2 - SYSLOG-FRAME-ID=3D+=
1001
> <SYSLOG-MSG> --> dropped by network --> DTLS seq 3 - SYSLOG-FRAME-ID=3D+1=
001
> <SYSLOG-MSG> DTLS seq 4 - SYSLOG-FRAME-ID=3D-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 implementat=
ion
> would have been holding DTLS seq 1, 2, and 4 waiting for 3. When it recei=
ved 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 protected] D=
ate:
> 05/24/2010 04:23 AM To: [email protected], [email protected] CC:
> [email protected] Subject: Re: [Syslog] AD review discuss/comments for
> draft-ietf-syslog-dtls   I haven't followed this discussion in detail, bu=
t it
> looks like there's some confusion about the basic "units" of transmission=
=2E 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  A=
s noted
> in Section 5.4, "It is possible that multiple syslog messages be containe=
d 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 l=
imit
> comes from TLS). One DTLS record must fit in one UDP datagram, but one UD=
P
> 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, a=
ll
> those records have to be in a single UDP datagram (so the syslog layer do=
es not
> reassemble syslog message pieces from multiple UDP datagrams -- SYSLOG-FR=
AME
> 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 recomme=
ndation
> 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 fr=
om
> DTLS).  Best regards, Pasi   ________________________________________ Fro=
m:
> [email protected] [[email protected]] On Behalf Of ext Sean T=
urner
> [[email protected]] Sent: Saturday, May 22, 2010 6:16 PM To: t.petch Cc: s=
yslog
> Subject: Re: [Syslog] AD review discuss/comments for draft-ietf-syslog-dt=
ls
> t.petch wrote: > I see that this I-D had entered 'Revised I-D needed' whi=
ch 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 requi=
rment,
> 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 bala=
nce
> 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 tha=
t
> 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 w=
ay I
> read his comment was that he's just asking why - he's not really requesti=
ng a
> change.  spt _______________________________________________ Syslog maili=
ng list
> [email protected] https://www.ietf.org/mailman/listinfo/syslog
> _______________________________________________ Syslog mailing list
> [email protected] https://www.ietf.org/mailman/listinfo/syslog
>
> _______________________________________________
> Syslog mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/syslog
>
---559023410-630072926-1274886812=:24171
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog

---559023410-630072926-1274886812=:24171--