ALTO Server Discovery
draft-ietf-alto-server-discovery-04
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (alto WG) | |
|---|---|---|---|
| Authors | Sebastian Kiesel , Martin Stiemerling , Nico Schwan , Michael Scharf , Song Yongchao | ||
| Last updated | 2012-07-16 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
SECDIR Last Call review
(of
-08)
Has Nits
GENART Last Call review
(of
-08)
Ready with Nits
|
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-alto-server-discovery-04
ALTO S. Kiesel
Internet-Draft University of Stuttgart
Intended status: Standards Track M. Stiemerling
Expires: January 17, 2013 NEC Europe Ltd.
N. Schwan
M. Scharf
Alcatel-Lucent Bell Labs
H. Song
Huawei
July 16, 2012
ALTO Server Discovery
draft-ietf-alto-server-discovery-04
Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications, which have to select one or several
hosts from a set of candidates that are able to provide a desired
resource.
Entities seeking guidance need to discover and possibly select an
ALTO server to ask. This is called ALTO server discovery. This memo
describes an ALTO server discovery mechanism based on several
alternative mechanisms that are applicable when the resource consumer
is co-located with the ALTO client.
Kiesel, et al. Expires January 17, 2013 [Page 1]
Internet-Draft ALTO Server Discovery July 2012
Requirements Language
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 17, 2013.
Copyright Notice
Copyright (c) 2012 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 17, 2013 [Page 2]
Internet-Draft ALTO Server Discovery July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 5
1.1.1. ALTO Server Discovery by Resource Consumers . . . . . 6
1.1.2. ALTO Server Discovery by a Third Party . . . . . . . . 7
1.2. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 8
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
3. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 12
3.1. Retrieving the Domain Name . . . . . . . . . . . . . . . . 12
3.1.1. Option 1: User input . . . . . . . . . . . . . . . . . 12
3.1.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 13
3.1.3. Option 3: PPP . . . . . . . . . . . . . . . . . . . . 13
3.2. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 14
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Applicability for Resource Consumer Server Discovery . . . 16
4.2. Applicability for Third Party Server Discovery . . . . . . 16
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 18
5.1. DHCP option for DNS Suffix . . . . . . . . . . . . . . . . 18
5.2. PPP option for DNS Suffix . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. Registration of PPP IPCP Configuration Option Type . . . . 19
6.2. Registration of U-NAPTR application service tag . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. For U-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 20
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Contributors List and Acknowledgments . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Kiesel, et al. Expires January 17, 2013 [Page 3]
Internet-Draft ALTO Server Discovery July 2012
1. Introduction
The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications, which have to select one or several
hosts from a set of candidates, that are able to provide a desired
resource [RFC5693]. The requirements for ALTO are itemized in
[I-D.ietf-alto-reqs].
ALTO is realized by a client-server protocol. ALTO clients send
queries to ALTO servers, in order to solicit guidance. Hence, ALTO
clients need to know the contact information of ALTO servers, which
can provide appropriate guidance for a given resource consumer.
Typically the closer an ALTO server is to a resource consumer the
more accurate guidance it can provide. Thus a design objective is to
automatically discover an ALTO server topologically close to the
network attachment point of the resource consumer, if available. The
contact information of the ALTO server is retrieved by invoking the
ALTO discovery procedure defined in this document.
The ALTO protocol specification [I-D.ietf-alto-protocol] is based on
HTTP. Therefore, it expects that the ALTO discovery procedure yields
the HTTP(S) URI of the ALTO server's Information Resource Directory,
which gives further information about the capabilities and services
provided by that ALTO server. Further (DNS) lookups may be necessary
in order to find out the ALTO server's IP address.
The goal of this memo is to propose a discovery mechanism for ALTO
client deployments in uncontrolled environments that is implementable
and deployable at a fast pace, i.e., without creating other
deployment dependencies for ALTO. We propose a schema which employs
the U-NAPTR mechanism [RFC4848] to determine the URI of the ALTO
server and where mutliple input methods to the U-NAPTR process can be
used. U-NAPTR is used because the discovery mechanism must return an
URI, and thus other discovery mechanisms are not applicable (e. g.,
DNS SRV records).
There are various architectural options where to place the ALTO
client and the ALTO server discovery procedure:
o One option is that the ALTO client and the ALTO server discovery
procedure are embedded directly in the resource consumer, i.e.,
the application protocol entity that will eventually initiate data
transmission to/from the selected resource provider(s). In this
case, the ALTO server discovery procedure might be able to
interact with the user (i.e., prompt for a host name).
Furthermore, it may use services such as DHCP, which are only
available within the access network to which the resource consumer
is connected. This option is described in this memo.
Kiesel, et al. Expires January 17, 2013 [Page 4]
Internet-Draft ALTO Server Discovery July 2012
o A similar architectural setup exists in controlled environments,
e.g. a CDN that uses ALTO as information base for request
redirection. However in such a controlled environment it is
unlikely that a dynamic server discovery is necessary. Instead it
is expected that the CDN administrator will manually configure the
contact information of the ALTO server. Thus this draft is
focused on allowing dynamic discovery in uncontrolled environments
where provisioning contact information is impossible or
undesireable.
o Another option is to integrate the ALTO client and the ALTO server
discovery procedure into a third party such as a resource
directory ("peer-to-peer tracker"), which issues ALTO queries on
behalf of various resource consumers. This third party may reside
in a different part of the network (administrative domain) than
the resource consumer. It may occur that said third party whishes
to issue ALTO queries on behalf of a resouce consumer, but all it
knows about the resource consumer is the source IP address of
messages originating from it (i.e., the resource consumer's IP
address or the "public" IP address of the outermost NAT in front
of the resource consumer). A general server discovery procedure
based solely on this IP address raises several issues, and are out
of scope of this document. This option is further discussed in
[I-D.kist-alto-3pdisc].
A more detailed discussion of various options where to place the
funcional entities comprising the overall ALTO architecture can be
found in [I-D.ietf-alto-deployments].
A general mechanism that redirects ALTO clients from one ALTO server
to another, potentially closer, ALTO server raises several issues.
First ALTO servers by definition provide Network Maps for the whole
IP address space and thus can provide each client with a potentially
useful answer. Second ALTO servers might be deployed independently
by seperate administrative entities and are thus not necessarily
aware of each other. The use of a redirection mechanism thus depends
on the deployment scenario and is for this reason out of the scope of
this document.
Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org.
1.1. Discovery Scenarios
Figure 1 below shows an overview on the different entities of a
generic ALTO framework. The ALTO Server discovery mechanism is used
by the peer-to-peer (P2P) application in order retrieve the point of
contact of the ALTO Service.
Kiesel, et al. Expires January 17, 2013 [Page 5]
Internet-Draft ALTO Server Discovery July 2012
+------+
+-----+ | Peers
+-----+ +------+ +=====| |--+-oo
| |......| |====+ oo+--*--+ o
+-----+ +------+ | o * ooooooo
Source of ALTO | o *
Topological Service | o +--*--+
information +===o=| | Tracker
o +-----+ /Super-peer
ALTO Discovery o o
Service o o
+------+ o o
| |oooooooooo
+------+
Legend:
=== ALTO query protocol
ooo ALTO service discovery protocol
*** Application protocol (out of scope)
... Provisioning or initialization (out of scope)
Figure 1: ALTO Discovery Overview
Hereby the ALTO service discovery scenarios are classified into two
types: one is the ALTO server discovery by the resource consumer, and
the other is the ALTO server discovery by a third party, such as
application trackers. Before the specification of the discovery
mechanism the following section illustrates and discusses both
scenarios.
1.1.1. ALTO Server Discovery by Resource Consumers
The ALTO service discovery in some scenarios needs to be performed by
the resource consumer itself. In particular in P2P applications
without a tracker like DHTs and other conventional client/server
applications. Also P2P application which are tracker based may embed
the ALTO client into the resource consumer to allow peers a selection
of peers after retrieving the peer list from the application tracker.
The following figure illustrates this scenario, showing the
relationship between the different entities as discussed before.
Kiesel, et al. Expires January 17, 2013 [Page 6]
Internet-Draft ALTO Server Discovery July 2012
+---------------+
| ALTO Server |
+---------------+
^ ^ +-----------+
| | | ALTO |
| +---+---+ | Service |
| |tracker| | Discovery |
| +-------+ +---------+-+
| | o o
+------------+--+ | o o
|P2P Application|ooooo|oooooooooooo o
| Client A | | o
+---------------+ | o
| o
+--+-------------+ o
| P2P Application|oooooo
| Client B |
+----------------+
Figure 2: Resource Consumer ALTO Server Discovery (Example)
1.1.2. ALTO Server Discovery by a Third Party
Some P2P applications have trackers, and these applications might not
need to have their clients looking for the ALTO server guidance. In
these scenarios trackers query the ALTO servers for guidance
themselves, and then return the final ranked result to the
application clients. However, application clients are distributed
among different network operators and autonomous systems. Trackers
thus need to find different ALTO servers for the clients located in
different operator networks or autonomous systems. In such scenarios
the discovery is thus not performed by the resource consumer, but a
third party entity on behalf of the resource consumer.
This third party ALTO server discovery raises several issues.
Typically only the IP address of the ALTO client is known that needs
to suffice for finding the corresponding ALTO server. This requires
detemining a FQDN as input for the U-NAPTR process. One option to do
this is to use a reverse DNS lookup. However, reverse DNS has
several limitations:
First, there is no established unique way of maintaining the DNS
tree, and there are different practices in different networks.
Furthermore, it is possible that a lookup fails or that the returned
value is not valid. For instance, it can point to a different
domain. As a result, any potential use of reverse DNS lookup for
service discovery must be able to deal with failures of lookup and
react accordingly.
Kiesel, et al. Expires January 17, 2013 [Page 7]
Internet-Draft ALTO Server Discovery July 2012
Second, determining a domain name from IP addresses by tree climbing
is problematic, in particular for IPv6. [RFC4472] discusses the
issues for IPv6.
Third, populating a DNS name space what looks like a reverse tree is
a significant administrative DNS overhead.
Finally it must be emphasized that any tree walking procedure raises
several issues. There is no single best way tree, and heuristics are
needed.
Given these problems, this memo does not specify a reverve DNS
mechanism to determine a FQDN.
Thus, this draft is limited to scenarios where the discovery
procedure is done by the resource consumer. In case a third party
needs to know the contact information of the ALTO server it is
RECOMMENDED that the resource consumer discovers the ALTO server and
then sends the contact information directly to the third party.
However, this requires a modification of the protocol used between
the resource consumer and the third party, e.g., the tracker protocol
in the peer-to-peer case. As a potential alternative, the client
could provide a valid FQDN, so that the third party can use this as
input for the U-NAPTR process, but this variant has no significant
advantages. The options on how to transmit the contact information
from the resource consumer to the third party are out of scope of
this document.
1.2. Pre-Conditions
In general, the ALTO server discovery SHOULD be based on the IP
address that is used to communicate with other peers, i. e., it
should return a server that can provide guidance for that address.
In order to achieve this, the whole document assumes certain pre-
conditions, in particular:
o The ALTO server discovery procedure is executed on a per IP family
base, i.e., seperate for IPv4 and IPv6. It is up to the ALTO
client to decide which of the possible multiple results of
different IP address families to use. The choice of whether to
use IPv4 or IPv6 is out of scope of this document.
o A change of the IP address at an interface invalidates the result
of the ALTO server discovery procedure. For instance, if the IP
address assigned to a mobile host changes due to host mobility, it
is required to run the ALTO server discovery procedure for the new
IP address without relying on earlier gained information.
Kiesel, et al. Expires January 17, 2013 [Page 8]
Internet-Draft ALTO Server Discovery July 2012
o The ALTO server discovery procedure is executed on a per IP
address base. Multiple IP addresses per interface or multiple IP
addresses assigned to different IP interfaces require to repeat
the procedure for every IP address. It may be fine to group IP
addresses according their domain suffixes and to perfom the
procedure for such a group. However, this is out of scope of this
document.
o There are several challenges with DNS on hosts with multiple
interfaces [RFC6418], which can affect the ALTO server discovery.
If the DNS resolution is performed on the wrong interface, it can
return an ALTO server that could provide sub-optimal or wrong
guidance. Finding the best ALTO server for multi-interfaced hosts
is outside the scope of this document.
o The discovery procedure may need information about the public IP
address and thus have to discover NATs. Details of NAT discovery
are not discussed in this memo.
o Similarly the discovery procedure may need information about the
IP address of a proxy or agent if this address is used for
communication. Examples include Virtual Private Network (VPN) or
mobile IP triangular routing. Details on how to obtain the IP
address that is used for communication in such setups are not
discussed in this memo, since they can be specific to the network
in use.
Kiesel, et al. Expires January 17, 2013 [Page 9]
Internet-Draft ALTO Server Discovery July 2012
2. Protocol Overview
We define multiple alternatives to discover the IP address of the
ALTO server, as there are a number of ways possible how such
information can be provided to the ALTO client. The choice of method
is up to the local network deployment. For instance, there can be
deployments where the ALTO server in charge for ALTO client is
provisioned by the network operator and communicated to the ALTO
client's host via a DHCP option, while in other deployments no such
means may exist.
It should be noted that there is no silver bullet solution to the
ALTO server discovery, as there too many deployment scenarios in the
server discovery space.
The following figure illustrates the different protocols that SHOULD
be used to find the URI of a suitable ALTO server.
Descending Order of Preference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
-------------- -------------- --------------
| User Input | | DHCP query | | PPP query |
| in res.c. | | by res.c. | | by res.c. |
-------------- -------------- --------------
| | |
\ | /
\--------+----------/
|
V
DNS suffix
|
V
------------------
| U-NAPTR lookup |
------------------
|
V
ALTO Server's Information Resource Directory URI
Legend:
res.c. : resource consumer
Figure 3: Protocol Overview
Figure 3 illustrates the U-NAPTR based resolution process to retrieve
the ALTO Server URI As a precondition for resolution the U-NAPTR
Kiesel, et al. Expires January 17, 2013 [Page 10]
Internet-Draft ALTO Server Discovery July 2012
process needs the right DNS suffix as input. This domain name is
typically the domain name of the client's IP address. In order to
retrieve the DNS suffix we specify three options, which are listed in
descending order of preference. A client SHOULD use the first method
that determines a DNS suffix. It MAY try the other methods in case
the U-NAPTR lookup failed.
User input: A user MAY manually specify the DNS suffix on its own,
either to access a 3rd party ALTO service provider or as it does
know such information. This input MAY also origin from a web page
where the user downloads the configuration, which is loaded as
user input, or obtained by other discovery methods.
DHCP: A network provider MAY provide the DNS suffix through a DHCP
option.
PPP: A network provider MAY provide the DNS suffix through a Point-
to-Point (PPP) Internet Protocol Control Protocol (IPCP)
extension.
This discovery method SHOULD be repeated if the resource consumer
moves, i. e., if its IP address changes.
Given that DHCP and PPP are widely used for IP address configuration,
this discovery method is applicable to many networks. The mechanism
described in this document can also be applied to further networks if
they provide an equivalent mechanism to retrieve the DNS suffix.
Such straightforward extensions to other technologies are not
specified in this memo.
Instead of using the standard ALTO server discovery method,
applications MAY also use own methods to discover an ALTO server.
This variant is outside the scope of this document.
Kiesel, et al. Expires January 17, 2013 [Page 11]
Internet-Draft ALTO Server Discovery July 2012
3. Retrieving the URI by U-NAPTR
This section specifies the U-NAPTR based resolution process. To
start the U-NAPTR resolution process a domain name is required as
input. Thus the section is devided into two parts: Section 3.2
describes the U-NAPTR resolution process itself. How the client
identifies this DNS suffix of the access network where the resource
consumer is registered in is described in Section 3.1.
3.1. Retrieving the Domain Name
The U-NAPTR resolution process requires a domain name as input. The
algorithm that SHOULD be applied to determine this domain name is
described in this section. We specify three different options. In
option 1 the user manually configures a specific ALTO service
instance that he wants to use. Option 2 defines a DHCP and option 3
defines a PPP IPCP option to allow the network service provider a
remote configuration of the client.
In general, the ALTO server discovery SHOULD be based on the IP
address that is used to communicate with other peers. The resource
consumer may have private IP addresses and public IP addresses and
depending on the deployment it might be necessary to determine for
all IP addresses the ALTO server in charge of. To determine its
public IP address the resource consumer may need to use STUN[RFC5389]
or BEP24[bep24]. Determining the correct IP address out of multiple
options strongly depends on the deployment scenario but is out of
scope for this document, although we discuss it to some extend in
Section 4. For the following examples we assume that the IP address
of the resource consumer is a.b.c.d.
3.1.1. Option 1: User input
A user may want to use a third party ALTO service instance.
Therefore we allow the user to specify a DNS suffix on its own, for
example in a config file option. The DNS suffix given by the user is
combined with the IP address of the resource consumer to allow the
third party ALTO service to direct the client to a suitable ALTO
server based on the location of the client. A possible DNS suffix
entered by the user may be:
myaltoprovider.org
In case not ALTO NAPTR records are found, we consider the discovery
process based on user input as failed. A client MAY try one of the
other options.
Kiesel, et al. Expires January 17, 2013 [Page 12]
Internet-Draft ALTO Server Discovery July 2012
3.1.2. Option 2: DHCP
As a second option network operators MAY configure the domain name to
be used for service discovery within an access network using DHCP.
RFC 5986[RFC5986] defines DHCP IPv4 and IPv6 access network domain
name options that identify a domain name that is suitable for service
discovery within the access network. The ALTO server discovery
procedure uses these DHCP options to retrieve the domain name as an
input for the U-NAPTR resolution. One example could be:
example.com
3.1.3. Option 3: PPP
In some network deployments the PPP [RFC1661] IPCP [RFC1332] is used
to do network configuration of residential user equipment, such as
assigning an IP address or the name of a DNS server[RFC1877]. Thus
as a third option a network operator MAY configure the domain name to
be used for the server discovery using a PPP IPCP extension. The
next section specifies the extension for configuration of the access
network domain name, which can be used as input for the U-NAPTR
process. One possible example yielded by this extension could be:
example.com
3.1.3.1. Access Network Name Encoding
This section describes the encoding of the domain name used in PPP
IPCP extension Section 3.1.3.2.
The domain name is encoded according to Section 3.1 of [RFC1035]
whereby each label is represented as a one-octet length field
followed by that number of octets. This is the same encoding as in
DHCP according to RFC 5986[RFC5986]. Since every domain name ends
with the null label of the root, a domain name is terminated by a
length byte of zero. The high-order two bits of every length octet
MUST be zero, and the remaining six bits of the length field limit
the label to 63 octets or less. To simplify implementations, the
total length of a domain name (i.e., label octets and label length
octets) is restricted to 255 octets or less.
For example, the domain "example.com." is encoded in 13 octets as:
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 | e | x | a | m | p | l | e | 3 | c | o | m | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
Kiesel, et al. Expires January 17, 2013 [Page 13]
Internet-Draft ALTO Server Discovery July 2012
3.1.3.2. Access Network Domain Name IPCP Configuration Option
This Configuration Option defines a method for negotiating with the
remote peer the name of the Access Network Domain Name to be used on
the local end of the link.
A summary of the Access Network Domain Name Configuration Option
format is shown below. The fields are transmitted from left to
right.
Type Len Access Network Domain Name
+-----+-----+-----+-----+-----+-----+-----+----
| TBD | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+----
The values s1, s2, s3, etc. represent the domain name labels in the
domain name encoding. Note that the length field in the IPCP option
represents the length of the entire domain name encoding, whereas the
length fields in the domain name encoding (see Section 3.1.3.1) is
the length of a single domain name label.
Type: to be assigned by IANA
Len: Length of the 'Access Network Domain Name' field in octets.
Access Network Domain Name: The domain name of the Access Network
for the client to use.
3.2. U-NAPTR Resolution
The ALTO protocol specification [I-D.ietf-alto-protocol] expects that
the ALTO discovery procedure yields the HTTP(S) URI of the ALTO
server's Information Resource Directory, which gives further
information about the capabilities and services provided by that ALTO
server. The first step of the ALTO server discovery procedure (see
Section 3.1) yielded an U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic
Delegation Discovery Service) [RFC4848] application unique strings,
in the form of a DNS name. An example is "example.com".
In the second step, the ALTO Server discovery procedure needs to use
the U-NAPTR [RFC4848] specification described below to obtain a URI
(indicating host and protocol) for the ALTO server's Information
Resource Directory. In this document, only the HTTP and HTTPS URL
schemes are defined, as the ALTO protocol specification defines the
access over both protocols, but no other [I-D.ietf-alto-protocol].
Note that the HTTP URL can be any valid HTTP(s) URL, including those
Kiesel, et al. Expires January 17, 2013 [Page 14]
Internet-Draft ALTO Server Discovery July 2012
containing path elements.
The following two DNS entries show the U-NAPTR resolution for
"example.com" to the HTTPS URL
https://altoserver.example.com/secure/directory or the HTTP URL
http://altoserver.example.com/directory, with the former being
preferred.
example.com.
IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://altoserver.example.com/secure/directory!" ""
IN NAPTR 200 10 "u" "ALTO:http"
"!.*!http://altoserver.example.com/directory!" ""
There is a potential that retrieveing the domain name or the U-NAPTR
lookup itself does not yield to a result, i.e. no ALTO NAPTR record
is found. In this case the discovery procedure failed for this IP
address. It is RECOMMENDED that clients give up the discovery
process and wait a period of time before repeating the procedure.
Clients MAY repeat the discovery procedure for a different IP address
instantaneously.
Kiesel, et al. Expires January 17, 2013 [Page 15]
Internet-Draft ALTO Server Discovery July 2012
4. Applicability
This section discusses the applicability of the proposed solution
with respect to the resource consumer server discovery and the third
party deployment scenarios. Each section discusses the proposed
steps that are needed to determine the ALTO Server URI.
4.1. Applicability for Resource Consumer Server Discovery
In this scenario the ALTO server discovery procedure is performed by
the resource consumer, for example a peer in a P2P system. After the
discovery the peer does the ALTO query on its own, or it might share
the ALTO server contact information with a third party, for example a
tracker, which then executes the ALTO query on behalf of the peer.
To complete the ALTO server discovery process the resource consumer
first SHOULD check whether the user has provider the domain name
through manual configuration. If this is not the case the next step
SHOULD be to check for the access network domain name DHCP option
(Section 3.1.2). Finally the client SHOULD try to retrieve the
domain name by the PPP option Section 3.1.3.
A client can have several candidate IP addresses that it may use for
the discovery process. For example if it is located behind a NAT, a
private and a public IP address may be used for the discovery
process. It depends on the deployment scenario which of the IP
addresses is the correct one. Thus it is out-of-scope of this
document to specify how exactly the client finds the right IP
address. However in the following we list methods that may be used
in order to determine these candidate IP addresses. Generally in P2P
environments peers already have implemented mechanisms for NAT-
traversal. This includes proprietary solutions to determine a peer's
public IP address, for example by asking a neighbour peer about its
record of the own IP address. Non-proprietary solutions that are
favorable include the Session Traversal Utilities for NAT (STUN)
[RFC5986] protocol to determine the public address. If the client is
behind a residential gateway another option may be to use Universal
Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] or the NAT Port
Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp].
In case the ALTO discovery client has determined the domain name
through one of the described options it proceedes with the U-NAPTR
lookup as described in Section 3.2.
4.2. Applicability for Third Party Server Discovery
In case of the third party server discovery deployment scenario the
entity performing the ALTO server discovery process is different from
Kiesel, et al. Expires January 17, 2013 [Page 16]
Internet-Draft ALTO Server Discovery July 2012
the resource consumer. Typically the resource consumer is a peer
whereas the ALTO client is a resource directory which seeks for ALTO
guidance on behalf of the peer. Another use case for the third party
discovery is an application that looks for ALTO guidance
transparently for the resource consumer, for example a CDN.
Here the ALTO server discovery process can also retrieve guidance
through the PPP/DHCP options or manual user configuration, but only
if the provided discovery information is forwarded by the resource
consumer to the third party entity. In this case, additional
mechanisms for the forwarding of this discovery information need to
be specified. However these mechanisms are out of scope of this
doument.
In case the resource consumer needs guidance for a different IP
address, for example one from a private network, we recommend that
the resource consumer discovers the server itself and forwards the
ALTO server contact information directly to the third party entity,
which in turn can then do the third party ALTO query. Again,
forwarding the contact information from the resource consumer to the
third party entity is out of scope of this document.
Kiesel, et al. Expires January 17, 2013 [Page 17]
Internet-Draft ALTO Server Discovery July 2012
5. Deployment Considerations
The mechanism specified in this document needs some configuration
effort in order to work properly.
5.1. DHCP option for DNS Suffix
Section 3.1.2 describes the usage of a DHCP option. It enables the
network operator of the network, in which the ALTO client is located,
to provide a DNS suffix. However, this assumes that this particular
DHCP option is correctly passed from the DHCP server to the actual
host with the ALTO client, and that the particular host understands
this DHCP option. This memo assumes the client to be able to
understand the proposed DHCP option, otherwise there is no further
use of the DHCP option, but the client has to use the other proposed
mechanisms.
There are well-known issues with the handling of DHCP options in home
gateways. One issue is that unkown DHCP options are not passed
through some home gateways, effectively eliminating the DHCP option.
Another well-known issues is the usage of home gateway specific DNS
suffixes which "override" the DNS suffix provided by the network
operator. For instance, a host behind a home gateway may receive a
DNS suffix ".local" instead of "example.com". This suffix is not
usuable for the server discovery procedure.
5.2. PPP option for DNS Suffix
Section 3.1.3 describes the usage of a PPP option. It enables the
network operator of the network, in which the ALTO client is located,
to provide a DNS suffix. In residental networks, PPP is often
terminated in the residential gateway. The ALTO client may run on
hosts behind that gateway. As a result, the information may have to
be passed to the client. The residential gateway could for instance
use the DHCP option for that.
Kiesel, et al. Expires January 17, 2013 [Page 18]
Internet-Draft ALTO Server Discovery July 2012
6. IANA Considerations
6.1. Registration of PPP IPCP Configuration Option Type
The IANA is requested to assign an Type code for the PPP IPCP
Configuration Option Types for an Access Network Domain Name, as
described in Section 3.1.3.2 of this document.
[TO BE REMOVED: This registration should take place at the following
location: http://www.iana.org/assignments/ppp-numbers]
6.2. Registration of U-NAPTR application service tag
The IANA is requested to register the following U-NAPTR application
service tag:
Application Service Tag: ALTO
Intended usage: Identifies a service that provides a Device with
its location information.
Defining Publication: The specification contained within this
document.
Contact information: The authors of this document
Author/Change controller: The IESG
Kiesel, et al. Expires January 17, 2013 [Page 19]
Internet-Draft ALTO Server Discovery July 2012
7. Security Considerations
7.1. General
There are two different failures for the ALTO server discovery, which
can both be caused by malicious attacks or by configuration problems,
e. g., in case of DNS configuration errors or multi-homed hosts.
First, the discovery might not be able to discover an ALTO server,
even if a suitable ALTO server exists. In that case, ALTO guidance
will not be used. The resulting application performance and traffic
distribution will correspond to a deployment scenario without ALTO
guidance. But given that users cannot rely on the availability of an
ALTO server, this results in no significant additional security risk.
Second, the discovery procedure may discover a sub-optimal or wrong
ALTO server. Such an ALTO server may either not be able to provide
information for a given resource consumer (e. g., behind a NAT), thus
rendering the ALTO service useless. Alternatively, it may provide
sub-optimal or forged information. In the latter case, attackers
could try to use ALTO to affect the traffic distribution or the
performance of applications. Users may then observe performance
problems, and network operators could detect traffic anormalities. A
potential counter-measure is to disable the use of the ALTO service.
Security issues of ALTO in general and potential solutions are also
discussed in [I-D.ietf-alto-protocol].
7.2. For U-NAPTR
The address of an ALTO server is usually well-known within an access
network; therefore, interception of messages does not introduce any
specific concerns.
The primary attack against the methods described in this document is
one that would lead to impersonation of an ALTO server since a device
does not necessarily have a prior relationship with an ALTO server.
An attacker could attempt to compromise ALTO discovery at any of
three stages:
1. providing a falsified domain name to be used as input to U-NAPTR
2. altering the DNS records used in U-NAPTR resolution
3. impersonation of the ALTO server
This document focuses on the U-NAPTR resolution process and hence
Kiesel, et al. Expires January 17, 2013 [Page 20]
Internet-Draft ALTO Server Discovery July 2012
this section discusses the security considerations related to the DNS
handling. The security aspects of obtaining the domain name that is
used for input to the U-NAPTR process is described in respective
documents, such as [RFC5986].
The domain name that is used to authenticated the ALTO server is the
domain name in the URI that is the result of the U-NAPTR resolution.
Therefore, if an attacker was able to modify or spoof any of the DNS
records used in the DDDS resolution, this URI could be replaced by an
invalid URI. The application of DNS security (DNSSEC) [RFC4033]
provides a means to limit attacks that rely on modification of the
DNS records used in U-NAPTR resolution. Security considerations
specific to U-NAPTR are described in more detail in [RFC4848].
An "https:" URI is authenticated using the method described in
Section 3.1 of [RFC2818]. The domain name used for this
authentication is the domain name in the URI resulting from U-NAPTR
resolution, not the input domain name as in [RFC3958]. Using the
domain name in the URI is more compatible with existing HTTP client
software, which authenticate servers based on the domain name in the
URI.
An ALTO server that is identified by an "http:" URI cannot be
authenticated. If an "http:" URI is the product of the ALTO
discovery, this leaves devices vulnerable to several attacks. Lower
layer protections, such as layer 2 traffic separation might be used
to provide some guarantees.
Kiesel, et al. Expires January 17, 2013 [Page 21]
Internet-Draft ALTO Server Discovery July 2012
8. Conclusion
This document describes a general ALTO server discovery process and
discusses how the process can be applied in different deployment
scenarios. The discovery process uses U-NAPTR resolution based on
input information obtained either manually, by DHCP, or by PPP.
Kiesel, et al. Expires January 17, 2013 [Page 22]
Internet-Draft ALTO Server Discovery July 2012
9. References
9.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol Extensions for Name Server Addresses", RFC 1877,
December 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
November 2011.
9.2. Informative References
[I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.ietf-alto-deployments]
Stiemerling, M. and S. Kiesel, "ALTO Deployment
Considerations", draft-ietf-alto-deployments-03 (work in
progress), November 2011.
Kiesel, et al. Expires January 17, 2013 [Page 23]
Internet-Draft ALTO Server Discovery July 2012
[I-D.ietf-alto-protocol]
Penno, R., Alimi, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-10 (work in progress),
October 2011.
[I-D.ietf-alto-reqs]
Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-11 (work in progress),
July 2011.
[I-D.kist-alto-3pdisc]
Kiesel, S. and M. Stiemerling, "3rd Party ALTO Server
Discovery (3pdisc)", draft-kist-alto-3pdisc-00 (work in
progress), July 2012.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472,
April 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986,
September 2010.
[UPnP-IGD-WANIPConnection1]
UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0: WANIPConnection:1 Service
Template Version 1.01 For UPnP Version 1.0", DCP 05-001,
November 2001.
[bep24] Harrison, D., "Tracker Returns External IP",
BEP http://bittorrent.org/beps/bep_0024.html.
Kiesel, et al. Expires January 17, 2013 [Page 24]
Internet-Draft ALTO Server Discovery July 2012
Appendix A. Contributors List and Acknowledgments
The initial version of this document was co-authored by Marco Tomsu
<marco.tomsu@alcatel-lucent.com>.
Hannes Tschofenig provided the initial input to the U-NAPTR solution
part. Hannes and Martin Thomson provided excellent feedback and
input to the server discovery.
Olafur Gudmundsson provided an excellent DNS expert review on an
earlier version of this document.
The authors would also like to thank the following persons for their
contribution to this document or its predecessors: Richard Alimi,
David Bryan, Roni Even, Gustavo Garcia, Jay Gu, Xingfeng Jiang,
Enrico Marocco, Victor Pascual, Y. Richard Yang, Yu-Shun Wang, Yunfei
Zhang, Ning Zong.
Nico Schwan is partially supported by the ENVISION project
(http://www.envision-project.org), a research project supported by
the European Commission under its 7th Framework Program (contract no.
248565). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the ENVISION project or the European Commission.
Michael Scharf is supported by the German-Lab project
(http://www.german-lab.de) funded by the German Federal Ministry of
Education and Research (BMBF).
Martin Stiemerling is partially supported by the COAST project
(COntent Aware Searching, retrieval and sTreaming,
http://www.coast-fp7.eu), a research project supported by the
European Commission under its 7th Framework Program (contract no.
248036). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the COAST project or the European Commission.
Kiesel, et al. Expires January 17, 2013 [Page 25]
Internet-Draft ALTO Server Discovery July 2012
Authors' Addresses
Sebastian Kiesel
University of Stuttgart Computing Center
Allmandring 30
Stuttgart 70550
Germany
Email: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/
Martin Stiemerling
NEC Laboratories Europe
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 113
Email: martin.stiemerling@neclab.eu
URI: http://ietf.stiemerling.org
Nico Schwan
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: nico.schwan@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs
Michael Scharf
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: michael.scharf@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs
Haibin Song
Huawei
Email: melodysong@huawei.com
Kiesel, et al. Expires January 17, 2013 [Page 26]