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

Qin Wu <> Mon, 16 December 2019 00:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15011120059 for <>; Sun, 15 Dec 2019 16:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KwTQGaHZzvWb for <>; Sun, 15 Dec 2019 16:50:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 414D612004A for <>; Sun, 15 Dec 2019 16:50:19 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id BDEF26B3D1ADC7C4B3ED; Mon, 16 Dec 2019 00:50:15 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 16 Dec 2019 00:50:14 +0000
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Mon, 16 Dec 2019 08:50:09 +0800
From: Qin Wu <>
To: Mahesh Jethanandani <>, "Acee Lindem (acee)" <>
CC: "" <>
Thread-Topic: [Idr] Securing BGP sessions (Issue#41)
Thread-Index: AdWzqsLIquMLsf+4TDedRY0JM2jAzQ==
Date: Mon, 16 Dec 2019 00:50:09 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA94FC36Fdggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Mon, 16 Dec 2019 00:50:22 -0000

To the question of IPsec, and whether we should support it or not, as I said, I will let Jeff comment. But what kind of documentation are you hoping for? Isn’t it just a question of giving IKE the parameters it needs to setup a IPsec tunnel? If we decide to support it, i2nsf WG has been working on an IKE model, as I just learnt, complete with re-keying,

[Qin] Mahesh, I believe you are referring to KARP working group instead of I2NSF working group.
which with a few changes could be used by the BGP model.


On Dec 13, 2019, at 10:47 AM, Acee Lindem (acee) <<>> wrote:

Hi Mahesh,

On 12/10/19, 8:41 PM, "Mahesh Jethanandani" <<>> wrote:

On Dec 10, 2019, at 5:29 PM, Acee Lindem (acee) <<>> wrote:

Hi Mahesh,

On 12/10/19, 8:19 PM, "Mahesh Jethanandani" <<>> wrote:

  Hi Acee,

On Dec 10, 2019, at 5:10 PM, Acee Lindem (acee) <<>> wrote:

Hi Mahesh,
I assume by IPsec, you mean transport mode IPsec.

  Yes. The assumption is that the underlying transport is secured using IPsec, and the model provides (if needed) key parameters needed to kick off the IKE to setup the SA in IPsec.


Well it doesn't help at all.... Normally, the usage of IPsec (AH, ESP, algorithms, key exchange, etc.) would be specified in some document. For example, IPsec usage by OSPFv3 is specified in RFC 4552. Granted, it is a lot simpler for BGP than OSPFv3 since BGP is strictly P2P but specification would still seem to necessary.

   You are right. It should be some document. That document in my mind is the YANG model for IPsec/IKE, something we need to ask the SEC ADs about. You would agree that what needs to be defined is not BGP specific, and therefore does not belong in the BGP model.

   Much like TCP-AO and TCP-MD5 I expect this other document to define a grouping that the BGP model imports and uses to define what is needed to setup IPsec.

Actually I disagree with you - TCP MD5 and TCP-AO are more than adequately documented.

  MD5 -
  TCP-AO -

It is only IPsec transport mode that isn't described. Also, I don't know of anyone who supports this so I'm wondering why it is in the discussion for this version of the BGP YANG model.




For IPsec protection of BGP, where are the details specified?

On 12/10/19, 7:35 PM, "Idr on behalf of Mahesh Jethanandani" <<> on behalf of<>> 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 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.


 Mahesh Jethanandani<>

 Idr mailing list<>

  Mahesh Jethanandani<>

   Mahesh Jethanandani<>