eap Mailing List: Issue 378: Network Selection Comments

[Bernard Aboba (bernard_aboba]

Issue 378: NetSel Comments
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: August 8, 2006
Reference:
Document: NETSEL-04
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1

"  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:"

The second and third sentences are more appropriate for the problem 
definition
section.  In this paragraph you need to set the stage.
Suggest this be changed to:

"  The realm discovery and selection problem affects network access and
  wireless access networks in particular.  Aspects of the problem will
  appear when any of the following situations arises:"

  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.

[BA] I think you need to describe what issue will arise.
For example: "In order to choose between the network attachment points,
it may be helpful to determine which realms are supported and what the
capabilities of those realms are."

  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.

[BA] I think you want to describe the issue that will arise.  For
example: "In this case it may be helpful to provide additional
information to enable the correct credential set to be determined."

Section 1.1

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.

I am confused by this definition of "Realm Selection".  The realm used
in the NAI seems more related to "Identity Selection" as defined in
RFC 4284, rather than selection of the operator/ISP to connect to.
Do you mean "Identity Selection" here, or are we talking about choosing
which operator to connect to?


Section 2.1

         Typically different enrollment methods and organizational 
locations
         within ESSes advertise or respond to different SSIDs.

This does not make sense.  An ESS is compromised of a single SSID.  
Enrollment
methods are properties of the home realm, not the SSID.

Section 2.2

  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.

I think you are trying to say that realm reachability may vary by network.
I'd suggest you change this to:

  "Figure 1 illustrates a situation where the user realm may not be
  reachable from each potential access network.  Access Network 1
  only enables access to the realm "isp.example1.com" whereas
  Access Network 3 enables access to the realm "corp.example2.com"
  whereas Access Network 2 enables access to both realms."

  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.

This is confusing because link layers typically don't provide information
about realm reachability.  Suggest you rewrite to:

  "Where a fixed set of realms are always reachable from a given
  network, access network names can be used to infer realm
  reachability.  For example, IEEE 802.11 Access Points provide
  the SSID, though in some cases the station may not learn
  all the SSIDs supported by the given access point without
  probing for them.  In IKEv2 [14], the identity of the responder
  (typically the security gateway) is provided as a
  part of the IKEv2 exchange.

  To use this information for identity selection, the client has
  to match the access network name with the realm portion of a
  valid client identity.  For example, the client may be configured
  with the network access names that have roaming contracts with
  each of the client's home realms."

Section 2.3

This section lacks coherence.  I think what it needs to do is to provide
a discussion of source routing versus network routing, as well as the
inherent difficulties involved in determining realm reachability.

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.

Where is the rest of this section?


Section 2.4

I was expecting a discussion of the "Payload Routing" problem here, based
on the list of problems described in Section 2.  I think this section 
belongs
in a new section (a replacement section 3?)

Section 2.5

I was expecting a discussion of the "realm capability discovery" problem 
here.
This is quite an important problem, because realm capabilities can change at
any time and a NAS cannot know what they are before completing a AAA 
exchange
to determine them.

I think this material belongs in a new section (also in a replacement 
section 3?)

Section 2.6

I think you need to add a section on scalability issues.  For example, there 
is the issue of whether reachable realms are advertised to the client as in 
RFC 4284 or whether they are only furnished on request, as suggested by Glen 
Zorn.

Section 3

I would recommend moving all of Section 3-3.4 to an Appendix.

Also, terms such as "network discovery process", "network selection" and
"access network selection" are used repeatedly in this section without
being defined.

Section 3.2

"although if SSIDs are used, the maximum length of 32 octets per SSId may
provide somewhat better scaling."

Not sure I understand the point here; RFC 4284 does not support
SSID advertisements, only realm advertisements.

Section 3.3

The current network advertisement and selection is based in [12].

Do you mean [13] here?  RFC 4282 doesn't define network advertisement or
selection.

  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.

Suggest changing to the following:

  Furthermore, the station may manually trigger the network
  advertisement by using Alternative NAI in the EAP-Response/Identity.  The
  Alternative NAI is guaranteed to be an unknown NAI realm throughout
  all 3GPP networks.

4.1

"such as link-state AAA" -> "such as AAA"  (might or might not be a protocol
based on link-state advertisements)

5

     For example,
     IEEE 802.1ab enables network devices to announce themselves and
     provide information on their capabilities.

Not sure why this is any better than EAP identity selection since 802.1AB
only is accessible after authentication has completed.