Extensible Authentication Protocol J. Arkko
Internet-Draft Ericsson
Expires: November 26, 2006 B. Aboba
Microsoft
J. Korhonen
TeliaSonera
F. Bari
Cingular Wireless
May 25, 2006
Network Discovery and Selection Problem
draft-ietf-eap-netsel-problem-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The so called realm discovery and selection problem affects network
access, particularly in the presence of multiple available wireless
accesses and roaming. This problem has been the subject of
Arkko, et al. Expires November 26, 2006 [Page 1]
Internet-Draft Network Discovery and PS May 2006
discussions in various standards bodies. This document summarizes
the discussion held about this problem in the Extensible
Authentication Protocol (EAP) working group at the IETF. The problem
is defined and divided into subproblems, and some constraints for
possible solutions are outlined. The document also provides a
discussion of the limitations of certain classes of solution,
including some that have been previously defined.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Discovery of the Point of Attachment to the Network . . . 5
2.2 Identity selection . . . . . . . . . . . . . . . . . . . . 7
2.3 AAA routing . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 The Incomplete Routing Table Problem . . . . . . . . . 9
2.3.2 The User and Identity Selection Problem . . . . . . . 10
2.4 Discovery, Decision, and Selection . . . . . . . . . . . . 12
2.5 Type of Information . . . . . . . . . . . . . . . . . . . 13
3. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Other . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 AAA issues . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Backward Compatibility . . . . . . . . . . . . . . . . . . 20
4.3 Efficiency Constraints . . . . . . . . . . . . . . . . . . 20
4.4 Network discovery and selection decision making . . . . . 20
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1 Normative References . . . . . . . . . . . . . . . . . . . 26
7.2 Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 32
Arkko, et al. Expires November 26, 2006 [Page 2]
Internet-Draft Network Discovery and PS May 2006
1. Introduction
The realm discovery and selection problem affects network access and
wireless access networks in particular. This problem spans multiple
protocol layers and has been the subject of discussions in IETF,
3GPP, and IEEE. This document summarizes the discussion held about
this problem in the Extensible Authentication Protocol working group
at IETF.
The realm discovery and selection problem becomes relevant when any
of the following conditions are true:
o There is more than one available network attachment point, and the
different attachment points may have different characteristics or
belong to different operators. In the case of virtual operators,
access network infrastructure including e.g. the access points can
be shared by multiple operators.
o The user has multiple sets of credentials. For instance, the user
could have one set of credentials from a public service provider
and set from the user's employer.
o There is more than one way to provide roaming between the visited
realm used for access and user's home realm, and service
parameters or pricing differs between them. For instance, the
visited access realm could have both a direct relationship with
the home realm and an indirect relationship through a roaming
consortium. In some scenarios, current AAA protocols may not be
able to route the requests to the home realm unaided, just based
on the domain in the given Network Access Identifier (NAI) [12].
In addition, payload packets can get routed or tunneled
differently, based on which particular roaming relationship
variation is used. This may have an impact on the available
services or their pricing.
In Section 2 the realm discovery and selection problem is defined and
divided into subproblems, and some constraints for possible solutions
are outlined in Section 4. Section 3 discusses existing mechanisms
which help solve at least parts of the problem. Section 5 gives some
suggestions on how to proceed for the rest.
1.1 Terminology
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 [2].
Arkko, et al. Expires November 26, 2006 [Page 3]
Internet-Draft Network Discovery and PS May 2006
Realm Selection
This refers to selection of the operator/ISP in order to access
the network. The process of realm selection can occur either at
the beginning of a new session or during a handoff in case the
user is mobile. The selection is dependent upon for example the
authentication credentials for the user / device and the roaming
agreements. The realm Selection can in turn also depend upon
Access Technology Selection and/or Bearer Selection.
Realm Discovery
This refers to a mechanisms that a node uses to discover available
realms prior the realm selection takes place. The discovery
process may be passive or active from a node point of view.
Typically the realm discovery mechanism varies depending on the
access technology. It is also possible that there are multiple
discovery mechanisms within one access technology depending on the
network deployment.
Access Technology Selection
This refers to the selection between access technologies e.g.
802.11, UMTS, WiMAX. The selection will be dependent upon for
example the support for an access technology by the device and
availability of such access technology based networks.
Bearer Selection
For some access technologies (e.g. UMTS), there can be a
possibility for delivery of a service (e.g. voice) by using either
a circuit switched or a packet switched bearer. The Bearer
selection refers to selecting one of the bearer type for service
delivery. The decision can be based on support of the bearer type
by the device and the network as well as user subscription and
operator preferences.
Arkko, et al. Expires November 26, 2006 [Page 4]
Internet-Draft Network Discovery and PS May 2006
2. Problem Definition
There are a set of somewhat orthogonal problems being discussed under
the rubric of "realm discovery and selection".
o The problem of "discovery of points of attachment". This is the
problem of discovering points of attachment available in the
vicinity, and the capabilities associated with these points of
attachment.
o The problem of "Identifier selection". This is the problem of
selecting which identity (and credentials) to use to authenticate
in a given point of attachment to the network.
o The problem of "AAA routing" which involves figuring out how to
route the authentication conversation originating from the
selected identity back to the home realm.
o The problem of "Payload routing" which involves figuring how the
payload packets are routed, where more advanced mechanisms than
destination-based routing is needed. However, while being an
interesting problem, this document does not attempt to do any
analysis or suggestions on it.
o The problem of "realm capability discovery". This is the problem
of discovering the capabilities of a particular destination realm.
For example, it may be important to know whether a given realm
supports enrollment, what the charges are, etc.
Alternatively, the problem can be divided to the discovery, decision,
and the selection components. The AAA routing problem, for instance,
involves all components: discovery (which mediating networks are
available?), decision (choose the "best" one), and selection (client
tells the network which mediating network it has decided to choose)
components.
2.1 Discovery of the Point of Attachment to the Network
"The discovery of points of attachment" problem has been extensively
studied, see for instance the IEEE specifications on 802.11 wireless
LAN beaconing and probing process, studies (such as [37]) on the
effectiveness of these mechanisms, specifications on GSM network
discovery, results of the IETF Seamoby WG, and so on.
Traditionally, the problem of discovering available point of
attachment has been handled as a part of the link layer attachment
procedures, or through out-of-band mechanisms.
Arkko, et al. Expires November 26, 2006 [Page 5]
Internet-Draft Network Discovery and PS May 2006
RFC 2194 [3] describes the pre-provisioning of dialup roaming
clients, which typically included a list of potential phone numbers,
updated by the provider(s) with which the client had a contractual
relationship. RFC 3017 [8] describes the IETF Proposed Standard for
the Roaming Access XML DTD. This covers not only the attributes of
the Points of Presence (POPs) and Internet Service Providers (ISPs),
but also hints on the appropriate NAI to be used with a particular
POP. The RFC supports dial-in and X.25 access, but has extensible
address and media type fields.
In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism
provides a way for Stations to discover Access Points (APs), as well
as the capabilities of those APs. Among the Information Elements
(IEs) included within the Beacon and Probe Response is the SSID, a
non-unique identifier of the network to which an Access Point is
attached. By combining network identification along with
capabilities discovery, the Beacon/Probe facility provides the
information required for both network discovery and roaming decisions
within a single mechanism.
As noted in [36], the IEEE 802.11 Beacon mechanism does not scale
well; with a Beacon interval of 100ms, and 10 APs in the vicinity,
approximately 32 percent of an 802.11b AP's capacity is used for
beacon transmission. In addition, since Beacon/Probe Response frames
are sent by each AP over the wireless medium, stations can only
discover APs within range, which implies substantial coverage overlap
for roaming to occur without interruption.
A number of enhancements have been proposed to the Beacon/Probe
Response mechanism in order to improve scalability and roaming
performance. These include allowing APs to announce capabilities of
neighbor APs as well as their own, as proposed in IEEE 802.11k.
Typically scalability enhancement mechanisms attempt to get around
Beacon/Probe Response restrictions by sending advertisements at the
higher layers which are enabled once the station has associated with
an AP and gained IP connectivity. Since these mechanisms run over
IP, they can utilize IP facilities such as fragmentation, which the
link layer mechanisms may not always be able to do. For instance, in
IEEE 802.11, Beacon frames cannot use fragmentation because they are
multicast frames, and multicast frames are not acknowledged in
802.11.
Another issue with the Beacon/Probe Request/Response mechanism is
that it is either insecure or its security can be assured only after
already attaching to this particular network.
When considering access systems such as 802.11 WLANs networks it is
Arkko, et al. Expires November 26, 2006 [Page 6]
Internet-Draft Network Discovery and PS May 2006
important to take into account different deployment options. For
example, a WLAN deployment may include a number of VLANs in order to
separate UAM and 802.1X users or users accessing network from
different geographical/organizational locations. It is also possible
that a larger network spans multiple ESSes and prefixes. Typically
different enrollment methods and organizational locations within
ESSes advertise or respond to different SSIDs. However, it is also
possible that users authenticating to different realms are able to
do so via the same SSID.
2.2 Identity selection
As networks proliferate, it becomes more and more likely that a given
user may have multiple identities and credential sets, available for
use in different situations. For example, the user may have an
account with one or more Public WLAN providers; a corporate WLAN;
one or more wireless WAN providers. As a result, the user has to
decide which credential set to use when presented with a choice.
Figure 1 illustrates a situation where the user does not know whether
the access network he or she is attached to supports the realms he or
she is attemping to authenticate with. The access network 1
interworks only with the ISP and the access network 3 interworks with
the corporate network whereas the access network 2 interworks with
both.
? ? +---------+ +------------------+
? | Access | | |
O_/ _-->| Network |------>| isp.example1.com |
/| / | 1 | _->| |
| | +---------+ / +------------------+
_/ \_ | /
| +---------+ /
User "subscriber@isp. | | Access |/
example1.com" -- ? -->| Network |
also known | | 2 |\
"employee123@corp. | +---------+ \
example2.com" | \
| +---------+ \_ +-------------------+
\_ | Access | ->| |
-->| Network |------>| corp.example2.com |
| 3 | | |
+---------+ +-------------------+
Figure 1: Two credentials, three possible access networks
Arkko, et al. Expires November 26, 2006 [Page 7]
Internet-Draft Network Discovery and PS May 2006
Traditionally, hints useful in identity selection have also been
provided out-of-band. For example, via the RFC 3017 XML DTD [8], a
client can select between potential POPs, and then based on
information provided in the DTD, determine the appropriate NAI to use
with the selected point of attachment to the network.
Perhaps the most typical case is a link layer that provides some
information about the realms that are reachable before EAP or some
other enrollment method is initiated. For instance, in IEEE 802.11
provides the SSID, though in some cases the client may not learn
about all the SSIDs supported by the given access point without
actively probing for additional SSIDs. In IKEv2 [14], the identity
of the responder (typically the security gateway) is provided as a
part of the usual IKEv2 exchange.
In order to use this information in deciding the right identity to
use, the provided information has to either match with one of the
client's home realms, or the client has to have some other knowledge
that enables to link the advertised access network name and the home
realm. For instance, the client may be aware that his home realm has
a roaming contract with a given access network.
It is also possible for hints to be embedded within credentials. In
[11], usage hints are provided within certificates used for wireless
authentication. This involves extending the client's certificate to
include the SSIDs with which the certificate can be used.
Finally, some EAP implementations use the space after the NUL
character in an EAP Identity Request to communicate some parameters
for example listing realms supported for authentication. The
Informational RFC [13] specifies the interpretation of the field
beyond the NUL character when realms are to be communicated.
2.3 AAA routing
Once the identity has been selected, it is necessary for the
authentication conversation to be routed back to the home realm.
This is typically done today through the use of the Network Access
Identifier (NAI), RFC 4282 [12], and the ability of the AAA network
to route requests to the realm indicated in the NAI.
Within the past IETF ROAMOPS WG, a number of additional approaches
were considered for routing authentication conversation back to the
home realm, including source routing techniques based on the NAI, and
techniques relying on the AAA infrastructure. Given the relative
simplicity of the roaming implementations described in RFC 2194 [3],
static routing mechanisms appeared adequate for the task and it was
not deemed necessary to develop dynamic routing protocols.
Arkko, et al. Expires November 26, 2006 [Page 8]
Internet-Draft Network Discovery and PS May 2006
As noted in RFC 2607 [5], RADIUS proxies are deployed not only for
routing purposes, but also to mask a number of inadequacies in the
RADIUS protocol design, such as the lack of standardized
retransmission behavior and the need for shared secret provisioning.
By removing many of the protocol inadequacies, introducing new AAA
agent types such as Redirects, providing support for certificate-
based authentication as well as inter and intra-domain service
discovery, allowing DNS based dynamic discovery of peer agents,
Diameter allows a NAS to directly open a Diameter connection to the
home realm without having to utilize a network of proxies. For
instance, the Redirect feature could be used to provide a centralized
routing function for AAA, without having to know all home network
names in all access networks. However, there are issues in the
previously mentioned approach as setting up security might turn out
to be problematic and the model might not meet business practices.
This is somewhat analogous to the evolution of email delivery. Prior
to the widespread proliferation of the Internet, it was necessary to
gateway between SMTP-based mail systems and alternative delivery
technologies, such as UUCP and FidoNet, and email-address based
source-routing was used to handle this. However, as mail could
increasingly be delivered directly, the use of source routing
disappeared.
As with the selection of certificates by stations, a Diameter client
wishing to authenticate with a Diameter server may have a choice of
available certificates, and therefore it may need to choose between
them.
2.3.1 The Incomplete Routing Table Problem
No dynamic routing protocols are in use in AAA infrastructure today.
This implies that there has to be a device (such as a proxy) within
the access network that knows how to route to different domains, even
if they are further than one hop away, as shown in Figure 2. In this
figure, the user "joe@c.example.com" has to be authenticated through
ISP 2, since the domain "c.example.com" is served by it.
Arkko, et al. Expires November 26, 2006 [Page 9]
Internet-Draft Network Discovery and PS May 2006
+---------+ +---------+
| | | |
User "joe@ | Access |----->| ISP 1 |-----> "a.example.com"
c.example.com"-->| Network | | |
| | +---------+
+---------+
|
|
V
+---------+
| |-----> "b.example.com"
| ISP 2 |
| |-----> "c.example.com"
+---------+
Figure 2: AAA routing problem
2.3.2 The User and Identity Selection Problem
A related issue is that the roaming relationship graph may have
ambiguous routes, as shown in Figure 3. As billing is based on AAA
and pricing may be based on the used intermediaries, it is necessary
to select which route is used. For instance, in Figure 3, access
through the roaming group 1 may be cheaper, than if roaming group 2
is used.
+---------+
| |----> "a.example.com"
| Roaming |
+---------+ | Group 1 |
| |----->| |----> "b.example.com"
User "joe@ | Access | +---------+
a.example.com"--->| Network |
| | +---------+
| |----->| |----> "a.example.com"
+---------+ | Roaming |
| Group 2 |
| |----> "c.example.com"
+---------+
Figure 3: Ambiguous AAA routing
There have been requests to place credential and AAA route selection
under user control, as the user is affected by the pricing and other
differences. Optionally, automatic tools could make the selection
Arkko, et al. Expires November 26, 2006 [Page 10]
Internet-Draft Network Discovery and PS May 2006
based on the user's preferences. On the other hand, user control is
similar to source routing, and as discussed earlier, network-based
routing mechanisms have traditionally won over source routing-based
mechanisms.
If users can control the selection of intermediaries, such
intermediaries still have to be legitimate AAA proxies. That is, an
access network should not send a request to an unknown intermediary.
If it has a business relationship with three intermediaries
int1.example.com, int2.example.com, and int3.example.com, it will
route the request through one of them, even if the user tried to
request routing through mitm.example.org. Thus, NAI-based source
routing is not source routing in the classic sense. It is merely
suggesting preferences among already established routes. If the
route does not already exist, or is not feasible, then NAI-based
source routing cannot establish it.
An additional issue is that even if the intermediaries are
legitimate, they could be switched. For instance, an access network
could advertise that it has a deal with
cheapintermediary.example.net, and then switch the user's selection
to priceyintermediary.example.com instead. To make this relevant,
the pricing would have to be based on the intermediary. Even if it
were possible to secure this selection, it would not be possible to
guarantee that QoS or other properties claimed by the network were
indeed provided. However, the ability to get authenticated via
intermediates implies that all the parties have a business agreement
with each other, which may also include an agreement about the
minimum service level guarantees.
Only a limited amount of information about AAA routes or pricing
information can be dynamically communicated [41]. It is necessary to
retrieve network and intermediary names, but quality of service or
pricing information is clearly something that would need to be pre-
provisioned, or perhaps just available via the web. Similarly,
dynamic communication of network names can not be expected to provide
all possible home network names, as their number can be quite large
globally.
As a result, network-based AAA routing mechanisms are preferred over
user-based selection where sufficient routes have been configured and
there is no need for user control. Where these conditions are not
met -- particularly when an attempt to use the network-based routing
mechanism has failed -- routing hints can be placed in an NAI as
defined in [12]. Where NAIs are used in this manner, the AAA routing
problem becomes a subset of the identifier selection problem.
Arkko, et al. Expires November 26, 2006 [Page 11]
Internet-Draft Network Discovery and PS May 2006
2.4 Discovery, Decision, and Selection
An alternative decomposition of the problem is to consider the
discovery, decision, and selection aspects separately. Discovery
consists of discovering access networks and associated points of
attachment to the network, discovering what identities the access
networks will accept (either directly or through roaming
relationships), and discovering which potential AAA intermediaries or
routes exist.
Selection consists of attaching to the "right" access network and
point of attachment, offering an identity through EAP Identity
Response, and providing a hint about the desired AAA intermediary.
The selection of the AAA intermediary, along with the home and access
realms, determines also the treatment of payload packets.
Decision can be either manual selection or automatic. Most likely,
automatic mechanisms are preferred, even if manual selection should
be retained as a fallback. The type of the decision also places
additional requirements on the type of information that the discovery
phase must provide. Just knowing which choices are available is
probably enough for manual selection. Unfortunately, automatic
selection based on a list of choices is by itself not possible:
o Some access networks may be preferred over others. For instance,
the user's private corporate access network may be preferred over
a public access network due to cost and efficiency reasons.
o Similarly, some credentials may be preferred over others.
o Use of an access network with direct connection to home realm may
be preferred over using mediating networks.
o Some mediating networks may be preferred to others, for example
based on cost. Note that optimizing cost is not a trivial
problem, because the total cost may be a combination of a fixed
fee, per-minute, per-megabyte, volume discounts, and so on.
o Preferences may come from the user, his or her employer (who's
paying the bill), home realm, or access network.
Different discovery mechanisms can accommodate such preferences in
various ways. Some user input or perhaps a pre-provisioned database
seems inevitable.
Finally, while the final step of choosing a new access network lies
always on the client side, different approaches vary in how much they
rely on the client vs. network driven decisions. In cellular
Arkko, et al. Expires November 26, 2006 [Page 12]
Internet-Draft Network Discovery and PS May 2006
networks, for instance, the network-based performance measurements
lead to instructions that the network gives to the client about the
appropriate base station(s) that should be used. Most of the
processing and decisions are performed on the network side. In
contrast, in a completely client-driven approach the client may get
some raw information from the access network, but makes all decisions
by itself.
2.5 Type of Information
A third alternative way to decompose the problem is to analyze the
type of information which is required [16]. For instance, access
network discovery may benefit from getting knowledge about the
quality of service available from a particular access network or
node, and AAA routing may require knowledge of roaming agreements.
References [16] and [27] describe the following categories of
information which can be discovered:
o Access network identification
o Roaming agreements
o Authentication mechanisms
o Quality of Service
o Cost
o Authorization policy
o Privacy policy
o Service parameters, such as the existence of middleboxes
The nature of the discovered information can be static, such as the
fastest available transmission speed on a given piece of equipment.
Or it can be dynamic, such as the current load on this equipment.
The information can describe something about the network access nodes
themselves, or it can be something that they simply advertise on
behalf of other parts of the network, such as roaming agreements
further in the AAA network.
Typically, it would be desirable to acquire all this information
prior to the authentication process. In some cases it is in fact
necessary, if the authentication process can not complete without the
information. Reference [27] classifies the possible steps at which
IEEE 802.11 networks can acquire this information:
Arkko, et al. Expires November 26, 2006 [Page 13]
Internet-Draft Network Discovery and PS May 2006
o Pre-association
o Post-association (or pre-authentication)
o Post-authentication
Note that some EAP methods (such as those defined in [18] [20] [15])
have an ability to agree about additional parameters during an
authentication process. While such parameters are useful for many
purposes, their use for access network selection suffers from an
obvious chicken-and-egg problem. Or at least it seems costly to run
a relatively heavy authentication process to decide whether the
client wants to attach to this access network.
Arkko, et al. Expires November 26, 2006 [Page 14]
Internet-Draft Network Discovery and PS May 2006
3. Existing Work
3.1 IETF
There has already been a lot of past work in this area, including a
number of IETF Proposed Standards generated by the ROAMOPS WG. The
topic of roaming was considered different enough from both AAA and
access protocols such as PPP that it deserved its own WG.
In addition to work on ROAMOPS directly relating to the problem,
there has been work in SEAMOBY relating to scaling of target access
network discovery mechanisms; work in PKIX relating to identity and
credential selection; and work in AAA WG relating to access routing.
The PANA protocol [17] has a mechanism to advertise and select "ISPs"
through the exchange of the ISP-Information AVP in its initial
exchange.
Adrangi et al [13] define the use of the EAP-Request/Identity for
identifier selection. It is necessary to have this kind of a
mechanism, as clients may have more than one credential, and when
combined with the '!' syntax for NAIs, it can also be used for
mediating network discovery and selection. The use of lower-layer
information may also be limited in terms of discovering identifiers
that are used on the EAP layer. In the longer term, the use of this
mechanism may run into scalability problems, however. As noted in
[10] Section 4.x, the minimum EAP MTU is 1020 octets, so that an EAP-
Request/Identity is only guaranteed to be able to include 1015 octets
within the Type-Data field. Since RFC 1035 [1] enables FQDNs to be
up to 255 octets in length, this may not enable the announcement of
many realms, although if SSIDs are used, the maximum length of 32
octets per SSID may provide somewhat better scaling. The use of
other network identifiers than domain names is also possible, for
instance the PANA protocol uses an a free form string and an SMI
Network Management Private Enterprise Code [17], or Mobile Network
Codes embedded in NAIs as specified in 3GPP.
As noted in [38], the use of the EAP-Request/Identity for network
discovery has substantial negative impact on handoff latency, since
this may result in a station needing to initiate an EAP conversation
with each Access Point in order to receive an EAP-Request/Identity
describing which networks are supported. Since IEEE 802.11-1999 does
not support use of Class 1 data frames in State 1 (unauthenticated,
unassociated) within an Extended Service Set (ESS), this implies
either that the APs must support 802.1X pre-authentication (optional
in IEEE 802.11i) or that the station must associate with each AP
prior to sending an EAPOL- Start to initiate EAP. This will
dramatically increase handoff latency.
Arkko, et al. Expires November 26, 2006 [Page 15]
Internet-Draft Network Discovery and PS May 2006
The effects to handoff latency depend also on the specific protocol
design, and the expected likelihood of having to provide
advertisements and initiate scanning of several APs. The use of
advertisements only as a last resort when the AAA routing has failed
is a better approach than the use of advertisement - scanning
procedure on every attachment.
Furthermore, if the AP has not been updated to present an up to date
set of realms in the EAP-Requests/Identity, after associating to
candidate APs and then choosing one, it is possible that the station
will find that the chosen realm is not supported after all. In this
case, the station's EAP-Response/Identity may be answered with an
updated EAP-Request/Identity, adding more latency. However, it is
possible to configure APs to pass through all EAP negotiation to a
local AAA proxy and provision the supported realms there. This would
ease the management of larger deployments but at the same time
require RFC 4284 support from the local AAA proxies. In general
upgrading the AAA proxies seems a better approach than upgrading and
managing all APs.
3.2 IEEE
There has been work in various IEEE 802 working groups relating to
network discovery enhancements.
Some recent and past contributions in this space include the
following:
o [22] defines the Beacon and Probe Response mechanisms used with
IEEE 802.11. Unfortunately, Beacons are only sent at the lowest
supported rate. Studies such as [40] have identified MAC layer
performance problems, and [36] have identified scaling issues
resulting from a lowering of the Beacon interval.
o [25] discusses the evolution of authentication models in WLANs,
and the need for the network to migrate from existing models to
new ones, based on either EAP layer indications or through the use
of SSIDs to represent more than the local network. It notes the
potential need for management or structuring of the SSID space.
The paper also notes that virtual APs have scalability issues. It
does not analyze these scalability issues in relation to those
existing in other alternative solutions, however.
o [23] discusses mechanisms currently used to provide "Virtual AP"
capabilities within a single physical access point. A "Virtual
AP" appears at the MAC and IP layers to be distinct physical AP.
As noted in the paper, full compatibility with existing 802.11
Arkko, et al. Expires November 26, 2006 [Page 16]
Internet-Draft Network Discovery and PS May 2006
station implementations can only be maintained if each virtual AP
uses a distinct MAC address (BSSID) for use in Beacons and Probe
Responses. This draft does not discuss scaling issues in detail,
but recommends that only a limited number of virtual APs be
supported by a single physical access point. The simulations
presented in [36] appear to confirm this conclusion; with a Beacon
interval of 100 ms, once more than 8 virtual APs are supported on
a single channel, more than 20% of bandwidth is used for Beacons
alone. This would indicate a limit of approximately 20 virtual
APs per physical AP.
o IEEE 802.11u group is defining the access network discovery and
selection solution as part of its requirements [29]. The
requirements related to access network discovery and selection
include the functionality by which a station can determine whether
its subscription to a service provider would allow it to access a
particular 802.11 access network or whether the access network is
able to route authentication to user's home realm before actually
joining a BSS within that 802.11 access network. The mechanism
should be able to handle multiple credentials from the same user
and be able to select the correct credentials. Other planned
features would allow the station to learn the supported enrollment
mechanisms and possibly the set of basic services (such as
Internet access is provided or not) in the access network prior to
the user authenticating to his or her home realm.
o IEEE 802.21 is developing standards to enable handover and
interoperability between heterogeneous network types including
both 802 and non 802 networks. The intention is to provide a
general information transfer capability for these purposes. As a
result, network discovery process may benefit from such standards.
Part of handover process is the discovery of candidate access
networks and selection of an access network for a handover. The
IEEE 802.21 group is looking into various information elements
that can be used to provide sufficient information to either a
network node or the terminal to make network selection possible.
Both link layer and layer 3 delivery mechanisms are being looked
into. Layer 3 protocol development is being looked into in IETF
MIPSHOP WG. Different query mechanisms between the terminal and
the network, including using of XML or basic TLV type interaction
are being explored.
3.3 3GPP
The 3GPP stage 2 technical specification [30] covers the architecture
of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G networks. This
specification discusses also network discovery and selection issues.
Arkko, et al. Expires November 26, 2006 [Page 17]
Internet-Draft Network Discovery and PS May 2006
The I-WLAN network discovery and selection procedure borrows ideas
from the cellular side Public Land-based Mobile Network (PLMN)
selection principles.
In the 3GPP defined cellular network selection [32] the mobile node
monitors surrounding cells and prioritizes them e.g. based on signal
strength before selecting a new possible target cell. Each cell also
broadcasts its PLMN information. A mobile node may automatically
select cells that belong to its Home PLMN, Registered PLMN or to a
allowed set of Visited PLMNs. These lists of PLMNs are prioritized
and stored in the SIM card. In a case of manual network selection
the mobile node lists all PLMNs it knows from the surrounding cells
and lets the user to choose the desired PLMN. After the PLMN has
been selected other cell related prioritization takes place in order
to select the appropriate target cell.
Ahmavaara, Haverinen, and Pichna [34] discuss the new network
selection requirements that I-WLAN roaming introduces. It is
necessary to support automatic network selection, and not just manual
selection by the user. There may be multiple levels of networks, the
hotspot owner may have a contract with a provider who in turn has a
contract with one 3G network, and this 3G network has a roaming
capability with a number of other networks.
The I-WLAN specification requires that access network discovery is
performed as specified in the standards for the relevant WLAN link
layer technology. In addition to access network discovery, it is
necessary to select intermediary networks for the purposes of AAA
Routing. In 3GPP, these networks are PLMNs. It is assumed that WLAN
networks may have a contract with more than one PLMN. The PLMN may
be a Home PLMN (HPLMN) or a Visited PLMN (VPLMN) is a roaming case.
GSM/UMTS roaming principles are employed for routing AAA requests
from the VPLMN to the Home Public Land-based Mobile Network (HPLMN)
using either RADIUS or Diameter. The procedure for selecting the
intermediary network has been specified in the stage 3 technical
specifications [43] and [44].
In order to select the PLMN, the following is required:
o User may choose the desired HPLMN or VPLMN manually or let the
WLAN User Equipment (WLAN UE) choose the PLMN automatically based
on the user and operator defined preferences.
o AAA messages are routed according to the (root) NAI or decorated
NAI.
o Existing EAP mechanisms are used where possible.
Arkko, et al. Expires November 26, 2006 [Page 18]
Internet-Draft Network Discovery and PS May 2006
o Extensibility is desired, to allow the advertisement of other
parameters later. The current network advertisement and selection
is based on [12].
The 3GPP I-WLAN technical specifications state that advertisement
information shall be provided only when the access network is unable
to route the request using normal AAA routing means, such as when it
sees an unknown NAI realm. It is also stated that where VPLMN
control is required, the necessary information is added to a NAI.
Furthermore, the WLAN UE may manually trigger the network
advertisement by using Alternative NAI in EAP Request/ Identity. The
Alternative NAI is guaranteed to be an unknown NAI realm throughout
all 3GPP networks.
The security requirements for 3GPP I-WLAN have been specified in the
3GPP stage 3 technical specification [42]. The security properties
related to different mediating network selection mechanisms have been
discussed earlier in the 3GPP contribution [31], which concludes that
both SSID- and EAP-based mechanisms have roughly similar (and very
limited) security properties, and that, as a result, network
advertisement should be considered only as hints.
3.4 Other
[35] discusses the need for network selection in a situation where
there is more than one available access network with a roaming
agreement to the home network. It also lists EAP-level, SSID-based,
and PEAP-based mechanisms as potential solutions to the network
selection problem.
Eijk et al [33] discussed the general issue of network selection.
They concentrated primarily on the access network discovery problem,
based on various criteria, and did not consider the other aspects of
the network selection problem. Nevertheless, they mention that one
of the network selection problems is that the information about
accessibility and roaming relationships is not stored in one
location, but rather spread around the network.
Arkko, et al. Expires November 26, 2006 [Page 19]
Internet-Draft Network Discovery and PS May 2006
4. Design Issues
The following factors should be taken into consideration while
evaluating solutions for problem of network selection and discovery:
4.1 AAA issues
Access network or realm selection may leverage or interact with the
AAA infrastructure. The solution should therefore be compatible with
all AAA protocols. AAA routing mechanisms should work for requests,
responses, as well as server-initiated messages. The solution should
not prevent the introduction of new AAA or access network features,
such as link-state AAA routing protocols or fast handoffs.
4.2 Backward Compatibility
The solution should allow interoperability with clients, protocols,
access networks, AAA proxies, and AAA servers that have not been
modified to support network discovery and selection. For example, it
should not cause a problem with limited packet sizes of current
protocols. Where new protocol mechanisms are required, it should be
possible to deploy the solution without requiring changes to the
largest base of installed devices -- network access servers, wireless
access points, and clients.
4.3 Efficiency Constraints
The solution should be efficient in network resource utilization,
specially on bandwidth constrained sections of the network (E.g.
wireless link). Mechanisms that could significantly increase
communication of an unauthenticated device with more than one points
of attachment during the selection process should be avoided. For
many handheld devices, battery life is a significant constraint.
Mechanisms that could significantly drain battery e.g. by requiring
one or more radios in multimode devices to continuously scan for
networks, should be avoided. In addition, the solution should not
significantly impact network attachment time.
4.4 Network discovery and selection decision making
"Phone-book" based approaches such as RFC 3017 appear attractive due
to their ability to provide sufficient information for automatic
selection decisions. However, there is no experience on applying
such approaches to wireless access. The number of WLAN access points
is significantly higher than the number of dial-in POPs; the
distributed nature of the access network has created a more
complicated business and roaming structure, and the expected rate of
change in the information is high. As noted in [39] and [16], a
Arkko, et al. Expires November 26, 2006 [Page 20]
Internet-Draft Network Discovery and PS May 2006
large fraction of current WLAN access points operate on the default
SSID, which may make the use of the phone book approach hard.
Arkko, et al. Expires November 26, 2006 [Page 21]
Internet-Draft Network Discovery and PS May 2006
5. Conclusions
The issues surrounding the network discovery and selection problem
have been summarized.
In the opinion of the authors of this document, the main findings
are:
o There is a clear need for access network discovery, identifier
selection, AAA routing, and payload routing.
o Identifier selection and AAA routing problems can and should be
seen as the different aspects of the same problem, identifier
selection.
o Nevertheless, many of the problems discussed in this draft are
very hard when one considers them in an environment that requires
a potentially large number of networks, fast handoffs, and
automatic decisions.
o The proliferation of multiple competing network discovery
technologies within IEEE 802, IETF, and 3GPP appears to a
significant problem going forward. In the absence of a clearly
defined solution to the problem it is likely that any or all of
these solutions will be utilized, resulting in industry
fragmentation and lack of interoperability.
o New link layers should be designed with facilities that enable the
efficient distribution of network advertisement information.
o Solving all problems with current link layers and existing network
access devices may not be possible. It may be useful to consider
a phased approach where only certain, limited functions are
provided now, and the full functionality is provided when
extensions to current link layers become available.
We will briefly comment on the specific mechanisms related to access
network discovery and selection:
o As noted in studies such as [40] and [36], the IEEE 802.11 Beacon/
Probe Response mechanism has substantial scaling issues, and as a
result a single physical access point is in practice limited to
less than a dozen virtual APs on each channel with IEEE 802.11b.
The situation is improved substantially with successors such as
IEEE 802.11a which enable additional channels, thus potentially
increasing the number of potential virtual APs.
Arkko, et al. Expires November 26, 2006 [Page 22]
Internet-Draft Network Discovery and PS May 2006
However, even these enhancements it is not feasible to advertise
more than 50 different networks using existing mechanisms, and
probably significantly less in most circumstances.
As a result, there appears to be justification for enhancing the
scalability of network advertisements.
o Work is already underway in IEEE 802.1, IEEE 802.21 and the IEEE
802.11u to provide enhanced discovery functionality. For example,
IEEE 802.1ab enables network devices to announce themselves and
provide information on their capabilities. Similarly, the IEEE
802.1af has discussed the idea of supporting network discovery
within a future revision to IEEE 802.1X. However, neither IEEE
801.ab nor IEEE 802.1af is likely to address the transport of
large quantities of data where fragmentation would be a problem.
Another typical limitation of link layer assistance in this area
is that in general, it would be desirable to retrieve also
information relating to the potential next access networks or
access points. However, such networks may be of another type than
the current one, so the link layer would have to carry information
relating to other types of link layers as well. This is possible,
but requires coordination among different groups in the industry.
o Given that EAP does not support fragmentation of EAP-Request/
Identity packets, and that use of EAP for network selection on all
attachments will have a substantial adverse impact on roaming
performance without appropriate lower layer support (such as
support for Class 1 data frames within IEEE 802.11), the use of
EAP is limited. For instance, the use of EAP to carry quality of
service as proposed in [16] seems hard given the limitations.
Long-term, it makes more sense for the desired functionality to be
handled either within IEEE 802 or at the IP layer. However, a
strictly limited discovery mechanism such as the one defined in
[13] is useful.
o In the IETF, a potential alternative is use of the SEAMOBY CARD
protocol [45], which enables advertisement of network device
capabilities over IP. Another alternative is the already expired
Device Discovery Protocol (DDP) [19] proposal, which provides
functionality equivalent to IEEE 802.1ab using ASN.1 encoded
advertisements sent to a link-local scope multicast address.
A limitation of these IP layer solutions is that they can only
work as a means to speed up the attachment procedures when moving
from one location to another; when a node starts up, it needs to
be able to attach to a network before IP communications are
available. This is fine for optimizations, but precludes the use
Arkko, et al. Expires November 26, 2006 [Page 23]
Internet-Draft Network Discovery and PS May 2006
in a case where the discovery information is mandatory before
successful attachment can be accomplished, for instance when the
access network is unable to route the AAA request unaided.
Arkko, et al. Expires November 26, 2006 [Page 24]
Internet-Draft Network Discovery and PS May 2006
6. Security Considerations
All aspects of the network discovery and selection problem are
security related. The security issues and requirements have been
discussed in the previous sections.
The security requirements for network discovery depend on the type of
information being discovered. Some of the parameters may have a
security impact, such as the claimed name of the network the user
tries to attach to. Unfortunately, current EAP methods do not always
make the verification of such parameters possible. New EAP methods
are doing it [18] [20], however, and there is even an attempt to
provide a backwards compatible extensions to older methods [15].
The security requirements for network selection depend on whether the
selection is considered as a command or a hint. For instance, the
selection that the user provided may be ignored if it relates to AAA
routing and the access network can route the AAA traffic to the
correct home network using other means in any case.
Arkko, et al. Expires November 26, 2006 [Page 25]
Internet-Draft Network Discovery and PS May 2006
7. References
7.1 Normative References
[1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.
[4] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[5] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[6] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.,
and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
RFC 2868, June 2000.
[8] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone
Book", RFC 3017, December 2000.
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[11] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point Protocol
(PPP) and Wireless Local Area Networks (WLAN)", RFC 3770,
May 2004.
[12] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
[13] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
Selection Hints for the Extensible Authentication Protocol
(EAP)", RFC 4284, January 2006.
Arkko, et al. Expires November 26, 2006 [Page 26]
Internet-Draft Network Discovery and PS May 2006
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
7.2 Informative References
[15] Arkko, J. and P. Eronen, "Authenticated Service Identities for
the Extensible Authentication Protocol (EAP)",
draft-arkko-eap-service-identity-auth-04 (work in progress),
October 2005.
[16] Tschofenig, H., "Network Selection Implementation Results",
draft-groeting-eap-netselection-results-00 (work in progress),
July 2004.
[17] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Access
(PANA)", draft-ietf-pana-pana-11 (work in progress),
March 2006.
[18] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected
EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07
(work in progress), October 2003.
[19] Enns, R., Marques, P., and D. Morrell, "Device Discovery
Protocol (DDP)", draft-marques-ddp-00 (work in progress),
May 2003.
[20] Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method (EAP-
IKEv2)", draft-tschofenig-eap-ikev2-10 (work in progress),
February 2006.
[21] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
[22] Institute of Electrical and Electronics Engineers, "Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications", IEEE Standard 802.11, 2003.
[23] Aboba, B., "Virtual Access Points", IEEE Contribution 11-03-
154r1, May 2003.
[24] Mishra, A., "Improving the latnecy of the Probe Phase during
802.11 Handoff", IEEE Contribution 11-03-417r2, May 2003.
[25] Hepworth, E., "Co-existence of Different Authentication
Models", IEEE Contribution 11-03-0827 2003.
Arkko, et al. Expires November 26, 2006 [Page 27]
Internet-Draft Network Discovery and PS May 2006
[26] Hong, C. and T. Yew, "Interworking - WLAN Control", IEEE
Contribution 11-03-0843 2003.
[27] Berg, S., "Information to Support Network Selection", IEEE
Contribution 11-04-0624 2004.
[28] Aboba, B., "Network Selection", IEEE Contribution 11-04-
0638 2004.
[29] Moreton, M., "TGu Requirements", IEEE Contribution 11-05-0822-
03-000u-tgu-requirements, August 2005.
[30] 3GPP, "3GPP System to Wireless Local Area Network (WLAN)
interworking; System Description; Release 6; Stage 2",
3GPP Technical Specification 23.234 v 6.6.0, September 2005.
[31] Ericsson, "Security of EAP and SSID based network
advertisements", 3GPP Contribution S3-030736, November 2003.
[32] 3GPP, "Non-Access-Stratum (NAS) functions related to Mobile
Station (MS) in idle mode", 3GPP TS 23.122 6.5.0, October 2005.
[33] Eijk, R., Brok, J., Bemmel, J., and B. Busropan, "Access
Network Selection in a 4G Environment and the Role of Terminal
and Service Platform", 10th WWRF, New York, October 2003.
[34] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking
Architecture between WLAN and 3G Systems", IEEE Communications
Magazine, November 2003.
[35] Intel, "Wireless LAN (WLAN) End to End Guidelines for
Enterprises and Public Hotspot Service Providers",
November 2003.
[36] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b
MAC Layer Handover Time", Laboratory for Communication
Networks, KTH, Royal Institute of Technology, Stockholm,
Sweden, TRITA-IMIT-LCN R 03:02, April 2003.
[37] Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point
Selection", Sigcomm Poster Session 2002.
[38] Eronen, P., "Network Selection Issues", presentation to EAP WG
at IETF 58, November 2003.
[39] Priest, J., "The State of Wireless London", July 2004.
[40] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG
Arkko, et al. Expires November 26, 2006 [Page 28]
Internet-Draft Network Discovery and PS May 2006
Laboratory, Grenoble, France, IEEE Infocom 2003.
[41] Eronen, P. and J. Arkko, "Role of authorization in wireless
network security", Extended abstract presented in the DIMACS
workshop, November 2004.
[42] 3GPP, "3GPP Technical Specification Group Service and System
Aspects; 3G Security; Wireless Local Area Network (WLAN)
interworking security (Release 6); Stage 2", 3GPP Technical
Specification 33.234 v 6.6.0, October 2005.
[43] 3GPP, "3GPP System to Wireless Local Area Network (WLAN)
interworking; User Equipment (UE) to network protocols; Stage 3
(Release 6)", 3GPP Technical Specification 24.234 v 6.4.0,
October 2005.
[44] 3GPP, "3GPP system to Wireless Local Area Network (WLAN)
interworking; Stage 3 (Release 6)", 3GPP Technical
Specification 29.234 v 6.4.0, October 2005.
[45] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim,
"Candidate Access Router Discovery (CARD)", RFC 4066,
July 2005.
Authors' Addresses
Jari Arkko
Ericsson
Jorvas 02420
Finland
Email: jari.arkko@ericsson.com
Bernard Aboba
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
Email: aboba@internaut.com
Arkko, et al. Expires November 26, 2006 [Page 29]
Internet-Draft Network Discovery and PS May 2006
Jouni Korhonen
TeliaSonera
Teollisuuskatu 13
Sonera FIN-00051
Finland
Email: jouni.korhonen@teliasonera.com
Farooq Bari
Cingular Wireless
7277 164th Avenue N.E.
Redmond WA 98052
USA
Email: farooq.bari@cingular.com
Arkko, et al. Expires November 26, 2006 [Page 30]
Internet-Draft Network Discovery and PS May 2006
Appendix A. Contributors
The editors of this document would like to especially acknowledge the
contributions of Farid Adrangi, Farooq Bari, Michael Richardson, Pasi
Eronen, Mark Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck-
Lowe.
Input for the early versions of this draft has been gathered from
many sources, including the above persons as well as 3GPP and IEEE
developments. We would also like to thank Alper Yegin, Victor Lortz,
Stephen Hayes, and David Johnston for comments.
Arkko, et al. Expires November 26, 2006 [Page 31]
Internet-Draft Network Discovery and PS May 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arkko, et al. Expires November 26, 2006 [Page 32]
