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

[Aijun Wang <[e-mail]>]

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: [e-mail] <[e-mail]> 
Sent: Thursday, January 21, 2021 11:50 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Lou Berger <[e-mail]>; [e-mail]
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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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 https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-09.  Is that sufficient?