Re: [Idr] Securing BGP sessions (Issue#41)

Jared Mauch <jared@puck.nether.net> Wed, 11 December 2019 00:55 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635011200F6 for <idr@ietfa.amsl.com>; Tue, 10 Dec 2019 16:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 np7oIOaaPfp8 for <idr@ietfa.amsl.com>; Tue, 10 Dec 2019 16:55:14 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABB112008C for <idr@ietf.org>; Tue, 10 Dec 2019 16:55:14 -0800 (PST)
Received: from [10.0.0.129] (c-68-40-189-22.hsd1.mi.comcast.net [68.40.189.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 29A49541304; Tue, 10 Dec 2019 19:51:20 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <D9C310C0-89C6-4CB5-80A2-98C274581E7F@gmail.com>
Date: Tue, 10 Dec 2019 19:51:18 -0500
Cc: idr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AAEA8BD6-0601-453A-B49E-1DC616F8C53B@puck.nether.net>
References: <D9C310C0-89C6-4CB5-80A2-98C274581E7F@gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8nbG-B2mggfDARhpsz1l23b365w>
Subject: Re: [Idr] Securing BGP sessions (Issue#41)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2019 00:55:16 -0000


> On Dec 10, 2019, at 7:34 PM, Mahesh Jethanandani <mjethanandani@gmail.com>; wrote:
> 
> This is the second thread in the list of issues that were discussed in IETF 106 w.r.t. to BGP YANG model. This particular thread is to discuss the issue of defining how BGP sessions are going to be secured.
> 
> As stated in Singapore, the model is being defined to secure BGP sessions using 
> - TCP AO
> - TCP MD5
> - IPSec
> 
> In case there was a question of why MD5, it is because there are existing implementations that are choosing to stay with MD5, regardless of the issues that have been raised about MD5. The model therefore has to support such implementations.
> 
> The model will use the ietf-key-chain model’s (RFC 8177) key-chain-ref to refer to an instance of the key chain. By doing that it will make use of the key rollover capability defined in that model, and for static key configuration by setting the end time to infinite in the key chain. The BGP model will leave the case of IPSec as TBD for now, and fill it when/if the IPSec YANG model is defined.
> 
> Questions/Concerns?

Some comments here:

I think of the above options the only two that are available are TCP-MD5 and IPSEC.  IPSEC doesn’t have use in the (public) internet space, but this doesn’t mean people don’t use it internally or elsewhere.. I just haven’t found any of these people in real life.

TCP-AO seems like it’s viable but as I mentioned in one of the security area meetings at IETF-101, the current operational requirements are generally stability for 180-1800 days of a BGP session (or longer).  People hate it when their BGP sessions go down and their routes go away as a result so there’s a lot of steps necessary to upgrade both sides once they support something like TCP-AO.

Also operators have a hard enough time keeping the static keys configured as they often outlast the lifetime of the engineer at the company and most key rotation systems (eg: IPSec on routers don’t often expose them in a way that survive device migrations, and key management/export are poor or non-existent, so people only use them internally vs externally facing …) don’t work well or require time sync in a way that if the fail will drop the TCP session and BGP goes down as well.

The other thing is most people just want transport integrity, not privacy.

- Jared