Hi, To clarify a point ... syslog/tls is not simply RECOMMENDED; it is MANDATORY TO IMPLEMENT.
syslog/dtls will be an optional transport; we do not need to RECOMMEND it. Implementers can decide for themselves whether to implement it. I agree that the IESG may not approve it with congestion control considerations. dbh > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of tom.petch > Sent: Wednesday, August 05, 2009 5:32 PM > To: Chris Lonvick > Cc: syslog; [email protected] > Subject: Re: [Syslog] Matters arising was: Re: syslog WG > meeting minutes(proposed) > > ----- Original Message ----- > From: "Chris Lonvick" <[email protected]> > To: "tom.petch" <[email protected]> > Cc: "syslog" <[email protected]>; <[email protected]> > Sent: Monday, August 03, 2009 3:52 PM > > > On Mon, 3 Aug 2009, tom.petch wrote: > > > > > Picking up on the point of commonality between DTLS for > IPFIX, ISMS and > syslog: > > > > > > - having a common statement of how to check certificates > would save work > here > > > and elsewhere ie get > draft-hodges-server-ident-check-00.txt to include as a > > > minimum the cases covered in syslog-tls and get that I-D > progressing onto > > > standards track so as to use it as a normative reference > (can we steal it > from > > > apps into security:-). > > > > Sounds good. > > > > > > > > - syslog has tls as RECOMMENDED transport at the > insistence of the IESG > because > > > it has flow control and the others do not. DTLS over UDP > has no flow > control > > > and so, by analogy, I would expect it to be unacceptable > to the IESG ie it > will > > > have to be DTLS over SCTP that will have to be there as > well or instead > > > (something I did not think of in 2006). > > > > I'm not that familiar with DTLS. Can we just specify how > to put syslog > > over it, or do we need to also state how it is to be layered above a > > substrate tranport such as sctp? My preference would be to > just define > > syslog/dtls and then have a pointer back to RFC 5424 > (syslog Protocol) > > Section 8.6. (Congestion Control) which spells out the > reason for choosing > > properly. I'm really hoping that we don't have to create a > document for > > anything other than syslog/dtls. > > > > > - having written a DTLS I-D (and looked at many more), I > am inclined to > agree > > > with Wes that there will not be much in common (apart > from certificate > > > checking - see above) > > > > If we _can_ just do XYZ/dtls (without having to go through the lower > > substrate definition) then the pieces of work are (imho): > > - state how the specification addresses the threats identified in > > syslog/tls, > > - explain certificate checking (as you note above) > > - explain how records will be separated. > > > > Can anyone think of anything else that needs to be defined > in this work? > > > > Tom, can a document just do XYZ/dtls, or does it also _really_ need > > definition for the substrate? > > I can write such a document, but will the IESG accept it? I > don't know; I was > surprised at Magnus's DISCUSS two years ago on > syslog-protocol that led us to > RECOMMEND a TLS transport, as opposed to UDP, on the grounds that it > offered congestion control and I doubt that concerns about > congestion have > decreased since then. > > So I am anticipating that syslog over DTLS with no mention of > underlying > transport cannot be RECOMMENDED; perhaps a question for our > AD to ponder, and > bounce off his transport area opposite numbers. > > As to other points, my list, of what xxx-over-DTLS must consider is > - authentication > - connection set up > - connection termination > - choice of ciphersuite > - choice of (D)TLS extensions > - delineation of datagrams > - invoking DTLS > - fragmentation > and nowadays I must add > - congestion control. > > Tom Petch > > > Thanks, > > Chris > > > > > > > > Tom Petch > <snip> > > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
