Early Review of draft-ietf-trill-channel-tunnel-07

Request Review of draft-ietf-trill-channel-tunnel
Requested rev. no specific revision (document currently at 11)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2016-07-21
Requested 2015-08-20
Draft last updated 2015-09-03
Completed reviews Genart Last Call review of -09 by Peter Yee (diff)
Genart Last Call review of -09 by Peter Yee (diff)
Genart Last Call review of -10 by Peter Yee (diff)
Secdir Early review of -07 by Yaron Sheffer (diff)
Secdir Last Call review of -09 by Yaron Sheffer (diff)
Opsdir Early review of -07 by Ron Bonica (diff)
Rtgdir Early review of -07 by Jonathan Hardwick (diff)



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.


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.


• 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 


• 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 


• 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.