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

"Scott G. Kelly" <scott@hyperthought.com> Sun, 15 November 2020 19:53 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C423A0995; Sun, 15 Nov 2020 11:53:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqVc4e9cyWjR; Sun, 15 Nov 2020 11:53:17 -0800 (PST)
Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755CA3A0991; Sun, 15 Nov 2020 11:53:17 -0800 (PST)
Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 890CF210D7; Sun, 15 Nov 2020 14:53:16 -0500 (EST)
Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app35.wa-webapps.iad3a (Postfix) with ESMTP id 76667A0081; Sun, 15 Nov 2020 14:53:16 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sun, 15 Nov 2020 11:53:16 -0800 (PST)
X-Auth-ID: scott@hyperthought.com
Date: Sun, 15 Nov 2020 11:53:16 -0800
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-idr-tunnel-encaps.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
X-Client-IP: 24.23.138.127
Message-ID: <1605469996.482420581@apps.rackspace.com>
X-Mailer: webmail/18.1.9-RC
X-Classification-ID: b259966a-3b60-4128-b5b2-0465e66a28c6-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Nx3FolURLXpkkGMxvkiVIU5Reuk>
Subject: [secdir] secdir review of draft-ietf-idr-tunnel-encaps-20
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Nov 2020 19:53:19 -0000

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