Reviewer: Brian Trammell Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. This document redefines that BGP Tunnel Encapsulation attribute to address issues with the original definition in RFC 5512, including deployability and fundamental operational incompatibility with certain kinds of tunnels. This review is not comprehensive potential issues with the expanded semantics of tunnel encapsulation TLVs which may give a malicious BGP speaker the ability to cause unwanted behavior on the data plane managed by another speaker -- I have no particular reason to suspect problems here (BGP's threat model is simplified by the fact that the configuration concerns traffic the speaker would like to receive), but the semantics are becoming more powerful and I haven't run the analysis; will leave this to the SECDIR review. IP in IP tunnel configuration in particular deserves more attention than I can spare at the moment, as it appears to allow a BGP speaker to steer a tunnel of its peer to any arbitrary address in the Internet, which seems like it might open new and interesting forms of hijacking not protected by RPKI. Security folks should also have a look at section 10 and think about malicious uses of this design deficiency. Instead, I'll focus on the most transport-relevant issues: First and foremost, I was surprised to find no reference to tunnel or MTU anywhere in the document, especially given the guidance in section 6 to stack tunnels. MTU issues are operationally difficulty in single-tunnel environments and become more likely to cause problems in multiple-tunnel environments. If the facility is not intended to allow BGP speakers to advertise the MTUs available on each tunnel directly (i.e. is this information universally available to all routers from dataplane configuration? on a link, yes, on a tunnel, I'm not sure) then I'd at least expect an operational considerations section letting users of the facility know that MTU discovery is left as an exercise to the endpoint transport stacks on the tunneled routes, and to the network engineers running the routers when the support calls come up. The sub-TLVs in 3.3.1 and 3.3.2 configure a DSCP and a UDP port, respectively, for encapsulations themselves encapsulated over UDP. The standard dataplane considerations for using UDP apply, but I don't think we need to reference 8084 from here. So this seems OK to me as is. I'd call this "ready except MTU", so ready with issues. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
