[secdir] secdir review of draft-ietf-forces-protoextension-04

[Tobias Gondrom <[e-mail]>]

I have reviewed this document as part of the security 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.

The draft is standards track and describes a few extensions to ease
programmability and to improve wire efficiency of some transactions. It
adds extensions to the ForCES Protocol RFC5810 and RFC7121.

The document appears mostly ready for publication.

The security considerations section (section 6) only refers to RFC 5810.


1 Nits and 3 Questions regarding the security section below:

Nits:
- section 3.2.3.1. last paragraph:
s/writting/writing

Questions:
1. section 3.2.3.1. last paragraph: 
"On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a
   master CE can turn on support for extended results by setting the
   value to 2 in which case the FE MUST switch over to sending only
   EXTENDEDRESULT-TLVs."

Not sure about the full network topology, but could that enable a master
CE to effectively make the replies of a FE unreadable to other
old-version CEs (which can only understand RESULT-TLVs) by switching on
the "only" new EXTENDEDRESULT-TLVs?

2. with the New Codes in section 3.2.1. :
do any of the new more detailed error codes (e.g. "E_EMPTY |  Table is
empty") pose a risk of data leakage of information detail that was not
intended to be disclosed in that detail in the original RFC 5810?

3. section 3.1.:
Could the new "TABLERANGE-TLV", which requires significantly more
computing on the receiver per request from the sender, enable an
attacker for a type of Denial of Service attack scenario?


NOTE: though I reviewed the ID, I did not validate the XML structure in
appendix A.


Thank you and best regards.

Tobias