Last Call Review of draft-ietf-idr-tunnel-encaps-20
review-ietf-idr-tunnel-encaps-20-secdir-lc-kelly-2020-11-19-00

Request Review of draft-ietf-idr-tunnel-encaps
Requested rev. no specific revision (document currently at 20)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-10-01
Requested 2020-09-17
Authors Keyur Patel, Gunter Van de Velde, Srihari Sangli, John Scudder
Draft last updated 2020-11-19
Completed reviews Rtgdir Last Call review of -19 by Harish Sitaraman (diff)
Genart Last Call review of -19 by Gyan Mishra (diff)
Tsvart Last Call review of -19 by Brian Trammell (diff)
Opsdir Last Call review of -19 by Jouni Korhonen (diff)
Secdir Last Call review of -20 by Scott Kelly
Assignment Reviewer Scott Kelly 
State Completed
Review review-ietf-idr-tunnel-encaps-20-secdir-lc-kelly-2020-11-19
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Nx3FolURLXpkkGMxvkiVIU5Reuk
Reviewed rev. 20
Review result Ready
Review completed: 2020-11-15

Review
review-ietf-idr-tunnel-encaps-20-secdir-lc-kelly-2020-11-19

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