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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 26 Jan 2022 12:55:57 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-alto-path-vector-20: 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:
----------------------------------------------------------------------

(Updated ballot to make the remaining issues clear)

Thanks for the update in -20 and in particular all of the new language in the
Security considerations to discuss applicability and obfuscation procedures.

In these edits in response to the earlier DISCUSS text, the following sentence
was introduced into Section 11:

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.

It appears to be trying to provide guidance on how to ensure that only the
expected ALTO clients get the sensitive path information in the case where the
server and clients are in different trust domains.  This new language contains
normative guidance to using DRM techniques.  Given this is a normative “MUST”,
the specifics of “DRM techniques” is under-specified.  Independent of that, DRM
techniques I quickly think of provides object security (i.e., embedding a
security envelope of some form directly in the data it is trying to protect). 
How would that mesh with the specified format for the path information in this
document?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Samuel Weiler for the SECDIR review.

Thanks for addressing my COMMENTs.

Previous DISCUSS point below
======
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.