Internet DRAFT - draft-kiesel-alto-xdom-disc-alg
draft-kiesel-alto-xdom-disc-alg
ALTO S. Kiesel
Internet-Draft K. Krause
Intended status: Experimental University of Stuttgart
Expires: January 5, 2015 M. Stiemerling
H-DA
July 4, 2014
Application Layer Traffic Optimization (ALTO) Cross-Domain Server
Discovery - Experimental Algorithm Specification
draft-kiesel-alto-xdom-disc-alg-00
Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired
resource. ALTO is realized by a client-server protocol. Before an
ALTO client can ask for guidance it needs to discover one or more
ALTO servers that can provide suitable guidance.
This document contains a strawman proposal for an ALTO Cross-Domain
Server Discovery procedure (also known as Third-Party Discovery).
Technically, the algorithm specified in this document takes one
IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or
"ALTO:https") as parameters. It performs several DNS lookups (for
U-NAPTR and SOA resource records) and returns one or more URI(s) of
information resources related to that IP address.
The functionality has been validated in a lab environment. However,
the feasibility and possible side-effects of Internet-wide
"production use" are not yet understood. The purpose of this
document is to foster further discussion within the ALTO working
group. Readers of this document should exercise caution in
evaluating its value for implementation and deployment.
Kiesel, et al. Expires January 5, 2015 [Page 1]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
Terminology and Requirements Language
This document makes use of the ALTO terminology defined in RFC 5693
[RFC5693].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Kiesel, et al. Expires January 5, 2015 [Page 2]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document History . . . . . . . . . . . . . . . . . . . . . 4
1.2. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. ALTO Cross-Domain Server Discovery Procedure Specification . . 5
2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Basic Principle . . . . . . . . . . . . . . . . . . . . . 5
2.3. Overall Procedure . . . . . . . . . . . . . . . . . . . . 6
2.4. Specification of Tasks and Conditional Branches . . . . . 7
2.4.1. T1: Prepare Domain Name for Reverse DNS Lookup . . . . 7
2.4.2. T2/B1: U-NAPTR Lookup in Reverse Zone . . . . . . . . 7
2.4.3. B2/T3/B3: Acquire SOA Record for Reverse Zone . . . . 8
2.4.4. T4/B4: U-NAPTR Lookup on SOA-MNAME . . . . . . . . . . 9
3. Implementation, Deployment, and Operational Considerations . . 10
3.1. Considerations for ALTO Clients . . . . . . . . . . . . . 10
3.1.1. Resource Consumer Initiated Discovery . . . . . . . . 10
3.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host
Mobility . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Deployment Considerations for Network Operators . . . . . 11
3.2.1. NAPTR in Reverse Tree vs. SOA-based discovery . . . . 11
3.2.2. Separation of Interests . . . . . . . . . . . . . . . 11
3.3. Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. Non-PTR Resource Records in Reverse Tree . . . . . . . 12
3.3.2. Usage with DNS Hidden Master Servers . . . . . . . . . 12
3.3.3. Load on the DNS . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 13
4.2. Availability of the ALTO Server Discovery Procedure . . . 14
4.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 14
4.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Kiesel, et al. Expires January 5, 2015 [Page 3]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
1. Introduction
The motivation for Application-Layer Traffic Optimization (ALTO)
Cross-Domain Server Discovery (also known as Third-Party Server
Discovery), as well as applicable scenarios and requirements for a
solution are documented in draft-kiesel-alto-xdom-disc-00. In the
following, we assume that the reader is familiar with said document.
This document presents the specification of an DNS-based procedure
that satisfies these requirements. The functionality has been
validated in a lab environment. However, the feasibility and
possible side-effects of Internet-wide "production use" are not yet
understood.
The purpose of this document is to foster further discussion within
the ALTO working group and the IETF community in general. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment.
1.1. Document History
This document is a direct successor of [I-D.kiesel-alto-3pdisc] and
[I-D.kist-alto-3pdisc]. The scenario and mechanisms described here
and in these documents have been referred to as "third-party server
discovery" in the past. However, to avoid ambiguities with a
completely different scenario, it has been renamed to "ALTO Cross-
Domain Server Discovery".
1.2. Feedback
Comments and discussions about this document should be directed to
the ALTO working group: alto@ietf.org.
Kiesel, et al. Expires January 5, 2015 [Page 4]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
2. ALTO Cross-Domain Server Discovery Procedure Specification
2.1. Interface
The algorithm specified in this document takes one IP address and a
U-NAPTR Service Parameter (i.e., "ALTO:http" or "ALTO:https") as
parameters. It performs several DNS lookups (for U-NAPTR and SOA
resource records) and returns one or more URI(s) of information
resources related to that IP address.
2.2. Basic Principle
The algorithm sequentially tries two different lookup strategies.
First, an ALTO-specific U-NAPTR lookup is performed in the "reverse
tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.,
respectively. If this lookup does not yield a usable result, the SOA
record for the reverse zone is acquired, its master name server
(MNAME) value is extracted and used for a further ALTO-specific
U-NAPTR lookup.
The goal is to allow deployment scenarios that require fine-grained
discovery on a per-IP basis, as well as large-scale scenarios where
discovery is to be enabled for a large number of IP addresses with a
small number of additional DNS resource records.
Kiesel, et al. Expires January 5, 2015 [Page 5]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
2.3. Overall Procedure
This figure gives an overview on the discovery procedure. All tasks
(T) and conditional branches (B) are specified below.
(---------------------------------------)
( START ALTO XDOM disc with parameters )
( IP_address IP, Service_Parameter SP )
(-------------------+-------------------)
V
+- T1 --------------+-------------------+
| R:=<IP>.in-addr.arpa. / <IP>.ip6.arpa.|
+-------------------+-------------------+
V
+- T2 --------------+-------------------+
| X:=DNSlookup(R,U-NAPTR,SP) |
+-------------------+-------------------+
V
/ B1 --------------+------------------\
/---------< One or more U-NAPTR results in X >
| yes \------------------+------------------/
| V no
| /- B2 -------------+------------------\
| /----< Authority sect. with SOA record in X >
| | yes \------------------+------------------/
| | V no
| | +- T3 --------------+-------------------+
| | | X:=DNSlookup(R,SOA) |
| | +-------------------+-------------------+
| | V
| | /- B3 -------------+------------------\
| | < Lookup OK, SOA record present in X >----\
| | \------------------+------------------/ no |
| | V yes |
| \----------------------->+ |
| V |
| +- T4 --------------+-------------------+ |
| | M:=extract MNAME from SOA record in X | |
| | X:=DNSlookup(M,U-NAPTR,SP) | |
| +-------------------+-------------------+ |
| V |
| /- B4 -------------+------------------\ V
\--->+<---< One or more U-NAPTR results in X >--->+
| yes \-------------------------------------/ no |
V V
(-------+-------) (-------+-------)
( END, result X ) ( END, failure )
(---------------) (---------------)
Kiesel, et al. Expires January 5, 2015 [Page 6]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
2.4. Specification of Tasks and Conditional Branches
2.4.1. T1: Prepare Domain Name for Reverse DNS Lookup
Task T1 takes the IP address parameter the procedure was called with
and constructs a domain name, which is stored in variable "R" for use
in subsequent tasks.
If the IP address given as a parameter to the procedure is an IPv4
address, the domain name is constructed according to the rules
specified in Section 3.5 of [RFC1035] and it is rooted in the in the
special domain "IN-ADDR.ARPA.". For IPv6 addresses, the construction
rules in Section 2.5 of [RFC3596] apply and the special domain
"IP6.ARPA." is used.
Example values for "R" for IPv4 and IPv6 addresses could be (Note: a
line break was added in the IPv6 example):
R:="3.100.51.198.in-addr.arpa."
R:="0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.ip6.arpa."
2.4.2. T2/B1: U-NAPTR Lookup in Reverse Zone
Task T1 performs a U-NAPTR lookup as specified in [RFC4848] on "R",
in order to get service-specific U-NAPTR resource records that are
directly associated with the IP address in question.
The ALTO protocol specification defines HTTP and HTTPS as transport
mechanisms and URI schemes for ALTO. Consequently, the U-NAPTR
lookup is performed with the "ALTO" Application Service Tag and
either the "http" or the "https" Application Protocol Tag.
Application Service Tag and Application Protocol Tag are concatenated
to form the Service Parameter SP, i.e., either "ALTO:http" or "ALTO:
https".
The goal of said U-NAPTR lookup is to obtain one or more URIs for the
ALTO server's Information Resource Directory. If two or more URIs
are found they are sorted according to their order and preference
fields as specified in [RFC4848] and [RFC3403].
The lookup result, including a SOA record that may or may not be
present in the authority section, is stored in variable "X".
As an example, the following two U-NAPTR resource records can be used
for mapping "3.100.51.198.in-addr.arpa." to the HTTPS URI
Kiesel, et al. Expires January 5, 2015 [Page 7]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
https://altoserver.isp.example.net/secure/directory or the HTTP URI
http://altoserver.isp.example.net/directory, with the former being
preferred.
3.100.51.198.in-addr.arpa.
IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://altoserver.isp.example.net/secure/directory!" ""
IN NAPTR 200 10 "u" "ALTO:http"
"!.*!http://altoserver.isp.example.net/directory!" ""
Conditional Branch B1 checks whether at least one U-NAPTR record
matching the service parameter SP could be retrieved. If so, the
procedure ends successfully and the sorted list of U-NAPTR records is
the result. Otherwise, if no U-NAPTR records could be retrieved, we
continue with B2.
Note: The U-NAPTR lookup in Task T2 is identical to Step 2 specified
in [RFC7286], which specifies with "manual input" and "DHCP" two
alternatives for acquiring the name to be looked up. Therefore, it
is possible to merge both documents into a common ALTO server
discovery framework.
2.4.3. B2/T3/B3: Acquire SOA Record for Reverse Zone
The task of B2/T3/B3 is to acquire the SOA record for the "reverse
zone", i.e., the zone in the in-addr.arpa. or ip6.arpa. domain that
contains the IP address in question.
A sample SOA record could be:
100.51.198.in-addr.arpa
IN SOA dns1.isp.example.net. hostmaster.isp.example.net. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
Conditional Branch B2 checks whether the SOA record was present in
the authority section of X, i.e., the result of Task T2. If not, an
explicit lookup is done in Task T3. If Conditional Branch B3
determines that this explicit lookup failed, the discovery procedure
is aborted without a result; otherwise we continue with T4.
Kiesel, et al. Expires January 5, 2015 [Page 8]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
2.4.4. T4/B4: U-NAPTR Lookup on SOA-MNAME
Now that the SOA record is available, Task T4 first extracts the
MNAME field, i.e., the responsible master name server from the SOA
record. An example MNAME could be:
dns1.isp.example.net.
Then, a U-NAPTR lookup as specified in Task T2 is performed on this
MNAME and the result is stored in variable "X".
Conditional Branch B4 checks whether at least one U-NAPTR record
matching the service parameter SP could be retrieved. If so, the
procedure ends successfully and the sorted list of U-NAPTR records is
the result. Otherwise, if no U-NAPTR records could be retrieved, the
discovery procedure is aborted without a result.
Kiesel, et al. Expires January 5, 2015 [Page 9]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
3. Implementation, Deployment, and Operational Considerations
3.1. Considerations for ALTO Clients
3.1.1. Resource Consumer Initiated Discovery
To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource
consumer initiated ALTO server discovery, can be seen as a special
case of cross-domain ALTO server discovery. To that end, an ALTO
client embedded in a resource consumer would have to figure out its
own "public" IP address and perform the procedures described in this
document on that address. However, due to the widespread deployment
of Network Address Translators (NAT), additional protocols and
mechanisms such as STUN [RFC5389] would be needed and considerations
for UNSAF [RFC3424] apply. Therefore, using the procedures specified
in this document for resource consumer based ALTO server discovery is
generally NOT RECOMMENDED. Note that a less versatile yet simpler
approach for resource consumer initiated ALTO server discovery is
specified in [RFC7286].
3.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility
The algorithm specified in this document can discover ALTO server
URIs for a given IP address. The intention is, that an entity taking
part in the application signaling (e.g., a resource directory such as
a P2P tracker) that receives signaling messages from a resource
consumer can use the source address contained in these messages to
discover suitable ALTO servers for this specific resource consumer.
However, resource consumers (as defined in Section 2 of [RFC5693])
may reside on hosts with more than one IP address, e.g., due to
IPv4/v6 dual stack operation and/or multihoming. IP packets sent
with different source addresses may be subject to different routing
policies and path costs. In some deployment scenarios, it may even
be required to ask different sets of ALTO servers for guidance.
Furthermore, source addresses in IP packets may be modified en-route
by Network Address Translators (NAT).
If a resource consumer queries a resource directory for candidate
resource providers, the locally selected (and possibly en-route
translated) source address of the query message - as observed by the
resource directory - will become the basis for the ALTO server
discovery and the subsequent optimization of the resource directory's
reply. If, however, the resource consumer then selects different
source addresses to contact returned resource providers, the desired
better-than-random "ALTO effect" may not occur.
Therefore, a dual stack or multihomed resource consumer SHOULD either
Kiesel, et al. Expires January 5, 2015 [Page 10]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
always use the same address for contacting the resource directory and
the resource providers, i.e., overriding the operating system's
automatic source IP address selection, or use resource consumer based
ALTO server discovery [RFC7286] to discover suitable ALTO servers for
every local address and then locally perform ALTO-influenced resource
consumer selection and source address selection. Similarly, resource
consumers on mobile hosts SHOULD query the resource directory again
after a change of IP address, in order to get a list of candidate
resource providers that is optimized for the new IP address.
3.2. Deployment Considerations for Network Operators
3.2.1. NAPTR in Reverse Tree vs. SOA-based discovery
As already outlined in Section 2.2, the ALTO cross-domain server
discovery procedure sequentially tries two different lookup
strategies, thus giving network operators the choice of two different
deployment options:
o Individual NAPTR records in the in-addr.arpa or ip6.arpa domains
allow very fine-grained discovery of ALTO "entry point" URIs on a
per-IP-address basis. This method also gives the fastest response
times and causes a comparatively low load on the DNS, as the
algorithm terminates successfully after the first DNS query. DNS
operators that already maintain reverse zones (e.g., for PTR
records) should prefer this option, possibly using DNS server
implementation-specific methods for mass deployment (e.g., BIND9's
$GENERATE statement).
o If a DNS operator considers the first option too cumbersome, or if
IPv6 privacy extensions is to be used without dynamic PTR updates,
setting up SOA records in the in-addr.arpa. or ip6.arpa.
subdomains plus setting up corresponding ALTO-specific U-NAPTR
records will also give reasonable, yet less fine-grained results
at the cost of slightly higher delay and load on the DNS.
3.2.2. Separation of Interests
We assume that if two organizations share parts of their DNS
infrastructure, i.e., have a common SOA record in their in-addr.arpa.
or ip6.arpa. subdomain(s), they will also be able to operate a common
ALTO server, which still may do redirections if desired or required
by policies.
Note that the ALTO server discovery procedure is supposed to produce
only a first URI of an ALTO server that can give reasonable guidance
to the client. An ALTO server can still return different results
based on the client's address (or other identifying properties) or
Kiesel, et al. Expires January 5, 2015 [Page 11]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
redirect the client to another ALTO server using mechanisms of the
ALTO protocol (see Sect. 9 of [RFC7285]).
3.3. Impact on DNS
3.3.1. Non-PTR Resource Records in Reverse Tree
Installing NAPTR records, i.e., a record type other than PTR records,
in the in-addr.arpa or ip6.arpa domain may seem uncommon, but it is
not a new concept. Earlier documents that specify the usage of Non-
PTR resource records in the reverse tree include RFC 4025 [RFC4025],
RFC 4255 [RFC4255], and RFC 4322 [RFC4322].
3.3.2. Usage with DNS Hidden Master Servers
In some deployment scenarios, the Master DNS server for a in-
addr.arpa. or ip6.arpa. subdomain, as indicated in the respective SOA
record, may not be reachable due to traffic restrictions ("hidden
master"). This does not cause any problems with the algorithm
described here, as the MNAME is only used for further DNS lookups;
but it is never attempted to contact this server directly.
3.3.3. Load on the DNS
The procedure described in this document features several nested
conditional branches, but no loops. Each time being called it
attempts one to three DNS lookups.
Kiesel, et al. Expires January 5, 2015 [Page 12]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
4. Security Considerations
A high-level discussion of security issues related to ALTO is part of
the ALTO problem statement [RFC5693]. A classification of unwanted
information disclosure risks, as well as specific security-related
requirements can be found in the ALTO requirements document
[RFC6708].
The remainder of this section focuses on security threats and
protection mechanisms for the ALTO cross-domain server discovery
procedure as such. Once the ALTO server's URI has been discovered
and the communication between the ALTO client and the ALTO server
starts, the security threats and protection mechanisms discussed in
the ALTO protocol specification [RFC7285] apply.
4.1. Integrity of the ALTO Server's URI
Scenario Description
An attacker could compromise the ALTO server discovery procedure
or infrastructure in a way that ALTO clients would discover a
"wrong" ALTO server URI.
Threat Discussion
This is probably the most serious security concern related to ALTO
server discovery. The discovered "wrong" ALTO server might not be
able to give guidance to a given ALTO client at all, or it might
give suboptimal or forged information. In the latter case, an
attacker could try to use ALTO to affect the traffic distribution
in the network or the performance of applications (see also
Section 15.1. of [RFC7285]). Furthermore, a hostile ALTO server
could threaten user privacy (see also Section 5.2.1, case (5a) in
[RFC6708]).
However, it should also be noted that, if an attacker was able to
compromise the DNS infrastructure used for ALTO cross-domain
server discovery (see below), (s)he could also launch
significantly more serious other attacks (e.g., redirecting
various application protocols).
Protection Strategies and Mechanisms
The ALTO cross-domain server discovery procedure relies on a
series of DNS lookups. If an attacker was able to modify or spoof
any of the DNS records, the resulting URI could be replaced by a
forged URI. The application of DNS security (DNSSEC) [RFC4033]
provides a means to limit attacks that rely on modification of the
DNS records while in transit. Additional operational precautions
for safely operating the DNS infrastructure are required in order
to ensure that name servers do not sign forged (or otherwise
Kiesel, et al. Expires January 5, 2015 [Page 13]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
"wrong") resource records. Security considerations specific to
U-NAPTR are described in more detail in [RFC4848].
A related risk is the impersonation of the ALTO server (i.e.,
attacks after the correct URI has been discovered). This threat
and protection strategies are discussed in Section 15.1 of
[RFC7285]. Note that if TLS is used to protect ALTO, the server
certificate will contain the host name (CN). Consequently, only
the host part of the HTTPS URI will be authenticated, i.e., the
result of the ALTO server discovery procedure. The DNS/U-NAPTR
based mapping within the ALTO cross-domain server discovery
procedure needs to be secured as described above, e.g., by using
DNSSEC.
In addition to active protection mechanisms, users and network
operators can monitor application performance and network traffic
patterns for poor performance or abnormalities. If it turns out
that relying on the guidance of a specific ALTO server does not
result in better-than-random results, the usage of the ALTO server
may be discontinued (see also Section 15.2 of [RFC7285]).
4.2. Availability of the ALTO Server Discovery Procedure
Scenario Description
An attacker could compromise the ALTO cross-domain server
discovery procedure or infrastructure in a way that ALTO clients
would not be able to discover any ALTO server.
Threat Discussion
If no ALTO server can be discovered (although a suitable one
exists) applications have to make their decisions without ALTO
guidance. As ALTO could be temporarily unavailable for many
reasons, applications must be prepared to do so. However, The
resulting application performance and traffic distribution will
correspond to a deployment scenario without ALTO.
Protection Strategies and Mechanisms
Operators should follow best current practices to secure their DNS
and ALTO (see Section 15.5 of [RFC7285]) servers against Denial-
of-Service (DoS) attacks.
4.3. Confidentiality of the ALTO Server's URI
Kiesel, et al. Expires January 5, 2015 [Page 14]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
Scenario Description
An unauthorized party could invoke the ALTO cross-domain server
discovery procedure, or intercept discovery messages between an
authorized ALTO client and the DNS servers, in order to acquire
knowledge of the ALTO server URI for a specific resource consumer.
Threat Discussion
In the ALTO use cases that have been described in the ALTO problem
statement [RFC5693] and/or discussed in the ALTO working group,
the ALTO server's URI as such has always been considered as public
information that does not need protection of confidentiality.
Protection Strategies and Mechanisms
No protection mechanisms for this scenario have been provided, as
it has not been identified as a relevant threat. However, if a
new use case is identified that requires this kind of protection,
the suitability of this ALTO server discovery procedure as well as
possible security extensions have to be re-evaluated thoroughly.
4.4. Privacy for ALTO Clients
Scenario Description
An unauthorized party could intercept messages between an ALTO
client and the DNS servers, and thereby find out the fact that
said ALTO client uses (or at least tries to use) the ALTO service
on behalf of a specific resource consumer.
Threat Discussion
In the ALTO use cases that have been described in the ALTO problem
statement [RFC5693] and/or discussed in the ALTO working group,
this scenario has not been identified as a relevant threat.
Protection Strategies and Mechanisms
No protection mechanisms for this scenario have been provided, as
it has not been identified as a relevant threat. However, if a
new use case is identified that requires this kind of protection,
the suitability of this ALTO server discovery procedure as well as
possible security extensions have to be re-evaluated thoroughly.
Kiesel, et al. Expires January 5, 2015 [Page 15]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
5. IANA Considerations
This document does not require any IANA action.
This document specifies an algorithm that uses U-NAPTR lookups
[RFC4848] with the Application Service Tag "ALTO" and the Application
Protocol Tags "http" and "https". These tags have already been
registered with IANA. In particular, for the registration of the
Application Service Tag "ALTO", see [RFC7286].
Kiesel, et al. Expires January 5, 2015 [Page 16]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
6. References
6.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
6.2. Informative References
[I-D.kiesel-alto-3pdisc]
Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M.,
Tomsu, M., and H. Song, "ALTO Server Discovery Protocol",
draft-kiesel-alto-3pdisc-05 (work in progress),
March 2011.
[I-D.kist-alto-3pdisc]
Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
(work in progress), January 2014.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
Kiesel, et al. Expires January 5, 2015 [Page 17]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
January 2006.
[RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic
Encryption using the Internet Key Exchange (IKE)",
RFC 4322, December 2005.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", RFC 6708, September 2012.
[RFC7285] Alimi, R., Penno, R., and Y. Yang, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285,
June 2014.
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
H. Song, "Application-Layer Traffic Optimization (ALTO)
Server Discovery", RFC 7286, June 2014.
Kiesel, et al. Expires January 5, 2015 [Page 18]
Internet-Draft ALTO Cross-Domain Server Disc.: Exp. Alg. July 2014
Authors' Addresses
Sebastian Kiesel
University of Stuttgart Information Center
Allmandring 30
Stuttgart 70550
Germany
Email: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/
Kilian Krause
University of Stuttgart Information Center
Allmandring 30
Stuttgart 70550
Germany
Email: schreibt@normalerweise.net
URI: http://www.rus.uni-stuttgart.de/nks/
Martin Stiemerling
University of Applied Sciences Darmstadt, Computer Science Dept.
Haardtring 100
Darmstadt 64295
Germany
Phone: +49 6151 16 7938
Email: mls.ietf@gmail.com
URI: http://ietf.stiemerling.org
Kiesel, et al. Expires January 5, 2015 [Page 19]
