Roman Danyliw has entered the following ballot position for draft-ietf-alto-path-vector-20: Discuss
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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (Updated ballot to make the remaining issues clear) Thanks for the update in -20 and in particular all of the new language in the Security considerations to discuss applicability and obfuscation procedures. In these edits in response to the earlier DISCUSS text, the following sentence was introduced into Section 11: For settings where the ALTO server and client are not in the same trust domain, Digital Right Management (DRM) techniques and legal contracts protecting the sensitive Path Vector information MUST be applied. It appears to be trying to provide guidance on how to ensure that only the expected ALTO clients get the sensitive path information in the case where the server and clients are in different trust domains. This new language contains normative guidance to using DRM techniques. Given this is a normative “MUST”, the specifics of “DRM techniques” is under-specified. Independent of that, DRM techniques I quickly think of provides object security (i.e., embedding a security envelope of some form directly in the data it is trying to protect). How would that mesh with the specified format for the path information in this document? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Samuel Weiler for the SECDIR review. Thanks for addressing my COMMENTs. Previous DISCUSS point below ====== Thanks for documenting the increased risk of exposing sensitive topology information and the potentially of this data being exploited for a highly targeted DoS attack in Section 11. While this significant problem is documented, the mitigation for this fundamental issue is underspecified. The security of this extension is predicated on the ANE obfuscation procedures, but those specifics are not provided. In my review, there doesn’t appear to be wide operational usage or implementations of this extension to inform these obfuscation procedures. Furthermore, it appears that these procedures remain an open research question. I appreciate the helpful references to the academic papers in Section 11 ([NOVA], [RESA][ MERCATOR]) but their practical applicability to the generic capability provided by this extension appears to be difficulty to align and be caveated. For example, [RESA] and [MERCATOR] made what appear to be significant assumptions on their approaches, “In this paper, we assume a semi-honest security model, i.e., the aggregator and all member networks will not deviate from the security protocol, but merely try to gather information during the execution of the protocol”. I believe this document needs to be provide a stronger applicability statement constraining where it can be fielded and what assumptions are made about the trust models. Additionally, given the uncertainty on the generic feasibility of obfuscation, this document should be published as experimental. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
