[Tsv-art] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19

[Brian Trammell via Datatracker <[e-mail]>]

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
[e-mail] 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.