Roman Danyliw has entered the following ballot position for draft-ietf-alto-path-vector-19: 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: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Samuel Weiler for the SECDIR review. ** Overstatement of security properties. Section 1. For better confidentiality, this document aims to minimize information exposure. Section 5.1.2. By design, ANEs are ephemeral and not to be used in further requests to other ALTO resources. More precisely, the corresponding ANE names are no longer valid beyond the scope of the Path Vector response or the incremental update stream for a Path Vector request. This has several benefits including better privacy of the ISPs and more flexible ANE computation. The text in both of these sections reads to strongly. This document defines the ANEs which in fact provides more detailed network information but provides no normative operational guidance or protocol-based protections to minimize (obfuscate) this information. These claims seem to rest of practices which are out of scope of this document ** Section 5.1.2. Editorial This has several benefits including better privacy of the ISPs and more flexible ANE computation. Words are missing from this sentence – “better privacy of the ISPs” what? ** Section 5.1.3. Resource-constrained ALTO clients may benefit from the filtering of Path Vector query results at the ALTO server ... Can you describe the use case of these “resource-constrained ALTO clients” as nothing about the use cases in Section 4.2 suggested that the clients were constrained. ** Section 5.2. To be pedantic on what’s strictly in C++: OLD For example, in programming languages such as C++, a Path Vector will have the type of JSONArray<ANEName>. NEW For example, in programming languages such as C++ where there existed a JSON array type named JSONArray, a Path Vector will have the type of JSONArray<ANEName>. _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
