Subject: Re: [eap] Proposed Resolution to Issue 376 (Section 2.3)

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 01 Mar 2007 17:10:20 -0800

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 "[email-masked]" 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

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 03 Mar 2007 16:39:13 -0800

>The suggested rewrite is OK by me with only small nit of changing the 
>example.net to example.com.

That's ok.