Early Review of draft-ietf-trill-channel-tunnel-07
review-ietf-trill-channel-tunnel-07-secdir-early-sheffer-2015-09-03-00

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.