Subject: [secdir] secdir review of draft-ietf-idr-tunnel-encaps-20

From: "Scott G. Kelly" <[email-masked]>
Date: Sun, 15 Nov 2020 11:53:16 -0800 (PST)

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is ready.

This review is more than a month late, and I'm not certain whether it is still useful, but I'm sending it along to clear it from everyone's backlog.

From the abstract, "This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional Tunnel Types, and allows a remote tunnel endpoint address to be specified for each tunnel.  This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel."

In a nutshell, the document deprecates one way of defining how to tunnel specific types of traffic, and then defines a different way to accomplish this. I'm not a BGP expert, and that's part of why it's taken me so long to respond. The main question I have is, does this introduce new ways to attack BGP, ways that have not already been considered?

The security considerations section says that the tunnel encapsulation attribute should only be used within a well-defined scope under the control of a single administrative entity, and references RFC4272 (BGP Security Vulnerabilities Analysis). It talks about traffic diversion attacks, noting that a tunnel encapsulation attribute adds a new way to divert traffic. It then describes several mitigation measures.

Based on my very limited understanding of BGP and a quick read of RFC4272, I think the security considerations are complete, and I see no security issues with this draft.

--Scott