eap Mailing List: Re: Proposed Resolution to Issue 376 (Section 2.3)

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 [at] 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.

Re: Proposed Resolution to Issue 376 (Section 2.3)	<– Date –> <– Thread –>
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Thu, 1 Mar 2007 17:10:26 -0800 (PST)

eap Mailing List
View Index by: Date - Thread - Author