Re: [secdir] [Idr] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Qin Wu <> Mon, 22 October 2018 01:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EFA7120072; Sun, 21 Oct 2018 18:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5gVesqZL3727; Sun, 21 Oct 2018 18:26:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1019D12D4EE; Sun, 21 Oct 2018 18:26:52 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 1D94EDB51A578; Mon, 22 Oct 2018 02:26:49 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Oct 2018 02:26:49 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 09:26:42 +0800
From: Qin Wu <>
To: Yoav Nir <>, "Les Ginsberg (ginsberg)" <>
CC: Robert Raszuk <>, "" <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13
Date: Mon, 22 Oct 2018 01:26:41 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0B8CE5nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [secdir] [Idr] Secdir early review of draft-ietf-idr-te-pm-bgp-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Oct 2018 01:26:54 -0000

Thanks Yoav for proposed change,:-)
发件人: Yoav Nir []
发送时间: 2018年10月22日 1:45
收件人: Les Ginsberg (ginsberg)
抄送: Robert Raszuk;;;;;
主题: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

See inline.

On 19 Oct 2018, at 17:51, Les Ginsberg (ginsberg) <<>> wrote:

Robert’s post addresses points I also want to make.

What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the  BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required.

In theory, we could have simply updated RFC 7752 rather writing a separate draft, but practically this would be a poor strategy as it would incorrectly suggest that some change was being made to the existing text in RFC 7752.

I appreciate that from the POV of the Security Area you folks are not as intimately familiar with the routing drafts and the relationship between them. It is therefore understandable that you start looking at the new draft as a standalone document – and in that context your comments are absolutely correct. But the document you are reviewing is most accurately seen as an “addendum” to RFC 7752.

[YN] Right, and as such, I believe that this document should address the part that it adds to RFC 7752. IOW it should state that the new IGP information that will now be sent through BGP does not present new/different risk to the information already defined in 7752. This is information that has up until now only been sent in IS-IS and OSPF and will not be sent in BGP, so we need a statement that it’s OK to send these attributes in BGP as well. Of course, such a statement could be challenged in WGLC or IETF LC, but it should be made.

The issues you raise have already been addressed in RFC 7752 and it is therefore very appropriate that we address your concerns by including a reference to the RFC 7752 security discussion.

I think it is important that you note this relationship, because the nature of BGP-LS is that whenever IGP extensions are defined to advertise new information it is necessary to define corresponding BGP-LS codepoints. This is not the first such BGP-LS extension document – and it is safe to say it won’t be the last. It would be helpful to all if we reached a common understanding or this discussion will take place every time a BGP-LS extension document is being reviewed – which will cost us all time needlessly.