[Pce] A review of draft-ietf-pce-stateful-pce-vendor

[Adrian Farrel <[e-mail]>]

Hi,

I'm continuing my campaign of reviewing PCE I-Ds that have been around
for a while. This one had a very long run as an individual I-D, saw an
implementation reported back in 2020, and was adopted in July last year.
It seems the work is pretty stable. Perhaps it's time to polish it and
move to last call.

So here is a review. The document is really well written and easy to
read. I only find a few nits.

Cheers,
Adrian

===

Abstract

s/the associated and the dependent/any associated and dependent/

---

1.

s/[RFC7470] defined Vendor/[RFC7470] defined the Vendor/
s/defined VENDOR-INFORMATION-TLV/defined the VENDOR-INFORMATION-TLV/

OLD
   This document extends the usage of Vendor Information Object and
   VENDOR-INFORMATION-TLV to Stateful PCE.
NEW
   This document extends the usage of the Vendor Information Object and
   the VENDOR-INFORMATION-TLV to Stateful PCE.
END

---

2.

Somewhere in this document, you need a reference to RFC 5511.  The usual
form of words is something like...

   The message formats in this document are specified using Routing
   Backus-Naur Format (RBNF) encoding as specified in [RFC5511].

---

Section 2 uses the VENDOR-INFORMATION object. That's all fine, but it
would be good to be more explicit with the pointer to RFC 7470. 
Something like...

OLD
   The contents and format of the object are described in Section 4 of
   [RFC7470].
NEW
   The contents and format of the object, including the 
   VENDOR-INFORMATION object, are described in Section 4 of [RFC7470].
END

---

I think that the 1.5 lines of Section 4 could easily be placed at the
top of Section 2 and so remove the need for the section.

---

8.

Something we never included in RFC 7470 (and 7150, before it) was the
potential for the vendor-specific information to act as a covert
channel. That is, as a way for applications to exchange information 
that is out of scope of PCEP. It could be used by malign software that
has infected a PCE and PCC, It could even carry executable code.

The nature of vendor-specific information is that it cannot be decoded
or inspected by third parties. So it is difficult to protect against a
covert channel.

There is some protection in the "unrecognised object" and "unknown
enterprise number" for a receiver, but this doesn't provide full 
protection against misuse. That is hard to mitigate.

I think that we should have raised this point in 7470, and that it is
not really something specific for this document. However, I think this
work should mention the problem and say what can be done. Something 
like...

   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.