It looks good to me, thank you Samul for editing the draft and Dhruv to propose the text. React so quickly! Amazing! LOL
Cheng From: Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org> Sent: Tuesday, October 15, 2024 9:49 AM To: Dhruv Dhody <dhruv.i...@gmail.com>; Linda Dunbar <linda.dun...@futurewei.com> Cc: sec...@ietf.org; draft-ietf-pce-stateful-pce-vendor....@ietf.org; last-c...@ietf.org; pce@ietf.org Subject: [Pce] Re: [Last-Call] Secdir last call review of draft-ietf-pce-stateful-pce-vendor-08 Thanks a lot Linda for your review. Adding also updated version with change proposed by Dhruv (not submitted yet). Regards, Samuel From: Dhruv Dhody <dhruv.i...@gmail.com<mailto:dhruv.i...@gmail.com>> Sent: Tuesday, October 15, 2024 7:33 AM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Cc: sec...@ietf.org<mailto:sec...@ietf.org>; draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org> Subject: Re: [Last-Call] Secdir last call review of draft-ietf-pce-stateful-pce-vendor-08 Hi Linda, Thanks for your review. On Tue, Oct 15, 2024 at 4:32 AM Linda Dunbar via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Reviewer: Linda Dunbar Review result: Has Nits I have reviewed this document as part of the SEC area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security area directors. Document editors and WG chairs should treat these comments just like any other last-call comments Summary: this document extends the vendor-specific information in the Stateless PCE communication protocol for the Stateful PECP message. The document is very clear and easy to read. Just a minor NITS with the Security Consideration: The method described in the Security Consideration to mitigate the security issue of "covert channel" relies on operators noticing that vendor-specific information is being used and then reaching out to the vendor for decoding mechanisms. This is a reactive approach rather than a proactive one. By the time the operator detects the use of vendor-specific information and obtains the necessary decoding tools, malicious or harmful actions could have already occurred. It would be useful to add more description on how can operator be proactive to prevent the issue. Dhruv: I can understand how the text gives the impression that this is reactive instead of proactive. I would suggest rephrasing the text to - OLD: The use of vendor-specific information as defined in [RFC7470] and in this document may provide a covert channel that could be misused by PCEP speaker implementations or by malign software at PCEP speakers. There is little protection against this, however, an operator that monitors the PCEP sessions can determine that vendor-specific information is being used and ask their suppliers (the PCE and PCC implementers) to provide a mechanism to decode the vendor-specific information. NEW: The use of vendor-specific information as defined in [RFC7470] and in this document may provide a covert channel that could be misused by PCEP speaker implementations or by malign software at PCEP speakers. While there is limited protection against this, an operator monitoring the PCEP sessions can detect the use of vendor-specific information, be aware of the decoding mechanism for this information, and stay vigilant for potential misuse. END Note that for vendor-specific information to be of use it needs to be understood by both sending and receiving PCEP speakers. Thanks! Dhruv Best Regards, Linda Dunbar -- last-call mailing list -- last-c...@ietf.org<mailto:last-c...@ietf.org> To unsubscribe send an email to last-call-le...@ietf.org<mailto:last-call-le...@ietf.org>
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
