This is an early security review, written at the request of the TRILL WG. The document defines a way to tunnel arbitrary frames of related control protocols within the TRILL "channel". Most of the document (and the focus of this review) is about security this tunnel. Summary I believe the draft is not ready for IETF LC in its current form. I assume the original intention was to use DTLS, but the use of DTLS is not well specified and the alternative that's proposed for multicast comes with inferior security. Details • In general, I don't understand why it makes sense to define a whole new security protocol, just for control-plane traffic of one specific protocol, important as it may be. At the very least I would expect an analysis of potential alternatives (IPsec? MACsec?) and why they do not fit this use case. • As a result of the home-brew transport protocol, we also don't get a standard key management protocol. • And from a process POV, the TRILL WG may not be the best place, as far as participants' expertise, to develop a security protocol. An early SecDir review certainly helps, but I'm not sure the current reviewer is capable of detecting every last issue that might be lurking in the protocol. • 4.1: the A and E bits are not guaranteed to be correct? Then why are they here? They describe critical security properties, and therefore someone is bound to use them to make critical policy decisions. If the bits' semantics are not guaranteed, we'd better drop them. • A bit: I think we are confusing authentication with integrity protection. With opportunistic security, you usually don't have authentication, but integrity protection is still worthwhile. • 4.2: Coverage - it would be nice if Fig. 2.1 showed the coverage of authentication (integrity protection!) and encryption. Why is an Ethernet frame's FCS not covered by integrity protection? Is there any non-malicious reason someone would want to modify the FCS in transit? • 4.3: "in some cases" - why not simply say, "When SType is 1 or 3"? • 4.3: why deconstruct HKDF and use HKDF-Expand instead of simply using the whole thing, including HKDF-Extract? • I am confused about 4.1 vs. 4.5, and specifically, what does the Size byte cover. I think this is incorrect in 4.5. • 4.6: this section starts with certificates (presumably, both client and server should authenticate with a cert) and then moves on to PSK. Are both allowed? • 4.6: TLS is rapidly moving toward perfect-forward secrecy. Why require a cipher suite that's being deprecated across all of industry (TLS_RSA_WITH_AES_128_CBC_SHA256)? • 4.6.: I am still unclear on how CT keys are derived from DTLS. • 4.6: Why have a TRILL-level key ID with DTLS-PSK has the notion of key ID? • 4.6: with certificates the frames may be very large. Does the protocol support such sizes? • 4.6: there should be a lot more text about how DTLS is used to wrap L2 frames. • 4.7: if this mode is assumed for multicast, what is the assumed/recommended mode for unicast? • Obviously integrity protection where the MAC key is shared with all peers is very weak. There are various ways to deal with that, starting with RSA signatures but including more efficient methods (TESLA comes to mind). Have you considered any of them? • 4.7.1: if the authentication data is variable length, you must ensure that the field that indicates its size is integrity-protected as well. • Actually, I'm not sure where this size is indicated. • It seems to me that a fully random 128-bit nonce would be both simpler to implement and more secure than the scheme proposed here. • Typo: designed -> designated. • 5: assuming we will have DTLS handshakes nested within CT, how are errors indicated? • General: is there any facility for replay protection? If no, why not? • 7: The more normative parts of the Security Considerations would probably fit nicely into a separate Applicability section. • 7: I think the document should be much more clear (normative) about what message types are allowed within the tunnel, or not. And possibly about required filtering by address.