RFC6708：Application-Layer Traffic Optimization (ALTO) Requirements，September 2012
梗概
许多 Internet 应用程序用于访问资源，例如在不同主机上的多个等效副本中可用的信息或服务器进程。这包括但不限于点对点文件共享应用程序。应用层流量优化 (Application-Layer Traffic Optimization，ALTO) 的目标是为应用程序提供指导，这些应用程序必须从一组能够提供所需资源的候选主机中选择一个或多个主机。该指南应基于影响主机之间数据传输性能和效率的参数，例如拓扑距离。最终目标是提高应用程序的性能或体验质量，同时降低底层网络基础设施的利用率。
本文档列举了指定、评估或比较协议和实现的要求。
本备忘录的状态
本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。
有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6708。
版权声明
版权所有 (c) 2012 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。
1、 介绍
应用层流量优化 (ALTO) 的动机在 ALTO 问题陈述 [RFC5693-“奥拓”？应用层流量优化 (ALTO) 问题陈述] 中有所描述。
ALTO 的目标是提供可以帮助点对点(peer-to-peer，P2P) 应用程序在对等体选择方面做出更好决策的信息。但是，ALTO 也可能对非 P2P 应用程序有用。例如，客户端-服务器应用程序的客户端可以使用 ALTO 提供的信息来选择多个服务器或信息副本之一。作为另一个示例，ALTO 信息可用于选择 NAT 穿越所需的媒体中继。这些明智决策的目标是提高应用程序的性能或体验质量，同时降低底层网络基础设施的利用率。
通常，由于复杂性或因为它基于网络拓扑信息、网络运营成本或网络策略，相应的网络提供商不想详细披露。
提供 ALTO 服务的功能实体不参与实际的用户数据传输，即它们不实现中继用户数据的功能。这些功能实体可以放置在各种物理节点上，例如，在专用服务器上，作为路由器中的辅助进程，P2P 应用程序的“跟踪器”或“超级对等体”等。
2、 术语和架构框架
2.1、 需求符号
本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是解释为 [RFC2119] 中的描述。
2.2、 ALTO术语
本文档使用以下 ALTO 相关术语，这些术语在 [RFC5693-“奥拓”？应用层流量优化 (ALTO) 问题陈述] 中定义：
Application，Peer，P2P，Resource，Resource Identifier，Resource Provider，Resource Consumer，Transport Address，Overlay Network，Resource Directory，ALTO Service，ALTO Server，ALTO Client，ALTO Query，ALTO Response，ALTO Transaction，Local Traffic，Peering Traffic，Transit Traffic，Application Protocol，ALTO Client Protocol，和 Provisioning Protocol。
此外，将使用以下附加术语：
Host-Group Descriptor/主机组描述符
用于描述一个或多个 Internet 主机（例如寻求 ALTO 指导的资源消费者，或一个或多个候选资源提供者）及其在网络拓扑中的位置的信息。可以有多种不同类型的主机组描述符，例如，单个 IP 地址、包含主机的地址前缀或地址范围或自治系统 (Autonomous System，AS) 编号。不同的主机组描述符类型可能提供不同级别的详细信息。根据系统架构的不同，这可能会影响 ALTO 能够提供的指导质量、是否可以汇总建议，以及可能会向其他方披露多少有关用户的隐私敏感信息。
Rating Criterion/评级标准
定义“优于随机同行选择”中“更好”的条件或关系，这是ALTO的最终目标。示例可能包括“主机的互联网访问不受基于流量的收费（统一费率）”或“低拓扑距离”。一些评级标准，例如“低拓扑距离”，需要包括一个参考点，例如“距给定资源消费者的低拓扑距离”。该参考点可以通过主机组描述符来描述。
Host-Characteristics Attribute/主机特性属性
主机的属性，主机组描述符除外。可以根据一个或多个评级标准对其进行评估。该信息可以存储在 ALTO 服务器中并通过 ALTO 协议传输。主机特性属性的一个示例是一个数据字段，该字段指示主机的 Internet 访问是否需要按量计费（统一费率）。
Target-Aware Query Mode/目标感知查询模式
在这种操作模式下，当所需资源和一组候选资源提供者已知时，ALTO 客户端执行 ALTO 查询，即在分布式哈希表 (Distributed Hash Table，DHT) 查找后，查询到资源目录等。为此，ALTO 客户端将主机组描述符列表和可选的一个或多个评级标准传输到 ALTO 服务器。ALTO 服务器根据指定的标准或默认标准评估主机组描述符。它将这些主机组描述符的列表返回给 ALTO 客户端，该列表根据评级标准进行排序和/或通过主机特征属性进行丰富。
Target-Independent Query Mode/目标无关查询模式
在这种操作模式下，ALTO 查询是提前或定期执行的，以获得全面的指导。ALTO 客户端在 ALTO 查询中指示所需的主机特征属性。ALTO 服务器用一个列表回答所有已知的主机组描述符（可能受服务器策略的影响）所需的主机特征属性。这些列表将在本地缓存并在稍后访问资源时进行评估。
2.3、 ALTO 的架构框架
ALTO 实现有多种架构选择。指定或强制要求一种特定的架构超出了本文档的范围。
除了术语（参见 [RFC5693-“奥拓”？应用层流量优化 (ALTO) 问题陈述] 的第 2 节和本文档的第 2.2 节），[RFC5693] 还提供了一个图表，该图给出了这些组件之间协议交互的高级概述。
本文档逐条列出了对以下组件的要求：ALTO 客户端协议、ALTO 服务器发现机制、主机组描述符、评级标准和主机特性属性。此外，还提出了有关整体架构的要求，尤其是在安全和隐私问题方面。
请注意，此类协议和机制的详细规范超出了本文档的范围。事实上，本文档甚至没有假设这些组件中的每一个都只有一个单独的规范。但是，本文档列举了在指定、评估或比较协议和实现时要考虑的 ALTO 要求。
3、 ALTO 要求
3.1、 ALTO 客户端协议
3.1.1、 一般要求
要求AR-1：ALTO 服务由一台或多台 ALTO 服务器提供。ALTO 客户可能会询问它，以寻求选择合适的资源提供商的指导。ALTO 客户端和 ALTO 服务器必须实现 ALTO 客户端协议。ALTO 客户端协议必须能够将 ALTO 查询从 ALTO 客户端传输到 ALTO 服务器，并且它必须能够将相应的 ALTO 回复从 ALTO 服务器传输到 ALTO 客户端。
ALTO 客户端协议的详细规范超出了本文档的范围。事实上，本文档甚至没有假设只有一个协议规范。但是，本文档列举了 ALTO 的要求，在指定、评估或比较协议和实现时要考虑这些要求。
要求AR-2：ALTO 客户端协议必须提供足够的操作和管理支持机制，如 RFC 5706 [RFC5706] 中所述。
3.1.2、 主机组描述符支持
ALTO 指南基于对多个资源提供者或资源提供者组的评估，并考虑一个或多个评级标准。资源提供者或资源提供者组通过主机组描述符来表征。
要求AR-3：ALTO 客户端协议必须支持使用多种主机组描述符类型。
要求AR-4：ALTO 客户端和 ALTO 服务器必须清楚地识别在 ALTO 查询或响应中发送的每个主机组描述符的类型。ALTO 协议规范必须提供适当的协议元素。
要求AR-5：ALTO 客户端协议必须支持主机组描述符类型“IPv4 地址前缀”和“IPv6 地址前缀”。它们可用于指定一台主机的 IP 地址，或包含所有相关主机的 IP 地址范围（以无类别域间路由 (Classless Inter-Domain Routing，CIDR) 表示法）。
要求AR-6：ALTO 客户端协议必须是可扩展的，以便将来支持其他主机组描述符类型。ALTO 客户端协议规范必须定义适当的程序来添加新的主机组描述符类型，例如，通过建立 IANA 注册。
要求AR-7：对于除“IPv4 地址前缀”和“IPv6 地址前缀”以外的主机组描述符类型，主机组描述符类型标识必须通过引用可用于转换主机组描述符的工具来补充这种类型的 IPv4/IPv6 地址前缀，例如，通过映射表或算法。
要求AR-8：将其他主机组描述符类型映射到 IPv4/IPv6 地址前缀的协议功能应该被设计和指定为 ALTO 客户端协议的一部分，并且相应的地址映射信息应该由想要的同一实体提供在 ALTO 客户端协议中使用这些主机组描述符。然而，ALTO 服务器或 ALTO 客户端也可以发送对外部映射工具的引用，例如，要通过替代机制获得的转换表。
前两个要求的基本原理：主机组描述符的首选类型是 IPv4 和 IPv6 前缀。但是，在某些情况下，一方可能更喜欢使用另一种类型，例如 AS 号码。通常，寻求 ALTO 指导的应用程序使用 IP 地址，例如，在建立连接时。理解基于其他主机组描述符类型的指导信息，即从这些其他类型映射到 IP 前缀并返回，可能是一项重要的任务。因此，在一方可以使用其他主机组描述符类型之前，他们必须提供到 IP 前缀的映射机制。
要求AR-9：ALTO 客户端协议规范必须定义可由 ALTO 服务器使用的机制，以指示 ALTO 客户端使用的主机组描述符是不受支持的类型，或者指示的映射机制无法使用。
要求AR-10：ALTO 客户端协议规范必须定义可由 ALTO 客户端使用的机制，以指示 ALTO 服务器使用的主机组描述符是不受支持的类型，或者指示的映射机制无法使用。
3.1.3、 评级标准支持
要求AR-11：ALTO 客户端协议规范必须定义可用于表达和评估“相对运营商偏好”的评级标准。这是一个相对度量，即它不与任何度量单位相关联。根据此标准，首选评级表明应用程序应优先选择相应的候选资源提供者，而不是其他具有较低首选评级的资源提供者（除非来自非 ALTO 来源的信息建议不同的选择，例如表明路径当前拥塞的传输尝试）。ALTO 服务器的运营商不必公开评级是如何以及基于哪些数据实际计算的。示例可能是：对等体或传输流量的成本、网络内的流量工程和其他策略。
要求AR-12：ALTO 客户端协议必须是可扩展的，以便将来支持其他评级标准类型。ALTO 客户端协议规范必须定义适当的程序来添加新的评级标准类型，例如，通过建立 IANA 注册。
要求AR-13：ALTO 客户端协议规范不得定义与瞬时网络拥塞状态密切相关的评级标准，即评级标准的主要目的是作为既定拥塞控制策略的替代方案，例如使用基于 TCP 的传输。
要求AR-14：使用 ALTO 引导的应用程序不得仅依赖 ALTO 引导以避免导致网络拥塞。相反，他们必须使用其他适当的方式，例如基于 TCP 的传输，以避免造成过度拥塞。
先前要求的基本原理： ALTO 的一个设计假设是主机特性属性可以接受，这些属性在 ALTO 服务器中存储和处理以提供指导，但很少更新。典型的更新间隔可能比典型的网络层数据包往返时间 (round-trip time，RTT) 长几个数量级。因此，ALTO 不能替代类似 TCP 的拥塞控制机制。
要求AR-15：在目标独立查询模式下，ALTO 查询消息应该允许 ALTO 客户端表达应该返回哪些主机特征属性。
要求AR-16：在目标感知查询模式下，ALTO 查询消息应该允许 ALTO 客户端表达服务器应该考虑哪些评级标准，以及它们与最终将使用指导。相应的 ALTO 响应消息应该允许 ALTO 服务器表达在生成响应时考虑了哪些评级标准。
要求AR-17：ALTO 客户端协议规范必须定义可由 ALTO 客户端和 ALTO 服务器使用的机制，以指示另一方使用的评级标准是不受支持的类型。
3.1.4、 实体的放置和操作的时间
关于 ALTO 客户端的放置，存在几种操作模式：
ALTO 操作的一种模式是 ALTO 客户端可以直接嵌入到资源消费者中，即最终将向/从所选资源提供者发起数据传输以访问所需资源的应用协议实体。例如，ALTO 客户端可以集成到 P2P 应用程序的对等体中，该应用程序使用分布式算法（例如“查询泛洪”）进行资源发现。
另一种操作方式是将ALTO客户端集成到第三方中，比如资源目录。考虑到各自的资源消费者，该第三方可以发出 ALTO 查询以征求对潜在资源提供者的偏好。例如，可以将 ALTO 客户端集成到基于跟踪器的 P2P 应用程序的跟踪器中，以便代表联系跟踪器的对等体请求 ALTO 指导。
要求AR-18：ALTO 客户端协议必须支持 ALTO 客户端直接嵌入资源消费者的操作模式。
要求AR-19：ALTO 客户端协议必须支持 ALTO 客户端嵌入第三方的操作模式。该第三方代表资源消费者执行查询。
要求AR-20：ALTO 客户端协议的设计方式必须确保 ALTO 服务可以由不是底层 IP 网络运营商的实体提供。
要求AR-21：ALTO 客户端协议的设计方式必须使不同提供商运营的 ALTO 服务的不同实例可以共存。
要求AR-22：ALTO 客户端协议规范必须至少指定一种查询模式，目标感知或独立于目标的查询模式。
请注意，此需求文档并不假设只有一个协议规范。
要求AR-23：ALTO 客户端协议规范应该指定目标感知和目标独立查询模式。如果 ALTO 客户端协议规范指定了多个查询模式，则必须将这些模式中的至少一种定义为 REQUIRED 以供 ALTO 客户端和 ALTO 服务器实现。此外，它必须为 ALTO 客户端和 ALTO 服务器之间的协商指定适当的协议机制，使用哪种查询模式。
要求AR-24：ALTO 客户端协议应该支持 ALTO 事务中的版本编号、TTL（time-to-live，生存时间）属性和/或类似机制，以便为缓存启用时间有效性检查，并启用对获得的多个建议的比较通过再分配。
要求AR-25：ALTO 客户端协议应该允许 ALTO 服务器将有关适当重用模式的信息添加到其 ALTO 响应中。重用可能包括将 ALTO 响应重新分发给其他方，以及在资源目录中使用相同的 ALTO 信息来改进在 ALTO 响应的指定生命周期内对不同资源消费者的响应。ALTO 服务器应该能够表达
** 不应发生重复使用。
** 重用适用于特定的“目标受众”，即由主机组描述符列表明确定义的一组资源消费者。ALTO 服务器可以在 ALTO 响应中指定一个“目标受众”，它只是已知实际“目标受众”的一个子集，例如，如果运营商政策要求。
** 重用适用于将发送（或导致第三方代表它发送）相同 ALTO 查询（即，具有相同的查询参数，除了资源使用者 ID，如果适用）的任何资源使用者ALTO服务器。
** 重用适用于将向任何资源消费者发送（或导致第三方代表它发送）相同 ALTO 查询（即，具有相同的查询参数，除了资源消费者 ID，如果适用）的任何资源消费者与此 ALTO 服务器一起发现的其他 ALTO 服务器（使用 ALTO 发现机制）。
** 重用适用于将向任何资源消费者发送（或导致第三方代表它发送）相同 ALTO 查询（即，具有相同的查询参数，除了资源消费者 ID，如果适用）的任何资源消费者全网ALTO服务器。
要求AR-26：ALTO 客户端协议必须支持 ALTO 事务的传输，即使 ALTO 客户端位于网络地址转换器 (network address translator，NAT) 后面的私有地址域中。有不同类型的 NAT，参见 [RFC4787] 和 [RFC5382]。
3.1.5、 协议扩展性
要求AR-27：ALTO 客户端协议必须支持以无中断、向后兼容的方式添加协议扩展。
要求AR-28：ALTO 客户端协议必须包括协议版本支持，以便清楚地区分不兼容的协议版本。
3.1.6、 错误处理和过载保护
要求AR-29：ALTO 客户端协议必须使用拥塞感知传输，例如，通过使用 TCP。
要求AR-30：ALTO 客户端协议规范必须为 ALTO 服务器指定机制，以通知客户端即将发生或正在发生的过载情况，或如何利用底层协议层提供的适当机制。这些机制必须为服务器提供以下所有选项：
* 终止与客户端的对话，
* 将客户端重定向到另一个 ALTO 服务器，以及
* 请求客户端限制其查询率。
特别是，一种简单的节流形式是让 ALTO 服务器用错误消息回答查询，建议客户端稍后重试查询（例如，使用协议功能，如 HTTP 的 Retry-After 报文头（[RFC2616]，第 14.37 节））。另一个简单的选择是用所需的信息实际回答查询，但添加一个指示，表明 ALTO 客户端不应在指定的时间段过去之前向该 ALTO 服务器发送进一步的查询。
要求AR-31：ALTO 客户端协议规范必须为 ALTO 服务器指定机制，以通知客户端由于技术问题或系统维护而无法回答查询，或者如何利用底层协议层提供的适当机制。这些机制必须为服务器提供以下所有选项：
* 终止与客户端的对话，
* 将客户端重定向到另一个 ALTO 服务器，以及
* 请求客户端稍后重试查询。
注意：上述协议机制的存在并不意味着ALTO服务器在面临过载、技术问题或维护情况时必须分别使用它们。在这种情况下，某些服务器可能无法使用它们，或者它们可能更愿意简单地拒绝连接或根本不发送任何答案。
3.2、 ALTO 服务器发现
ALTO 客户端协议由一个或多个 ALTO 服务器发现机制支持，ALTO 客户端可以使用这些机制来确定一个或多个 ALTO 服务器，ALTO 请求可以发送到这些服务器。本节列举了 ALTO 客户端的要求，以及 ALTO 服务器发现机制要满足的一般要求。
要求AR-32：ALTO 服务器发现机制必须支持允许嵌入在资源消费者中的 ALTO 客户端使用与 ALTO 客户端兼容的 ALTO 协议版本找到一个或多个可以提供适合资源消费者的 ALTO 指导的 ALTO 服务器的功能。这种操作模式称为“资源消费者发起的ALTO服务器发现”。
要求AR-33：ALTO 服务器发现机制必须支持允许嵌入资源目录中的 ALTO 客户端并代表远程资源消费者执行第三方 ALTO 查询的功能，以找到一个或多个可以提供适用于以下情况的 ALTO 指导的 ALTO 服务器各自的资源消费者，使用与 ALTO 客户端兼容的 ALTO 协议版本。这种操作模式称为“第三方ALTO服务器发现”。
要求AR-34：ALTO 客户端必须能够执行资源消费者发起的 ALTO 服务器发现，即使它们位于 NAT 后面。
要求AR-35：ALTO 客户端必须能够执行第三方 ALTO 服务器发现，即使它们位于 NAT 之后。
要求AR-36：ALTO 客户端必须能够执行第三方 ALTO 服务器发现，即使将代表 ALTO 查询发送的资源消费者位于 NAT 之后。
要求AR-37：ALTO 服务器发现机制应该利用现有的协议或机制，例如基于 DNS、DHCP 或 PPP 的自动配置等。具有广泛适用性的单一机制应该优先于几种不同的机制范围更窄。
要求AR-38：每个 ALTO 服务器发现机制应该能够返回多个 ALTO 服务器各自的联系信息。
要求AR-39：每个 ALTO 服务器发现机制应该能够指示每个返回的 ALTO 服务器联系信息的偏好。
3.3、 安全和隐私
注意：以下要求要求在协议规范级别包含某些安全机制。在给定的部署场景中启用这些机制是否有意义取决于针对该特定场景的威胁分析。信息披露潜在风险分类参见5.2节。
要求AR-40：ALTO 客户端协议规范必须指定 ALTO 服务器的身份验证机制或指定如何利用底层协议层提供的适当机制。
要求AR-41：ALTO 客户端协议规范必须指定 ALTO 客户端的身份验证机制或指定如何利用底层协议层提供的适当机制。
要求AR-42：ALTO 客户端协议规范必须指定消息加密机制或指定如何利用底层协议层提供的适当机制。
要求AR-43：ALTO 客户端不需要实施机制或遵守限制其重新分发从 ALTO 服务器检索到的信息给第三方的能力的规则。
要求AR-44：ALTO 客户端协议必须支持查询和响应中不同级别的详细信息，以保护用户的隐私，以确保 ALTO 服务器的运营商和同一应用程序的其他用户无法获得敏感信息。
要求AR-45：ALTO 客户端协议可以包括 ALTO 客户端在请求指导以指定其想要访问的资源（例如，内容标识符）时可以使用的机制。ALTO 服务器必须提供足够的指导，即使 ALTO 客户端不想指定所需的资源（例如，保持数据字段为空）。如果 ALTO 客户端不愿意指定资源标识符（例如，P2P 文件共享中的文件名），则该机制必须设计为使得 ALTO 服务器的运营商无法轻易推断出资源标识符。
要求AR-46：ALTO 客户端协议规范必须指定适当的机制来保护 ALTO 服务免受拒绝服务 (Denial-of-Service，DoS) 攻击或指定如何利用底层协议层提供的适当机制。
4、 IANA 考虑
本要求文件不强制要求立即采取任何 IANA 行动。但是，此类 IANA 考虑因素可能来自未来的 ALTO 规范文档，这些文档试图满足此处给出的要求。
5、 安全考虑
5.1、 高级安全注意事项
ALTO 服务的高级安全注意事项可以在 ALTO 问题陈述文档 [RFC5693-“奥拓”？应用层流量优化 (ALTO) 问题陈述] 的“安全注意事项”部分找到。
5.2、 信息披露场景
不必要的信息披露是与 ALTO 相关的关键问题之一。ALTO 服务器或使用或滥用 ALTO 服务的第三方都不应以侵犯用户隐私的方式推断应用程序行为或关联数据，例如，谁使用 P2P 文件共享与谁交换哪些文件应用。此外，许多网络运营商担心可能通过 ALTO 发布的与其网络基础设施相关的信息量（例如，拓扑信息、“高级客户”数量或利用率统计信息）。本节对信息披露场景和潜在对策进行分类和讨论。
5.2.1、 信息披露场景分类
以下问题可能被视为 ALTO 服务器运营商的风险，具体取决于具体部署场景：
(1) 向授权的 ALTO 客户端过度披露 ALTO 服务器运营商的数据。 ALTO 服务器的运营商必须将信息（例如将主机组描述符映射到主机特征属性的表）提供给服务器，从而使其能够为 ALTO 客户端提供指导。一些运营商可能认为该信息的完整集合是机密的（例如，运营商网络拓扑的详细地图），并且可能只想公开其中的一个子集或以某种方式向 ALTO 客户端公开混淆的信息。
(2) 向未经授权的第三方披露 ALTO 服务器运营商的数据（例如，网络拓扑信息）。这里有三个子案例：
(2a) ALTO 服务器接收并回答来自未经授权的 ALTO 客户端的查询。
(2b) 未授权方窥探从 ALTO 服务器到授权 ALTO 客户端的数据传输。
(2c) 授权的 ALTO 客户端有意将其从 ALTO 服务器接收到的信息转发给未授权方。
(3) 通过合作ALTO客户端对ALTO服务器运营商数据的过度检索。几个授权的 ALTO 客户端可以向一个或多个 ALTO 服务器请求指导，可能在很长一段时间内多次，并在彼此之间重新分配响应（另见案例 2c）。通过汇总和关联 ALTO 响应，他们可以找到比 ALTO 服务器运营商打算披露的更多信息。
以下问题可能被视为对 ALTO 客户端用户的风险，具体取决于特定的部署场景：
(4) 向（授权的）ALTO服务器披露应用行为或其他用户隐私数据。 ALTO 服务器的运营商可以从 ALTO 客户端发送的 ALTO 查询推断应用程序行为（例如，P2P 文件共享应用程序中的内容标识符，或考虑建立连接的资源提供者列表）。
(5) 向未经授权的第三方披露应用行为或其他用户隐私数据。这里有三个子案例：
(5a) ALTO 客户端愿意直接向不受信任或恶意的 ALTO 服务器发送查询，这可能是由于 ALTO 服务器发现机制的伪造响应。
(5b) 未授权方窥探从 ALTO 客户端到授权 ALTO 服务器的数据传输。
(5c) 授权的 ALTO 服务器有意将其从 ALTO 客户端收到的信息转发给未授权方。
(6) 一个或多个协作（见案例 5c）ALTO 服务器可能会尝试通过聚合和关联来自一个或多个 ALTO 客户端的查询来推断应用程序行为或其他用户私有数据，可能是在很长一段时间内。
5.2.2、 信息披露情景讨论
ALTO 服务器运营商应考虑：
** 问题 (1) 可以由 ALTO 服务器操作员选择要填充到 ALTO 服务器并在响应中返回的信息的详细级别来解决。例如，通过指定比所讨论的一组主机实际使用的地址范围更广的地址范围（即，更短的前缀长度），ALTO 服务器运营商可以在一定程度上控制关于网络拓扑结构的多少信息被公开。此外，可能会在 ALTO 服务器中安装用于根据经过身份验证的 ALTO 客户端身份过滤 ALTO 响应的访问控制机制，尽管鉴于缺乏用于寻址 (2c) 和 (3) 的有效机制，这可能不是有效的，见下文。
** (2a) 和 (2b) 可以通过 ALTO 客户端协议的身份验证、访问控制和加密方案来解决。然而，由于缺乏用于寻址 (2c) 和 (3) 的有效机制，加密方案的部署可能不会有效，见下文。
** 简单的认证和加密方案无助于解决（2c）和（3），并且没有其他已知的简单有效的机制。复杂方法的成本，例如基于数字版权管理 (DRM) 的方法，可能很容易超过整个 ALTO 解决方案的好处；因此，它们不被视为可行的解决方案。也就是说，ALTO服务器运营商必须意识到，（2c）和（3）的发生是无法避免的；因此，他们应该只将这样的数据馈送到 ALTO 服务器，他们认为对于 (2c) 和 (3) 不敏感。
ALTO 客户端的用户应该考虑：
** 问题 (4) 可以并且需要通过多种方式解决：如果 ALTO 客户端嵌入在资源消费者中，则资源消费者的 IP 地址（或资源消费者前面最外层 NAT 的“公共”IP 地址）原则上会向 ALTO 服务器公开，因为它位于 IP 报文头的源地址字段中。通过使用代理，可以避免将源地址泄露给 ALTO 服务器，代价是将它们泄露给所述代理。相反，如果 ALTO 客户端嵌入在代表资源消费者发出 ALTO 请求的第三方（例如，资源目录）中，则可以向 ALTO 服务器隐藏资源消费者的确切地址，例如，通过将 IP 地址的最后几位清零或随机化。但是，存在产生不准确结果的潜在副作用。
通过允许 ALTO 客户端使用与目标无关的查询模式，可以避免将候选资源提供者的地址泄露给 ALTO 服务器。在这种操作模式下，从 ALTO 服务器检索引导信息（例如，“地图”）并完全由 ALTO 客户端在本地使用，即，无需将候选资源提供者的主机位置属性发送到 ALTO 服务器。在目标感知查询模式下，ALTO 客户端可以通过混淆候选资源消费者的身份来解决这个问题，例如，通过指定比一组有问题的主机实际使用的地址范围更广的地址范围（即更短的前缀长度） ，或者通过将 IP 地址的最后几位清零或随机化。但是，存在产生不准确结果的潜在副作用。
** (5a) 可以通过强制要求 ALTO 服务器发现过程作为一个整体必须安全防止欺骗来解决。
注意：鉴于本文档并未强制要求特定的系统架构，因此很难指定比发现过程作为一个整体应该是安全的、可以防止欺骗的更多细节。有许多不同的架构选项，例如，具有不安全的发现机制并使用服务器证书稍后验证其响应（参见万维网中广泛使用的 DNS + HTTPS 安全模型）。因此，在这个需求阶段，发现机制本身并不强制要求能够抵御欺骗攻击。
** (5b) 可以通过 ALTO 客户端协议的加密方案来解决。但是，应该针对任何特定部署场景评估工作量与收益，同时还要考虑问题 (4)、(5c) 和 (6) 的风险和解决方案。
** 直接的身份验证和加密方案无助于解决 (5c) 和 (6)。但是，可以使用与问题 (4) 相同的方法来减轻潜在风险，请参见上文。
这些见解反映在本文档的要求中。
5.3、 ALTO 服务器发现
见上面(5a)的讨论。
5.4、 安全要求
有关一组特定的安全要求，请参阅本文档的第 3.3 节。
6、 参考文献
6.1、 规范参考
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
6.2、 参考资料
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
附录 A、 贡献者
本文档的早期草稿版本由 Laird Popkin 合著。
附录 B、 致谢
作者要感谢 Vijay K. Gurbani 和 Enrico Marocco 促成了导致创建本文档的讨论，并对其提出了宝贵的意见。
作者要感谢 P2PI 和 ALTO 邮件列表成员的贡献和反馈，特别是：Richard Alimi、Jason Livingood、Michael Scharf、Nico Schwan 和 Jan Seedorf。
Laird Popkin 和 Y. Richard Yang 对 P4P 工作组和耶鲁大学网络系统实验室成员的许多贡献表示感谢。P4P 工作组由 DCIA 主持。
Martin Stiemerling 得到了 COAST 项目（内容感知搜索、检索和流媒体，http://www.coast-fp7.eu）的部分支持，该研究项目由欧盟委员会根据其第 7 框架计划（合同编号 248036）提供支持.此处包含的观点和结论是作者的观点和结论，不应被解释为必然代表 COAST 项目或欧盟委员会的官方政策或认可，无论明示或暗示。
