Multi-Cost Application-Layer Traffic Optimization (ALTO)
RFC 8189

Received changes through RFC Editor sync (changed abstract to 'The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.

This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics.')

Received changes through RFC Editor sync (created alias RFC 8189, changed title to 'Multi-Cost Application-Layer Traffic Optimization (ALTO)', changed abstract to 'The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.', changed pages to 29, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2017-10-24, changed IESG state to RFC Published)

[Ballot discuss]
This document states:
"This document does not introduce any privacy or security issues not
  already present in the ALTO protocol."

This may be true, but it's not obvious it is, because when questions are asked together, that's more of a privacy signature than independently. So, suppose that application A asks for metric A and application B asks for metric B and application C asks for A and B. If these applications are mixed behind a CGN, with single queries then you don't know whether you have some A clients and some B clients, but if you do multi-query, it's clear these are C clients. This is a potentially serious issue if (for instance) Bittorrent always asks for a very distinguished set of parameters, so an ALTO server might use this to find Bittorrent clients.

I don't think any normative change to the protocol is required here, but I do think you need to accurately characterize the situation. Something like the following text should be fine

"The privacy and security properties of the mechanism specified in this
document are generally similar to those already present in the ALTO
protocol. However, because queries for multiple metrics represent
a stronger fingerprinting signal than queries for a single metric,
implementations of this protocol may leak more information about the
ALTO client than would occur with a succession of individual queries;
although in many cases it would already be possible to link those
queries by using the source IP address or other existing information.
"

[Ballot discuss]
This document states:
"This document does not introduce any privacy or security issues not
  already present in the ALTO protocol."

This may be true, but it's not obvious it is, because when questions are asked together, that's more of a privacy signature than independently. So, suppose that application A asks for metric A and application B asks for metric B and application C asks for A and B. If these applications are mixed behind a CGN, with single queries then you don't know whether you have some A clients and some B clients, but if you do multi-query, it's clear these are C clients. This is a potentially serious issue if (for instance) Bittorrent always asks for a very distinguished set of parameters, so an ALTO server might use this to find Bittorrent clients.

I don't think any normative change to the protocol is required here, but I do think you need to accurately characterize the situation.

[Ballot discuss]
This document states:
"This document does not introduce any privacy or security issues not
  already present in the ALTO protocol."

This may be true, but it's not obvious it is, because when questions are asked together, that's more of a privacy signature than independently. So, suppose that application A asks for metric A and application B asks for metric B and application C asks for A and B. If these applications are mixed behind a CGN, with single queries then you don't know whether you have some A clients and some B clients, but if you do multi-query, it's clear these are C clients. This is a potentially serious issue if (for instance) Bittorrent always asks for a very distinguished set of parameters, so an ALTO server might use this to find Bittorrent clients.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-alto-multi-cost-07.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: alto@ietf.org, ietf@kuehlewind.net, ietf@j-f-s.de, alto-chairs@ietf.org, draft-ietf-alto-multi-cost@ietf.org, Jan Seedorf
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multi-Cost ALTO) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document:
- 'Multi-Cost ALTO'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-03-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The ALTO (Application Layer-Traffic Optimization) Protocol
  ([RFC7285]) defines several services that return various metrics
  describing the costs between network endpoints.  An ALTO Server may
  offer a variety of cost metrics, based on latency,bandwidth, hop
  count, jitter, or whatever else the ALTO Server deems useful.  For
  example, when downloading a file that is mirrored on several sites, a
  user application may consider more than one metric, perhaps trading
  bandwidth for latency to determine the most efficient mirror site.

  While the base ALTO Protocol allows an ALTO Client to use more than
  one cost metric, to do so, the Client must request each metric
  separately.  This document defines a new service that allows a Client
  to retrieve several cost metrics with one request, which is
  considerably more efficient.  In addition, this document extends the
  ALTO constraint tests to allow a user to specify an arbitrary logical
  combination of tests on several cost metrics.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1628/
  https://datatracker.ietf.org/ipr/2615/

1. Summary
Jan Seedorf is the document shepherd for draft-ietf-alto-multi-cost. Mirja Kühlewind is the responsible Area Director.

The document itself has a long history, having started as a -00 document in the ALTO WG as an individual draft in October 2010 (author: Sabine Randriamasy).  It transitioned to a WG document in May 2015 (after the ALTO WG had been re-chartered to work on extensions to the original ALTO protocol as specified in RFC 7285) (authors: Sabine Randriamasy, Wendy Roome, Nico Schwan).

The ALTO protocol as specified in RFC 7285 allows to only query results for one single ALTO cost metric in a given ALTO request. draft-ietf-alto-multi-cost defines a “new service that allows a client to retrieve several cost metrics with one request, which is considerably more  efficient” [draft-ietf-alto-multi-cost-04]. This is clearly a very useful extension of the ALTO protocol and covered in the current ALTO charter.

The working group is targeting this document as Standards Track, which is appropriate as the document extends the ALTO protocol, specifying new formats for allowed client requests (in JSON).


2. Review and Consensus
The document has been presented at multiple IETF meetings and discussed on the mailing list. It is well-known in the ALTO WG and there is clear consensus to standardise the proposed ALTO extension. A WGLC was issued on July 4, 2016.  During this WGLC a detailed review has been produced by Xin Wang, extensive additional comments were provided by Richard Yang and Hans Seidel. The comments raised have been addressed in the -03 version of draft-ietf-alto-multi-cost. Last outstanding comments have been finally addressed in the latest -04 (September 2016) and -05 versions (February 2017).

In summary, there is clear support and consensus for draft-ietf-alto-multi-cost in the ALTO WG, and it provides a very useful extension to the base ALTO protocol. A WGLC has successfully been passed, and extensive reviews were provided by various members of the WG and have all been addressed.


3. Intellectual Property
The shepherd confirms that each author has stated to him that to the best of his/her (i.e. the author’s) knowledge, all IPR related to this document has been disclosed.

There have been two IPR disclosures on this document (see https://datatracker.ietf.org/ipr/2615/ and https://datatracker.ietf.org/ipr/1628/). Both these IPR disclosures have been posted on the ALTO mailing list. There was no discussion on these IPR statements.


4. Other Points
This document does not introduce any IANA considerations and does not introduce any privacy or security issues that are not already present in the ALTO protocol.