Skip to main content

Minutes interim-2023-alto-05: Tue 14:00
minutes-interim-2023-alto-05-202305301400-00

Meeting Minutes Application-Layer Traffic Optimization (alto) WG
Date and time 2023-05-30 14:00
Title Minutes interim-2023-alto-05: Tue 14:00
State Active
Other versions markdown
Last updated 2023-06-08

minutes-interim-2023-alto-05-202305301400-00

IETF ALTO Interim #5

ALTO Interim #5, May 30, 2023
Chairs: Mohamed Boucadair & Qin Wu

Chair starting remarks

  • Transport I-D WGLC ends 01/06

  • Waiting for a revised version of the OAM

  • Will initiate a 2nd WGLC as soon as the new version is out

  • Prepare revised versions as a function of received comments (by
    09/06)

  • Finalize the write-up and Submit the I-Ds to the IESG (Second week
    of June)

Towards a trusted-enhanced ALTO: Ayoub Messous

  • Overview of ALTO

  • Value for trust

    • Important decision making
    • Relevant for instance in routing
  • Integration with ALTO

    • Trustworthiness metrics
    • Extended cost metrics
    • Real-time trust updates
    • Informed decision making
    • Improved security
  • ALTO before and after trust

  • Trust IP-based geolocation

    • Accurate geolocation of network entities
    • How to include geolocation info to server
    • Also outside ALTO: this party, focused on resources
  • Trust as a cost map

    • An ALTO server would offer QualityOfTrust
    • Higher value higher trust
    • QoT depends on sensitivity of data, type of traffic, projected
      application
    • Consider trust-cost (analogy to routing-cost)
  • Enhanced property maps

    • Net map, entity property map, cost map, endpoint cost map
    • Trust-enhanced property map
  • Multidomain and trust

    • ALTO info very coarse
    • ISPs dislike disclosing info
    • ALTO designed to use non-sensitive info
    • Proper multi-domain features will allow operators to be more
      willing to use ALTO
  • Questions:

    • Relevance to only ALTO? other WGs?

[RY] Multiple servers available for downloading content. Can be very
useful to know trust.

[AM] Trust is subjective. Different providers will have different
interpretation. Our goal is to provide a standard way.

[LC] Server can provide such info, should we protect client from
server tracking the information queried by client?

[AM] Privacy definitely relevant. Possibility to use third party to
anonimize.

[SR] Can you trust a client? How secure and robust is the path?

[AM] You are welcome to join us in this discussion

[JR] In scope to define trust itself?

[AM] Need to connect with other groups IPPM

[RY] ALTO owns info and can distribute to clients

[QW] How does this trust info relate to identity management, should it
integrate into ALTO or separate.

[QW] Check how trust info should work with RATS and other WGs that are
related.

Security Aspects Regarding ALTO (Luis Contreras)

  • Issues described in the past:

    • RFC5693
    • Unwanted disclosed info
    • Discovery
  • Focus here is security issues from operations standpoint

  • Focus here is on the server, retrieval of info

Network:

  • R1: connection ALTO server - controllers must be secured
  • R2: robustness against new parameters
  • R3: Robustness against frequent updates

Data/Sources:

  • R4: Secure retrieval of info
  • R5: Secure exchange of info

PID identifiers:

  • PID can reveal topology info
  • Performance metrics can permit malicious parties produce attacks

Interaction with client:

  • Sub/pub to isolate client/server
  • DoS with too often client requests
  • Secure transport for client request

Information privacy:

  • Disclosure to other clients

Proposal for action:

Overview general security considerations raised in previous RFCs
Document new security considerations

[QW] Need to look for balance between security attributes and network
performance.