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.ietf@xxxxxxxxx>
Sent: Tuesday, October 15, 2024 7:33 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: secdir@xxxxxxxx; draft-ietf-pce-stateful-pce-vendor.all@xxxxxxxx; last-call@xxxxxxxx; pce@xxxxxxxx
Subject: Re: [Last-Call] Secdir last call review of draft-ietf-pce-stateful-pce-vendor-08
On Tue, Oct 15, 2024 at 4:32 AM Linda Dunbar via Datatracker <noreply@xxxxxxxx> 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.
Best Regards,
Linda Dunbar
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to
last-call-leave@xxxxxxxx
|
<<< text/html; name="draft-ietf-pce-stateful-pce-vendor-09.diff.html": Unrecognized >>>
<<< text/html; name="draft-ietf-pce-stateful-pce-vendor-09.html": Unrecognized >>>
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
