Skip to main content

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 revision No specific revision (document currently at 22)
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 R. Sangli , John Scudder
I-D 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 G. Kelly (diff)
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-ietf-idr-tunnel-encaps by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Nx3FolURLXpkkGMxvkiVIU5Reuk
Reviewed revision 20 (document currently at 22)
Result Ready
Completed 2020-11-15
review-ietf-idr-tunnel-encaps-20-secdir-lc-kelly-2020-11-19-00
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