Application-Layer Traffic Optimization (ALTO) Server Discovery
Extracted elements (25)
Local configuration is checked before DHCP to allow users to override DHCP-provided domain names, accommodating scenarios where the user prefers an ALTO provider other than the network operator or where DHCP is unavailable.
Only HTTP and HTTPS URI schemes are defined for ALTO server discovery because the ALTO protocol specification (RFC 7285) defines access only over HTTP/HTTPS and no other scheme. The U-NAPTR result can nonetheless be any valid HTTP(S) URI.
PTR lookup on an interface's IP address to determine the DNS domain name is not recommended for resource-consumer-initiated ALTO server discovery due to the widespread use of NAT, which would yield an unroutable or incorrect domain name.
DNS resolution performed on the wrong interface in a multi-interfaced host (per RFC 6418) can return an ALTO server that provides suboptimal or incorrect guidance; selecting the best interface for DNS resolution in multi-interface environments is out of scope for this document.
On multi-homed hosts, single-interface local configuration discovers only one set of ALTO servers; DHCP-based discovery can discover different sets per interface and address family, which is the preferred approach for mobility and multihoming scenarios.
Some home gateways do not pass unknown DHCP options (such as OPTION_V4_ACCESS_DOMAIN or OPTION_V6_ACCESS_DOMAIN) to downstream hosts, eliminating those options and forcing fallback to local configuration. Home-gateway-specific DNS domain names (e.g., ".local") may also shadow the network operator's domain, making U-NAPTR lookups fail unless the gateway implements DNS split-horizon.
VPN connections typically lack DHCP, so users must enter the DNS domain name manually. For good optimization, the domain name should correspond to the VPN concentrator's network location, not the user's physical location; similar considerations apply to Mobile IP.
A change of IP address at an interface invalidates the result of the ALTO server discovery procedure; it is required to re-run the discovery procedure without relying on earlier information (e.g., after host mobility).
Before retrying a U-NAPTR lookup that has failed, a client MUST wait a time period appropriate for the encountered error (NXDOMAIN, timeout, etc.).
For IPv4, the ALTO server discovery procedure MUST try to retrieve DHCP option 213 (OPTION_V4_ACCESS_DOMAIN). If unavailable, the procedure SHOULD try option 15 (Domain Name); if neither is retrievable the procedure fails for that interface.
For IPv6, the ALTO server discovery procedure MUST try to retrieve DHCP option 57 (OPTION_V6_ACCESS_DOMAIN); if unavailable the procedure fails for that interface.
If a client wishes to communicate using a specific interface and IP address family, it SHOULD query the ALTO server(s) discovered for that specific interface and address family.
Implementations MAY give the user the opportunity to specify an individual domain name for every address family on every interface. Implementations SHOULD allow the user to specify a default name used when no more specific name has been configured.
The algorithm first checks for a locally configured domain name override before attempting DHCP retrieval; if neither yields a domain name, the procedure terminates with an error.
The ALTO server discovery procedure MUST be performed for every address family on every interface the application considers for communicating with resource providers.
An unauthorized party intercepting discovery messages (DHCP/DNS) could learn that a host is using or attempting to use the ALTO service. This has not been identified as a relevant threat in current ALTO use cases; no protection mechanisms are provided, but re-evaluation is required if a use case emerges that demands privacy here.
Step 2 uses a U-NAPTR [RFC4848] lookup with the application service tag "ALTO" and either the "http" or "https" application protocol tag to obtain one or more URIs for the ALTO server's IRD. Only HTTP and HTTPS URI schemes are defined by this procedure.
The ALTO server discovery procedure is performed in two steps: (1) retrieve a DNS domain name per interface/address-family via local configuration or DHCP, and (2) perform a U-NAPTR/DDDS lookup on that domain name to obtain one or more HTTP(S) URIs for the ALTO server's Information Resource Directory (IRD).
IANA has registered the U-NAPTR application service tag "ALTO" for use with application protocol tags "http" and "https". No new application protocol tags are registered; the existing http/https tags in the IANA registry are reused.
An attacker could render ALTO server discovery unavailable via DoS against DHCP, DNS, or the ALTO server itself. Applications must be prepared to operate without ALTO guidance; operators should apply DoS protection best practices to all three infrastructure components.
DHCP is inherently prone to injection attacks. An attacker able to inject forged DHCP replies can configure a wrong ALTO server; best current practices for safely operating DHCP should be followed.
The ALTO server's URI has been considered public information not requiring confidentiality protection. No protection mechanisms are defined; if a future use case requires confidentiality, the discovery procedure and possible extensions must be re-evaluated.
The most serious security threat is compromise of the ALTO server discovery infrastructure (DHCP or DNS) so that clients discover a wrong ALTO server URI, which could yield suboptimal or forged guidance, affect traffic distribution, or threaten user privacy. DNSSEC [RFC4033] should be applied to U-NAPTR DNS records to limit this attack vector.
When TLS is used to protect ALTO, the server certificate authenticates only the host part of the HTTPS URI (the CN), so the U-NAPTR mapping that produces the URI must itself be secured (e.g., via DNSSEC) to prevent URI substitution before TLS establishment.
U-NAPTR NAPTR resource records for ALTO use the flags field "u", the service field "ALTO:https" (or "ALTO:http"), and a regex that rewrites the domain to the full ALTO server URI (e.g., "!.*!https://alto1.example.net/ird!"). Order and preference fields follow standard NAPTR conventions.