On Wed, 3 Feb 2010 16:37:38 -0500 David wrote: DH> syslog: DH> Implementations MUST support DH> the denial of service countermeasures defined by DTLS. When these DH> countermeasures are enabled, the transport receiver responds with a DH> DTLS Hello Verify Request containing a cookie. DH> snmp: DH> DTLS Transport DH> Model server implementations MUST support DTLS cookies. DH> DH> Implementations are not required to perform the stateless DH> cookie DH> exchange for every DTLS handshake, but in environments where an DH> overload on server side resources is detectable by the DH> implementation it is RECOMMENDED that the cookie exchange is DH> utilized by the implementation. DH> DH> My impression is that syslog allows an admin to enable this as a DH> deployment option; tlstm seems to depend on the implementation.
Hmm... DTLS says that cookies MUST be supported, so it seems like simply mentioning that admins can enabled it, as opposed to only RECOMMENDING it under special circumstances, would bring the two in line. DH> 1) Is enable/disable capability a MUST implement for DTLS cookie DH> exchange? Does syslog have this MUST, or simply a mention of 'when it is enabled' implying it is configurable? I agree that parity would be good, and it would be nice for it to be configurable. DH> Since DTLS can run over DCCP, tlstm might want to define a domain for DH> that while you're at it (or not). Couldn't hurt to add a domain and say implementations MAY support DCCP, but I don't think it's worth it if it's going to hold up the document. DH> Could this impact interoperability? I know this is one of those points DH> that keeps getting discussed. DH> 1) A mandatory-to-implement cipher suite ensures that different DH> implementations will have at least one suite that cna be used for DH> interoperability. DH> 2) But doesn't DTLS already define mandatory-to-implement cipher DH> suites? Do we need to do that here as well? Isn't it inherited from DH> DTLS? I vote for 2, that we inherit from DTLS... -- Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions)
signature.asc
Description: PGP signature
_______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
