< draft-kiesel-alto-3pdisc-03.txt   draft-kiesel-alto-3pdisc-04.txt >
ALTO S. Kiesel ALTO S. Kiesel
Internet-Draft University of Stuttgart Internet-Draft University of Stuttgart
Intended status: Informational M. Tomsu Intended status: Standards Track M. Tomsu
Expires: January 10, 2011 N. Schwan Expires: April 28, 2011 Alcatel-Lucent
N. Schwan
M. Scharf M. Scharf
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
M. Stiemerling M. Stiemerling
NEC Europe Ltd. NEC Europe Ltd.
July 9, 2010 October 25, 2010
Third-party ALTO server discovery ALTO Server Discovery Protocol
draft-kiesel-alto-3pdisc-03 draft-kiesel-alto-3pdisc-04
Abstract Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications, which have to select one or several provide guidance to applications, which have to select one or several
hosts from a set of candidates that are able to provide a desired hosts from a set of candidates that are able to provide a desired
resource. resource.
Entities seeking guidance need to discover and possibly select an Entities seeking guidance need to discover and possibly select an
ALTO server to ask. This is called ALTO server discovery. This memo ALTO server to ask. This is called ALTO server discovery. This memo
describes an ALTO server discovery mechanism based on DNS SRV describes an ALTO server discovery mechanism based on several
records. alternative mechanisms that are applicable in a diverse set of ALTO
deployments.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DNS-based ALTO Server Discovery . . . . . . . . . . . . . . . 5 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DNS SRV record definition . . . . . . . . . . . . . . . . 5 1.2. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 4
2.2. DNS SRV record lookup procedure . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Step 1: Finding the IP address . . . . . . . . . . . . 6 3. Retrieving the URI by DHCP . . . . . . . . . . . . . . . . . . 7
2.2.2. Step 2: Determining the DNS suffix . . . . . . . . . . 6 3.1. ALTO Server Domain Name Encoding . . . . . . . . . . . . . 7
2.2.3. Step 3: Lookup SRV record . . . . . . . . . . . . . . 7 3.2. ALTO Server DHCPv4 Option . . . . . . . . . . . . . . . . 7
2.2.4. Step 4: Final lookup . . . . . . . . . . . . . . . . . 8 3.3. ALTO Server DHCPv6 Option . . . . . . . . . . . . . . . . 8
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 10
3.1. Applicability for third party server discovery . . . . . . 9 4.1. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 10
3.2. Applicability for resource consumer server discovery . . . 9 4.2. Retrieving the Domain Name . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Option 1: User input . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4.2.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 12
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 5.1. Applicability for Resource Consumer Server Discovery . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 5.2. Applicability for Third Party Server Discovery . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. For U-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 16
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications, which have to select one or several provide guidance to applications, which have to select one or several
hosts from a set of candidates, that are able to provide a desired hosts from a set of candidates, that are able to provide a desired
resource[RFC5693]. The requirements for ALTO are itemized in resource [RFC5693]. The requirements for ALTO are itemized in
[I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol. [I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol.
ALTO clients send queries to ALTO servers, in order to solicit ALTO clients send queries to ALTO servers, in order to solicit
guidance. guidance.
ALTO clients have to discover suitable ALTO servers. Therefore the ALTO clients have to discover suitable ALTO servers. Therefore the
ALTO discovery client tells the ALTO client which ALTO servers to output of the herein defined ALTO discovery procedure tells the ALTO
send the queries to. The ALTO discovery client and the ALTO client client which ALTO servers to send the queries to. The ALTO discovery
can be embedded in the resource consumer, which will eventually procedure, as part of the the ALTO client, can be embedded in the
access the desired resource. As an alternative, they can be embedded resource consumer, which will eventually access the desired resource.
in a resource directory, which assists resource consumers in finding As an alternative, they can be embedded in a resource directory,
appropriate resource providers. In some specific peer-to-peer which assists resource consumers in finding appropriate resource
application protocols these resource directories are called providers. In some specific peer-to-peer application protocols these
"trackers". Finally the ALTO discovery client can be embedded in the resource directories are called "trackers". Finally the ALTO server
resource consumer, whereas the ALTO client is embedded in the discovery procedure can be embedded in the resource consumer, whereas
resource directory. ALTO queries, which are issued by a resource the ALTO client is embedded in the resource directory. ALTO queries,
directory on behalf of a resource consumer, are referred to as third- which are issued by a resource directory on behalf of a resource
party ALTO queries. The various possibilities to place ALTO servers consumer, are referred to as third-party ALTO queries. The various
and the placement of ALTO clients is discussed in possibilities to place ALTO servers and the placement of ALTO clients
[I-D.stiemerling-alto-deployments]. is discussed in [I-D.stiemerling-alto-deployments].
[I-D.song-alto-server-discovery] compares different protocol options
and identifies DHCP and DNS as two approaches for the ALTO server
discovery without detailing on the exact solution.
No matter where ALTO server and client are located, clients have to No matter where ALTO server and client are located, clients have to
first find out if there is an ALTO server deployed that is in charge first find out if there is an ALTO server deployed that is in charge
for them and second to get the contact information of that server, for them, and second they have to get the contact information of that
i.e., the IP address, port number, and probably transport protocol server, i.e., the IP address, port number, and probably transport
(which defaults to TCP for [I-D.ietf-alto-protocol]). protocol (which defaults to TCP for [I-D.ietf-alto-protocol]).
There exists a number of service location protocols, such as SLP
[RFC2608] or DHCP [RFC2131][RFC3315], which could in principle be
used for ALTO discovery. However, SLP is not widely deployed or used
within the Internet. DHCP is widely deployed but has several
limitations:
o Though widely deployed DHCP is not in use everywhere. For
important scenarios, such as PPPoE based DSL access networks one
would have to specify another mechanism.
o A DHCP-based discovery mechanism will always yield the addresses
of the ALTO servers that are provided by the network operator.
The user cannot influence the discovery and, e.g., select an
alternative ALTO service from an "independent" ALTO operator.
o There are problems with residential gateways or broadband routers
with NAT. If the network operator gives information about ALTO
serves to the residential gateway via DHCP, the residential
gateway would have to forward this information to the hosts with
the (P2P) applications within the local network. This is not
supported by any of the already deployed residential gateways.
o DHCP poorly supports third-party ALTO server discovery, i.e., in
scenarios where the ALTO client is co-located with a resource
directory ("tracker"), which is located in a different
administrative domain than the client which will eventually access
the ressource.
The goal of this memo is to propose a uniform mechanism for all types The goal of this memo is to propose a uniform mechanism for all types
of ALTO client deployments that is implementable and deployable at a of ALTO client deployments that is implementable and deployable at a
fast pace, i.e., without creating other deployment dependecies for fast pace, i.e., without creating other deployment dependecies for
ALTO. One way of fulfilling the previous mentioned requirements is ALTO. We propose to use a combination of DHCP and DNS to retrieve
using the Service Records (SRV) of the Domain Name System (DNS), as the URL of the resposnsible ALTO server.
described in [RFC2782]. DNS SRVs have been defined and are used for
a number of protocols, such as SIP and XMPP.
Comments and discussions about this memo should be directed to the Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org. ALTO working group: alto@ietf.org.
2. DNS-based ALTO Server Discovery 1.1. Requirements
2.1. DNS SRV record definition There is other related works on server discovery, for instance
GEOPRIV has rather strong security requirements (for good reasons),
which are documented in [I-D.ietf-geopriv-lis-discovery]. However,
these requirements do not apply for the ALTO server discovery, as
ALTO as such has very different requirements (see
[I-D.ietf-alto-reqs]).
We define a new service record for ALTO servers according to The result of the guidance provided to the application via the ALTO
[RFC2782]. The general format of the SRV RR, whose DNS type code is protocol is input to improve the initial peer selection process for
33, is peer-to-peer applications, or any other application applicable. A
missing ALTO server, i.e., no result returned as part of the ALTO
server discovery procedure, does not prevent the application to
operate. A wrong or forged guidance from the ALTO server may only
impact the overall operational result of the peer-to-peer system for
a limited time, as these systems fine-tune their behavior depending
on the experience network behavior.
_Service._Proto.Name TTL Class SRV Priority Weight Port Target This means that a wrong, missing, or forged ALTO guidance will not
cause damage to the application or peer-to-peer system. This is in
sharp contrast to the GEOPRIV use case, where a failure may have
severe impact, including loss of human life. This is not the case
for ALTO, as it is intended to be used today and as it is explored
right now from the networking community.
Where for the ALTO server discovery, we define: 1.2. Pre-Conditions
Service alto The whole document assumes certain pre-conditions, such as:
Proto tcp 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.
Name "The domain this RR refers to. The SRV RR is unique in that o The ALTO server discovery procedure is executed on a per IP family
the name one searches for is not this name; the example near the base, i.e., seperate for IPv4 and IPv6. It is up to the ALTO
end shows this clearly."[RFC2782] 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.
TTL Standard DNS meaning [RFC2782] 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.
Class Standard DNS meaning[RFC2782] 2. Protocol Overview
Priority "The priority of this target host. A client MUST attempt We define multiple alternatives to discover the IP address of the
to contact the target host with the lowest-numbered priority it ALTO server, as there are a number of ways possible how such
can reach; target hosts with the same priority SHOULD be tried in information can be provided to the ALTO client. The choice of method
an order defined by the weight field. The range is 0-65535. This is up to the local network deployment. For instance, there can be
is a 16 bit unsigned integer in network byte order." [RFC2782] 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.
Weight "A server selection mechanism. The weight field specifies a The following figure illustrates the different protocols that are
relative weight for entries with the same priority. Larger used to find the URI of a suitable ALTO server.
weights SHOULD be given a proportionately higher probability of
being selected. The range of this number is 0-65535. This is a
16 bit unsigned integer in network byte order. Domain
administrators SHOULD use Weight 0 when there isn't any server
selection to do, to make the RR easier to read for humans (less
noisy). In the presence of records containing weights greater
than 0, records with weight 0 should have a very small chance of
being selected.[...]" [RFC2782]
Port "The port on this target host of this service. The range is 0- Descending order of Preference
65535. This is a 16 bit unsigned integer in network byte order. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
This is often as specified in Assigned Numbers but need not
be."[RFC2782] It will be set to 80, if the standard TCP port for
HTTP is used, but this also allows to run the service on any other
port.
Target "The domain name of the target host. There MUST be one or -------- -------------- -------- ---------------
more address records for this name, the name MUST NOT be an alias | DHCP | | User Input | | DHCP | | Reverse DNS |
(in the sense of RFC 1034 or RFC 2181). Implementors are urged, -------- -------------- -------- ---------------
but not required, to return the address record(s) in the | | | |
Additional Data section. Unless and until permitted by future | \ | /
standards action, name compression is not to be used for this | Retrieving the DNS suffix
field. A Target of "." means that the service is decidedly not | \ | /
available at this domain. "[RFC2782] | --------+----------
\ |
\ Determine own IP address
\ |
\ -----------
\ | U-NAPTR |
\ -----------
\ |
Retrieving ALTO Server URI
\ |
---------+----------
|
Final DNS lookup
An example for querying for such an ALTO service record running in Figure 1: Protocol Overview
the domain myisp.net:
_alto._tcp.example.com IN SRV 1 0 80 alto-srv01.myisp.net One option to retrieve the URI directly from the access network
provider is DHCP. However for DHCP there are problems with
residential gateways or broadband routers with NAT. If the network
operator gives information about ALTO serves to the residential
gateway via DHCP, the residential gateway would have to forward this
information to the hosts with the (P2P) applications within the local
network. This is not supported by already deployed residential
gateways. Also DHCP poorly supports third-party ALTO server
discovery, i.e., in scenarios where the ALTO client is co-located
with a resource directory ("tracker"), which is located in a
different administrative domain than the client which will eventually
access the ressource.
2.2. DNS SRV record lookup procedure Thus in deployment scenarios where DHCP is not possible, we specify a
U-NAPTR based resolution process as a second option to retrieve the
URL. As a precondition for resolution the U-NAPTR process needs the
right domain name as input. This domain name is determined by the IP
address of the client and the DNS suffix of the access network where
the client is registered in. In order to retrieve the DNS suffix we
specify three options:
This section describes the algorithm that is applied to discover the User input: a user may manually specify the DNS suffix on its own,
ALTO server. We differentiate between two use cases: In use case (a) either to access a 3rd party ALTO service provider or as it does
the user has no specific wish which ALTO service instance to use. know such information.
Here the ALTO service instance is provided by default by the user's
access network provider, thus the ALTO discovery client needs to
determine the correct domain name automatically. In case (b) the
user configures a specific ALTO service instance that he wants to
use. Here the ALTO discovery client already has the information
about which DNS suffix to use.
2.2.1. Step 1: Finding the IP address DHCP: a network provider provides the DNS suffix through a DHCP
option.
The first step for the ALTO discovery client is to determine the IP Reverse DNS: the DNS system can be used to retrieve the DNS suffix
address or IP addresses of the resource consumer. The resource through reverse lookup of an FQDN associated with an IP address.
consumer may have private IP addresses and public IP addresses and This is the last resort if all other options failed.
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]. For the following example we assume that the IP
address of the resource consumer is a.b.c.d
2.2.2. Step 2: Determining the DNS suffix 3. Retrieving the URI by DHCP
To get the DNS suffix in case (a) the ALTO discovery uses a DNS PTR One way of directly configuring the ALTO server URI for an access
query for the IP address of the resource consumer as determined in network provider is the DHCP protocol. The ALTO server URI consists
step 1. The local DNS server resolves the IP address to the FQDN of a domain name and the protocol the client should use to contact
that also contains the DNS suffix for the respective IP address. A the server. While the domain name can vary and is configured by
possible answer for a PTR lookup for d.c.b.a.in-addr.apra might be, DHCP, the protocol is always HTTP.
for example:
d-c-b-a.dsl.westcoast.myisp.net For example a client may retrieve the domain name
altoserver.example.com by the DHCP option as described in the
remaining section. The client uses this domain name to contact the
ALTO server under
In case (b) The user specifies the DNS suffix on its own, for example http://altoserver.example.com/
in a config file option. Here the user wants to use an ALTO service
instance which is operated by a third party as for example the 3.1. ALTO Server Domain Name Encoding
tracker operator. A possible DNS suffix entered by the user may be:
This section describes the encoding of the domain name used in the
DHCPv4 option shown in Section 3.2 and also used in the DHCPv6 option
shown in Section 3.3.
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. 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.
3.2. ALTO Server DHCPv4 Option
The ALTO server DHCPv4 option carries a DNS ([RFC1035]) fully-
qualified domain name (FQDN) to be used by the ALTO client to locate
a ALTO server.
The DHCP option for this encoding has the following format:
Code Len ALTO Server Domain Name
+-----+-----+-----+-----+-----+-----+-----+----
| tba | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+----
Figure 2: ALTO FQDN DHCPv4 Option
The values s1, s2, s3, etc. represent the domain name labels in the
domain name encoding. Note that the length field in the DHCPv4
option represents the length of the entire domain name encoding,
whereas the length fields in the domain name encoding (see
Section 3.1) is the length of a single domain name label.
Code: to be assigned by IANA
Len: Length of the 'ALTO Server Domain Name' field in octets;
variable.
ALTO Server Domain Name: The domain name of the ALTO server for the
client to use.
A DHCPv4 client MAY request a ALTO server domain name in a Parameter
Request List option, as described in [RFC2131].
The encoding of the domain name is described in Section 3.1.
This option contains a single domain name and, as such, MUST contain
precisely one root label.
3.3. ALTO Server DHCPv6 Option
This section specifies the DHCP option for IPv6 (DHCPv6) to carry the
domain name of the ALTO server. It is similar formatted to the
DHCPv4 option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA: OPTION CODE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ALTO Server Domain Name .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ALTO Server Domain Name DHCPv4 Option
option-code: to be assigned by IANA
option-length: The length of the 'ALTO Server Domain Name' field in
octets; variable.
ALTO Server Domain Name: The domain name of the ALTO server for the
client to use.
A DHCPv6 client MAY request a ALTO server domain name in an Options
Request Option (ORO), as described in [RFC3315].
The encoding of the domain name is described in Section 3.1.
This option contains a single domain name and, as such, MUST contain
precisely one root label.
4. Retrieving the URI by U-NAPTR
As already described a direct DHCP configuration may not always be
possible, for example due to deployment restrictions of the access
network. Alternatively the ALTO server URI can be discovered by a
U-NAPTR resolution process, as specified in this section.
The section is devided in two parts: Section 4.1 describes the
U-NAPTR resolution process itself. As a precondition this process
requires the domain name of the access network where the resouce
consumer is registered in. How the client identifies this DNS suffix
is described in Section 4.2.
4.1. U-NAPTR Resolution
ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/
Dynamic Delegation Discovery Service) [RFC4848] application unique
strings, in the form of a DNS name. An example is
'altoserver.example.com'.
Clients need to use the U-NAPTR [RFC4848] specification described
below to obtain a URI (indicating host and protocol) for the
applicable ALTO service. In this document, only the HTTP and HTTPS
URL schemes are defined. Note that the HTTP URL can be any valid
HTTP URL, including those 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
or the HTTP URL http://altoserver.example.com, with the former being
preferred.
example.com.
IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://altoserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "ALTO:http"
"!.*!http://altoserver.example.com!" ""
4.2. Retrieving the Domain Name
The U-NAPTR resolution process requires a domain name as input. The
algorithm that is 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 option to allow the network
service provider a remote configuration of the client. In option 3
the client tries to get the domain name by performing a reverse DNS
lookup on its IP address.
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]. For the following examples we assume
that the IP address of the resource consumer is a.b.c.d.
4.2.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 myaltoprovider.org
2.2.3. Step 3: Lookup SRV record This DNS suffix is prepended with the IP address of the resource
consumer in reverse order to compose the domain name used for the
final U-NAPTR lookup Section 4.1. In case there are multiple ALTO
servers deployed, the third party ALTO service instance can direct
the ALTO client to the ALTO server closest to the client based on the
IP address.
In step 3 the ALTO discovery client uses the information that has Multiple lookups with different domain names might be necessary to
been determined in the previous steps to composes the domain name complete the U-NAPTR resolution process. If there is no response for
that is used for the SRV queries. As the suffix part in not obvious a lookup the domain name is shortened by one part for the succeeding
in all cases e.g., it can be for the above example lookup, until a lookup is successful, as for example
"westcoast.myisp.net" or "myisp.net", the ALTO discovery client might
need to perform multiple SRV lookups until it gets a PTR reply.
In case (a) the ALTO discovery client composes the domain name as d.c.b.a.myaltoprovider.org.
described in Section 2. If there is no response to the lookup the
DNS suffix is shortened by one part for the succeeding lookup. The
domain names used for the example as described above are:
_alto._tcp.d-c-b-a.dsl.westcoast.myisp.net. c.b.a.myaltoprovider.org.
_alto._tcp.dsl.westcoast.myisp.net. b.a.myaltoprovider.org.
_alto._tcp.westcoast.myisp.net. a.myaltoprovider.org.
_alto._tcp.myisp.net. myaltoprovider.org.
For case (b) the ALTO discovery client extends the DNS suffix by the 4.2.2. Option 2: DHCP
IP address of the resource consumer in reverse order to compose the
domain name. This is needed for the third party ALTO service
instance to direct the ALTO client to the ALTO server closest to the
client in case there are multiple ALTO servers deployed. The suffix
is then shortened as described before until a lookup is successful,
as for example
_alto._tcp.d.c.b.a.myaltoprovider.org. As a second option network operators can configure the domain name to
be used for service discovery within an access network. 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:
_alto._tcp.c.b.a.myaltoprovider.org. example.com
_alto._tcp.b.a.myaltoprovider.org. 4.2.3. Option 3: Reverse DNS Lookup
_alto._tcp.a.myaltoprovider.org. The last option to get the domain name is to use a DNS PTR query for
the IP address of the resource consumer. The local DNS server
resolves the IP address to the FQDN that also contains the DNS suffix
for the respective IP address. A possible answer for a PTR lookup
for d.c.b.a.in-addr.apra might be, for example:
_alto._tcp.myaltoprovider.org. d-c-b-a.dsl.westcoast.myisp.net
2.2.4. Step 4: Final lookup This domain name can be used for the final U-NAPTR lookup
Section 4.1. Again, if there is no response to the lookup the domain
name is shortened by one part for the succeeding lookup. The domain
names used for the example as described above are:
After step 3 has been completed the ALTO discovery client processes d-c-b-a.dsl.westcoast.myisp.net.
the PTR records and performs the final DNS lookup on the A record.
It then forwards the contact information to the ALTO client, which
can now contact the ALTO server to perform ALTO queries.
3. Applicability dsl.westcoast.myisp.net.
westcoast.myisp.net.
myisp.net.
5. Applicability
This section discusses the applicability of the proposed solution This section discusses the applicability of the proposed solution
with respect to the third party and the resource consumer server with respect to the resource consumer server discovery and the third
discovery deployment scenarios. Each section discusses the proposed party deployment scenarios. Each section discusses the proposed
steps that are needed to create the right domain name for the final steps that are needed to determine the ALTO Server URI.
DNS lookup.
3.1. Applicability for third party server discovery 5.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 does the ALTO query on behalf of the peer.
The access network provider has two options based on DHCP to remotely
configure the ALTO client to use its ALTO server. The first option
is to provide the ALTO server URI directly by a DHCP option as
described in Section 3, the second option is to provide the access
network domain name as described in Section 4.2.2. It is up to the
access network provider to choose one of both options.
To complete the ALTO server discovery process the resource consumer
first SHOULD try to retrieve the ALTO server URI by the DHCP option
as described in Section 3. In case this is successful the discovery
process is finished, in case it fails, either as the access network
provider has not configured the specified option or through
deployment restrictions, the resource consumer SHOULD subsequently
check whether the user has provider the domain name through manual
configuration. If this is also not the case the next step SHOULD be
to check for the access network domain name DHCP option
(Section 4.2.2). Finally the client SHOULD try to retrieve the
domain name by the last option, the DNS reverse lookup on its IP
address as described in Section 4.2.3.
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 4.1.
If the ALTO server URI could not be retrieved either through direct
configuration by the access network provider through DHCP nor through
the U-NAPTR lookup the discovery process fails.
5.2. Applicability for Third Party Server Discovery
In case of the third party server discovery deployment scenario the In case of the third party server discovery deployment scenario the
ALTO discovery client is a different entity than the resource entity performing the ALTO server discovery process is different from
consumer. Typically the resource consumer is a peer wehereas the the resource consumer. Typically the resource consumer is a peer
ALTO (discovery) client is a resource directory which seeks for ALTO 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 guidance on behalf of the peer. Another use case for the third party
discovery is an application that looks for ALTO guidance discovery is an application that looks for ALTO guidance
transparently to the resource consumer, for example a CDN. transparently for the resource consumer, for example a CDN.
Here the ALTO discovery client already knows the IP address of the Here the ALTO server discovery process can also retrieve guidance
resource consumer which was used to establish the initial connection. through one of the DHCP options or manual user configuration, but
In general this IP address is a public address, either of the only if the provided discovery information is forwarded by the
resource consumer or of the last NAT on the path to the ALTO client. resource consumer to the third party entity. In this case,
This makes the IP address a good candidate for the next steps. In additional mechanisms for the forwarding of this discovery
case the resource consumer needs guidance for a different IP address, information need to be specified. However these mechanisms are out
for example one from a private network, we propose that the resource of scope of this doument.
consumer does the server discovery by itself and forwards the ALTO
server contact information directly to the ALTO client which in turn
can then do the third party ALTO query.
To determine the DNS suffix the ALTO discovery client uses a DNS PTR If the third party entity cannot obtain this discovery information,
query. As here the IP address is public we expect that the DNS query the ALTO server discovery process relies on retrieving the domain
will be successfully resolved to the FQDN of the domain where the name used as input to the U-NAPTR lookup through reverse DNS lookup
resource consumer is registered in. of the IP address of the resource consumer as described in
Section 4.2.3. Usually the third party entity already knows the IP
address of the resource consumer which was used to establish the
initial connection. In general this IP address is a public address,
either of the resource consumer or of the last NAT on the path to the
ALTO client. This makes the IP address a good candidate for the DNS
PTR query. Thus, we expect that the DNS query will be successfully
resolved to the FQDN of the domain where the resource consumer is
registered in.
To compose the right domain name from the FQDN the ALTO discovery In case the resource consumer needs guidance for a different IP
client follows the mechansims as described in Section 2.2.3. address, for example one from a private network, we recommend that
Additionally the ALTO discovery client can cache domain names and the resource consumer discovers the server itself and forwards the
contact details of already discovered ALTO servers and compare them ALTO server contact information directly to the third party entity,
with the FQDN by a longest suffix matching. If successful the client which in turn can then do the third party ALTO query. Again,
can use the contact information and skip the final discovery step. forwarding the contact information from the resource consumer to the
third party entity is out of scope of this document.
The fourth step of the procedure can be applied as described. 6. IANA Considerations
3.2. Applicability for resource consumer server discovery This document registers the following U-NAPTR application service
tag:
In this scenario the ALTO discovery client that performs the Application Service Tag: ALTO
discovery is also 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 does the ALTO query on
behalf of the peer.
DNS SRV records can be used for resource consumer discovery, too. Defining Publication: The specification contained within this
Depending on the deployment scenario the resource consumer will have document.
multiple IP addresses which are possible candidates for a reverse
lookup to determine the FQDN in step 2. Usually the ALTO server is
responsible for a set of public IP addresses, thus in case the
resource consumer is behind a NAT or a residential gateway it needs
to determine the public IP address assigned to it. As discussed in
Section 2.2.1 this can be done by the use of STUN[RFC5389] or
BEP24[bep24].
In other deployment scenarios where internal guidance for a large This document registers the following U-NAPTR application protocol
private domain is desired the ALTO server might be inside the same tags:
private domain as the resource consumer. In this case the resource
consumer can either use a private IP address or it needs to find a
STUN server that is also inside the private domain in order to find
the right IP address.
To determine the DNS suffix for a public IP address the procedure is o Application Protocol Tag: http
as described in the respective section. In case of a private IP
address it has to be ensured that the DNS server that is used by the
discovery client is a local one that is capable of resolving the
private IP address.
The third and fourth step of the procedure can be applied as Defining Publication: RFC 2616 [RFC2616]
described.
4. IANA Considerations o Application Protocol Tag: https
This document does not mandate any immediate IANA actions. However, Defining Publication: RFC 2818 [RFC2818]
such IANA considerations may arise from future ALTO discovery
specification documents which try to meet the requirements given
here.
5. Security Considerations 7. Security Considerations
This early version of this memo does not yet have any security 7.1. General
considerations, but they will be added in future revision.
6. Conclusion This is still to be done in later revision of this draft, as the
draft evolves heavily right now.
This document describes a general DNS SRV queries based ALTO server 7.2. For U-NAPTR
discovery mechanism and discusses how ALTO discovery clients can find
the right domain name which has to be used for the query. In
addition this document discusses the applicability of the described
mechanism for the third party as well as the resource consumer
discovery.
7. References The address of an ALTO server is usually well-known within an access
network; therefore, interception of messages does not introduce any
specific concerns.
7.1. Normative References The primary attack against the methods described in this document is
one that would lead to impersonation of a ALTO server since a device
does not necessarily have a prior relationship with a ALTO server.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate An attacker could attempt to compromise ALTO discovery at any of
Requirement Levels", BCP 14, RFC 2119, March 1997. three stages:
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1. providing a falsified domain name to be used as input to U-NAPTR
specifying the location of services (DNS SRV)", RFC 2782,
February 2000. 2. altering the DNS records used in U-NAPTR resolution
3. impersonation of the ALTO
This document focuses on the U-NAPTR resolution process and hence
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 [I-D.ietf-geopriv-lis-discovery].
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 were 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.
8. Open Issues
Here are a few open issues to be clarified:
Handling of reverse DNS lookups for IPv6: Refer to [RFC4472] for a
discussion about the issues.
Missing reverse DNS entries for an IP address: There may be cases
where the reverse DNS lookup does not yield any result. However,
this will leave the ALTO client with no choice, other than giving
up. This needs better documentation.
How to handled multiple results: For instance, a host behind a NAT
that yields an ALTO server in the private IP address domain and
one in the public IP address domain. Whom to ask?
Suffix Issues Document issues with suffix information provided by
DHCP or by other means. For instance, a host behind a NAT may
have a configured DNS suffix ".local". This suffix is not usuable
for the server discovery procedure.
9. Conclusion
This document describes a general ALTO server discovery process and
discusses how the process can be applied in different deployment
scenarios, including the resouce consumer discovery as well as the
third party discovery.
10. References
10.1. Normative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
7.2. Informative References 10.2. Informative References
[I-D.ietf-alto-protocol] [I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-04 (work in progress), May 2010. draft-ietf-alto-protocol-05 (work in progress), July 2010.
[I-D.ietf-alto-reqs] [I-D.ietf-alto-reqs]
Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO) Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-05 (work in progress), Requirements", draft-ietf-alto-reqs-06 (work in progress),
June 2010. October 2010.
[I-D.kiesel-alto-3pdisc] [I-D.ietf-geopriv-lis-discovery]
Kiesel, S., Tomsu, M., Schwan, N., and M. Scharf, "Third- Thomson, M. and J. Winterbottom, "Discovering the Local
party ALTO server discovery", draft-kiesel-alto-3pdisc-02 Location Information Server (LIS)",
(work in progress), March 2010. draft-ietf-geopriv-lis-discovery-15 (work in progress),
March 2010.
[I-D.song-alto-server-discovery]
Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V.
Avila, "ALTO Service Discovery",
draft-song-alto-server-discovery-03 (work in progress),
July 2010.
[I-D.stiemerling-alto-deployments] [I-D.stiemerling-alto-deployments]
Stiemerling, M. and S. Kiesel, "ALTO Deployment Stiemerling, M. and S. Kiesel, "ALTO Deployment
Considerations", draft-stiemerling-alto-deployments-03 Considerations", draft-stiemerling-alto-deployments-05
(work in progress), June 2010. (work in progress), October 2010.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[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 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693,
October 2009. October 2009.
[bep22] Harrison, D., Shalunov, S., and G. Greg Hazel, "BitTorrent [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Local Tracker Discovery Protocol", Location Information Server (LIS)", RFC 5986,
BEP http://bittorrent.org/beps/bep_0022.html. September 2010.
[bep24] Harrison, D., "Tracker Returns External IP", [bep24] Harrison, D., "Tracker Returns External IP",
BEP http://bittorrent.org/beps/bep_0024.html. BEP http://bittorrent.org/beps/bep_0024.html.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Haibin Song, Richard Alimi, and Roni The authors would like to thank Haibin Song, Richard Alimi, and Roni
Even for fruitful discussions during the 75th IETF meeting. Even for fruitful discussions during the 75th IETF meeting.
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.
Marco Tomsu and Nico Schwan are partially supported by the ENVISION Marco Tomsu and Nico Schwan are partially supported by the ENVISION
project (http://www.envision-project.org), a research project project (http://www.envision-project.org), a research project
supported by the European Commission under its 7th Framework Program supported by the European Commission under its 7th Framework Program
(contract no. 248565). The views and conclusions contained herein (contract no. 248565). The views and conclusions contained herein
are those of the authors and should not be interpreted as necessarily are those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed representing the official policies or endorsements, either expressed
or implied, of the ENVISION project or the European Commission. or implied, of the ENVISION project or the European Commission.
Michael Scharf is supported by the German-Lab project Michael Scharf is supported by the German-Lab project
(http://www.german-lab.de) funded by the German Federal Ministry of (http://www.german-lab.de) funded by the German Federal Ministry of
Education and Research (BMBF). Education and Research (BMBF).
Martin Stiemerling is partially supported by the NAPA-WINE project Martin Stiemerling is partially supported by the COAST project
(Network-Aware P2P-TV Application over Wise Networks, (COntent Aware Searching, retrieval and sTreaming,
http://www.napa-wine.org), a research project supported by the http://www.coast-fp7.eu), a research project supported by the
European Commission under its 7th Framework Program (contract no. European Commission under its 7th Framework Program (contract no.
214412). The views and conclusions contained herein are those of the 248036). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of official policies or endorsements, either expressed or implied, of
the NAPA-WINE project or the European Commission. the COAST project or the European Commission.
Authors' Addresses Authors' Addresses
Sebastian Kiesel Sebastian Kiesel
University of Stuttgart Computing Center University of Stuttgart Computing Center
Allmandring 30 Allmandring 30
Stuttgart 70550 Stuttgart 70550
Germany Germany
Email: ietf-alto@skiesel.de Email: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/ URI: http://www.rus.uni-stuttgart.de/nks/
Marco Tomsu Marco Tomsu
Alcatel-Lucent Bell Labs Alcatel-Lucent
Lorenzstrasse 10 Lorenzstrasse 10
Stuttgart 70435 Stuttgart 70435
Germany Germany
Email: marco.tomsu@alcatel-lucent.com Email: marco.tomsu@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs URI: www.alcatel-lucent.com/bell-labs
Nico Schwan Nico Schwan
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
Lorenzstrasse 10 Lorenzstrasse 10
 End of changes. 87 change blocks. 
290 lines changed or deleted 585 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/