Re: [secdir] Secdir early review of draft-ietf-rtgwg-atn-bgp-12

Benjamin Kaduk <kaduk@mit.edu> Sun, 23 January 2022 03:53 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B87B3A10A3; Sat, 22 Jan 2022 19:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 CvuDPh9n-uhY; Sat, 22 Jan 2022 19:53:51 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DC63A10A1; Sat, 22 Jan 2022 19:53:51 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20N3rY4e011524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Jan 2022 22:53:40 -0500
Date: Sat, 22 Jan 2022 19:53:34 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: Russ Housley <housley@vigilsec.com>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-rtgwg-atn-bgp.all@ietf.org" <draft-ietf-rtgwg-atn-bgp.all@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: [secdir] Secdir early review of draft-ietf-rtgwg-atn-bgp-12
Message-ID: <20220123035334.GI11486@mit.edu>
References: <c10062dd0ac24e1f8a8e00175c54eee6@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c10062dd0ac24e1f8a8e00175c54eee6@boeing.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/3N3LnGP5ddOyx2N0BdHRbn9hn8U>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2022 03:53:54 -0000

On Wed, Jan 19, 2022 at 04:53:20PM +0000, Templin (US), Fred L wrote:
> 
> > -----Original Message-----
> > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Russ Housley via Datatracker
> > Sent: Tuesday, January 18, 2022 2:22 PM
> > To: secdir@ietf.org
> > Cc: draft-ietf-rtgwg-atn-bgp.all@ietf.org; rtgwg@ietf.org
> > Subject: Secdir early review of draft-ietf-rtgwg-atn-bgp-12
> > 
[...]
> > Section 5 says: "...tunnels packets directly between Proxys ...".
> > Are these IPsec tunnels?  I am trying to fully understand when the
> > tunnels require IPsec (or some other security protocol) and when they
> > do not.
> 
> This is a good point. We want to establish an environment where security
> tunneling is used to protect only control messages and BGP protocol
> messages while unsecured tunneling is used to convey data plane packets
> when higher-layer security is used end-to-end. Again, more words may
> help clarify.

Without looking too hard at the specifics of this draft's situation, as a
general statement, knowing that higher-layer security is used end-to-end is
hard to 100% reliably determine, and the cost of getting it wrong can be
very high.  As a general design pattern, having multiple layers of crypto
that aim to protect different aspects of the traffic is perfectly fine, and
in some cases actually required in order to get the needed properties.
If the only tunnel available is a secure tunnel, then you don't have to
worry about getting the decision wrong.

Looking at the specific scenario in §5, it is not a direct analogue of the
scenario I describe, but I would caution against being too eager to discard
the certainty of always having a secure tunnel.

-Ben