Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-lsp-setup-type-09: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm concerned about defining the space for optional sub-TLVs in PATH-SETUP-TYPE-CAPABILITY but not giving much description of how future sub-TLVs would work (since none are currently defined). Is there expected to be a one-to-one mapping from PST to sub-TLV, or one-to-many, or something else? If a given sub-TLV can be associated with more than one PST, some rules would need to be specified for how that mapping works, what dependency there is on the order in which sub-TLVs appear in the message, etc. I am not balloting DISCUSS because I suspect the intent is for each sub-TLV to correspond to exactly one PST, in which case the behavior is pretty easy. But I would like to see more description of how this is expected to work. Both new TLVs have 'Reserved' fields that MUST be set to zero. Should they be ignored on receipt (to allow for potential future use as an extension) or can the receiver validate that they are zero? The Security Considerations defer to RFCs 5440 and 8281, which (as the secdir review notes) is mostly okay. RFC 5440 does have a long discussion of the value of TCP authentication, but IIUC it does not mandate that TCP authentication be used. That would leave open the possibility that an attacker (e.g., TCP MITM) could generate error messages when a particular PST is used, potentially forcing the use of a different PST, and this attacker capability seems to be new in this document. As such, it would merit a mention in the Security Considerations. (This attack only becomes relevant in the face of some additional weakness or flaw in a PST that makes forcing its use advantageous to the attacker for other reasons.) _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
