Re: [Teas] Roman Danyliw's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

Aijun Wang <> Thu, 21 January 2021 06:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B511A3A0E43; Wed, 20 Jan 2021 22:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P-HUXofeX_Mc; Wed, 20 Jan 2021 22:19:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F0B403A0E3D; Wed, 20 Jan 2021 22:19:33 -0800 (PST)
Received: from clientip- (unknown []) by (HERMES) with SMTP id B1520280098; Thu, 21 Jan 2021 14:19:11 +0800 (CST)
Received: from ([]) by App0024 with ESMTP id 72b0ff2e0f1a4b0b91f10bfa92bca05c for; Thu Jan 21 14:19:28 2021
X-Transaction-ID: 72b0ff2e0f1a4b0b91f10bfa92bca05c
X-filter-score: filter<0>
X-MEDUSA-Status: 0
From: "Aijun Wang" <>
To: "'Roman Danyliw'" <>, "'The IESG'" <>
Cc: <>, <>, <>, "'Lou Berger'" <>
References: <>
In-Reply-To: <>
Date: Thu, 21 Jan 2021 14:19:10 +0800
Message-ID: <002401d6efbd$5f4f2c90$1ded85b0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGXJNCQ2+3nnecpbSvWoTYs9F/UIaqxKMbg
Content-Language: zh-cn
Archived-At: <>
Subject: Re: [Teas] Roman Danyliw's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jan 2021 06:19:40 -0000

Hi, Roman:

Would you like to give some suggestions/recommendation directly on the following intended update part for "Security Consideration" of this draft:

"The setup of BGP sessions, prefix advertisement, and explicit peer route establishment are all controlled by the PCE. See RFC4271 and RFC4272 for BGP security considerations. Security consideration part in RFC5440  and RFC8231 should be considered. To prevent a bogus PCE sending harmful messages to the network nodes, the network devices should authenticate the validity of the PCE and ensure a secure communication channel between them. Mechanisms described in RFC8253 should be used.
The CCDR architecture does not require changes to the forwarding behavior of the underlay devices. There are no additional security impacts on these devices."

Other responses for your comments are inline below.

Thanks in advance for your guidance.[WAJ]

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: <> 
Sent: Thursday, January 21, 2021 11:50 AM
To: The IESG <>
Cc:;;; Lou Berger <>et>;
Subject: Roman Danyliw's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-teas-pce-native-ip-15: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks to Donald Eastlake for the SECDIR review

** Section 8.  Since PCE is used to setup the BGP sessions, etc., the references to the Security Considerations of PCE specs should be reiterated as applying – minimally RFC5440 and RFC8231.
[WAJ] Add the reference to the security part considerations of RFC5440 and RFC8231

** To restate Alvaro Retana's comment #9, RFC8231 already notes that malicious PCE and PCCs are possible (see above comment).  In this context, the new variant relevant to this architecture would be in form of (malicious) BGP configurations.  It's worth highlighting.
[WAJ] Correct together also the responses to Alvaro' comments. -------Current text of this draft has mentioned that "the network devices should authenticate the validity of the PCE, and a secure communication channel between them". Based on such mechanism, is it impossible for a bogus PCE to step in? For the errors that induced via the messages that sent by the authorized PCE, the related PCEP error messages have already been defined in  Is that sufficient?