Hi, Roman: Ping your feedback on author’s proposed change (See below), which is used to address your comments. You also can check diff as follows: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-path-vector-20.txt Thanks in advance!
-Qin (on behalf of chairs) 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Qin Wu 发送时间: 2022年1月5日 10:26 收件人: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> 抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>; draft-ietf-alto-path-vec...@ietf.org<mailto:draft-ietf-alto-path-vec...@ietf.org>; alto@ietf.org<mailto:alto@ietf.org> 主题: Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT) Hi, Roman: Happy new year, I forward Kai’s response message sent yesterday to you since he report his message got rejected again for some reasons. Please help review his proposed text and let authors whether your comments are addressed. Thanks in advance. -Qin (on behalf of chairs) 发件人: kai...@scu.edu.cn<mailto:kai...@scu.edu.cn> [mailto:kai...@scu.edu.cn] 发送时间: 2022年1月4日 11:44 收件人: Qin Wu <bill...@huawei.com<mailto:bill...@huawei.com>> 抄送: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>>; The IESG <i...@ietf.org<mailto:i...@ietf.org>>; alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; draft-ietf-alto-path-vec...@ietf.org<mailto:draft-ietf-alto-path-vec...@ietf.org>; alto@ietf.org<mailto:alto@ietf.org>; Mohamed Boucadair <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 主题: Re: 答复: Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT) Hi Roman and all, Happy New Year! We have submitted a new version of the Path Vector draft (-20) [1]. The proposed texts are integrated in Section 11. Please let us know if they address you comments. Best, Kai [1] https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-path-vector-19&url2=draft-ietf-alto-path-vector-20 2021-12-16 14:56:27"Qin Wu" <bill...@huawei.com><mailto:>wrote: Hi, Roman: It seems the leading author can not reach you via his personal email address (kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>). Therefore I forward his recent reply to you. Please help take a look at his proposed text and tell us whether it can address your comments. -Qin 发件人: kai...@scu.edu.cn<mailto:kai...@scu.edu.cn> [mailto:kai...@scu.edu.cn] 发送时间: 2021年12月16日 9:37 收件人: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> 抄送: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; draft-ietf-alto-path-vec...@ietf.org<mailto:draft-ietf-alto-path-vec...@ietf.org>; alto@ietf.org<mailto:alto@ietf.org>; Qin Wu <bill...@huawei.com<mailto:bill...@huawei.com>>; Mohamed Boucadair <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 主题: Re: Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT) Hi Roman, Please find below for the proposed text for Sec 11. Please let us know if it makes sense and any further comments or suggestions are welcomed! Best, Kai -----Original Messages----- From:kai...@scu.edu.cn Sent Time:2021-12-06 22:53:04 (Monday) To: "Roman Danyliw" <r...@cert.org<mailto:r...@cert.org>> Cc: "The IESG" <i...@ietf.org<mailto:i...@ietf.org>>, alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>, draft-ietf-alto-path-vec...@ietf.org<mailto:draft-ietf-alto-path-vec...@ietf.org>, alto@ietf.org<mailto:alto@ietf.org> Subject: Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT) Hi Roman, Thanks for the review and please see the replies inline. > -----Original Messages----- > From: "Roman Danyliw via Datatracker" > <nore...@ietf.org<mailto:nore...@ietf.org>> > Sent Time: 2021-11-30 23:33:54 (Tuesday) > To: "The IESG" <i...@ietf.org<mailto:i...@ietf.org>> > Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>, > draft-ietf-alto-path-vec...@ietf.org<mailto:draft-ietf-alto-path-vec...@ietf.org>, > alto@ietf.org<mailto:alto@ietf.org> > 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. We have discussed with the chairs and agree that the document proceeds as experimental. OLD: From "For confidentiality of ALTO information, ..." to "by using minimal feasible region compression algorithms [NOVA] or obfuscation protocols [RESA][MERCATOR]." NEW: For confidentiality of ALTO information, a network operator should be aware that this extension may introduce a new risk: the Path Vector information, when used together with sensitive ANE properties such as capacities of bottleneck links, may make network attacks easier. For example, as the Path Vector information may reveal more fine-grained internal network structures than the base protocol, an attacker may identify the bottleneck link and start a distributed denial-of-service (DDoS) attack involving minimal flows to conduct the in-network congestion. Given the potential risk of leaking sensitive ^^^^^^ the applicability statement starts here information, the Path Vector extension is mainly applicable in scenarios where 1) the ANE structures and ANE properties do not impose security risks to the ALTO service provider, e.g., not carrying sensitive information, or 2) the ALTO server and client have established a reliable trust relationship, for example, operated in the same administrative domain, or managed by business partners with legal contracts. ^^^^^ Two cases are discussed: 1) PV does not impose security risks ^^^^^ e.g., not carrying sensitive information, and 2) PV carries sensitive ^^^^^ information between server/client of a reliable trust relationship. Three risk types are identified in Section 15.3.1 of {{RFC7285}}: (1) Excess disclosure of the ALTO service provider’s data to an unauthorized ALTO client; (2) Disclosure of the ALTO service provider's data (e.g., network topology information or endpoint addresses) to an unauthorized third party; and (3) Excess retrieval of the ALTO service provider’s data by collaborating ALTO clients. To mitigate these risks, an ALTO server MUST follow the guidelines in Section 15.3.2 of {{RFC7285}}. Furthermore, an ALTO server MUST follow the following additional protections strategies for risk types (1) and (3). ^^^^^ We revisit RFC 7285 and identify additional protections for PV. ^^^^^ Note that risk type (2) is not affected. For risk type (1), an ALTO server MUST use the authentication methods specified in Section 15.3.2 of [RFC7285] to authenticate the identify of an ALTO client, and apply access control techniques to restrict unprivileged ALTO clients from retrieving sensitive Path Vector information. 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. Otherwise, the ALTO server MUST NOT offer the Path Vector service carrying sensitive information to the clients unless the potential risks are fully assessed and mitigated. For risk type (3), an ALTO server MUST use dynamic mappings from ephemeral ANE names to underlying physical entities. Thus, ANE names contained in the Path Vector responses to different clients or even for different request from the same client SHOULD point to different physical entities. Further, to protect the network topology from graph reconstruction (e.g., through isomorphic graph identification [BONDY]), the ALTO server SHOULD consider protection mechanisms to reduce information exposure or obfuscate the real information. When doing so, the ALTO server must be aware that information reduction/obfuscation may lead to potential Undesirable Guidance from Authenticated ALTO Information risk (Section 15.2 of [RFC7285]). [BONDY] J.A. Bondy, R.L. Hemminger, “Graph reconstruction—a survey” J. Graph Theory, 1 (1977) pp. 227–268 Thus, implementations of ALTO servers involving reduction or obfuscation of the Path Vector information SHOULD consider reduction/obfuscation mechanisms that can preserve the integrity of ALTO information, for example, by using minimal feasible region compression algorithms [NOVA] or obfuscation protocols [RESA][MERCATOR]. However, these obfuscation methods are experimental and their practical applicability of these methods ^^^^^ We make it clear that these obfuscation methods ^^^^^ are experimental. to the generic capability provided by this extension is not fully assessed. The ALTO server MUST carefully verify that the deployment scenario satisfies the security assumptions of these methods before applying them to protect Path Vector services with sensitive network information. > > ---------------------------------------------------------------------- > 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 > alto@ietf.org<mailto:alto@ietf.org> > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto