I thankfully have now also been able to review the document. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of tom.petch > Sent: Tuesday, October 27, 2009 10:13 AM > To: Joseph Salowey (jsalowey); [email protected] > Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt > > Good stuff.
full ack! > Ports; I like the idea of a common port, because it makes operational > deployment (eg filtering in Middle boxes) so much simpler and less > error prone. I agree, especially if we intend to prohibit DTLS use over TCP (what I think is a good idea). > DTLS has an updated I-D in Working Group Last Call > draft-ietf-tls-rfc4347-bis > which I think we should reference. It covers DTLS over DCCP properly, > which its predecessor might not be seen to. > > Message size I think needs more coverage. I would include a summary of > the > advice on PMTU discovery in DTLS 4.1.1.1 and specifically mention the > 2**14 > limit on records in DTLS. Earlier discussions on this list showed a > desire for > 2**16 > syslog messages which, to me, implies fragmentation by the transport > sender. This is a hard issue. I think we should review our use case for DTLS. To me, the primary driver behind DTLS in a syslog system is the ability to encrypt messages, while still retaining the ability to send single-frame messages, which may be the only way to convey any information inside a broken network. This is properly described in Section 1. When this is our ultimate goal, we need to preserve that capability. That means we can not permit fragmentation. While I am always an advocate for longer message sizes, I do not think that the reasoning behind that fits in into the DTLS scenario. Larger size messages are almost exclusively seen in audit-like systems (e.g. IHE), much less in network management. RFC5426 defines a lower limit of 480 octets, which is hard, but fact. It then recommends 2K and specifies an upper limit of 64K. I think we should follow that route with a lower limit of 512, recommended 2K (should be well sufficient for management info) and 16K being the upper bound. As of my understanding, that should solve the size limit issue without hurting anyone. The lower limit is higher than in RFC5426, the recommended size is the same, only the upper limit is lower, but still on the save side for management information. As a side-note, it may make sense to spell out - if we agree on that - that DTLS is NOT a transport to be used for auditing purposes. > Dead Peer Detection I would sit on until something more happens with > the > TLS Working Group. sounds reasonable. Rainer Gerhards > > Tom Petch > > ----- Original Message ----- > From: "Joseph Salowey (jsalowey)" <[email protected]> > To: <[email protected]> > Sent: Wednesday, October 14, 2009 10:23 PM > Subject: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt > > > I Just posted a -00 version of the syslog DTLS draft > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-00.txt). I > tried to merge the two proposals together and keep consistent with the > Syslog TLS draft. Below are some issues I have identified, I'm sure > there are others. > > 1. Transport > > DTLS can run over several different transports, right now the draft > requires UDP and recommends DCCP. I think these are the most well > defined. The draft also forbids DTLS over TCP and favors TLS over TCP > to keep things consistent. I left out SCTP, I'm not sure where SCTP > over DTLS is in the process and there also is a TLS option for SCTP. > > 2. Port Number > > DTLS could use the same port and TLS, which seems simple. The > difficulty could be that for some transports you could use either TLS > or > DTLS (SCTP for example). In theory you could tell the difference > between TLS and DTLS by version number so maybe this isn't a problem. > > 3. Initiation > > One of the drafts allowed either side to initiate. I did not include > this. If we have a use case for it we could bring it back in. > > 4. Dead Peer Detection > > There has been a lot of discussion on DPD on the list. I don't have > any > specific remedy in the draft, just a warning that it could be a > problem. > Its likely that some work on this will happen in DTLS, but I'm not > confident on the timeframe at this point. > > 5. Message Size > > The text on message size could use some review. > > Cheers, > > Joe > > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
