Session Date/Time: 30 May 2023 14:00

ALTO

Summary

The ALTO working group held its fifth interim meeting focusing on deployment considerations, security, privacy, and trust issues. The meeting featured two main presentations: one on "Trust-Enhanced ALTO" proposing various ways to integrate trust concepts into the ALTO protocol, and another on "Security Issues for ALTO Deployment" outlining risks and potential security-related properties for ALTO. Extensive discussion followed both presentations, highlighting the complexity and multi-faceted nature of trust and security in network information exchange. The chairs also invited feedback on the future charter of the working group.

Key Discussion Points

Trust-Enhanced ALTO (Presented by Ayub)
- Ayub presented a concept of integrating "trust" into ALTO to enhance network decision-making, security, and user satisfaction.
- Four initial ideas were proposed for trust integration:
  - Trusted IP-based geolocation: Enhancing accuracy and reliability of geolocation data provided by ALTO.
  - Trust as a cost measurement: Introducing trust as a non-renewable cost metric within ALTO, allowing for trust-aware resource selection.
  - Trust-enhanced property map: Creating a new ALTO map type focused on trust-related measurements for entities.
  - Multi-domain settings and trust: Facilitating information exchange between domains by establishing trust, especially for fine-grained information.
- Discussion on Trust-Enhanced ALTO:
  - Chairs' Initial Feedback: The chairs suggested that while integrating trust information is valuable, the current ALTO WG scope primarily focuses on the ALTO client-server interface and ALTO server-network infrastructure interface, not internal measurement or transport mechanisms for trust. They recommended reformulating the proposals into concrete use cases and requirements that fit the ALTO charter.
  - Trust as a Cost Metric: Participants expressed interest in "trust as a cost metric," particularly for policy-constrained routing (e.g., ensuring traffic stays within a geographical region like Europe). Questions arose regarding how such a subjective metric would be encoded (vector vs. filter) and standardized, with Ayub noting that a standard computation method with configurable weights for service providers could be considered.
  - Client Privacy: A concern was raised about protecting client privacy, specifically preventing the ALTO server from tracking client selections based on trust information. Ayub acknowledged this, suggesting potential solutions like third-party attestation for client trustworthiness.
  - Dimensions of Trust: Participants highlighted the multi-dimensional nature of "trust," including trust in the information itself, trust in the client, trust in the server, trust in the content provider, and trust in the path. It was suggested that these dimensions need to be clearly sorted out for any formal documentation.
  - Defining Trust Metrics: There was a discussion on whether the ALTO WG should define objective trust metrics or merely provide mechanisms for their conveyance. Ayub indicated that an initial focus on a new cost measurement might be more feasible than a dedicated trust map, and acknowledged the need to collaborate with other working groups (e.g., IPPM) and organizations to define "trust."
  - Architectural Implications: The point was made that ALTO traditionally relies on the server owning the information it distributes. Incorporating "trusted IP geolocation" might require new architectural elements, such as third-party entities for managing and distributing trusted information (e.g., certification authorities), which is currently a missing piece in ALTO.
  - Related Work: Suggestions were made to break down "trust" into specific attributes and consult relevant WGs such as IPPM (for metrics), RATS (for remote attestation), GeoPrivacy (concluded, but relevant to information management), and Privacy Preservation Management.
Security Issues for ALTO Deployment (Presented by Luis)
- Luis provided a comprehensive overview of security considerations based on ALTO deployment experiences (e.g., Telefonica CDN) and future use cases.
- The presentation distinguished between risks (security concerns for ALTO components) and potential properties (ALTO providing security-related information).
- Risks Identified:
  - Information Retrieval (Southbound): Securing connections to network elements/controllers (BGP, LLDP, SDN controllers), robustness against new protocol augmentations that could crash retrieval, and protecting the ALTO server from overly frequent network updates. Secure retrieval and interchange of information from external components (probes, management systems, inventory) were also emphasized.
  - Information Exposure (Northbound): Protecting PID identifiers from revealing too much topological detail (suggesting randomization or dynamic generation with secure exchange), obfuscating performance metrics to prevent targeted attacks, mitigating client-server interface attacks (malicious clients, DoS from frequent requests, TCP zero-window), and preventing disclosure of client-specific information to other clients (requiring filtering).
- Potential Properties (ALTO Enabling Security):
  - Augmenting maps with security-related properties (e.g., indicating if a path has encryption capabilities).
  - Providing additional security information (e.g., session-specific public keys).
- Call for Action: Luis proposed reviewing existing ALTO security considerations in RFCs and documenting new ones based on recent deployment experiences, foreseen concerns from ALTO augmentations/extensions, and new architectural approaches.
- Discussion on Security Issues:
  - Secure Mechanisms: There was agreement on the need for more secure mechanisms for both information retrieval and exposure. Luis suggested publish/subscribe models for the client-server interface to decouple clients from the server, and protecting communications with backend management/inventory systems.
  - Examples of Security Information: Examples of security-related information ALTO could provide include path encryption capabilities and public keys for specific communication sessions.
  - Information Integrity: A participant raised the crucial point of information integrity – what if an ALTO server provides incorrect cost information (e.g., a path with zero cost that is actually congested)? Luis acknowledged that integrity has been discussed in previous ALTO deployment RFCs and this is a valuable consideration for future work.
  - Balancing Security and Performance: The chairs cautioned against introducing too many security attributes, which could negatively impact the performance of ALTO information distribution. The use of mechanisms like JOSE for carrying ALTO information was mentioned as a potential approach.
  - Next Steps for Deployment RFC: It was discussed whether the outcome should be a revision of the existing ALTO deployment RFC or a new, security-specific document. The consensus was that this would become clearer after further exploration of the identified issues.

Next Steps

Working Group Future: The chairs invited participants to provide feedback on the future of the ALTO working group, specifically regarding the proposed new charter items. This discussion should continue on the mailing list and GitHub.
New Proposals: The chairs noted the potential of the new proposals presented at this interim meeting and encouraged continued discussion and development of these concepts.
IETF 117: The next IETF 117 meeting will likely include further discussions on these topics and the working group's future.