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>wrote:
Hi, Roman:
It seems the leading author can not reach you via his personal email address
(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]
发送时间: 2021年12月16日 9:37
收件人: Roman Danyliw <r...@cert.org>
抄送: The IESG <i...@ietf.org>; alto-cha...@ietf.org;
draft-ietf-alto-path-vec...@ietf.org; alto@ietf.org; Qin Wu
<bill...@huawei.com>; Mohamed Boucadair <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>
Cc: "The IESG" <i...@ietf.org>, alto-cha...@ietf.org,
draft-ietf-alto-path-vec...@ietf.org, 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>
> Sent Time: 2021-11-30 23:33:54 (Tuesday)
> To: "The IESG" <i...@ietf.org>
> Cc: alto-cha...@ietf.org, draft-ietf-alto-path-vec...@ietf.org, 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
> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto