Subject: [alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 30 Nov 2021 07:33:54 -0800

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>.