Hi Roman,
Thanks for the review and please see the replies inline. > -----Original Messages----- > From: "Roman Danyliw via Datatracker" <[email protected]> > Sent Time: 2021-11-30 23:33:54 (Tuesday) > To: "The IESG" <[email protected]> > Cc: [email protected], [email protected], [email protected] > Subject: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: > (with DISCUSS and COMMENT) > > 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. > The protection mechanisms depend heavily on what information is exposed and how it is used. For example, for bandwidth information, the order of ANEs in a response can be reshuffled, some even be removed, without compromising the functionality. However, for edge server discovery, if the order of edge servers is reshuffled, the usefulness of the information is compromised. Thus, from the extensions' perspective, it is difficult to define a general protection mechanism without knowing the semantics of the ANE and the objectives/constraints of the application. > 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. > We agree that an applicability statement is needed and will propose the text asap. Publishing the document as experiment is an option and we will discuss this with the AD and WG chairs. > > ---------------------------------------------------------------------- > 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 > Thanks for the comment. If nothing is exposed at all, the information exposure is certainly minimal. However, if the information must be exposed, exposing nothing will not be a valid option so comparing with it will not make sense. Thus, the claim in section 1 that "this document aims to minimize information exposure" is based on the condition that "this information must be exposed". We will clarify this with the proposed text below: For better confidentiality, this document aims to minimize information exposure of an ALTO server when providing the Path Vector service. Also the claim that "This has several benefits including better privacy of the ISPs and more flexible ANE computation" will be revised as: Compared with globally unique ANE names, ephemeral ANE has several benefits including ... > ** 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? Thanks for the comment. Please see the proposed text below: This has several benefits including better privacy of the ISP's internal structure and more flexible ANE computation. > > ** 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. The term is used as in Section 4.1.2 of RFC 7285: Resource-constrained ALTO clients may benefit from the filtering of query results at the ALTO server. This avoids the situation in which an ALTO client first spends network bandwidth and CPU cycles to collect results and then performs client-side filtering. We will add a reference to the section. > > ** 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>. > Thanks for the proposed text and we will adopt it in the next revision. > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
