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

Jeff Tantsura <> Wed, 11 December 2019 00:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 452041200F6 for <>; Tue, 10 Dec 2019 16:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sQlra6DfBtNq for <>; Tue, 10 Dec 2019 16:50:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4CC112008C for <>; Tue, 10 Dec 2019 16:50:46 -0800 (PST)
Received: by with SMTP id r11so9879105pgf.1 for <>; Tue, 10 Dec 2019 16:50:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=7LhFtwU/DW13merEPRGHETe/94687qYpoD+DRNphTfE=; b=YFFx5CT1lYLRaCHN+V7CS/SM1QhAcJ3BCXtAWJIGVwXh0Li+sle6y4r23d94capQJ7 eXyn9szz0b3aUX1XAsk5DNgiWLt7geKcZxa/hJcGf7mzSd3HpOS7XG8h2aHa71gDarnt gUAEite6hEn0rqcMUIOt5edqep88MbOTYSJu+L2boDMeMCLve4y/YiPEQqXRp7+FwdXa gLmgNlCIv7gDbjkUJL+reI2u1sJIA6cy6f8SjKFyTn/kUKyrB4Jyg2B4hTSiJySZfrWN ZqvFmBrhO84YoE/sVhcj2vfkXM9eW3jUy5REviNfiw1UjOl1qwG2bjJi05vskjDaj7+S +Djg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=7LhFtwU/DW13merEPRGHETe/94687qYpoD+DRNphTfE=; b=j0EUAG6KpzMCEzgVGafThDDxFXh13xAiTDW5TYx8Q5pO2Qyfk0qfOBgV9SSuBoO9cC KUsPRaGdhuXril8ANQPqqJexnNtkFyrVkSkmYZujP2SGfnx1p11IJUyLHBp3A42RNQwu GEbcubisria9mWpvDCp6ZhdflbvY4gkxkrywfG/glmlrfojxunUnqt1LEwcGA299mpNp BRtYH3zdBxK5u/8Xn8A3SPu+7cPAeP9mmjJI7/qnancXSwKB5Kxbb9i7/4X7k9z2oHys ZENBxccRk7t+F0v2CdtNzGeIhd4wnb7M4VVeQMYN4OW13oLpXztahSRcVGERVfxdkEyK 2AQQ==
X-Gm-Message-State: APjAAAVlz+HbwkCZF2apv40xVPUJThMwwMX6euPE9Tc7EW7c6+3qffue WJhJQVNmxdWOcnFWcK/w0lZgzfkF
X-Google-Smtp-Source: APXvYqxv4YvlyNqT+CEt/dwLCocWRjegdHjoe/M1G9hd4sInCDi7fHyw93Qh92FLylg9YajESOJ3xQ==
X-Received: by 2002:a63:6fca:: with SMTP id k193mr1106495pgc.416.1576025445759; Tue, 10 Dec 2019 16:50:45 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id p186sm237292pfp.56.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Dec 2019 16:50:45 -0800 (PST)
Date: Tue, 10 Dec 2019 16:50:36 -0800
From: Jeff Tantsura <>
To:, Mahesh Jethanandani <>
Message-ID: <7e96a2d8-59b2-4c38-a17d-67335a07defd@Spark>
In-Reply-To: <>
References: <>
X-Readdle-Message-ID: 7e96a2d8-59b2-4c38-a17d-67335a07defd@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5df03d64_42963e5a_872b"
Archived-At: <>
Subject: Re: [Idr] Securing BGP sessions (Issue#41)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Dec 2019 00:50:48 -0000


I believe the below clearly represent what has been discussed in Singapore.

On Dec 10, 2019, 4:34 PM -0800, Mahesh Jethanandani <>om>, 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?
> Mahesh Jethanandani
> _______________________________________________
> Idr mailing list