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