Hi,
I quickly looked at the two documents for differences.
I found a few I thought might deserve discussion:
-- DoS --
syslog:
Implementations MUST support
the denial of service countermeasures defined by DTLS. When these
countermeasures are enabled, the transport receiver responds with a
DTLS Hello Verify Request containing a cookie.
snmp:
DTLS Transport
Model server implementations MUST support DTLS cookies.
Implementations are not required to perform the stateless
cookie
exchange for every DTLS handshake, but in environments where an
overload on server side resources is detectable by the
implementation it is RECOMMENDED that the cookie exchange is
utilized by the implementation.
My impression is that syslog allows an admin to enable this as a
deployment option; tlstm seems to depend on the implementation. (and I
have difficulty knowing how an implementation will know if overlaod on
server side is detectable, unless it is doing the detection itself.)
1) Is enable/disable capability a MUST implement for DTLS cookie
exchange?
2) Should tlstm recognize whether it is enabled/disabled?
3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in
syslog when the implementation can detect an overload on server
resources?
4) in syslog, would it be better to specify the actions of the DTLS
entity rather than "the transport receiver"? Does the draft spell out
clearly whether the "transport receiver" is the DTLS client or DTLS
server? When a syslog entity can act as both sender and receiver, what
is that implementation REQUIRED to support in terms of DTLS client and
DTLS server? I didn't see that in the text prior to section 5.3.1;
should this be made clear in the terminology section? Should there be
mandatory-to-implement text about this?
-- DCCP --
syslog/dtls supports the dccp transport:
As the Internet best runs on the basis of appropriate resource
sharing, SYSLOG over DTLS over DCCP [RFC5238] is defined in this
document. For systems where DCCP is either not available or not
usable (such as the afformentioned situation), DTLS over UDP is
also
defined. In those circumstances where reliability or ordering is
important, SYSLOG over TLS is appropriate. Syslog over TLS does
not
provide application layer acknowledgements and therefore is not a
fully reliable solution.
and
DTLS can run over multiple transports. Implementations of this
specification MUST support DTLS over UDP and SHOULD support DTLS
over
DCCP [RFC5238].
and
When TCP is used syslog over DTLS MUST NOT be used. If a secure
transport is required with TCP then the appropriate mechanism is
syslog over TLS.
although we are discussing:
Based on some advice from Lars, I recommend
s/Implementations of this specification MUST support DTLS over UDP and
SHOULD support DTLS over DCCP [RFC5238]. /
Implementations of this specification MUST support both DTLS over UDP
and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but
implementations of this specification MUST be prepared to support DCCP
where it is available."
I notice DCCP is not mentioned by TLSTM.
I'm not sure how much extra work it would take to add DCCP support to
snmp/dtls.
-- ports --
Since DTLS can run over DCCP, tlstm might want to define a domain for
that while you're at it (or not).
-- cipher suites --
syslog:
Implementations MUST support DTLS 1.1 [RFC4347] and MUST support
the
mandatory to implement cipher suite, which is
TLS_RSA_WITH_AES_128_CBC_SHA.
tsltm:
does not define a mandatory-to-implement cipher suite.
Could this impact interoperability? I know this is one of those points
that keeps getting discussed.
1) A mandatory-to-implement cipher suite ensures that different
implementations will have at least one suite that cna be used for
interoperability.
2) But doesn't DTLS already define mandatory-to-implement cipher
suites? Do we need to do that here as well? Isn't it inherited from
DTLS?
How's this for a discussion starter?
David Harrington
[email protected]
[email protected]
[email protected]
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
