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 [RFC4282], and the ability of
the AAA
network to route requests to the realm indicated in the
NAI.
Within the past IETF ROAMOPS WG, 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
[RFC2194], static routing mechanisms appeared adequate
for the task
and it was not deemed necessary to develop dynamic
routing protocols.
[BA] Source routing was not a major topic of discussion in
ROAMOPS WG,
although there was a fleeting reference in RFC 2486.
As noted in RFC 2607 [RFC2607], 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.
[BA] The shared secret scaling issue creates a need for a
greater hierarchy
in the roaming relationship path that might not otherwise be
needed.
That element of hierarchy (but not hierarchy that derives
from business
model issues) can be eliminated by Diameter redirect and
DNS-based
lookup functionality. But Diameter's improved routing
functionality
probably won't by itself lead to a dramatic reduction in
roaming path
length.
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.
[BA] Not sure what "know all home network names"
means. Are
you referring to the need for static realm/AAA server
routing tables on
proxies?
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.
[BA] I agree that source routing is not a long-term
solution, but I'm
not sure that Diameter's improved routing capability is
enough to supplant
it. This probably deserves more discussion in this section.
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.
[BA] Right -- but the problems with certificate selection
mirror those
in AAA route selection, so we have just shifted the problem
around, but
we haven't really solved it.
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.
[BA] I think that it is necessary to go into a bit more
detail about
the nature of the problem described in the figure.
Today's AAA protocols do not disseminate realm routing
tables, enabling
upstream AAA proxies to build their own realm routing tables
based on
shortest path first (SPF) or other algorithms. Instead, we
typically
see the edge devices (NAS & local proxy) configured with
a "default"
route. Typically the "default free" zone consists
of core AAA proxies
or AAA servers. This design in many ways mirrors the
architecture of
the Internet, in which only the core routers maintain a
complete routing
table and thus constitute the "default free
zone".
Just as a ping to an unreachable prefix will be forwarded
several hops
before an ICMP error message is returned, Access-Requests
containing
an unreachable NAI in the User-Name attribute will be
forwarded until they
reach the
"default free" zone, where the problem will be
detected by a core AAA
proxy or AAA server. The result will either be silent
discard (not a
good idea, since this will lead to retransmission), sending
of an
Access-Reject or sending an Access-Challenge including an
EAP-Request/Identity with a realm hint based on the realms
included in the "default free" routing table (as
suggested by RFC 4284).
+---------+ +---------+
| | | |
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.
[BA] The ambiguity here is not created by the routes, but by
the
lack of mechanism and policy. The missing mechanism is
dissemination
of realm routes. The missing policy involves filtering and
selection
of realm routes, so as to remove the ambiguities. For
example, if
all realm routes had a metric of 1 in the figure below, then
if
hop count is the metric, then the Access Network would have
two routes
to "a.example.com", each one with a metric of 2.
However, if there
were a polcy stating that routes utilizing Roaming Group 1
were
preferred over those involving Roaming Group 2, then one of
the
routes would be preferred over the other.
+---------+
| |---->
"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
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.
[BA] I think what is being said here is that in the absence
of a
mechanism for route dissemination, filtering and selection,
the
NAS cannot build its own realm routing table; it can only
be
configured with a "default" route.
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 [Eronen04].
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 should
be used
instead of user-based selection where sufficient routes
exist. In an
error situation, such as when an attempt to use the
network-based
routing mechanism has failed, routing hints can be
advertised and
used as defined in [RFC4282] and [RFC4284]. Even so,
such approaches
have severe scalability limitations. See Appendix A.1
for further
discussion
[BA] Suggest rewriting to:
2.3. AAA Routing
Once the identity has been selected, the AAA
infrastructure needs
to route the access request back to the home AAA server.
Typically
the routing is based on the Network Access Identifier
(NAI) defined
in [RFC4282].
Where the NAI does not encode a source route, the routing
of
requests is determined by the AAA infrastructure. As
described in
[RFC2194] most roaming implementations are relatively
simple,
relying on static realm routing table which determine the
next
based on the NAI realm included within the User-Name
attribute.
Within RADIUS, the IP address of the home AAA server is
typically
determined based on static mappings of realms to IP
addresses
maintained within RADIUS proxies.
Diameter [RFC3588] supports mechanisms for intra and
inter-domain
service discovery including support for DNS as well as
service discovery protocols such as SLPv2 [RFC2608]. As a
result,
it may not be necessary to configure static tables
mapping realms
to the IP addresses of Diameter agents. However, while
this
simplifies maintenance of the AAA routing infrastructure,
it does
not necessarily simplify roaming relationship path
selection.
As noted in RFC 2607 [RFC2607], 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
between each AAA client and server.
Diameter [RFC3588] supports certificate-based
authentication
(using either TLS or IPsec) as well as Redirect
functionality,
enabling a Diameter client to obtain obtain a referral to
the
home server from a Diameter redirect server, so that the
client
can contact the home server directly. In situations in
which
a trust model can be established, these Diameter
capabilities can
enable a reduction in the length of the roaming
relationship path.
However, in practice there are a number of pitfalls. In
order
for certificate-based authentication to enable
communication
between a NAS or local proxy and the home AAA server,
trust anchors
need to be configured, and certificates need to be
selected.
The AAA server certificate needs to chain to a trust
anchor
configured on the AAA client, and the AAA client
certificate
needs to chain to a trust anchor configured on the AAA
server. Where multiple potential roaming relationship
paths are
available, this will reflect itself in multiple
certificate choices,
transforming the path selection problem into a
certificate selection
problem. Depending on the functionality supported within
the
certificate selection implementation, this may not
make the problem easier to solve. For example, in order
to provide
the desired control over the roaming path, it may be
necessary to
implement custom certificate selection logic, which may
be difficult
to introduce within a certificate handling implementation
designed
for general purpose usage.
As noted in [RFC4284], it is also possible to utilize an
NAI for
the purposes of source routing. In this case, the client
provides
guidance to the AAA infrastructure as to how it would
like the
access request to be routed. An NAI including source
routing
information is said to be "decorated"; the
decoration format is
defined in [RFC4282].
When decoration is utilized, the EAP peer provides the
decorated
NAI within the EAP-Response/Identity, and as described in
[RFC3579],
the NAS copies the decorated NAI included in the
EAP-Response/Identity
into the User-Name attribute included within the access
request.
As the access request transits the roaming relationship
path,
AAA proxies determine the next hop based on the realm
included
within the User-Name attribute, in the process
successively removing
decoration from the NAI included in the User-Name
attribute.
In contrast, the decorated NAI included within the
EAP-Response/Identity
encapsulated in the access request remains untouched. As
a result,
when the access request arrives at the AAA home server,
the decorated
NAI included in the EAP-Response/Identity may differ from
the NAI
included in the User-Name attribute (which may have some
or all of
the decoration removed). For the purpose of identity
verification,
the EAP server utilizes the NAI in the User-Name
attribute, rather than
the NAI in the EAP-Response/Identity.
Over the long term, it is expected that the need for NAI
"decoration" and source routing will disappear.
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. Prior to the
implementation
of email gateways utilizing MX RR routing, email
address-based
source-routing was used extensively. However, over time
the need
for emamil source-routing disappeared.
2.3.1. The Default Free Zone
AAA clients on the edge of the network, such as NAS
devices and
local AAA proxies, typically maintain a default realm
route,
providing a default next hop for realms not otherwise
taken into
account within the realm routing table. This permits
devices with
limited resources to maintain a small realm routing
table.
Deeper within the AAA infrastructure, AAA proxies may be
maintained
with a "default free" realm table, listing next
hops for all known
realms, but not providing a default realm route.
While dynamic realm routing protocols are not in use
within AAA
infrastructure today, even if such protocols were to be
introduced,
it is likely that they would be deployed solely within
the core
AAA infrastructure, but not on NAS devices, which are
typically
resource contrained.
Since NAS devices do not maintain a full realm routing
table, they
do not have knowledge of all the realms reachable from
the local
network. The situation is analagous to that of Internet
hosts or
edge routers which do not participate in the BGP mesh.
In order
for an Internet host to determine whether it an reach a
destination
on the Internet, it is necessary to send a packet to the
destination.
Similarly, when a user provides an NAI to the NAS, the
NAS does know
apriori whether the realm encoded in the NAI is reachable
or not; it
simply forwards the access request to the next hop on the
roaming
relationship path. Eventually the access request reaches
the
"default free" zone, where a core AAA proxy
determines whether
the realm is reachable or not. As described in
[RFC4284],
where EAP authentication is in use, the core AAA proxy
can send
an Access-Reject, or it can send an Access-Challenge
encapsulating
an EAP-Request/Identity containing realm hints based on
the content
of the "default free" realm routing table.
There are a number of intrinsic problems with this
approach. Where
the "default free" routing table is large, it
may not fit within
a single EAP packet, and the core AAA proxy may not have
a mechanism
for selecting the most promising entries to include.
Even where the
"default free" realm routing table would fit
within a single
EAP-Request/Identity packet, the core AAA router may not
choose to
include all entries, since the list of realm routes could
be
considered confidential information not appropriate for
disclosure
to hosts seeking network access. Therefore it cannot be
assumed that the list of "realm hints" included
within the
EAP-Request/Identity is complete. Given this, a NAS or
local
AAA proxy snooping the EAP-Request/Identity cannot rely
on it to
provide a complete list of reachable realms. The
"realm hint"
mechanism described in [RFC4284] is not a dynamic routing
protocol.
2.3.2. Route Selection and Policy
Along with lack of a dynamic AAA routing protocol,
today's AAA
infrastructure lacks mechanisms for route selection and
policy.
As a result, multiple routes may exist to a destination
realm, without a mechanism for the selection of a
preferred route.
In Figure 3, Roaming Groups 1 and 3 both include a route
to the
realm "a.example.com". However, these realm
routes are not
disseminated to the NAS along with associated metrics,
and
as a result there is no mechanism for implementation of
dynamic
routing policies (such as selection of realm routes by
shortest path,
or preference for routes originating a given proxy).
+---------+
| |---->
"a.example.com"
| Roaming |
+---------+ | Group 1 |
| |----->| Proxy
|----> "b.example.com"
User "joe | Access | +---------+
a.example.com"--->| Provider|
| NAS | +---------+
| |----->|
|----> "a.example.com"
+---------+ | Roaming |
| Group 2 |
| Proxy |---->
"c.example.com"
+---------+
Figure 2: Multiple routes to a destination
realm
In the example in Figure 2, access through Roaming Group
1 may be less
expensive than access through Roaming Group 2, and as a
result
it would be desirable to prefer Roaming Group 1 as a
next
hop for an NAI with a realm of"a.example.com".
However, the
only way to obtain this result would be to manually
configure the
NAS realm routing table with the following entries:
Realm Next Hop
----- --------
b.example.com Roaming Group 1
c.example.com Roaming Group 2
Default Roaming Group 1
While manual configuration may be practical in situations
where
the realm routing table is small and entries are static,
Where the list of supported realms change frequently, or
the preferences
change dynamically, manual configuration will not be
manageable.
2.3.2 Source Routing
Due the limitations of current AAA routing mechanisms,
there are
situations in which better control over AAA routing
behavior is
required. Utilizing NAI-based source routing, a
decorated
NAI can be used to influence the roaming relationship
path.
Since the AAA proxies on the roaming relationship path
are
constrained by existing relationships, NAI-based source
routing
is not source routing in the classic sense; it merely
suggests
preferences among already established realm routes. If a
realm
route does not exist or is not feasible, then NAI-based
source
routing cannot establish it.
While in principle source routing can provide users with
better control over AAA routing decisions, there are a
number
of practical problems to be overcome. In order to
enable
the client to construct optimal source routes, it is
necessary
for it to be provided with a complete and up to date
realm routing table. However, if a solution to this
problem was
readily available, then it could be applied to the AAA
routing
infrastructure, enabling the selection of routes without
the need for user intervention.
As noted in [Eronen04], only a limited number of
parameters can
be updated dynamically. For example, quality of service
or
pricing information typically will be pre-provisioned or
made
available on the web rather than being updated on a
continuous
basis. Where realm names are communicated dynamically,
the "default free" realm list is unlikely to be
provided in full
since this table could be quite large. Given the
constraints on
the availability of information, the construction of
source routes typically needs to occur in the face of
incomplete
knowledge.
In addition, there are few mechanisms available to audit
whether
the requested source route is honored by the AAA
infrastructure.
For example, an access network could advertise a realm
route to
costsless.example.net, while instead routing the
access-request
through costsmore.example.net. While the decorated NAI
would
be made available to the home AAA server in the
EAP-Response/Identity,
the home AAA server might have a difficult time verifying
that the
source route requested in the decorated NAI was actually
honored
by the AAA infrastructure. Similarly, it could be
difficult to
determine whether QoS or other routing requests were
actually
provided as requested. To some extent, this problem may
be
addressed as part of the business arrangements between
roaming
partners, which may provide minimum service level
guarantees.
Given the potential issues with source routing,
conventional
AAA routing mechanisms are to be preferred wherever
possible.
Where an error is encountered, such as an attempt to
authenticate
to an unreachable realm, "realm hints" can be
provided as
described [RFC4284]. However, this approach has severe
scalability limitations, as outlined in Appendix A.1.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
