Ballot deferred by Mirja Kühlewind on 2018-03-08.
Summary: Needs a YES. Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
DSCP ----- 1) Section 4.3 should also talk about decapsulation as DCSP is often overwritten on the path and therefore the DCSP of the inner and other IP headers can differe on decapsulation. Please see RFC2983 for further guidance. You probabably should specify to discard the outer DSCP at tunnel egress in your use case. 2) Further it is not clear to me if the use of CS7 in appropriate for this use case as RFC 4594 says " o CS7 marked packets SHOULD NOT be sent across peering points. Exchange of control information across peering points SHOULD be done using CS6 DSCP and the Network Control service class." 3) Moreover, if my understanding is correct, the high priority classes in TRILL are not exclusively reserved for control data. However, CS6 and CS7 is only meant for control and rounting traffic. If those classes are used it must be ensure that the traffic send with these DSCP is not overloading the network. I think further (security) considertations are needed here. Broadcast Link Encapsulation Considerations ------ Not every transport encapsualtion can be used for Broadcast/Multicast. TCP cannot be used. This is mention later but also be consider in the text in section 5.3 TCP Encapsulation ----- If my understanding is correct than TRILL does not know that the connect of a TRILL data packet is. That means the data could can also contain traffic that is runing over TCP, right? Encapsulating TCP in TCP should generally avoided if possible and need further considerations as loss in the outer control loop that is used on the TRILL IP link appears as strongly varying delays to the inner control loop and therefore can have very negative effects. TCP Connection Establishment (section 5.6.1) ----- This section seem to assume for all configured or discovered tunnel endpoints there should be immeditately (at node start up time) and permantly a/multiple open TCP connections. I'm in general uncertain if this is the right approach. However, even if the connection is not closed, it might not be usable after an idle time, as middlebox on the path may have removed their state. Therefore to keep a connection permanently the endpoint need probaly to send keep-alives, or alternative a meachism to detect such a failure (quickly) and re-establish the connection such be used. However,
Editorial coments: 1) It is really confusing that the whole document is talking about ports as tunnel endpoints while it also often talks about transport (TCP/UDP) ports. It makes it really hard to read this document. Maybe these things can be better distighlished somehow. 2) This document should not re-specify the UDP header (5.4). At minimum the text should be changed the following way. OLD "Where he UDP Header is as follows:" NEW "Where he UDP Header is as follows as specified in [RFC0768] :"
Balloting NoObj in the "I've read the protocol action, and I trust the sponsoring AD so have no problem." sense of the term.
Based on my conversation with DEE, I understand that the HMAC is always computed over a value which is disjoint with the HKDF-Label. This is not really cryptographically ideal -- as I stated in my review, you should be HKDFing two keys off the same key -- but it does imply that the trivial attack doesn't work, so I'm removing my DISCUSS. As we discussed, please add some explanation of why this is a non-issue to the document.