Last Call Review of draft-ietf-forces-protoextension-04
review-ietf-forces-protoextension-04-secdir-lc-gondrom-2014-08-07-00

  
  
    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