Hi Tom,

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?

Thanks,
Chris


Tom Petch

----- Original Message -----
From: "Chris Lonvick" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Thursday, July 30, 2009 4:50 PM
Subject: [Syslog] syslog WG meeting minutes (proposed)


Hi Folks,

Here are the meeting minutes that I took.  Please send back edits if you
want anything changed.

===
Meeting was started, blue sheets passed around, no one in jabber room
other than the people in the room.

Chairs went through the slides.

Q about syslog/BEEP on slide 10: We're not proposing to standardize this;
it's already RFC 3195.  Since the uptake on implementation (of this RFC,
and of BEEP overall) is low, then the WG should consider moving the RFC to
HISTORIC.

Jurgen S. gave a review of his thoughts on the proposed new charter items:
Slide 8,
  MIB, OK
  DHCP, has some operational value
  don't need an architectural reference to be done in the IETF
Slide 9
  might be interesting to have a guideline but not sure who would commit
the time to do that
  DTLS, should be done and aligned with RFC 5425 (syslog/tls)
  syslog/tcp, should be very straightforward and easy to do
  syslog/BEEP, declare HISTORIC

Dan R. - Since syslog WG is proposing to do syslog/DTLS is there enough
commonality so that ISMS/DTLS and IPFIX/DTLS can re-use?
  - Consensus was that this was likely.  David also noted that the others
are also doing SCTP.

Pasi E. - syslog/DTLS should be easy since it will draw directly from
syslog/TLS.
  - IPFIX also working on Dead Peer Detection (DTLS Heartbeet), we should
likely support this as well.
  - There were problems with the previous IPFIX/DTLS but that was because
of bad libraries in OpenSSL which have since been fixed.

Wes H. - there is not that much commonality between the schemes because of
a lot of useage details.

Chris and David have asked Joe Saloway to act as WG editor for the DTLS
work.

Meeting adjurned at 10am.

===

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


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

Reply via email to