Summary: Needs a YES. Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Usage of encapsulation schemes ---- The document does not clearly explain and justify why different encapsulations are needed. The document should more extensively discuss the different properties and trade-offs for each encapsulation and give clear recommendations when you to use which encapsulation. E.g. the document does not clearly specify when to use IPSec (besides saying „if security in needed“), however, the document needs to explain more clearly what is meant by this: given the over-the-Internet path is always not trusted, does that mean that IPSec should always be used in that scenario? Why is IPSec specified instead of using TLS or DTLS with the TCP or UDP encapsulations respectively? Why is both UDP and TCP encapsulation needed, given that UDP is the default that is mandatory to implement anyway? Why are the short-comings of UDP and when is it recommended/beneficial to switch to TCP? 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 differ on decapsulation. Please see RFC2983 for further guidance. You probably 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) considerations are needed here. Broadcast Link Encapsulation Considerations ------ Not every transport encapsulation 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 running 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 should immediately (at node start up time) and permanently open one/multiple 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 open, the endpoint need probably to send keep-alives, or alternative a mechanism to detect such a failure (quickly) and re-establish the connection such be used. Alternative, a connection could be open and closed when needed. In this case also more recommendation is needed when to open and close the connection(s). Fragmentation ---- The fragmentation problem for Internet links is not sufficiently addressed. trill requires a minimum size of 1,470 bytes while most Internet paths only support an MTU of 1,470 bytes which will automatically lead to fragmentation when encapsulation is added. It can not be assumed that all Internet path support IPv6, therefore the recommendation "if fragmentation is anticipated with the encapsulations specified in this document, the use of IPv6 is RECOMMENDED" is often hard to realize. I assume that many trill IS-IS packets are smaller than 1,470 bytes thus fragmentation might not occur, however, for larger packets I would rather recommend to implement an additional mechanism to enable segmentation above UDP (+ PMTU discovery) or the use of TCP. In any case more clear recommendation is needed. Port assignment ---- Only one port per service can be assigned (see principles in rfc6335 and guidelines in rfc7605). Therefore the spec should be changed to the use of one ports and describe how different kinds of packets can be distinguished by other means (which should be easily possible to my understanding). Further, it is expected that the document confirms that any new security added later on will also use the port assigned (i.e., future versions will not be eligible for new ports e.g. for a “TLS” variant).
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] :"
This draft has received significant attention from the transport area while I was recovering from pneumonia, so I'm balloting No Objection while noting a couple of things that I'm confused about, that I haven't seen mentioned previously, and trusting people to Do The Right Thing. Otherwise, I'll sit with my hands folded quietly, and watch the Discussion on Mirja's ballot position with interest. I have (at a Comment level) the same curiosity that Mirja included in her Discuss ballot about why both UDP and TCP encapsulations are included. My curiosity extends to whether NAT traversal being out of scope for this document makes sense, given that one of the use cases given is 3.1 Remote Office Scenario In the Remote Office Scenario, as shown in the example below, a remote TRILL network is connected to a TRILL campus across a multihop IP network, such as the public Internet. If NAT traversal were in scope, offering both TCP and UDP encapsulations would make more sense - TCP and UDP are treated differently enough at NATs and firewalls that HTTP/2 over QUIC/UDP uses HTTP/2 over TCP as its fallback. But it might be worth thinking about what would be required to make this work well over the public Internet. That doesn't have to be in this document, of course. I see that Mirja has asked about the request to allocate two port numbers in this draft, one for TRILL IS-IS, and the other for TRILL Data. I'm reading this text The Link Header and Link Trailer in these formats depend on the specific link technology. The Link Header contains one or more fields that distinguish TRILL Data from TRILL IS-IS. For example, over Ethernet, the Link Header for TRILL Data ends with the TRILL Ethertype while the Link Header for TRILL IS-IS ends with the L2-IS- IS Ethertype; on the other hand, over PPP, there are no Ethertypes in the Link Header but different PPP protocol code points are included that distinguish TRILL Data from TRILL IS-IS. as saying that those two types of packets could be distinguished, if they were carried over a single five-tuple. I'd offer that the conversation about allocating two port numbers would terminate more quickly if you could explain whether I'm misreading that text, so that you really can't distinguish between these two packet types, or whether there is some other reason why you'd want to avoid fate-sharing between these two packet types that seem to make up an adjacency.
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.